From report at bugs.python.org  Tue Dec  1 00:26:09 2020
From: report at bugs.python.org (Clint Allen)
Date: Tue, 01 Dec 2020 05:26:09 +0000
Subject: [issue34079] Multiprocessing module fails to build on Solaris 11.3
In-Reply-To: <1531209271.96.0.56676864532.issue34079@psf.upfronthosting.co.za>
Message-ID: <1606800369.74.0.910381515017.issue34079@roundup.psfhosted.org>


Clint Allen <clint.allen at ni.com> added the comment:

I don't see anything further needed with this issue.  Closing it is fine with me.

----------
status: pending -> open

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

From report at bugs.python.org  Tue Dec  1 01:26:29 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 01 Dec 2020 06:26:29 +0000
Subject: [issue34079] Multiprocessing module fails to build on Solaris 11.3
In-Reply-To: <1531209271.96.0.56676864532.issue34079@psf.upfronthosting.co.za>
Message-ID: <1606803989.21.0.309642169136.issue34079@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Dec  1 01:37:14 2020
From: report at bugs.python.org (Kshitish)
Date: Tue, 01 Dec 2020 06:37:14 +0000
Subject: [issue42518] Error Message
Message-ID: <1606804634.41.0.958530528001.issue42518@roundup.psfhosted.org>


New submission from Kshitish <nishantgautam930 at gmail.com>:

print (5 + 2 == 7 and 10 <= 1232 and 100 ^ 1000 >= 128) # Incorrect 

  Output: True

This argument should be false but it prints true. This is the logical error vulnerability. Try this code in another language too. You find out they print false because the argument is false but unfortunately Python prints true. Because Python does not understand this.

----------
components: Windows
files: main.py
messages: 382216
nosy: blue555, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Error Message
versions: Python 3.8
Added file: https://bugs.python.org/file49640/main.py

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

From report at bugs.python.org  Tue Dec  1 02:11:03 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 01 Dec 2020 07:11:03 +0000
Subject: [issue42518] Error Message
In-Reply-To: <1606804634.41.0.958530528001.issue42518@roundup.psfhosted.org>
Message-ID: <1606806663.59.0.0679390403074.issue42518@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

This appears to be similar to issue42488, which it looks like you also reported, with a different account.

It's not clear to me why you expect the output to be False. But in any event, this is not a bug in Python.

>>> 100 ^ 1000
908

Please do not create issues on the bug tracker without doing some research. You're wasting volunteer's time.

----------
nosy: +eric.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Dec  1 02:48:47 2020
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 01 Dec 2020 07:48:47 +0000
Subject: [issue42518] Error Message
In-Reply-To: <1606804634.41.0.958530528001.issue42518@roundup.psfhosted.org>
Message-ID: <1606808927.84.0.274768449788.issue42518@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
type:  -> behavior

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

From report at bugs.python.org  Tue Dec  1 02:49:13 2020
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 01 Dec 2020 07:49:13 +0000
Subject: [issue42518] Error Message
In-Reply-To: <1606804634.41.0.958530528001.issue42518@roundup.psfhosted.org>
Message-ID: <1606808953.65.0.498887788002.issue42518@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
components:  -Windows

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

From report at bugs.python.org  Tue Dec  1 03:20:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Dec 2020 08:20:57 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1606810857.86.0.728617740208.issue31904@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b2d0c66e881301ed8908da3cb41bbf253c449b0c by pxinwr in branch 'master':
bpo-31904: Fix fifo test cases for VxWorks (GH-20254)
https://github.com/python/cpython/commit/b2d0c66e881301ed8908da3cb41bbf253c449b0c


----------

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

From report at bugs.python.org  Tue Dec  1 03:21:25 2020
From: report at bugs.python.org (Julien Palard)
Date: Tue, 01 Dec 2020 08:21:25 +0000
Subject: [issue42238] Deprecate suspicious.py?
In-Reply-To: <1604274563.95.0.828690163802.issue42238@roundup.psfhosted.org>
Message-ID: <1606810885.62.0.472419955824.issue42238@roundup.psfhosted.org>


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

I'll try to track this closely, the drop of `make suspicious` has been merged in master, but not backported yet, one week ago.

Up to today, no commit has introduced suspicious warnings (0 false positive, 0 false negative).

I think I'll soon backport the PR, if no one objects, because the current situation is a bit risky: some PR could get merged to master but fail the tests during the backport.

----------

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

From report at bugs.python.org  Tue Dec  1 03:55:35 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Dec 2020 08:55:35 +0000
Subject: [issue42519] [C API] Upgrade the C API in extension modules
Message-ID: <1606812935.61.0.224275559553.issue42519@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Python has around 118 extension modules. Most of them are quite old and still use the old way to write C extensions. I created this issue as a placeholder to modernize the code using my new tool:
https://github.com/pythoncapi/upgrade_pythoncapi

For example, replace PyMem_MALLOC() with PyMem_Malloc(), since PyMem_MALLOC() is a deprecated alias.

----------
components: C API
messages: 382220
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] Upgrade the C API in extension modules
versions: Python 3.10

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

From report at bugs.python.org  Tue Dec  1 03:55:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Dec 2020 08:55:47 +0000
Subject: [issue42519] [C API] Upgrade the C API in extension modules
In-Reply-To: <1606812935.61.0.224275559553.issue42519@roundup.psfhosted.org>
Message-ID: <1606812947.92.0.669006916356.issue42519@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +22460
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23586

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

From report at bugs.python.org  Tue Dec  1 03:57:02 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Dec 2020 08:57:02 +0000
Subject: [issue42519] [C API] Upgrade the C API in extension modules
In-Reply-To: <1606812935.61.0.224275559553.issue42519@roundup.psfhosted.org>
Message-ID: <1606813022.33.0.506546575185.issue42519@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 00d7abd7ef588fc4ff0571c8579ab4aba8ada1c0 by Victor Stinner in branch 'master':
bpo-42519: Replace PyMem_MALLOC() with PyMem_Malloc() (GH-23586)
https://github.com/python/cpython/commit/00d7abd7ef588fc4ff0571c8579ab4aba8ada1c0


----------

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

From report at bugs.python.org  Tue Dec  1 04:06:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Dec 2020 09:06:15 +0000
Subject: [issue42519] [C API] Upgrade the C API in extension modules
In-Reply-To: <1606812935.61.0.224275559553.issue42519@roundup.psfhosted.org>
Message-ID: <1606813575.53.0.859581310259.issue42519@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22461
pull_request: https://github.com/python/cpython/pull/23587

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

From report at bugs.python.org  Tue Dec  1 04:18:30 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 01 Dec 2020 09:18:30 +0000
Subject: [issue24506] make fails with gcc 4.9 due to fatal warning of unused
 variable and empty macro in Parser/pgen.c
In-Reply-To: <1435183984.12.0.342400171116.issue24506@psf.upfronthosting.co.za>
Message-ID: <1606814310.83.0.898389285878.issue24506@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

This macro is no longer in the codebase.

----------
nosy: +iritkatriel
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Dec  1 04:21:59 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 01 Dec 2020 09:21:59 +0000
Subject: [issue23946] Invalid timestamps reported by os.stat() when Windows
 FILETIME structures are mistakenly reset.
In-Reply-To: <1429012619.96.0.846306201826.issue23946@psf.upfronthosting.co.za>
Message-ID: <1606814519.2.0.483226340452.issue23946@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

The code of posixmodule.c looks very different now. It this issue still relevant?

----------
nosy: +iritkatriel
status: open -> pending

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

From report at bugs.python.org  Tue Dec  1 04:37:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Dec 2020 09:37:47 +0000
Subject: [issue42519] [C API] Upgrade the C API in extension modules
In-Reply-To: <1606812935.61.0.224275559553.issue42519@roundup.psfhosted.org>
Message-ID: <1606815467.44.0.668577869427.issue42519@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 32bd68c839adb7b42af12366ab0892303115d1d1 by Victor Stinner in branch 'master':
bpo-42519: Replace PyObject_MALLOC() with PyObject_Malloc() (GH-23587)
https://github.com/python/cpython/commit/32bd68c839adb7b42af12366ab0892303115d1d1


----------

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

From report at bugs.python.org  Tue Dec  1 04:44:41 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 01 Dec 2020 09:44:41 +0000
Subject: [issue24429] msvcrt error when embedded
In-Reply-To: <1434020370.09.0.0614095337988.issue24429@psf.upfronthosting.co.za>
Message-ID: <1606815881.53.0.680330015192.issue24429@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

This is a python 2.7-only issue.

----------
nosy: +iritkatriel
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Dec  1 04:56:48 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 01 Dec 2020 09:56:48 +0000
Subject: [issue21195] None float format: incomplete documentation
In-Reply-To: <1397132375.36.0.349385981395.issue21195@psf.upfronthosting.co.za>
Message-ID: <1606816608.95.0.910145840494.issue21195@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

Python 2.7-only issue.

----------
nosy: +iritkatriel
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Dec  1 05:01:43 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 01 Dec 2020 10:01:43 +0000
Subject: [issue15104] Unclear language in __main__ description
In-Reply-To: <1340092965.02.0.675870286607.issue15104@psf.upfronthosting.co.za>
Message-ID: <1606816903.11.0.719103387478.issue15104@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

Fixed for Python 3, too late for Python 2.

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

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

From report at bugs.python.org  Tue Dec  1 05:02:39 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 01 Dec 2020 10:02:39 +0000
Subject: [issue42508] macOS IDLE with Tk 8.6.10 in 3.9.1rc1 universal2
 installer fails smoke test
In-Reply-To: <1606706274.22.0.163331071262.issue42508@roundup.psfhosted.org>
Message-ID: <1606816959.87.0.288058299541.issue42508@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage:  -> patch review

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

From report at bugs.python.org  Tue Dec  1 05:03:32 2020
From: report at bugs.python.org (Antony Lee)
Date: Tue, 01 Dec 2020 10:03:32 +0000
Subject: [issue42520] add_dll_directory only accepts absolute paths
Message-ID: <1606817012.16.0.476843949209.issue42520@roundup.psfhosted.org>


New submission from Antony Lee <anntzer.lee at gmail.com>:

os.add_dll_directory appears to only accept absolute paths, inheriting this restriction from AddDllDirectory.  That's absolutely fine, but could perhaps be mentioned in the docs (https://docs.python.org/3/library/os.html#os.add_dll_directory), especially considering that the docs do mention the parallel with `sys.path`, which *does* support relative paths.

----------
assignee: docs at python
components: Documentation
messages: 382228
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: add_dll_directory only accepts absolute paths
versions: Python 3.9

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

From report at bugs.python.org  Tue Dec  1 05:30:55 2020
From: report at bugs.python.org (Sara Kelley)
Date: Tue, 01 Dec 2020 10:30:55 +0000
Subject: [issue31990] Pickling deadlocks in thread with python -m
In-Reply-To: <1510222459.1.0.213398074469.issue31990@psf.upfronthosting.co.za>
Message-ID: <1606818655.19.0.839963897773.issue31990@roundup.psfhosted.org>


Sara Kelley <serakeri at gmail.com> added the comment:

>python3 -m testqueuepickle3.py
>It hangs.

I see this hang too.

If you only specify the module name it does not hang.
python3 -m testqueuepickle3

----------
nosy: +serakeri

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

From report at bugs.python.org  Tue Dec  1 05:41:25 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 01 Dec 2020 10:41:25 +0000
Subject: [issue22376] urllib2.urlopen().read().splitlines() opening a
 directory in a FTP server randomly returns incorrect result
In-Reply-To: <1410299620.11.0.341288273378.issue22376@psf.upfronthosting.co.za>
Message-ID: <1606819285.85.0.305658431835.issue22376@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

2.7 backport is no longer possible.

----------
nosy: +iritkatriel
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Dec  1 05:51:45 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 01 Dec 2020 10:51:45 +0000
Subject: [issue19570] distutils' Command.ensure_dirname fails on Unicode
In-Reply-To: <1384348317.37.0.567121673163.issue19570@psf.upfronthosting.co.za>
Message-ID: <1606819905.14.0.972099971501.issue19570@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

Python 2-only issue.

----------
nosy: +iritkatriel
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Dec  1 05:53:20 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 01 Dec 2020 10:53:20 +0000
Subject: [issue22455] idna/punycode give wrong results on narrow builds
In-Reply-To: <1411337375.42.0.97875155095.issue22455@psf.upfronthosting.co.za>
Message-ID: <1606820000.37.0.103690572817.issue22455@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Dec  1 05:53:50 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 01 Dec 2020 10:53:50 +0000
Subject: [issue17852] Built-in module _io can lose data from buffered files in
 reference cycles
In-Reply-To: <1367048010.96.0.3580561262.issue17852@psf.upfronthosting.co.za>
Message-ID: <1606820030.5.0.546311357625.issue17852@roundup.psfhosted.org>


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


New changeset 4a44f53aa85c9400471ab084bc8fd8169065fc41 by Miss Islington (bot) in branch '3.9':
[3.9] bpo-17852: Doc: Fix the tutorial about closing files (GH-23135) (GH-23527)
https://github.com/python/cpython/commit/4a44f53aa85c9400471ab084bc8fd8169065fc41


----------

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

From report at bugs.python.org  Tue Dec  1 06:00:24 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 01 Dec 2020 11:00:24 +0000
Subject: [issue22187] commands.mkarg() buggy in East Asian locales
In-Reply-To: <1407867185.09.0.871560290901.issue22187@psf.upfronthosting.co.za>
Message-ID: <1606820424.85.0.94004686532.issue22187@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

Python 2 only issue.

----------
nosy: +iritkatriel
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Dec  1 06:05:45 2020
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 01 Dec 2020 11:05:45 +0000
Subject: [issue41837] Upgrade installers to OpenSSL 1.1.1h
In-Reply-To: <1600822748.89.0.850484234677.issue41837@roundup.psfhosted.org>
Message-ID: <1606820745.44.0.91299963265.issue41837@roundup.psfhosted.org>


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

You may want to hold off until next week:

https://mta.openssl.org/pipermail/openssl-announce/2020-December/000186.html

OpenSSL 1.1.i is a security-fix release. The highest severity issue fixed in this release is HIGH.

----------

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

From report at bugs.python.org  Tue Dec  1 06:11:35 2020
From: report at bugs.python.org (Kshitish)
Date: Tue, 01 Dec 2020 11:11:35 +0000
Subject: [issue42518] Error Message
In-Reply-To: <1606804634.41.0.958530528001.issue42518@roundup.psfhosted.org>
Message-ID: <1606821095.03.0.881677602315.issue42518@roundup.psfhosted.org>


Kshitish <nishantgautam930 at gmail.com> added the comment:

Please do not talk like behave properly. I know here I am wrong but it is not way to talk to some one like that. I respect your knowledge but maintain your language. Okay! 

I send you new file with full research. Please check it out and thank you

----------
resolution: not a bug -> 
status: closed -> open
type: behavior -> security
Added file: https://bugs.python.org/file49641/main.py

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

From report at bugs.python.org  Tue Dec  1 06:15:39 2020
From: report at bugs.python.org (anthony shaw)
Date: Tue, 01 Dec 2020 11:15:39 +0000
Subject: [issue42521] Debug (-d) mode not working in 3.9
Message-ID: <1606821339.69.0.708367922333.issue42521@roundup.psfhosted.org>


New submission from anthony shaw <anthony.p.shaw at gmail.com>:

I noticed since the new parser implementation, the debug mode in the tokeniser is no longer working.

This is the case for 3.9.0 and also 3.9.1rc1. Running python3.9 with a simple application like this:

 # Demo application
 def my_function():
   proceed

Does not output anything

> python3.9 -d ~/PycharmProjects/cpython-book-samples/13/test_tokens.py

> 
Produces no output

Whereas python3.10 (the latest alpha) outputs the expected results

----------
messages: 382236
nosy: anthony shaw, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: Debug (-d) mode not working in 3.9
versions: Python 3.9

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

From report at bugs.python.org  Tue Dec  1 06:19:16 2020
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 01 Dec 2020 11:19:16 +0000
Subject: [issue42518] Error Message
In-Reply-To: <1606804634.41.0.958530528001.issue42518@roundup.psfhosted.org>
Message-ID: <1606821556.61.0.799886596771.issue42518@roundup.psfhosted.org>


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


----------
resolution:  -> not a bug
status: open -> closed
type: security -> behavior

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

From report at bugs.python.org  Tue Dec  1 06:21:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Dec 2020 11:21:37 +0000
Subject: [issue42522] [C API] Add Py_Borrow() function: call Py_XDECREF() and
 return the object
Message-ID: <1606821697.29.0.99350380249.issue42522@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

I'm working on a script to migrate old C extension modules to the latest flavor of the Python C API:
https://github.com/pythoncapi/upgrade_pythoncapi

I would like to replace frame->f_code with PyFrame_GetCode(frame). The problem is that frame->f_code is a borrowed reference, whereas PyFrame_GetCode() returns a strong reference. Having a Py_Borrow() function would help to automate migration to PyFrame_GetCode():

static inline PyObject* Py_Borrow(PyObject *obj)
{
    Py_XDECREF(obj);
    return obj;
}

So frame->f_code can be replaced with Py_Borrow(PyFrame_GetCode(frame)).

Py_Borrow() is similar to Py_XDECREF() but can be used as an expression:

    PyObject *code = Py_Borrow(PyFrame_GetCode(frame));

Py_Borrow() is the opposite of Py_XNewRef(). For example, Py_Borrow(Py_XNewRef(obj)) leaves the reference count unchanged (+1 and then -1).


My pratical problem is that it's not easy not add Py_XDECREF() call when converting C code to the new C API.

Example 1:

    PyObject *code = frame->f_code;

This one is easy and can be written as:

    PyObject *code = PyFrame_GetCode(frame); Py_XDECREF(code);


Example 2:

    func(frame->f_code);

This one is more tricky. For example, the following code using a macro is wrong:

    #define Py_BORROW(obj) (Py_XDECREF(obj), obj)
    func(Py_BORROW(PyFrame_GetCode(frame->f_code)));

since it calls PyFrame_GetCode() twice when proceed by the C preprocessor and so leaks a reference:

    func(Py_XDECREF(PyFrame_GetCode(frame->f_code)), PyFrame_GetCode(frame->f_code));


Attached PR implements Py_Borrow() function as a static inline function.

----------
components: C API
messages: 382237
nosy: vstinner
priority: normal
severity: normal
status: open
title: [C API] Add Py_Borrow() function: call Py_XDECREF() and return the object
versions: Python 3.10

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

From report at bugs.python.org  Tue Dec  1 06:23:19 2020
From: report at bugs.python.org (hai shi)
Date: Tue, 01 Dec 2020 11:23:19 +0000
Subject: [issue41626] port shebang of tools from python2 to python3
In-Reply-To: <1598286525.38.0.443257169426.issue41626@roundup.psfhosted.org>
Message-ID: <1606821799.26.0.0973741555041.issue41626@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

I create PR23581 to remove the inner Tools' shebang.

But I am not remove Tools/ssl/make_ssl_data.py, Tools/gdb/libpython.py in PR23581.
* To make_ssl_data.py, I guess Christian may give us some guide.
* libpython.py will be installed in kinds of OS, some OS will use or maintain python2.7 for a long times. so I perfer like to keep it.

----------

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

From report at bugs.python.org  Tue Dec  1 06:24:10 2020
From: report at bugs.python.org (hai shi)
Date: Tue, 01 Dec 2020 11:24:10 +0000
Subject: [issue41626] port shebang of tools from python2 to python3
In-Reply-To: <1598286525.38.0.443257169426.issue41626@roundup.psfhosted.org>
Message-ID: <1606821850.01.0.991891080027.issue41626@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


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

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

From report at bugs.python.org  Tue Dec  1 06:29:15 2020
From: report at bugs.python.org (hai shi)
Date: Tue, 01 Dec 2020 11:29:15 +0000
Subject: [issue42522] [C API] Add Py_Borrow() function: call Py_XDECREF() and
 return the object
In-Reply-To: <1606821697.29.0.99350380249.issue42522@roundup.psfhosted.org>
Message-ID: <1606822155.82.0.70189857186.issue42522@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
nosy: +shihai1991

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

From report at bugs.python.org  Tue Dec  1 06:30:08 2020
From: report at bugs.python.org (hai shi)
Date: Tue, 01 Dec 2020 11:30:08 +0000
Subject: [issue42519] [C API] Upgrade the C API in extension modules
In-Reply-To: <1606812935.61.0.224275559553.issue42519@roundup.psfhosted.org>
Message-ID: <1606822208.62.0.242296190492.issue42519@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
nosy: +shihai1991

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

From report at bugs.python.org  Tue Dec  1 06:30:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Dec 2020 11:30:34 +0000
Subject: [issue42522] [C API] Add Py_Borrow() function: call Py_XDECREF() and
 return the object
In-Reply-To: <1606821697.29.0.99350380249.issue42522@roundup.psfhosted.org>
Message-ID: <1606822234.36.0.698365333756.issue42522@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +22462
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23591

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

From report at bugs.python.org  Tue Dec  1 06:35:56 2020
From: report at bugs.python.org (Werner Smidt)
Date: Tue, 01 Dec 2020 11:35:56 +0000
Subject: [issue31990] Pickling deadlocks in thread with python -m
In-Reply-To: <1510222459.1.0.213398074469.issue31990@psf.upfronthosting.co.za>
Message-ID: <1606822556.43.0.0819593057209.issue31990@roundup.psfhosted.org>


Werner Smidt <werner.smidt at gmail.com> added the comment:

Sorry for being lacking in providing some OS info.  b

Opensuse Tumbleweed, Linux kernel 5.8.10-1, Intel system

I cannot explain why, but relating to Sara's answer, if you remove the .join() statements at the end, you get the following exception:

/usr/bin/python3: Error while finding module specification for 'testqueuepickle3.py' (ModuleNotFoundError: __path__ attribute not found on 'testqueuepickle3' while trying to find 'testqueuepickle3.py')
mynamedtuple(param1='INSIDE thread', param2='namedtuple')


So I guess that it gets stuck after an exception is thrown?  If I call it Sara's way, there is no exception thrown. 

Sorry, I know this is a very specific case, but I thank you both for taking the time to contribute :-)

----------

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

From report at bugs.python.org  Tue Dec  1 06:38:18 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 01 Dec 2020 11:38:18 +0000
Subject: [issue17454] ld_so_aix not used when linking c++ (scipy)
In-Reply-To: <1363595248.19.0.716647347764.issue17454@psf.upfronthosting.co.za>
Message-ID: <1606822698.62.0.883230703798.issue17454@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


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

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

From report at bugs.python.org  Tue Dec  1 06:43:44 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 01 Dec 2020 11:43:44 +0000
Subject: [issue4724] setting f_exc_traceback aborts in debug builds
In-Reply-To: <1229966419.5.0.164799717047.issue4724@psf.upfronthosting.co.za>
Message-ID: <1606823024.38.0.425412076921.issue4724@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

2.7-only issue.

----------
nosy: +iritkatriel
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue Dec  1 06:51:42 2020
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 01 Dec 2020 11:51:42 +0000
Subject: [issue41626] port shebang of tools from python2 to python3
In-Reply-To: <1598286525.38.0.443257169426.issue41626@roundup.psfhosted.org>
Message-ID: <1606823502.06.0.816918717507.issue41626@roundup.psfhosted.org>


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

make_ssl_data.py is an internal tool that generates internal header files. It's rarely used. The tool is not bound to any Python version, too. Feel free to change the shebang or leave it as it is. I don't care.

----------

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

From report at bugs.python.org  Tue Dec  1 07:01:30 2020
From: report at bugs.python.org (Kshitish)
Date: Tue, 01 Dec 2020 12:01:30 +0000
Subject: [issue42518] Error Message
In-Reply-To: <1606804634.41.0.958530528001.issue42518@roundup.psfhosted.org>
Message-ID: <1606824090.55.0.295229019815.issue42518@roundup.psfhosted.org>


Kshitish <nishantgautam930 at gmail.com> added the comment:

Look tell why you close this
 

In the argument:
print (5 + 2 == 7 and 10 <= 1232 != 10 ^ 100 <= 100)

10 <= 1232 != 10 ^ 100 <= 100

10 <= 1232 is true
10 ^ 100 <= 100 is false

These two argument compares by != 
So, this statement must be true. 

Overall: print (5 + 2 == 7 and 10 <= 1232 != 10 ^ 100 <= 100)

This is the argument is true but is print false.

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

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

From report at bugs.python.org  Tue Dec  1 07:01:36 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 01 Dec 2020 12:01:36 +0000
Subject: [issue42522] [C API] Add Py_Borrow() function: call Py_XDECREF() and
 return the object
In-Reply-To: <1606821697.29.0.99350380249.issue42522@roundup.psfhosted.org>
Message-ID: <1606824096.25.0.362525199025.issue42522@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'm -1 on adding this API as it is inherently unsafe and is bound to be used in locations where its contract is not honoured (especially outside of the core). 

Note that the pre-condition on the argument is that you now only own a reference to the object, but that there's also someone else that owns a reference.

It is better to bite the bullet and go for correct reference count updates when converting to the new PyFrame_GetCode API.

----------
nosy: +ronaldoussoren

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

From report at bugs.python.org  Tue Dec  1 07:28:46 2020
From: report at bugs.python.org (Paul Moore)
Date: Tue, 01 Dec 2020 12:28:46 +0000
Subject: [issue42518] Error Message
In-Reply-To: <1606804634.41.0.958530528001.issue42518@roundup.psfhosted.org>
Message-ID: <1606825726.33.0.607921556112.issue42518@roundup.psfhosted.org>


Paul Moore <p.f.moore at gmail.com> added the comment:

You need to learn about chained comparisons in Python. This is not a bug. Please stop reopening it.

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

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

From report at bugs.python.org  Tue Dec  1 07:30:39 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Dec 2020 12:30:39 +0000
Subject: [issue42522] [C API] Add Py_Borrow() function: call Py_XDECREF() and
 return the object
In-Reply-To: <1606821697.29.0.99350380249.issue42522@roundup.psfhosted.org>
Message-ID: <1606825839.97.0.851573126173.issue42522@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Ronald Oussoren: "I'm -1 on adding this API as it is inherently unsafe and is bound to be used in locations where its contract is not honoured (especially outside of the core)."

I'm trying to update old C extensions which already rely on borrowed references.

I expect that only my script will use this function. Developers should not call it directly, but use strong references. I explained it in the function documentation.

Obviously, using strong references is safer, but it's not possible to automate the conversion of borrowed references to strong references. Maybe it's possible on simple functions, but not in the general code (long functions with loops, function calls, goto, etc.).


> Note that the pre-condition on the argument is that you now only own a reference to the object, but that there's also someone else that owns a reference.

Py_Borrow() is unsafe by design and should not be used :-)

Replacing frame->f_code with Py_Borrow(PyFrame_GetCode(frame)) doesn't make the code worse nor better in term of reference counting.


> It is better to bite the bullet and go for correct reference count updates when converting to the new PyFrame_GetCode API.

My goal is to automate conversion to new C API. Using strong references is really challenging and I expect that it would be done manually.

--

Once a code base is updated to use Py_Borrow(), it might become possible to replace automatically some simple patterns to use strong references.

----------

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

From report at bugs.python.org  Tue Dec  1 07:33:56 2020
From: report at bugs.python.org (Numerlor)
Date: Tue, 01 Dec 2020 12:33:56 +0000
Subject: [issue42523] using windows doc incorrectly states version support
Message-ID: <1606826036.29.0.083322027972.issue42523@roundup.psfhosted.org>


New submission from Numerlor <miso1038 at gmail.com>:

In this paragraph, the using windows doc page dynamically adjusts the version to the one that's being looked at by the user, however the statement is no longer true for python 3.9 and above as support for vista/7 was dropped

> As specified in PEP 11, a Python release only supports a Windows 
  platform while Microsoft considers the platform under extended 
  support. This means that Python |version| supports Windows Vista 
  and newer. If you require Windows XP support then please install 
  Python 3.4.

----------
assignee: docs at python
components: Documentation
messages: 382246
nosy: Numerlor, docs at python
priority: normal
severity: normal
status: open
title: using windows doc incorrectly states version support
versions: Python 3.9

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

From report at bugs.python.org  Tue Dec  1 07:38:12 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Dec 2020 12:38:12 +0000
Subject: [issue42522] [C API] Add _Py_Borrow() private function: call
 Py_XDECREF() and return the object
In-Reply-To: <1606821697.29.0.99350380249.issue42522@roundup.psfhosted.org>
Message-ID: <1606826292.17.0.936481131363.issue42522@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

My proposed function doesn't have to be public. I updated the issue and my PR to propose to add a *private* function to clarify that it should not be used unless you understand what you do.

----------
title: [C API] Add Py_Borrow() function: call Py_XDECREF() and return the object -> [C API] Add _Py_Borrow() private function: call Py_XDECREF() and return the object

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

From report at bugs.python.org  Tue Dec  1 07:53:58 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Tue, 01 Dec 2020 12:53:58 +0000
Subject: [issue42521] Debug (-d) mode not working in 3.9
In-Reply-To: <1606821339.69.0.708367922333.issue42521@roundup.psfhosted.org>
Message-ID: <1606827238.74.0.987161017651.issue42521@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

Hi Anthony,

could it be that your 3.9 is not a debug build, while the others are? We only enable parser debug ouput when Python has been build --with-pydebug.

Building the 3.9.0 tag --with-pydebug works fine for me.

----------

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

From report at bugs.python.org  Tue Dec  1 08:20:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Dec 2020 13:20:18 +0000
Subject: [issue42522] [C API] Add _Py_Borrow() private function: call
 Py_XDECREF() and return the object
In-Reply-To: <1606821697.29.0.99350380249.issue42522@roundup.psfhosted.org>
Message-ID: <1606828818.32.0.764304472911.issue42522@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

In the meanwhile, I modified my upgrade_pythoncapi.py tool to include pythoncapi_compat.h, and I added _Py_Borrow() and _Py_XBorrow() to pythoncapi_compat.h:

* https://github.com/pythoncapi/upgrade_pythoncapi
* https://github.com/pythoncapi/pythoncapi_compat

----------

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

From report at bugs.python.org  Tue Dec  1 08:50:46 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 01 Dec 2020 13:50:46 +0000
Subject: [issue42522] [C API] Add _Py_Borrow() private function: call
 Py_XDECREF() and return the object
In-Reply-To: <1606821697.29.0.99350380249.issue42522@roundup.psfhosted.org>
Message-ID: <1606830646.48.0.511063129716.issue42522@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

A private function is less problematic, but still far from ideal. Any use of the function is IMHO a code smell that should be refactored. 

I'm primarily against this function in the public API because it will be used where it isn't appropriate because it looks convenient (such as ``somefuntion(Py_Borrow(PyUnicode_FromUTF8(...)))``).

----------

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

From report at bugs.python.org  Tue Dec  1 09:06:58 2020
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 01 Dec 2020 14:06:58 +0000
Subject: [issue23946] Invalid timestamps reported by os.stat() when Windows
 FILETIME structures are mistakenly reset.
In-Reply-To: <1429012619.96.0.846306201826.issue23946@psf.upfronthosting.co.za>
Message-ID: <1606831618.96.0.438924821381.issue23946@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> The code of posixmodule.c looks very different now.

The conversion code was moved to FILE_TIME_to_time_t_nsec() in Python/fileutils.c. 

time_t is a signed 64-bit integer type, so there's no immediate problem storing 1601-01-01 as the negative (pre-epoch) Unix timestamp -11644473600. But there are indirect problems with using negative Unix timestamps in Windows. In particular, datetime.fromtimestamp doesn't support them:

    >>> datetime.fromtimestamp(-11644473600)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    OSError: [Errno 22] Invalid argument

----------
nosy: +eryksun
status: pending -> open

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

From report at bugs.python.org  Tue Dec  1 09:18:58 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 01 Dec 2020 14:18:58 +0000
Subject: [issue42522] [C API] Add _Py_Borrow() private function: call
 Py_XDECREF() and return the object
In-Reply-To: <1606821697.29.0.99350380249.issue42522@roundup.psfhosted.org>
Message-ID: <1606832338.64.0.495027260752.issue42522@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

BTW. Have you considered using coccinelle <https://coccinelle.gitlabpages.inria.fr/website/> instead of a python script?

I have no experience with the tool, but it is meant to be used for code transformation ("semantic patches").  I only know of the tool because of articles on LWN.net, I haven't tried using it yet.

----------

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

From report at bugs.python.org  Tue Dec  1 09:23:02 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 01 Dec 2020 14:23:02 +0000
Subject: [issue40060] socket.TCP_NOTSENT_LOWAT is missing in official macOS
 builds
In-Reply-To: <1585120826.63.0.863724436073.issue40060@roundup.psfhosted.org>
Message-ID: <1606832582.62.0.457220641279.issue40060@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The work in #441100 is merged into master and 3.9, including an (experimental) "universal2" build of the latter in 3.9.1rc1 that is build with the latest SDK.

I'm therefore closing this issue.

----------
dependencies:  -Support macOS 11 and Apple Silicon Macs
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Tue Dec  1 09:34:13 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Dec 2020 14:34:13 +0000
Subject: [issue42522] [C API] Add _Py_Borrow() private function: call
 Py_XDECREF() and return the object
In-Reply-To: <1606821697.29.0.99350380249.issue42522@roundup.psfhosted.org>
Message-ID: <1606833253.81.0.240823304205.issue42522@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> BTW. Have you considered using coccinelle <https://coccinelle.gitlabpages.inria.fr/website/> instead of a python script?

I wrote Python code just because I like Python. There are likely other more advanced tools like coccinelle, but Python users are more used to install Python scripts and Python is portable.

----------

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

From report at bugs.python.org  Tue Dec  1 09:35:57 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 01 Dec 2020 14:35:57 +0000
Subject: [issue42521] Debug (-d) mode not working in 3.9
In-Reply-To: <1606821339.69.0.708367922333.issue42521@roundup.psfhosted.org>
Message-ID: <1606833357.04.0.426726222433.issue42521@roundup.psfhosted.org>


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

I cannot reproduce it either in 3.9. Building 3.9 in debug mode and using -d works as expected

----------

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

From report at bugs.python.org  Tue Dec  1 09:36:33 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 01 Dec 2020 14:36:33 +0000
Subject: [issue42521] Debug (-d) mode not working in 3.9
In-Reply-To: <1606821339.69.0.708367922333.issue42521@roundup.psfhosted.org>
Message-ID: <1606833393.43.0.642757918631.issue42521@roundup.psfhosted.org>


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

Also, note the -d flag activates the debug mode **in the parser**, not in the tokenizer.

----------

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

From report at bugs.python.org  Tue Dec  1 09:43:56 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 01 Dec 2020 14:43:56 +0000
Subject: [issue42522] [C API] Add _Py_Borrow() private function: call
 Py_XDECREF() and return the object
In-Reply-To: <1606821697.29.0.99350380249.issue42522@roundup.psfhosted.org>
Message-ID: <1606833836.95.0.977086475598.issue42522@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I totally understand, I would have done the same.  Coccinelle looks like an interesting tool for refactorings like this, but I prefer to write Python scripts (and often just refactor manually).

----------

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

From report at bugs.python.org  Tue Dec  1 10:01:31 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Dec 2020 15:01:31 +0000
Subject: [issue37221] PyCode_New API change breaks backwards compatibility
 policy
In-Reply-To: <1560209067.42.0.855519802872.issue37221@roundup.psfhosted.org>
Message-ID: <1606834891.3.0.693459753923.issue37221@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22463
pull_request: https://github.com/python/cpython/pull/23595

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

From report at bugs.python.org  Tue Dec  1 10:10:09 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Dec 2020 15:10:09 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1606835409.31.0.216117013902.issue1635741@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22465
pull_request: https://github.com/python/cpython/pull/23598

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

From report at bugs.python.org  Tue Dec  1 10:10:09 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Dec 2020 15:10:09 +0000
Subject: [issue39947] [C API] Make the PyThreadState structure opaque (move it
 to the internal C API)
In-Reply-To: <1584035214.47.0.672795796186.issue39947@roundup.psfhosted.org>
Message-ID: <1606835409.92.0.568587112098.issue39947@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22467
pull_request: https://github.com/python/cpython/pull/23598

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

From report at bugs.python.org  Tue Dec  1 10:10:09 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Dec 2020 15:10:09 +0000
Subject: [issue37194] Move new vector private declarations to the internal C
 API
In-Reply-To: <1559908440.37.0.746705371355.issue37194@roundup.psfhosted.org>
Message-ID: <1606835409.87.0.664117872982.issue37194@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22466
pull_request: https://github.com/python/cpython/pull/23598

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

From report at bugs.python.org  Tue Dec  1 10:10:09 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Dec 2020 15:10:09 +0000
Subject: [issue40421] [C API] Add getter functions for PyFrameObject and maybe
 move PyFrameObject to the internal C API
In-Reply-To: <1588079870.34.0.984904607646.issue40421@roundup.psfhosted.org>
Message-ID: <1606835409.11.0.151154721241.issue40421@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22464
pull_request: https://github.com/python/cpython/pull/23598

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

From report at bugs.python.org  Tue Dec  1 10:13:18 2020
From: report at bugs.python.org (Romuald Brunet)
Date: Tue, 01 Dec 2020 15:13:18 +0000
Subject: [issue42524] pdb access to return value
Message-ID: <1606835598.54.0.959102851686.issue42524@roundup.psfhosted.org>


New submission from Romuald Brunet <romuald.brunet at gmail.com>:

When using the pdb module, there is currently no way to easy access the current return value of the stack

This return value is accessed by the 'retval command'

I propose using the currently unused argument to allow storing the return value in the local variables, accessible via the debugger

For example:


    def foo():
        debugger()
        return ComplexObject()

    def bar():
        return foo()

(pdb) retval
<ComplexObject instance at 0x1234>
(pdb) retval zz
(pdb) zz.attribute
'some value'

----------
components: Library (Lib)
messages: 382259
nosy: Romuald
priority: normal
severity: normal
status: open
title: pdb access to return value
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Tue Dec  1 10:17:44 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Dec 2020 15:17:44 +0000
Subject: [issue39573] [C API] Make PyObject an opaque structure in the limited
 C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1606835864.75.0.530743963608.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I created the https://github.com/pythoncapi/upgrade_pythoncapi project which updates automatically a C extension to newer C API. For example, it uses Py_TYPE(), Py_SIZE(), Py_REFCNT(), Py_SET_SIZE(), Py_SET_SIZE() and Py_SET_REFCNT() functions.

----------

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

From report at bugs.python.org  Tue Dec  1 10:22:28 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Dec 2020 15:22:28 +0000
Subject: [issue37221] PyCode_New API change breaks backwards compatibility
 policy
In-Reply-To: <1560209067.42.0.855519802872.issue37221@roundup.psfhosted.org>
Message-ID: <1606836148.58.0.201240379034.issue37221@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 1867b462de427bcb8dfbcd256028410aea6ae929 by Victor Stinner in branch 'master':
bpo-37221: PyCode_New() didn't change in Python 3.8 (GH-23595)
https://github.com/python/cpython/commit/1867b462de427bcb8dfbcd256028410aea6ae929


----------

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

From report at bugs.python.org  Tue Dec  1 10:22:43 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 01 Dec 2020 15:22:43 +0000
Subject: [issue37221] PyCode_New API change breaks backwards compatibility
 policy
In-Reply-To: <1560209067.42.0.855519802872.issue37221@roundup.psfhosted.org>
Message-ID: <1606836163.18.0.961798259988.issue37221@roundup.psfhosted.org>


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


----------
nosy: +miss-islington
nosy_count: 9.0 -> 10.0
pull_requests: +22468
pull_request: https://github.com/python/cpython/pull/23599

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

From report at bugs.python.org  Tue Dec  1 10:23:23 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 01 Dec 2020 15:23:23 +0000
Subject: [issue37221] PyCode_New API change breaks backwards compatibility
 policy
In-Reply-To: <1560209067.42.0.855519802872.issue37221@roundup.psfhosted.org>
Message-ID: <1606836203.69.0.617683021356.issue37221@roundup.psfhosted.org>


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


----------
pull_requests: +22469
pull_request: https://github.com/python/cpython/pull/23600

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

From report at bugs.python.org  Tue Dec  1 10:25:02 2020
From: report at bugs.python.org (Romuald Brunet)
Date: Tue, 01 Dec 2020 15:25:02 +0000
Subject: [issue42524] pdb access to return value
In-Reply-To: <1606835598.54.0.959102851686.issue42524@roundup.psfhosted.org>
Message-ID: <1606836302.05.0.88788429398.issue42524@roundup.psfhosted.org>


Change by Romuald Brunet <romuald.brunet at gmail.com>:


----------
keywords: +patch
pull_requests: +22470
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23601

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

From report at bugs.python.org  Tue Dec  1 10:25:13 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 01 Dec 2020 15:25:13 +0000
Subject: [issue19478] Add ability to prefix posix semaphore names created by
 multiprocessing module
In-Reply-To: <1383335608.62.0.190972038385.issue19478@psf.upfronthosting.co.za>
Message-ID: <1606836313.08.0.66308259702.issue19478@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

Fixed in 3.4, won't be fixed in 2.7.

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

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

From report at bugs.python.org  Tue Dec  1 10:30:37 2020
From: report at bugs.python.org (Yurii Karabas)
Date: Tue, 01 Dec 2020 15:30:37 +0000
Subject: [issue42525] Optimize class/module level annotation
Message-ID: <1606836637.51.0.505503737654.issue42525@roundup.psfhosted.org>


New submission from Yurii Karabas <1998uriyyo at gmail.com>:

This issue is inspired by https://bugs.python.org/issue42202

We can do smth similar for class/module level annotations.

Inada Naoki what do you think regarding that?

----------
components: Interpreter Core
messages: 382263
nosy: methane, uriyyo
priority: normal
severity: normal
status: open
title: Optimize class/module level annotation
type: resource usage
versions: Python 3.10

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

From report at bugs.python.org  Tue Dec  1 10:34:11 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 01 Dec 2020 15:34:11 +0000
Subject: [issue37221] PyCode_New API change breaks backwards compatibility
 policy
In-Reply-To: <1560209067.42.0.855519802872.issue37221@roundup.psfhosted.org>
Message-ID: <1606836851.19.0.297973968807.issue37221@roundup.psfhosted.org>


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


New changeset d9d63f13cf5b6b896c245099c42b08f6da083d05 by Miss Islington (bot) in branch '3.8':
bpo-37221: PyCode_New() didn't change in Python 3.8 (GH-23595)
https://github.com/python/cpython/commit/d9d63f13cf5b6b896c245099c42b08f6da083d05


----------

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

From report at bugs.python.org  Tue Dec  1 10:36:26 2020
From: report at bugs.python.org (Andy Lester)
Date: Tue, 01 Dec 2020 15:36:26 +0000
Subject: [issue39573] [C API] Make PyObject an opaque structure in the limited
 C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1606836986.58.0.145983798515.issue39573@roundup.psfhosted.org>


Change by Andy Lester <andy at petdance.com>:


----------
nosy:  -petdance

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

From report at bugs.python.org  Tue Dec  1 10:42:34 2020
From: report at bugs.python.org (Tom)
Date: Tue, 01 Dec 2020 15:42:34 +0000
Subject: [issue42526] Exceptions in asyncio.Server callbacks are not
 retrievable
Message-ID: <1606837354.76.0.196975943835.issue42526@roundup.psfhosted.org>


New submission from Tom <tom at collider.in>:

Consider this program:

    import asyncio

    async def handler(r, w):
        raise RuntimeError

    async def main():
        server = await asyncio.start_server(handler, host='localhost', port=1234)
        r, w = await asyncio.open_connection(host='localhost', port=1234)
        await server.serve_forever()
        server.close()

    asyncio.run(main())

The RuntimeError is not retrievable via the serve_forever coroutine. To my
knowledge, there is no feature of the asyncio API which causes the server to
stop on an exception and retrieve it. I have also tried wrapping serve_forever
in a Task, and waiting on the coro with FIRST_EXCEPTION.

This severely complicates testing asyncio servers, since failing tests hang
forever if the failure occurs in a callback.

It should be possible to configure the server to end if a callback fails, e.g.
by a 'stop_on_error' kwarg to start_server (defaulting to False for
compatibility).

I know this isn't a technical problem, since AnyIO, which uses asyncio, does
this by default. This equivalent program ends after the exception:

    import anyio

    async def handler(client):
        raise RuntimeError

    async def main():
        async with anyio.create_task_group() as tg:
            listener = await anyio.create_tcp_listener(local_host='localhost', local_port=1234)
            await tg.spawn(listener.serve, handler)
            async with await anyio.connect_tcp('localhost', 1234) as client:
                pass

    anyio.run(main)

----------
components: asyncio
messages: 382265
nosy: asvetlov, tmewett, yselivanov
priority: normal
severity: normal
status: open
title: Exceptions in asyncio.Server callbacks are not retrievable
versions: Python 3.7

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

From report at bugs.python.org  Tue Dec  1 10:49:54 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 01 Dec 2020 15:49:54 +0000
Subject: [issue42526] Exceptions in asyncio.Server callbacks are not
 retrievable
In-Reply-To: <1606837354.76.0.196975943835.issue42526@roundup.psfhosted.org>
Message-ID: <1606837794.26.0.318094126767.issue42526@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

This is a deliberate decision.
An exception in handling one client connection should not break another connected client.

----------

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

From report at bugs.python.org  Tue Dec  1 10:55:03 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 01 Dec 2020 15:55:03 +0000
Subject: [issue37221] PyCode_New API change breaks backwards compatibility
 policy
In-Reply-To: <1560209067.42.0.855519802872.issue37221@roundup.psfhosted.org>
Message-ID: <1606838103.36.0.461899676275.issue37221@roundup.psfhosted.org>


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


New changeset ed4614386f210964840daa1f7cbddbbd575f7a49 by Miss Islington (bot) in branch '3.9':
bpo-37221: PyCode_New() didn't change in Python 3.8 (GH-23595)
https://github.com/python/cpython/commit/ed4614386f210964840daa1f7cbddbbd575f7a49


----------

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

From report at bugs.python.org  Tue Dec  1 11:39:36 2020
From: report at bugs.python.org (hai shi)
Date: Tue, 01 Dec 2020 16:39:36 +0000
Subject: [issue15674] PEP 3121, 384 Refactoring applied to _thread module
In-Reply-To: <1345043183.1.0.612175209954.issue15674@psf.upfronthosting.co.za>
Message-ID: <1606840776.82.0.105069088435.issue15674@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
versions: +Python 3.10 -Python 3.4

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

From report at bugs.python.org  Tue Dec  1 11:40:04 2020
From: report at bugs.python.org (Yanfeng Wang)
Date: Tue, 01 Dec 2020 16:40:04 +0000
Subject: [issue42527] UnicodeEncode error in BaseHttpRequestHandler class when
 send unicode data.
Message-ID: <1606840804.64.0.232983390658.issue42527@roundup.psfhosted.org>


New submission from Yanfeng Wang <wangyanfeng.p at gmail.com>:

My environment:
system: MacOS 10.15.x
python: 3.9.0

when I inherit the BaseHTTPRequestHandler class, and call the send_error(error_di, msg) method in my own class's do_GET override function:
the msg argument can't accept unicode string, an UnicodeEncodeError of 'latin-1' encoding error with ordinal call failed of out of range(255).

I tracked the code, and found in the implementation of this class, the data was sent through a encode call with 'latin-1' hard coded in. in the file: server.py near line 507. 
BTW, I tried u'my string'.encode('utf-8'), and it didn't work, another TypeError in module html __init__.py line 19.

If I commented the original hard code 'latin-1' line and replace with the hard code encoding to 'utf-8', all will be fine.
 
Thanks for your read anyone who cares or takes care of this issue.

----------
components: Unicode
messages: 382268
nosy: ezio.melotti, vstinner, wangyanfeng.p
priority: normal
severity: normal
status: open
title: UnicodeEncode error in BaseHttpRequestHandler class when send unicode data.
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Tue Dec  1 11:47:45 2020
From: report at bugs.python.org (Antonio Cuni)
Date: Tue, 01 Dec 2020 16:47:45 +0000
Subject: [issue42528] Improve the docs of most Py*_Check{,Exact} API calls
Message-ID: <1606841265.25.0.130640674128.issue42528@roundup.psfhosted.org>


New submission from Antonio Cuni <anto.cuni at gmail.com>:

I think that none of these API calls can fail, but only few of them are
documented as such. E.g. PyNumber_Check contains the sentece "This function always succeeds" but PyBytes_Check does not.

----------
assignee: docs at python
components: Documentation
messages: 382269
nosy: antocuni, docs at python
priority: normal
severity: normal
status: open
title: Improve the docs of most Py*_Check{,Exact} API calls
type: enhancement

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

From report at bugs.python.org  Tue Dec  1 11:47:52 2020
From: report at bugs.python.org (Christoph Reiter)
Date: Tue, 01 Dec 2020 16:47:52 +0000
Subject: [issue42522] [C API] Add _Py_Borrow() private function: call
 Py_XDECREF() and return the object
In-Reply-To: <1606821697.29.0.99350380249.issue42522@roundup.psfhosted.org>
Message-ID: <1606841272.04.0.463433426789.issue42522@roundup.psfhosted.org>


Christoph Reiter <reiter.christoph at gmail.com> added the comment:

I find it confusing that the function is called Py_Borrow() but steals the reference.

----------
nosy: +lazka

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

From report at bugs.python.org  Tue Dec  1 11:48:55 2020
From: report at bugs.python.org (Antonio Cuni)
Date: Tue, 01 Dec 2020 16:48:55 +0000
Subject: [issue42528] Improve the docs of most Py*_Check{,Exact} API calls
In-Reply-To: <1606841265.25.0.130640674128.issue42528@roundup.psfhosted.org>
Message-ID: <1606841335.57.0.121322533355.issue42528@roundup.psfhosted.org>


Change by Antonio Cuni <anto.cuni at gmail.com>:


----------
keywords: +patch
pull_requests: +22471
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23602

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

From report at bugs.python.org  Tue Dec  1 12:47:12 2020
From: report at bugs.python.org (Bar Harel)
Date: Tue, 01 Dec 2020 17:47:12 +0000
Subject: [issue40800] asyncio.sleep(0) should "yield" back to the event loop, 
 but it doesn't behave as expected
In-Reply-To: <1590644219.7.0.394616254827.issue40800@roundup.psfhosted.org>
Message-ID: <1606844832.05.0.110147128627.issue40800@roundup.psfhosted.org>


Bar Harel <bzvi7919 at gmail.com> added the comment:

It relinquishes control for exactly one event loop cycle.

You'll see that it takes two or three cycles and then gets cancelled correctly.

The reason being is that recovery from your `await asyncio.sleep(1)` takes two or three cycles. (Under the hood, a few `asyncio.call_soon()` are called in a chain and only 1 is executed each cycle).

This is not a bug, but rather intended behavior. You should probably use `asyncio.to_thread()` or preferably run cpu-intensive code on a different process.

@triage Please close as not-a-bug.

----------
nosy: +bar.harel

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

From report at bugs.python.org  Tue Dec  1 12:50:38 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 01 Dec 2020 17:50:38 +0000
Subject: [issue40800] asyncio.sleep(0) should "yield" back to the event loop, 
 but it doesn't behave as expected
In-Reply-To: <1590644219.7.0.394616254827.issue40800@roundup.psfhosted.org>
Message-ID: <1606845038.98.0.0313052157664.issue40800@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Agree, not a bug.

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

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

From report at bugs.python.org  Tue Dec  1 12:51:11 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 01 Dec 2020 17:51:11 +0000
Subject: [issue42525] Optimize class/module level annotation
In-Reply-To: <1606836637.51.0.505503737654.issue42525@roundup.psfhosted.org>
Message-ID: <1606845071.49.0.379882416502.issue42525@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

Would it require a substantial amount of changes? If so, I don't think this is a critical optimization since nearly-all of class definitions happens on the module level and evaluated on the import time only once.

----------
nosy: +BTaskaya

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

From report at bugs.python.org  Tue Dec  1 12:55:06 2020
From: report at bugs.python.org (Tom)
Date: Tue, 01 Dec 2020 17:55:06 +0000
Subject: [issue42526] Exceptions in asyncio.Server callbacks are not
 retrievable
In-Reply-To: <1606837354.76.0.196975943835.issue42526@roundup.psfhosted.org>
Message-ID: <1606845306.16.0.610024670222.issue42526@roundup.psfhosted.org>


Tom <tom at collider.in> added the comment:

How do you suggest one might test code in a Server callback with asyncio?

Of course, I don't want any old exception to affect another client connection,
only an exception which is uncaught up to the handler coro. And I'm not
suggesting that it happen by default, only that it be possible.

With this, the behaviour would perfectly align with the asyncio.gather
functionality, and its 'return_exceptions' kwarg.

----------

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

From report at bugs.python.org  Tue Dec  1 13:03:03 2020
From: report at bugs.python.org (Karl Nelson)
Date: Tue, 01 Dec 2020 18:03:03 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
Message-ID: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>


New submission from Karl Nelson <nelson85 at llnl.gov>:

While trying to use JPype on Windows Python 3.9.0, we are running into an bizarre issue with loading the internal module which is written in C.  When running a python script the first time the internal module loads correctly.  However, the second time that script is run the internal module reports "A dynamic link library (DLL) initialization routine failed."  If you then erase the pyc cache file that is importing the internal module then it works again.  This only occurs on Windows and was not present using the same source prior versions of Python 3.8.

We investigate the byte codes from both version and they are doing the same series of actions so the problem appears to be calling the same opcode to execute an import.

I make sure all required symbols were found in the libraries and only only copy of the internal DLL was the same with and without loading from a pyc.

It may be a change in the requirements of module initialization, but I don't know how to proceed.  There was one deprecation warning but correcting that did not alter the outcome.  

It appears that the execute path for importing a CPython module takes a different path when the script was imported from something compiled on the fly as opposed to loading from a pyc.
 

 ```
 import: 'jpype'
 Traceback (most recent call last):
    File "D:\bld\jpype1_1605785280189\test_tmp\run_test.py", line 2, in <module>
      import jpype
    File "D:\bld\jpype1_1605785280189\_test_env\lib\site-packages\jpype\__init__.py", line 18, in <module>
      import _jpype
 ImportError: DLL load failed while importing _jpype: A dynamic link library (DLL) initialization routine failed.
 ```

----------
components: Windows
messages: 382275
nosy: Thrameos, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: CPython DLL initialization routine failed from PYC cache file
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Tue Dec  1 15:11:49 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 01 Dec 2020 20:11:49 +0000
Subject: [issue42523] using windows doc incorrectly states version support
In-Reply-To: <1606826036.29.0.083322027972.issue42523@roundup.psfhosted.org>
Message-ID: <1606853509.21.0.451897571993.issue42523@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 2.0 -> 3.0
pull_requests: +22472
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23603

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

From report at bugs.python.org  Tue Dec  1 15:35:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Dec 2020 20:35:03 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1606854903.28.0.744629811001.issue31904@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset e483d281bd55be0beee3e62d18e0719175bde671 by pxinwr in branch 'master':
bpo-31904: Fix test_netrc for VxWorks RTOS (GH-21675)
https://github.com/python/cpython/commit/e483d281bd55be0beee3e62d18e0719175bde671


----------

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

From report at bugs.python.org  Tue Dec  1 15:53:30 2020
From: report at bugs.python.org (Steve Dower)
Date: Tue, 01 Dec 2020 20:53:30 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1606856010.9.0.740327003359.issue42529@roundup.psfhosted.org>


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

There really shouldn't be any difference between those two paths, apart from skipping the compile step in the second case.

It sounds like you're pretty well set up for testing, so would you be able to try the test while running under either the Visual Studio debugger (easiest way is to add an "input()" to your code, run to there, then Debug/Attach and press enter to let it continue) or WinDbg if you prefer that? That will give much more information about which DLL is actually failing, and possibly why.

----------

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

From report at bugs.python.org  Tue Dec  1 15:59:25 2020
From: report at bugs.python.org (Tom Middleton)
Date: Tue, 01 Dec 2020 20:59:25 +0000
Subject: [issue32830] tkinter documentation suggests "from tkinter import *", 
 contradicting PEP8
In-Reply-To: <1518439905.14.0.467229070634.issue32830@psf.upfronthosting.co.za>
Message-ID: <1606856365.25.0.718967816843.issue32830@roundup.psfhosted.org>


Tom Middleton <busfault at gmail.com> added the comment:

While I agree that it shouldn't be imposed on changing previous code, changing the documentation isn't changing the previous code it is encouraging future code. I think that the documentation should have a caveat. I'm seeing a lot of new code using tkinter with glob import which is obviously from the documentation as it suggests doing so. I think that the glob import practice should be overall discouraged. I think adding a disclaimer in the documentation at the reference to `from tkinter import *` would be sufficient. A reference to PEP8 would be good. I'd imagine that most people look up docs and are not as familiar with PEP.
Why can't something like that be added to the documentation?

----------
nosy: +busfault

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

From report at bugs.python.org  Tue Dec  1 17:09:13 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Dec 2020 22:09:13 +0000
Subject: [issue42528] Improve the docs of most Py*_Check{,Exact} API calls
In-Reply-To: <1606841265.25.0.130640674128.issue42528@roundup.psfhosted.org>
Message-ID: <1606860553.11.0.0629031482308.issue42528@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


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

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

From report at bugs.python.org  Tue Dec  1 17:29:09 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 01 Dec 2020 22:29:09 +0000
Subject: [issue10486] http.server doesn't set all CGI environment variables
In-Reply-To: <1290325295.78.0.545647251788.issue10486@psf.upfronthosting.co.za>
Message-ID: <1606861749.02.0.849572639103.issue10486@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
keywords: +patch
pull_requests: +22473
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/23604

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

From report at bugs.python.org  Tue Dec  1 17:33:47 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 01 Dec 2020 22:33:47 +0000
Subject: [issue42526] Exceptions in asyncio.Server callbacks are not
 retrievable
In-Reply-To: <1606837354.76.0.196975943835.issue42526@roundup.psfhosted.org>
Message-ID: <1606862027.63.0.679839757427.issue42526@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

You can use try/except in handler() and dispatch the exception whatever you want.
It doesn't require a new asyncio version, debug-only flag, etc.

----------

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

From report at bugs.python.org  Tue Dec  1 17:40:05 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 01 Dec 2020 22:40:05 +0000
Subject: [issue10486] http.server doesn't set all CGI environment variables
In-Reply-To: <1290325295.78.0.545647251788.issue10486@psf.upfronthosting.co.za>
Message-ID: <1606862405.36.0.997343301342.issue10486@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:

I spent some time reviewing and researching the specification. It also says

   The server is not required to create meta-variables for all the
   header fields that it receives.  

And this in issue, open since 2010, we have issue two different set of variables one from Apache and from Nginx. So, it Is not certain if http.server should be alinged it any or all, and plus if anything is required.

The discussion on QUERY_STRING was noted, but as Pierre pointed out it was set too

        for k in ('QUERY_STRING', 'REMOTE_HOST', 'CONTENT_LENGTH',
                  'HTTP_USER_AGENT', 'HTTP_COOKIE', 'HTTP_REFERER'):
            env.setdefault(k, "")

For cosmetic purpose, I could remove the existing if condition - https://github.com/python/cpython/pull/23604

I am not sure if we need to add other variables with an empty string value for any reason. 

As a maintainer, I think, we should close this issue.

If there is a bug report, like issue5054, then that is a valid issue, and we should fix it.  If there any specific issues raised with parsing or lack of "required" meta variable that caused the application to break, even that could be fixed.

I am closing this issue with a cosmetic change that stemmed out from the discussion - https://github.com/python/cpython/pull/23604

----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10 -Python 2.7, Python 3.2, Python 3.3

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

From report at bugs.python.org  Tue Dec  1 17:41:03 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 01 Dec 2020 22:41:03 +0000
Subject: [issue5054] CGIHTTPRequestHandler.run_cgi() HTTP_ACCEPT improperly
 parsed
In-Reply-To: <1232897403.01.0.0399148938595.issue5054@psf.upfronthosting.co.za>
Message-ID: <1606862463.02.0.0982113571642.issue5054@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
assignee:  -> orsenthil
versions: +Python 3.10, Python 3.9 -Python 2.6, Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Dec  1 18:06:18 2020
From: report at bugs.python.org (anthony shaw)
Date: Tue, 01 Dec 2020 23:06:18 +0000
Subject: [issue42521] Debug (-d) mode not working in 3.9
In-Reply-To: <1606821339.69.0.708367922333.issue42521@roundup.psfhosted.org>
Message-ID: <1606863978.66.0.0585871240101.issue42521@roundup.psfhosted.org>


anthony shaw <anthony.p.shaw at gmail.com> added the comment:

thanks, it would be great if this were documented in the --help section like the other options which require a debug build (-X showrefcount)

----------

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

From report at bugs.python.org  Tue Dec  1 18:15:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Dec 2020 23:15:19 +0000
Subject: [issue42521] Debug (-d) mode not working in 3.9
In-Reply-To: <1606821339.69.0.708367922333.issue42521@roundup.psfhosted.org>
Message-ID: <1606864519.46.0.00333265244171.issue42521@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

In PyConfig, I chose to name the option "parser_debug" rather than the very generic "debug" name :-)

"""
Parser debug mode. If greater than 0, turn on parser debugging output (for expert only, depending on compilation options).

Incremented by the -d command line option. Set to the PYTHONDEBUG environment variable value.
"""

https://docs.python.org/dev/c-api/init_config.html#c.PyConfig.parser_debug

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

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

From report at bugs.python.org  Tue Dec  1 18:16:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Dec 2020 23:16:58 +0000
Subject: [issue42521] Debug (-d) mode not working in 3.9
In-Reply-To: <1606821339.69.0.708367922333.issue42521@roundup.psfhosted.org>
Message-ID: <1606864618.99.0.176429709492.issue42521@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> thanks, it would be great if this were documented in the --help section like the other options which require a debug build (-X showrefcount)

PyConfig.show_ref_count documentation explains that a debug build is required:

"Need a debug build of Python (Py_REF_DEBUG macro must be defined)."

https://docs.python.org/dev/c-api/init_config.html#c.PyConfig.show_ref_count

By the way, it would be nice to add a link on "debug build" to explain how to detect if Python is built in debug mode and how to build Python in debug mode.

----------

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

From report at bugs.python.org  Tue Dec  1 18:47:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 01 Dec 2020 23:47:46 +0000
Subject: [issue42522] [C API] Add _Py_Borrow() private function: call
 Py_XDECREF() and return the object
In-Reply-To: <1606821697.29.0.99350380249.issue42522@roundup.psfhosted.org>
Message-ID: <1606866466.24.0.118106509371.issue42522@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I had more time to think about this issue.

First, I decided to always include "pythoncapi_compat.h" and so there is no strict requirement to add new C API functions to Python.

Second, the _Py_Borrow() function looked nice, but there is a practical issue: its return type is always PyObject* which makes it not convenient to "convert" a function returning a different type.

For example, I replaced "frame->f_code" with "((PyCodeObject *)_Py_Borrow(PyFrame_GetCode(frame)))", but this expression requires 3 levels of parenthesis, it's long and it's hard to read :-( The outter parenthesis is needed if the modified expresion is used to get a code member, like: "frame->f_code->co_name".

I chose another approach: add a "Borrow" variant of the functions that I need.

For example, add _PyFrameGetCodeBorrow() variant of PyFrameGetCode(). This function is only added to pythoncapi_compat.h, and so Python doesn't have to be modified.

I reject my issue :-)

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

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

From report at bugs.python.org  Tue Dec  1 19:08:50 2020
From: report at bugs.python.org (Igor Skochinsky)
Date: Wed, 02 Dec 2020 00:08:50 +0000
Subject: [issue40939] Remove the old parser
In-Reply-To: <1591788317.65.0.969058655213.issue40939@roundup.psfhosted.org>
Message-ID: <1606867730.67.0.291698600923.issue40939@roundup.psfhosted.org>


Igor Skochinsky <skochinsky at gmail.com> added the comment:

Attached is a sample program which works on 3.9 but fails linking with 3.10.0a2 

The .so is missing the symbol:

igor at LAPTOP:~/py_limited_api_example$ nm /home/igor/lib/libpython3.9.so | grep Py_CompileString
0000000000212720 T Py_CompileString
000000000020fe30 T Py_CompileStringExFlags
0000000000212730 T Py_CompileStringFlags
000000000020fd40 T Py_CompileStringObject

igor at LAPTOP:~/py_limited_api_example$ nm /home/igor/lib/libpython3.10.so | grep Py_CompileString
0000000000201a40 T Py_CompileStringExFlags
0000000000201980 T Py_CompileStringObject


Please stop breaking the Stable ABI :/

----------
Added file: https://bugs.python.org/file49642/py_limited_api_example.zip

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

From report at bugs.python.org  Tue Dec  1 19:15:31 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 02 Dec 2020 00:15:31 +0000
Subject: [issue42470] DeprecationWarning triggers for sequences which happen
 to be sets as well
In-Reply-To: <1606379035.36.0.842330798084.issue42470@roundup.psfhosted.org>
Message-ID: <1606868131.1.0.713731128034.issue42470@roundup.psfhosted.org>


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

>>> Do you want to submit a PR for this?
>
> Sure. Do you think the code I proposed would be suitable?

Yes.  It will need tests and a news entry as well.

----------
assignee:  -> rhettinger

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

From report at bugs.python.org  Tue Dec  1 20:07:27 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 02 Dec 2020 01:07:27 +0000
Subject: [issue40939] Remove the old parser
In-Reply-To: <1591788317.65.0.969058655213.issue40939@roundup.psfhosted.org>
Message-ID: <1606871247.42.0.243940618883.issue40939@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Hm, I wonder if there's a typo here in pythonrun.c:

/* For use in Py_LIMITED_API */
#undef Py_CompileString
PyObject *
PyCompileString(const char *str, const char *filename, int start)
{
    return Py_CompileStringFlags(str, filename, start, NULL);
}

Shouldn't that function be named Py_CompileString (i.e. Py_ instead of Py)?

This seems to be old code, but there's normally a macro Py_CompileString() that translates to Py_CompileStringFlags() in pythonrun.h:

#ifdef Py_LIMITED_API
PyAPI_FUNC(PyObject *) Py_CompileString(const char *, const char *, int);
#else
#define Py_CompileString(str, p, s) Py_CompileStringExFlags(str, p, s, NULL, -1)
#define Py_CompileStringFlags(str, p, s, f) Py_CompileStringExFlags(str, p, s, f, -1)
.
.
.

----------

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

From report at bugs.python.org  Tue Dec  1 20:23:01 2020
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 02 Dec 2020 01:23:01 +0000
Subject: [issue42525] Optimize class/module level annotation
In-Reply-To: <1606836637.51.0.505503737654.issue42525@roundup.psfhosted.org>
Message-ID: <1606872181.18.0.0997257046618.issue42525@roundup.psfhosted.org>


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

I agree with Batuhan.

Although bytecode for class annotations seems inefficient, it is difficult to optimize without breaking backward compatibility.
You can write arbitrary code in class/module block which dynamically manipulate __annotations__.

```
class Foo:
    __annotations__["spam"] = "list"
    ham: tuple
```

----------

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

From report at bugs.python.org  Tue Dec  1 21:58:28 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 02 Dec 2020 02:58:28 +0000
Subject: [issue40939] Remove the old parser
In-Reply-To: <1591788317.65.0.969058655213.issue40939@roundup.psfhosted.org>
Message-ID: <1606877908.08.0.847444590832.issue40939@roundup.psfhosted.org>


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


----------
pull_requests: +22474
pull_request: https://github.com/python/cpython/pull/23606

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

From report at bugs.python.org  Tue Dec  1 21:59:49 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 02 Dec 2020 02:59:49 +0000
Subject: [issue40939] Remove the old parser
In-Reply-To: <1591788317.65.0.969058655213.issue40939@roundup.psfhosted.org>
Message-ID: <1606877989.3.0.015368675299.issue40939@roundup.psfhosted.org>


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

Seems that commit 1ed83adb0e95305af858bd41af531e487f54fee7 was deleting some functions that were not correctly covered by redirection macros. I have opened PR 23606 to restore those as they were.

----------

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

From report at bugs.python.org  Tue Dec  1 22:00:53 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 02 Dec 2020 03:00:53 +0000
Subject: [issue42523] using windows doc incorrectly states version support
In-Reply-To: <1606826036.29.0.083322027972.issue42523@roundup.psfhosted.org>
Message-ID: <1606878053.58.0.0814253202522.issue42523@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


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

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

From report at bugs.python.org  Tue Dec  1 22:04:34 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 02 Dec 2020 03:04:34 +0000
Subject: [issue42521] Debug (-d) mode not working in 3.9
In-Reply-To: <1606821339.69.0.708367922333.issue42521@roundup.psfhosted.org>
Message-ID: <1606878274.69.0.402697129217.issue42521@roundup.psfhosted.org>


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


----------
keywords: +patch
pull_requests: +22475
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23607

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

From report at bugs.python.org  Tue Dec  1 22:14:21 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 02 Dec 2020 03:14:21 +0000
Subject: [issue41625] Add splice() to the os module
In-Reply-To: <1598284638.54.0.211220433787.issue41625@roundup.psfhosted.org>
Message-ID: <1606878861.3.0.902642272881.issue41625@roundup.psfhosted.org>


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


----------
pull_requests: +22476
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/23608

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

From report at bugs.python.org  Tue Dec  1 22:17:44 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 02 Dec 2020 03:17:44 +0000
Subject: [issue41625] Add splice() to the os module
In-Reply-To: <1598284638.54.0.211220433787.issue41625@roundup.psfhosted.org>
Message-ID: <1606879064.16.0.932405961825.issue41625@roundup.psfhosted.org>


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

https://buildbot.python.org/all/#/builders/526/builds/3

----------

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

From report at bugs.python.org  Tue Dec  1 22:17:32 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 02 Dec 2020 03:17:32 +0000
Subject: [issue41625] Add splice() to the os module
In-Reply-To: <1598284638.54.0.211220433787.issue41625@roundup.psfhosted.org>
Message-ID: <1606879052.75.0.367994363528.issue41625@roundup.psfhosted.org>


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

Started custom build of PR 23608 in https://buildbot.python.org/all/#/buildrequests/84365

----------

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

From report at bugs.python.org  Tue Dec  1 22:32:39 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 02 Dec 2020 03:32:39 +0000
Subject: [issue41625] Add splice() to the os module
In-Reply-To: <1598284638.54.0.211220433787.issue41625@roundup.psfhosted.org>
Message-ID: <1606879959.08.0.288928974867.issue41625@roundup.psfhosted.org>


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

Seems that adding #include <sys/socket.h> does not work so I am going to skip adding this function on AIX. If someone is interested in fixing it, they can remove the #ifdef and figure out what's going on with that buildbot

----------

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

From report at bugs.python.org  Wed Dec  2 00:16:39 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 02 Dec 2020 05:16:39 +0000
Subject: [issue40939] Remove the old parser
In-Reply-To: <1591788317.65.0.969058655213.issue40939@roundup.psfhosted.org>
Message-ID: <1606886199.34.0.230205666644.issue40939@roundup.psfhosted.org>


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


New changeset 46bd5ed94cf3d5e03f45eecf9afea1659980c8bf by Pablo Galindo in branch 'master':
bpo-40939: Restore some stable API functions incorrectly deleted (GH-23606)
https://github.com/python/cpython/commit/46bd5ed94cf3d5e03f45eecf9afea1659980c8bf


----------

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

From report at bugs.python.org  Wed Dec  2 00:17:21 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 02 Dec 2020 05:17:21 +0000
Subject: [issue40939] Remove the old parser
In-Reply-To: <1591788317.65.0.969058655213.issue40939@roundup.psfhosted.org>
Message-ID: <1606886241.24.0.875204429119.issue40939@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/issue40939>
_______________________________________

From report at bugs.python.org  Wed Dec  2 01:23:16 2020
From: report at bugs.python.org (Daniel Kostecki)
Date: Wed, 02 Dec 2020 06:23:16 +0000
Subject: [issue42530] Pickle Serialization Mangles NllLossBackward Objects in
 Tensor Objects
Message-ID: <1606890196.44.0.812849435025.issue42530@roundup.psfhosted.org>


New submission from Daniel Kostecki <dandankostecki at gmail.com>:

torch.nn.functional.nll_loss returns Tensor objects which contain a loss value as well as a grad_fn object. Pickle does not throw an exception when serializing (dumps) the Tensor object. When loading (loads) the serialized data, the grad_fn object is lost and it becomes a requires_grad object. 

However, if one attempts to serialize the grad_fn object encapsulated in the Tensor object, Pickle then throws a TypeError (TypeError: cannot pickle 'NllLossBackward' object). This behavior seems inconsistent. Perhaps serialization of NllLossBackward objects should be supported or their encapsulating Tensors should also throw a TypeError.

This behavior should be easily reproducible.

----------
components: Library (Lib)
messages: 382294
nosy: dkostecki
priority: normal
severity: normal
status: open
title: Pickle Serialization Mangles NllLossBackward Objects in Tensor Objects
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Dec  2 01:27:14 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 02 Dec 2020 06:27:14 +0000
Subject: [issue42530] Pickle Serialization Mangles NllLossBackward Objects in
 Tensor Objects
In-Reply-To: <1606890196.44.0.812849435025.issue42530@roundup.psfhosted.org>
Message-ID: <1606890434.35.0.608466681228.issue42530@roundup.psfhosted.org>


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

Torch is not the part of the standard Python library. Please file the report on the Torch bug tracker.

----------
nosy: +serhiy.storchaka
resolution:  -> third party
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Dec  2 01:31:42 2020
From: report at bugs.python.org (William Schwartz)
Date: Wed, 02 Dec 2020 06:31:42 +0000
Subject: [issue42531] importlib.resources.path() raises TypeError for packages
 without __file__
Message-ID: <1606890702.39.0.177441013455.issue42531@roundup.psfhosted.org>


New submission from William Schwartz <wkschwartz at gmail.com>:

Suppose pkg is a package, it contains a resource r, pkg.__spec__.origin is None, and p = importlib.resources.path(pkg, r). Then p.__enter__() raises a TypeError in Python 3.7 and 3.8. (The problem has been fixed in 3.9). The error can be demonstrated by running the attached path-test.py. The tracebacks in 3.7 and 3.8 are nearly identical, so I'll just show the 3.8 traceback.

3.8.6 (default, Nov 20 2020, 18:29:40) 
[Clang 12.0.0 (clang-1200.0.32.27)]
Traceback (most recent call last):
  File "path-test.py", line 19, in <module>
    p.__enter__()  # Kaboom
  File "/usr/local/Cellar/python at 3.8/3.8.6_2/Frameworks/Python.framework/Versions/3.8/lib/python3.8/contextlib.py", line 113, in __enter__
    return next(self.gen)
  File "/usr/local/Cellar/python at 3.8/3.8.6_2/Frameworks/Python.framework/Versions/3.8/lib/python3.8/importlib/resources.py", line 196, in path
    package_directory = Path(package.__spec__.origin).parent
  File "/usr/local/Cellar/python at 3.8/3.8.6_2/Frameworks/Python.framework/Versions/3.8/lib/python3.8/pathlib.py", line 1041, in __new__
    self = cls._from_parts(args, init=False)
  File "/usr/local/Cellar/python at 3.8/3.8.6_2/Frameworks/Python.framework/Versions/3.8/lib/python3.8/pathlib.py", line 682, in _from_parts
    drv, root, parts = self._parse_args(args)
  File "/usr/local/Cellar/python at 3.8/3.8.6_2/Frameworks/Python.framework/Versions/3.8/lib/python3.8/pathlib.py", line 666, in _parse_args
    a = os.fspath(a)
TypeError: expected str, bytes or os.PathLike object, not NoneType

The fix is super simple, as shown below. I'll submit this as a PR as well.

diff --git a/Lib/importlib/resources.py b/Lib/importlib/resources.py
index fc3a1c9cab..8d37d52cb8 100644
--- a/Lib/importlib/resources.py
+++ b/Lib/importlib/resources.py
@@ -193,9 +193,11 @@ def path(package: Package, resource: Resource) -> Iterator[Path]:
         _check_location(package)
     # Fall-through for both the lack of resource_path() *and* if
     # resource_path() raises FileNotFoundError.
-    package_directory = Path(package.__spec__.origin).parent
-    file_path = package_directory / resource
-    if file_path.exists():
+    file_path = None
+    if package.__spec__.origin is not None:
+        package_directory = Path(package.__spec__.origin).parent
+        file_path = package_directory / resource
+    if file_path is not None and file_path.exists():
         yield file_path
     else:
         with open_binary(package, resource) as fp:

----------
components: Library (Lib)
files: path-test.py
messages: 382297
nosy: William.Schwartz, brett.cannon
priority: normal
severity: normal
status: open
title: importlib.resources.path() raises TypeError for packages without __file__
type: behavior
versions: Python 3.7, Python 3.8
Added file: https://bugs.python.org/file49643/path-test.py

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

From report at bugs.python.org  Wed Dec  2 01:31:31 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 02 Dec 2020 06:31:31 +0000
Subject: [issue42507] test_ttk_guionly test failures on macOS with Tcl/Tk
 8.6.10
In-Reply-To: <1606704400.88.0.0493725264205.issue42507@roundup.psfhosted.org>
Message-ID: <1606890691.65.0.550712814034.issue42507@roundup.psfhosted.org>


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

Can I get a remote access to machine with macOS?

----------

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

From report at bugs.python.org  Wed Dec  2 01:50:34 2020
From: report at bugs.python.org (William Schwartz)
Date: Wed, 02 Dec 2020 06:50:34 +0000
Subject: [issue42531] importlib.resources.path() raises TypeError for packages
 without __file__
In-Reply-To: <1606890702.39.0.177441013455.issue42531@roundup.psfhosted.org>
Message-ID: <1606891834.61.0.852735491241.issue42531@roundup.psfhosted.org>


Change by William Schwartz <wkschwartz at gmail.com>:


----------
keywords: +patch
pull_requests: +22477
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23611

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

From report at bugs.python.org  Wed Dec  2 01:56:44 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 02 Dec 2020 06:56:44 +0000
Subject: [issue42328] ttk style.map function incorrectly handles the default
 state for element options.
In-Reply-To: <1605140874.05.0.0614253934034.issue42328@roundup.psfhosted.org>
Message-ID: <1606892204.18.0.435451092831.issue42328@roundup.psfhosted.org>


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


----------
pull_requests: +22479
pull_request: https://github.com/python/cpython/pull/23612

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

From report at bugs.python.org  Wed Dec  2 01:58:53 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 02 Dec 2020 06:58:53 +0000
Subject: [issue42328] ttk style.map function incorrectly handles the default
 state for element options.
In-Reply-To: <1605140874.05.0.0614253934034.issue42328@roundup.psfhosted.org>
Message-ID: <1606892333.84.0.0229394036818.issue42328@roundup.psfhosted.org>


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

Thank you for your report David. I have not Windows 7 and does not know how to reproduce this on Windows 10 so will just skip tests for specific themes on Windows 7.

----------

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

From report at bugs.python.org  Wed Dec  2 02:29:30 2020
From: report at bugs.python.org (Idan Weiss)
Date: Wed, 02 Dec 2020 07:29:30 +0000
Subject: [issue42532] spec_arg's __bool__ is called while initializing
 NonCallableMock
Message-ID: <1606894170.3.0.122228066862.issue42532@roundup.psfhosted.org>


Change by Idan Weiss <idanweiss97 at gmail.com>:


----------
components: Library (Lib)
nosy: idanweiss97
priority: normal
severity: normal
status: open
title: spec_arg's __bool__ is called while initializing NonCallableMock
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Dec  2 02:35:11 2020
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 02 Dec 2020 07:35:11 +0000
Subject: [issue42532] spec_arg's __bool__ is called while initializing
 NonCallableMock
Message-ID: <1606894511.37.0.805984825203.issue42532@roundup.psfhosted.org>


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


----------
keywords: +patch
nosy: +python-dev
nosy_count: 1.0 -> 2.0
pull_requests: +22480
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23613

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

From report at bugs.python.org  Wed Dec  2 04:43:00 2020
From: report at bugs.python.org (Igor Skochinsky)
Date: Wed, 02 Dec 2020 09:43:00 +0000
Subject: [issue40939] Remove the old parser
In-Reply-To: <1591788317.65.0.969058655213.issue40939@roundup.psfhosted.org>
Message-ID: <1606902180.28.0.509078843935.issue40939@roundup.psfhosted.org>


Igor Skochinsky <skochinsky at gmail.com> added the comment:

Thanks for the fix! I'd like to submit a test to avoid this and similar  issues in future. Are there any guidelines for this? Sorry if this is a wrong place to ask.

----------

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

From report at bugs.python.org  Wed Dec  2 04:54:58 2020
From: report at bugs.python.org (Tobias Kunze)
Date: Wed, 02 Dec 2020 09:54:58 +0000
Subject: [issue42533] Document encodings.idna limitations
Message-ID: <1606902898.84.0.956500804562.issue42533@roundup.psfhosted.org>


New submission from Tobias Kunze <r at rixx.de>:

The documentation for the encodings.idna module contains no indicator that the RFC it supports has been obsoleted by another RFC: https://docs.python.org/3.10/library/codecs.html#module-encodings.idna

I'm sure this is obvious when you know your RFCs, but when just looking at the docs, it's easy to miss. In #msg379674, Marc-Andre suggested to fix the situation by deprecating or updating IDNA support. I'd like to propose to add a warning message in the meantime, pointing out the newer RFC and linking to the idna package on PyPI (if links to PyPI packages are alright in the docs?)

----------
assignee: docs at python
components: Documentation, Unicode
messages: 382300
nosy: docs at python, ezio.melotti, rixx, vstinner
priority: normal
severity: normal
status: open
title: Document encodings.idna limitations
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Wed Dec  2 05:11:44 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Dec 2020 10:11:44 +0000
Subject: [issue40686] Compiler warnings in _zoneinfo.c on Windows build in
 64-bit
In-Reply-To: <1589906488.33.0.285207996013.issue40686@roundup.psfhosted.org>
Message-ID: <1606903904.63.0.132095061364.issue40686@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22482
pull_request: https://github.com/python/cpython/pull/23614

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

From report at bugs.python.org  Wed Dec  2 05:18:16 2020
From: report at bugs.python.org (Jussi Enkovaara)
Date: Wed, 02 Dec 2020 10:18:16 +0000
Subject: [issue42534] venv does not work correctly when imported from .zip
Message-ID: <1606904296.18.0.0189453228301.issue42534@roundup.psfhosted.org>


New submission from Jussi Enkovaara <jussi.enkovaara at csc.fi>:

In some cases it can be useful to provide standard library in a zip-file. 
However, when "venv" is imported from a zip-file, activate etc. scripts are not generated. The directory for script templates is determined in function setup_scripts in venv/__init__.py as

   path = os.path.abspath(os.path.dirname(__file__))
   path = os.path.join(path, 'scripts')

which becomes .../python38.zip/venv/scripts when is venv is imported from zip-file. No scripts are now generated, and no error / warning messages are invoked either.

----------
components: Library (Lib)
messages: 382301
nosy: jussienko
priority: normal
severity: normal
status: open
title: venv does not work correctly when imported from .zip
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Dec  2 05:55:01 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Dec 2020 10:55:01 +0000
Subject: [issue41625] Add splice() to the os module
In-Reply-To: <1598284638.54.0.211220433787.issue41625@roundup.psfhosted.org>
Message-ID: <1606906501.39.0.571077343757.issue41625@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Seems that adding #include <sys/socket.h> does not work so I am going to skip adding this function on AIX.

I'm fine with not implementing the function on AIX for now.

----------

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

From report at bugs.python.org  Wed Dec  2 05:55:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Dec 2020 10:55:41 +0000
Subject: [issue42533] Document encodings.idna limitations
In-Reply-To: <1606902898.84.0.956500804562.issue42533@roundup.psfhosted.org>
Message-ID: <1606906541.7.0.389463335143.issue42533@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


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

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

From report at bugs.python.org  Wed Dec  2 06:14:10 2020
From: report at bugs.python.org (=?utf-8?q?Tymek_Wo=C5=82od=C5=BAko?=)
Date: Wed, 02 Dec 2020 11:14:10 +0000
Subject: [issue42535] unittest.patch confuses modules with base modules
Message-ID: <1606907650.68.0.627501426895.issue42535@roundup.psfhosted.org>


New submission from Tymek Wo?od?ko <twolodzko at gmail.com>:

Nonetheless having several attempts, I wasn't able to create reproducible example for this bug, but I will try describing it in detail.

I have a package with multiple modules. One of the paths is like `mymodule.nestedmodule.io`, among other functions, this module contains functions `foo()` and `bar()`, where `bar()` does call `foo()`. The module *does not* import base python's `io` module. I have a unit test that patches:

with path('mymodule.nestedmodule.io.foo'):
    bar()


The problem is, when running the test I get the following error: `AttributeError: <module 'io' from '/usr/local/lib/python3.7/io.py'> does not have the attribute 'foo'`. The problem is solved when I rename `io` to `myio` and correct all the paths to use the new name.

----------
components: Library (Lib)
messages: 382303
nosy: twolodzko
priority: normal
severity: normal
status: open
title: unittest.patch confuses modules with base modules
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Wed Dec  2 06:48:35 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Dec 2020 11:48:35 +0000
Subject: [issue42536] test_itertools leaks sometimes references
Message-ID: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

12:07:06 vstinner at apu$ ./python -m test test_itertools -R 3:3 -F -j4
0:00:00 load avg: 0.44 Run tests in parallel using 4 child processes
(...)
0:02:03 load avg: 4.24 [  1] test_itertools passed (2 min 2 sec) -- running: test_itertools (2 min 3 sec), test_itertools (2 min 3 sec), test_itertools (2 min 3 sec)
beginning 6 repetitions
123456
......

0:02:03 load avg: 4.24 [  2/1] test_itertools failed (2 min 3 sec) -- running: test_itertools (2 min 3 sec), test_itertools (2 min 3 sec)
beginning 6 repetitions
123456
......

test_itertools leaked [32, 32, 32] references, sum=96
test_itertools leaked [24, 22, 22] memory blocks, sum=68

Kill <TestWorkerProcess #1 running test=test_itertools pid=159366 time=2 min 3 sec> process group
Kill <TestWorkerProcess #2 running test=test_itertools pid=159586 time=164 ms> process group
Kill <TestWorkerProcess #3 running test=test_itertools pid=159371 time=2 min 3 sec> process group

== Tests result: FAILURE ==

1 test OK.

1 test failed:
    test_itertools

Total duration: 2 min 3 sec
Tests result: FAILURE

----------
components: Tests
messages: 382304
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_itertools leaks sometimes references
versions: Python 3.10

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

From report at bugs.python.org  Wed Dec  2 06:49:26 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Dec 2020 11:49:26 +0000
Subject: [issue42536] test_itertools leaks sometimes references
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1606909766.43.0.147952665129.issue42536@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Leak seen on AMD64 RHEL7 Refleaks 3.x:
https://buildbot.python.org/all/#builders/562/builds/109

Recent itertools change, I have no idea if it's related:

commit cc061d0e6fb2569efa91531686f75b89e94ec865
Author: Raymond Hettinger <rhettinger at users.noreply.github.com>
Date:   Mon Nov 30 20:42:54 2020 -0800

    bpo-38200: Add itertools.pairwise() (GH-23549)

----------

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

From report at bugs.python.org  Wed Dec  2 06:51:29 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 02 Dec 2020 11:51:29 +0000
Subject: [issue42535] unittest.patch confuses modules with base modules
In-Reply-To: <1606907650.68.0.627501426895.issue42535@roundup.psfhosted.org>
Message-ID: <1606909889.74.0.819392452665.issue42535@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/issue42535>
_______________________________________

From report at bugs.python.org  Wed Dec  2 06:52:24 2020
From: report at bugs.python.org (Qingyao Sun)
Date: Wed, 02 Dec 2020 11:52:24 +0000
Subject: [issue42537] Implement built-in shorthand b() for breakpoint()
Message-ID: <1606909944.93.0.455067472723.issue42537@roundup.psfhosted.org>


New submission from Qingyao Sun <sunqingyao19970825 at icloud.com>:

Placeholder issue for discussion of the proposal of a built-in shorthand b() for breakpoint().

----------
components: Interpreter Core
messages: 382306
nosy: nalzok
priority: normal
severity: normal
status: open
title: Implement built-in shorthand b() for breakpoint()
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Wed Dec  2 07:17:27 2020
From: report at bugs.python.org (Alexander Greckov)
Date: Wed, 02 Dec 2020 12:17:27 +0000
Subject: [issue42538] AsyncIO strange behaviour
Message-ID: <1606911447.68.0.828780901691.issue42538@roundup.psfhosted.org>


New submission from Alexander Greckov <alexander.greckov at gmail.com>:

Hi! I've met strange behaviour related to the coroutine execution. Probably it's somehow related to the asyncio.Queue get() method. I have the following lines of code:
class WeightSource:
    def __init__(self):
        self._queue = asyncio.Queue(maxsize=1)
    def __aiter__(self):
        return self
    async def __anext__(self):
        return await self._queue.get()

async def _preconfigure(app: web.Application) -> None:
    setup_db()
    # asyncio.create_task(WeightSource.listen_scales('/dev/ttyACM0', 9600)
    asyncio.create_task(handle_weight_event_creation()) # coroutine prints WEIGHT <int>
    await create_track_tasks()

async def create_track_tasks():
    asyncio.create_task(track_scales_availability())
    asyncio.create_task(track_crm_availability())

async def track_scales_availability():
    async for weight in WeightSource():
        print(weight)

When I'm trying to run _preconfigure coroutine (automatically started by aiohttp), i see the message: ERROR:asyncio:Task was destroyed but it is pending. The strange things two:
The process and loop remains alive (so by the logic error should be not shown) and the second thing is when I export PYTHONASYNCIODEBUG=1 everything works well without any error. 
On unset this variable the error returns. When I don't use asyncio.Queue and just place asyncio.sleep(), coroutine doesn't fall. Error happens inside the `async for weight in WeightSource()` statement. Why PYTHONASYNCIODEBUG changes behaviour?

----------
components: asyncio
files: output.txt
messages: 382307
nosy: Alexander-Greckov, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: AsyncIO strange behaviour
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file49644/output.txt

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

From report at bugs.python.org  Wed Dec  2 07:18:41 2020
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 02 Dec 2020 12:18:41 +0000
Subject: [issue42533] Document encodings.idna limitations
In-Reply-To: <1606902898.84.0.956500804562.issue42533@roundup.psfhosted.org>
Message-ID: <1606911521.08.0.29536860511.issue42533@roundup.psfhosted.org>


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

+1 for updating our documentation.

Please use bpo-17305. The ticket contains more information on the issue.

----------
superseder:  -> IDNA2008 encoding is missing

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

From report at bugs.python.org  Wed Dec  2 07:35:29 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 02 Dec 2020 12:35:29 +0000
Subject: [issue42538] AsyncIO strange behaviour
In-Reply-To: <1606911447.68.0.828780901691.issue42538@roundup.psfhosted.org>
Message-ID: <1606912529.73.0.0506589458732.issue42538@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

I understand the issue as the following:

1. You don't save the result of `asyncio.create_task()` somewhere.
The task object is dereferenced and thus you see a warning.

2. With PYTHONASYNCIODEBUG on the task is referenced also by internal debug structure, that's why you don't see the warning.

Perhaps we should store a weak reference to task in _source_traceback

Minor thing but nice to have it fixed.

----------

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

From report at bugs.python.org  Wed Dec  2 07:48:38 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 02 Dec 2020 12:48:38 +0000
Subject: [issue42537] Implement built-in shorthand b() for breakpoint()
In-Reply-To: <1606909944.93.0.455067472723.issue42537@roundup.psfhosted.org>
Message-ID: <1606913318.23.0.411692495681.issue42537@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Wed Dec  2 07:49:40 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 02 Dec 2020 12:49:40 +0000
Subject: [issue42536] test_itertools leaks sometimes references
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1606913380.74.0.263282124071.issue42536@roundup.psfhosted.org>


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


----------
nosy: +rhettinger, serhiy.storchaka

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

From report at bugs.python.org  Wed Dec  2 07:50:02 2020
From: report at bugs.python.org (Alexander Greckov)
Date: Wed, 02 Dec 2020 12:50:02 +0000
Subject: [issue42538] AsyncIO strange behaviour
In-Reply-To: <1606911447.68.0.828780901691.issue42538@roundup.psfhosted.org>
Message-ID: <1606913402.36.0.7820645999.issue42538@roundup.psfhosted.org>


Alexander Greckov <alexander.greckov at gmail.com> added the comment:

Thanks! That's resolved my problem, but this thing wasn't really obvious as for me. Probably it would be better to write about this explicitly in docs for the create_task. All in all this issue can be closed.

----------

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

From report at bugs.python.org  Wed Dec  2 08:31:09 2020
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 02 Dec 2020 13:31:09 +0000
Subject: [issue42500] crash with unbounded recursion in except statement
In-Reply-To: <1606635563.54.0.549807759752.issue42500@roundup.psfhosted.org>
Message-ID: <1606915869.08.0.266001633938.issue42500@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset 4e7a69bdb63a104587759d7784124492dcdd496e by Mark Shannon in branch 'master':
bpo-42500: Fix recursion in or after except (GH-23568)
https://github.com/python/cpython/commit/4e7a69bdb63a104587759d7784124492dcdd496e


----------

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

From report at bugs.python.org  Wed Dec  2 08:31:43 2020
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 02 Dec 2020 13:31:43 +0000
Subject: [issue42246] Implement PEP 626
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1606915903.99.0.929941148978.issue42246@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset 5977a7989d49c3e095c7659a58267d87a17b12b1 by Mark Shannon in branch 'master':
bpo-42246: Make sure that line number is correct after a return, as required by PEP 626 (GH-23495)
https://github.com/python/cpython/commit/5977a7989d49c3e095c7659a58267d87a17b12b1


----------

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

From report at bugs.python.org  Wed Dec  2 08:54:51 2020
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 02 Dec 2020 13:54:51 +0000
Subject: [issue42500] crash with unbounded recursion in except statement
In-Reply-To: <1606635563.54.0.549807759752.issue42500@roundup.psfhosted.org>
Message-ID: <1606917291.33.0.0271493235361.issue42500@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


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

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

From report at bugs.python.org  Wed Dec  2 09:05:34 2020
From: report at bugs.python.org (Mingchii Suen)
Date: Wed, 02 Dec 2020 14:05:34 +0000
Subject: [issue42539] Missing parenthesis in `platform._sys_version_parser`
Message-ID: <1606917934.84.0.784006855646.issue42539@roundup.psfhosted.org>


New submission from Mingchii Suen <crazy95sun at gmail.com>:

in `platform.py`, `_sys_version_parser`
the last part of regex is `r'\[([^\]]+)\]?'`
which should be `r'(?:\[([^\]]+)\])?'

without this change, the question mark only make the last `\]` optional, not the whole part optional

this will cause unable to detect python implementation issue in some custom build python if the `[compiler]` part in `sys.version` is missing

will make a pull request soon
I have o

----------
components: Library (Lib)
messages: 382313
nosy: crazy95sun
priority: normal
severity: normal
status: open
title: Missing parenthesis in `platform._sys_version_parser`
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Wed Dec  2 09:22:16 2020
From: report at bugs.python.org (CendioOssman)
Date: Wed, 02 Dec 2020 14:22:16 +0000
Subject: [issue42540] Debug pymalloc crash when using os.fork() [regression]
Message-ID: <1606918936.38.0.790172378115.issue42540@roundup.psfhosted.org>


New submission from CendioOssman <ossman at cendio.se>:

A python equivalent of the classical daemon() call started throwing an error from 3.8 when the debug hooks are active for pymalloc. If the tracing is also active it segfaults.

This simple example triggers it:


import os

def daemon():
    pid = os.fork()
    if pid != 0:
        os._exit(0)

daemon()


The error given is:

Debug memory block at address p=0xf013d0: API '1'
    0 bytes originally requested
    The 7 pad bytes at p-7 are not all FORBIDDENBYTE (0xfd):
        at p-7: 0x00 *** OUCH
        at p-6: 0x00 *** OUCH
        at p-5: 0x00 *** OUCH
        at p-4: 0x00 *** OUCH
        at p-3: 0x00 *** OUCH
        at p-2: 0x00 *** OUCH
        at p-1: 0x00 *** OUCH
    Because memory is corrupted at the start, the count of bytes requested
       may be bogus, and checking the trailing pad bytes may segfault.
    The 8 pad bytes at tail=0xf013d0 are not all FORBIDDENBYTE (0xfd):
        at tail+0: 0x01 *** OUCH
        at tail+1: 0x00 *** OUCH
        at tail+2: 0x00 *** OUCH
        at tail+3: 0x00 *** OUCH
        at tail+4: 0x00 *** OUCH
        at tail+5: 0x00 *** OUCH
        at tail+6: 0x00 *** OUCH
        at tail+7: 0x00 *** OUCH

Enable tracemalloc to get the memory block allocation traceback

Fatal Python error: bad ID: Allocated using API '1', verified using API 'r'
Python runtime state: finalizing (tstate=0xf023b0)



Tested on Fedora, Ubuntu and RHEL with the same behaviour everwhere. Everything up to 3.8 works fine. 3.8 and 3.9 both exhibit the issue.

Since this is a very standard way of starting a daemon it should affect quite a few users. At the very least it makes it annoying to use development mode to catch other issues.

----------
components: Interpreter Core
messages: 382314
nosy: CendioOssman
priority: normal
severity: normal
status: open
title: Debug pymalloc crash when using os.fork() [regression]
type: crash
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Dec  2 09:49:55 2020
From: report at bugs.python.org (E. Paine)
Date: Wed, 02 Dec 2020 14:49:55 +0000
Subject: [issue42541] Tkinter colours wrong on MacOS universal2
Message-ID: <1606920595.63.0.665509072103.issue42541@roundup.psfhosted.org>


New submission from E. Paine <paineelisha at gmail.com>:

When using tkinter from the universal2 package, the colours are completely confused. Most text tries to white, even though the background is light and this makes text in Entries completely unreadable (where the background is white). This affects both Tk and Ttk.

The first included screenshot is of a simple script which just creates a Tk label and Ttk label. The second screenshot is of the IDLE 'open module' interface in which I have typed 'test' (though, you cannot see this).

The main problem is that I cannot check whether this is a Tkinter or Tk issue as ActiveTcl only offers 8.6.9 and I haven't yet compiled my own copy of Tk.

This is not a problem on the standard installer.

----------
components: Tkinter, macOS
files: Screenshot from 2020-12-02 14-37-02.png
messages: 382315
nosy: epaine, ned.deily, ronaldoussoren, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Tkinter colours wrong on MacOS universal2
versions: Python 3.10, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49645/Screenshot from 2020-12-02 14-37-02.png

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

From report at bugs.python.org  Wed Dec  2 09:50:06 2020
From: report at bugs.python.org (E. Paine)
Date: Wed, 02 Dec 2020 14:50:06 +0000
Subject: [issue42541] Tkinter colours wrong on MacOS universal2
In-Reply-To: <1606920595.63.0.665509072103.issue42541@roundup.psfhosted.org>
Message-ID: <1606920606.12.0.66952786438.issue42541@roundup.psfhosted.org>


Change by E. Paine <paineelisha at gmail.com>:


Added file: https://bugs.python.org/file49646/Screenshot-2020-12-02-at-12-46-06.png

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

From report at bugs.python.org  Wed Dec  2 10:07:41 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 02 Dec 2020 15:07:41 +0000
Subject: [issue42541] Tkinter colours wrong on MacOS universal2
In-Reply-To: <1606920595.63.0.665509072103.issue42541@roundup.psfhosted.org>
Message-ID: <1606921661.43.0.879488530758.issue42541@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Are you running in dark mode?

----------

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

From report at bugs.python.org  Wed Dec  2 10:10:57 2020
From: report at bugs.python.org (E. Paine)
Date: Wed, 02 Dec 2020 15:10:57 +0000
Subject: [issue42541] Tkinter colours wrong on MacOS universal2
In-Reply-To: <1606920595.63.0.665509072103.issue42541@roundup.psfhosted.org>
Message-ID: <1606921857.01.0.622853642198.issue42541@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

> Are you running in dark mode?

Yes. It works fine in light mode.

----------

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

From report at bugs.python.org  Wed Dec  2 10:13:52 2020
From: report at bugs.python.org (E. Paine)
Date: Wed, 02 Dec 2020 15:13:52 +0000
Subject: [issue42541] Tkinter colours wrong on MacOS universal2
In-Reply-To: <1606920595.63.0.665509072103.issue42541@roundup.psfhosted.org>
Message-ID: <1606922032.27.0.375764954338.issue42541@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

Sorry, that was an important piece of information. It is worth noting that Text widgets correctly change background to black.

----------

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

From report at bugs.python.org  Wed Dec  2 10:18:59 2020
From: report at bugs.python.org (Ryan Govostes)
Date: Wed, 02 Dec 2020 15:18:59 +0000
Subject: [issue42542] weakref documentation does not fully describe proxies
Message-ID: <1606922339.94.0.698325525788.issue42542@roundup.psfhosted.org>


New submission from Ryan Govostes <rgovostes at gmail.com>:

The documentation for weakref.proxy() does not describe how the proxy object behaves when the object it references is gone.

The apparent behavior is that it raises a ReferenceError when an attribute of the proxy object is accessed.

It would probably be a good idea to describe what the proxy object does in general, for those who are unfamiliar with the concept: attribute accesses on the proxy object are forwarded to the referenced object, if it exists.

----------
assignee: docs at python
components: Documentation
messages: 382319
nosy: docs at python, rgov
priority: normal
severity: normal
status: open
title: weakref documentation does not fully describe proxies
versions: Python 3.9

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

From report at bugs.python.org  Wed Dec  2 10:25:06 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 02 Dec 2020 15:25:06 +0000
Subject: [issue14111] IDLE Debugger should handle interrupts
In-Reply-To: <1330112839.68.0.0096879566667.issue14111@psf.upfronthosting.co.za>
Message-ID: <1606922706.05.0.0246378574487.issue14111@roundup.psfhosted.org>


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

Mark, since you are working on redoing the debugger gui, do you have any opinion on this?  The basic idea is that ^C when debugging should just interrupt the remote process, not end it, just as when there is no debugger.  I agree.

I just updated the PR to current master but have not at the moment tested it.

----------
nosy:  -roger.serwy
versions: +Python 3.10 -Python 3.7

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

From report at bugs.python.org  Wed Dec  2 10:34:07 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 02 Dec 2020 15:34:07 +0000
Subject: [issue42541] Tkinter colours wrong on MacOS universal2
In-Reply-To: <1606920595.63.0.665509072103.issue42541@roundup.psfhosted.org>
Message-ID: <1606923247.68.0.451026382333.issue42541@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The problem seems to be that the window background doesn't adjust to dark mode, while the window contents does.  

I don't know if we should do something in Tkinter for this.

----------

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

From report at bugs.python.org  Wed Dec  2 11:09:30 2020
From: report at bugs.python.org (Sean Grogan)
Date: Wed, 02 Dec 2020 16:09:30 +0000
Subject: [issue42543] case sensitivity in open() arguments
Message-ID: <1606925370.25.0.425660398835.issue42543@roundup.psfhosted.org>


New submission from Sean Grogan <sean.grogan at gmail.com>:

I was stuck on a problem today using an open statement where I was trying to open a file for writing

e.g. 

    with open("RESULTS.CSV", "W") as csvfile:
        csvwriter = csv.writer(csvfile)
        csvwriter.writerow(["X", "Y"])
        csvwriter.writerows(data) 

I did not notice I had the mode W in upper case. I am not sure if there is a legacy reason for only allowing lower case arguments here but I think a quick note in the documentation that it's case sensitive or a check (or note) when throwing an error would be helpful?  such as 

    ValueError: invalid mode: 'W' -- your case appears to be an upper case, please ensure the case of the mode is correct

or 

    ValueError: invalid mode: 'W' -- note the mode is case sensitive

could be helpful?

----------
assignee: docs at python
components: Documentation
messages: 382322
nosy: docs at python, sean.grogan
priority: normal
severity: normal
status: open
title: case sensitivity in open() arguments
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Dec  2 11:28:32 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 02 Dec 2020 16:28:32 +0000
Subject: [issue40939] Remove the old parser
In-Reply-To: <1591788317.65.0.969058655213.issue40939@roundup.psfhosted.org>
Message-ID: <1606926512.2.0.726337534041.issue40939@roundup.psfhosted.org>


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

I am currently working on test that checks that the stable API symbols are correctly exported. Unfortunately there is no official maintained list if those symbols, so is taking a while

----------

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

From report at bugs.python.org  Wed Dec  2 11:47:10 2020
From: report at bugs.python.org (Igor Skochinsky)
Date: Wed, 02 Dec 2020 16:47:10 +0000
Subject: [issue40939] Remove the old parser
In-Reply-To: <1591788317.65.0.969058655213.issue40939@roundup.psfhosted.org>
Message-ID: <1606927630.52.0.208244235107.issue40939@roundup.psfhosted.org>


Igor Skochinsky <skochinsky at gmail.com> added the comment:

> I am currently working on test that checks that the stable API symbols are correctly exported.

Thank you very much! For added motivation, the 3.8.0 release was unusable thanks to issue37633 which was somewhat similar (also in pythonrun). For reference, I've attached a list of symbols we currently use (a few more we have to import dynamically since they're not in the stable ABI but we'd like to keep that list as short as possible).

----------
Added file: https://bugs.python.org/file49647/py3.txt

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

From report at bugs.python.org  Wed Dec  2 11:55:26 2020
From: report at bugs.python.org (Nikita Nemkin)
Date: Wed, 02 Dec 2020 16:55:26 +0000
Subject: [issue40939] Remove the old parser
In-Reply-To: <1591788317.65.0.969058655213.issue40939@roundup.psfhosted.org>
Message-ID: <1606928126.81.0.809741681953.issue40939@roundup.psfhosted.org>


Nikita Nemkin <nikita at nemkin.ru> added the comment:

> Unfortunately there is no official maintained list if those symbols, so is taking a while

On Windows there is PC/python3dll.c.

----------

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

From report at bugs.python.org  Wed Dec  2 12:09:28 2020
From: report at bugs.python.org (E. Paine)
Date: Wed, 02 Dec 2020 17:09:28 +0000
Subject: [issue42541] Tkinter colours wrong on MacOS universal2
In-Reply-To: <1606920595.63.0.665509072103.issue42541@roundup.psfhosted.org>
Message-ID: <1606928968.09.0.861551804103.issue42541@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

I just compiled Tk 8.6.10 and it has the same problems. So the question now is whether we work-around it in Tkinter/IDLE or close this issue as third party.

----------

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

From report at bugs.python.org  Wed Dec  2 12:13:17 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 02 Dec 2020 17:13:17 +0000
Subject: [issue42508] macOS IDLE with Tk 8.6.10 in 3.9.1rc1 universal2
 installer fails smoke test
In-Reply-To: <1606706274.22.0.163331071262.issue42508@roundup.psfhosted.org>
Message-ID: <1606929197.44.0.162171629655.issue42508@roundup.psfhosted.org>


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

The new tk/tkinter bug in the macOS11 U2 build, other than those reported in #42507 and #42541, is that pressing F5 causes the corresponding pseudoevent handler, run_module_event, to be called twice.  (Its code is above.)  The interval between calls is about 1 millesecond -- .7 to 1.1 in 5 tries.  See this by adding the following at the top of the function's and subtracting after running code with or without syntax  error.
  print('run', time.perf_counter())

Adding multiple prints in _run_module_event shows the following for code that compiles.  With the 200 millesecond cocoa delay, the two calls run interleaved closely interleaved.  I don't understand the details, but the result is the scrambled and incorrect output given above.  With no delay as with PR 23577, the first call calls restart_subprocess in _run_module_event.  Then call 2 gets to the top of this function, then call 1 appears to finish, and call 2 is somehow aborted.

With a syntax error, the 2nd call, redisplaying the error, is not aborted.

F5 resulting in two calls is not unique, even though I have not yet seen overt double call effects.  In Shell, Control-F6 restarts.  A print in its event handler shows that it is called twice even though there is only 1 restart.

A possible kludge workaround would be to call perf_counter when the class is created and for Cocoa, each run_module call.  Return when new-old < 2milliseconds.  But the double call should be fixed as it could show up elsewhere.

----------
nosy: +serhiy.storchaka, wordtech

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

From report at bugs.python.org  Wed Dec  2 12:16:34 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 02 Dec 2020 17:16:34 +0000
Subject: [issue42507] test_ttk_guionly test failures on macOS with Tcl/Tk
 8.6.10
In-Reply-To: <1606704400.88.0.0493725264205.issue42507@roundup.psfhosted.org>
Message-ID: <1606929394.79.0.637054123501.issue42507@roundup.psfhosted.org>


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

It might be the tk/tkinter build, not the tests, that is at fault.  That is my current conclusion for #42508 (regarding IDLE as a test).

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Wed Dec  2 12:53:19 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 02 Dec 2020 17:53:19 +0000
Subject: [issue42531] importlib.resources.path() raises TypeError for packages
 without __file__
In-Reply-To: <1606890702.39.0.177441013455.issue42531@roundup.psfhosted.org>
Message-ID: <1606931599.13.0.610262763117.issue42531@roundup.psfhosted.org>


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


----------
nosy: +barry, jaraco -brett.cannon

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

From report at bugs.python.org  Wed Dec  2 12:55:15 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 02 Dec 2020 17:55:15 +0000
Subject: [issue40939] Remove the old parser
In-Reply-To: <1591788317.65.0.969058655213.issue40939@roundup.psfhosted.org>
Message-ID: <1606931715.35.0.00856351970372.issue40939@roundup.psfhosted.org>


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

> On Windows there is PC/python3dll.c.

Even that is severely out of date, unfortunately. There are many functions that were removed in 3.8 and 3.7 that are still listed there.

----------

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

From report at bugs.python.org  Wed Dec  2 12:56:45 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 02 Dec 2020 17:56:45 +0000
Subject: [issue42521] Debug (-d) mode not working in 3.9
In-Reply-To: <1606821339.69.0.708367922333.issue42521@roundup.psfhosted.org>
Message-ID: <1606931805.53.0.951126265276.issue42521@roundup.psfhosted.org>


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


New changeset 99b594404d364b363c184f48338d6ee81bee26dd by Pablo Galindo in branch 'master':
bpo-42521: Add note about 'Python -d' only working on debug builds (GH-23607)
https://github.com/python/cpython/commit/99b594404d364b363c184f48338d6ee81bee26dd


----------

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

From report at bugs.python.org  Wed Dec  2 12:57:08 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Dec 2020 17:57:08 +0000
Subject: [issue42521] Debug (-d) mode not working in 3.9
In-Reply-To: <1606821339.69.0.708367922333.issue42521@roundup.psfhosted.org>
Message-ID: <1606931828.5.0.583955826296.issue42521@roundup.psfhosted.org>


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


----------
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +22483
pull_request: https://github.com/python/cpython/pull/23615

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

From report at bugs.python.org  Wed Dec  2 12:57:22 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 02 Dec 2020 17:57:22 +0000
Subject: [issue41625] Add splice() to the os module
In-Reply-To: <1598284638.54.0.211220433787.issue41625@roundup.psfhosted.org>
Message-ID: <1606931842.6.0.0929276129735.issue41625@roundup.psfhosted.org>


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


New changeset dedc2cd5f02a2e2fc2c995a36a3dccf9d93856bb by Pablo Galindo in branch 'master':
bpo-41625: Do not add os.splice on AIX due to compatibility issues (GH-23608)
https://github.com/python/cpython/commit/dedc2cd5f02a2e2fc2c995a36a3dccf9d93856bb


----------

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

From report at bugs.python.org  Wed Dec  2 12:57:39 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 02 Dec 2020 17:57:39 +0000
Subject: [issue41625] Add splice() to the os module
In-Reply-To: <1598284638.54.0.211220433787.issue41625@roundup.psfhosted.org>
Message-ID: <1606931859.52.0.99582428381.issue41625@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/issue41625>
_______________________________________

From report at bugs.python.org  Wed Dec  2 12:59:23 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 02 Dec 2020 17:59:23 +0000
Subject: [issue42521] Debug (-d) mode not working in 3.9
In-Reply-To: <1606821339.69.0.708367922333.issue42521@roundup.psfhosted.org>
Message-ID: <1606931963.6.0.67534267883.issue42521@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/issue42521>
_______________________________________

From report at bugs.python.org  Wed Dec  2 13:00:30 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 02 Dec 2020 18:00:30 +0000
Subject: [issue42541] Tkinter colours wrong on MacOS universal2
In-Reply-To: <1606920595.63.0.665509072103.issue42541@roundup.psfhosted.org>
Message-ID: <1606932030.47.0.832460297066.issue42541@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

With some luck it might be possible to work around this. If it isn?t we should at least opt out of dark mode for IDLE by changing its Info.plist.


https://developer.apple.com/documentation/appkit/nsappearancecustomization/choosing_a_specific_appearance_for_your_macos_app

https://wiki.tcl-lang.org/page/Tk+differences+on+Mac+OS+X

BTW. @epaine: could you file an issue about this in the Tk tracker if you can reproduce it directly with Tk (without Tkinter)?

----------

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

From report at bugs.python.org  Wed Dec  2 13:11:26 2020
From: report at bugs.python.org (E. Paine)
Date: Wed, 02 Dec 2020 18:11:26 +0000
Subject: [issue42541] Tkinter colours wrong on MacOS universal2
In-Reply-To: <1606920595.63.0.665509072103.issue42541@roundup.psfhosted.org>
Message-ID: <1606932686.56.0.499229815386.issue42541@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

It seems to be some weird internal mismatch. Code modified from https://wiki.tcl-lang.org/page/Tk+differences+on+Mac+OS+X (see following) suggests that dark mode is not enabled for the window (and yet we are getting white foreground colours)

import tkinter as tk
root = tk.Tk()
print(root.tk.call("tk::unsupported::MacWindowStyle", "isdark", "."))

I presume this is a MacOS 11 issue. I will look into raising this with the Tk team.

----------

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

From report at bugs.python.org  Wed Dec  2 15:13:46 2020
From: report at bugs.python.org (Cameron Hudson)
Date: Wed, 02 Dec 2020 20:13:46 +0000
Subject: [issue36964] `python3 -m venv NAME`: virtualenv is not portable
In-Reply-To: <1558267639.25.0.0700835222258.issue36964@roundup.psfhosted.org>
Message-ID: <1606940026.66.0.775379557225.issue36964@roundup.psfhosted.org>


Cameron Hudson <CameronHudson8 at gmail.com> added the comment:

@MarcoSulla thank you for opening this issue, it is a very necessary improvement.

My use case: I install packages one machine inside VPN, which downloads from a private pypi repo. I then package this as a zip file and deploy it on a cloud-hosted VM. I cannot simply reinstall the dependencies on the VM, because it can't reach the private pypi repo.

I have not contributed to Python before, but I am happy to help with reviewing a PR with the changes that you suggested.

----------
nosy: +CameronHudson8

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

From report at bugs.python.org  Wed Dec  2 15:45:17 2020
From: report at bugs.python.org (Alex Sherman)
Date: Wed, 02 Dec 2020 20:45:17 +0000
Subject: [issue42544] In windows,
 asyncio.run_in_executor strips logger class information from modified
 logging.Logger objects
Message-ID: <1606941917.4.0.387310203547.issue42544@roundup.psfhosted.org>


New submission from Alex Sherman <adsherman09 at gmail.com>:

IN WINDOWS asyncio's loop.run_in_executor(pool, callback, logger, *args) strips the subclass information about logging.Loggers when passed into concurrent.futures.ProcessPoolExecutor. The logger behaves as a default logging.Logger object as far as I can tell.

Run the attached file to see via print statements that the logger information (such as additional verbosity and file handling) is all removed from the logger but only inside the loop.run_in_executor call. 

This is a windows specific error. Tested on windows 10 (misbehaved) and ubuntu 18.04 (behaved as expected).

----------
components: IO, asyncio
files: example_logger_behavior.py
messages: 382335
nosy: adsherman09, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: In windows, asyncio.run_in_executor strips logger class information from modified logging.Logger objects
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49648/example_logger_behavior.py

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

From report at bugs.python.org  Wed Dec  2 15:52:19 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 02 Dec 2020 20:52:19 +0000
Subject: [issue42545] Check that all symbols in the limited ABI are exported
Message-ID: <1606942339.51.0.833109264536.issue42545@roundup.psfhosted.org>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

>From the discussion at the end of https://bugs.python.org/issue40939 is important to add a check to the CI that can tell us if we mistakenly remove a symbol of the limited ABI.

----------
components: Tests
messages: 382336
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Check that all symbols in the limited ABI are exported
versions: Python 3.10

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

From report at bugs.python.org  Wed Dec  2 15:52:28 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 02 Dec 2020 20:52:28 +0000
Subject: [issue40939] Remove the old parser
In-Reply-To: <1591788317.65.0.969058655213.issue40939@roundup.psfhosted.org>
Message-ID: <1606942348.61.0.658229457621.issue40939@roundup.psfhosted.org>


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

Opened https://bugs.python.org/issue42545 for that

----------

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

From report at bugs.python.org  Wed Dec  2 15:53:01 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 02 Dec 2020 20:53:01 +0000
Subject: [issue42545] Check that all symbols in the limited ABI are exported
In-Reply-To: <1606942339.51.0.833109264536.issue42545@roundup.psfhosted.org>
Message-ID: <1606942381.92.0.754808507635.issue42545@roundup.psfhosted.org>


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


----------
keywords: +patch
pull_requests: +22484
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23616

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

From report at bugs.python.org  Wed Dec  2 15:57:34 2020
From: report at bugs.python.org (Daniel Rose)
Date: Wed, 02 Dec 2020 20:57:34 +0000
Subject: [issue42546] copy - Allow .copy(deep=True) alongside .deepcopy() for
 easier usage and zen
Message-ID: <1606942654.49.0.938602064992.issue42546@roundup.psfhosted.org>


New submission from Daniel Rose <daniel at whitehatcat.net>:

It would be convenient and cleaner/more in line with the Python zen to allow `.copy()` to allow a `deep=True` argument, to use `.deepcopy()` in a simpler way. This is easier to read, and brings some more usefulness to `.copy()`. `.deepcopy()` would be kept for backwards compatibility.

----------
components: Library (Lib)
messages: 382338
nosy: TheCatster
priority: normal
severity: normal
status: open
title: copy - Allow .copy(deep=True) alongside .deepcopy() for easier usage and zen
type: enhancement
versions: Python 3.9

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

From report at bugs.python.org  Wed Dec  2 16:04:10 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 02 Dec 2020 21:04:10 +0000
Subject: [issue42546] copy - Allow .copy(deep=True) alongside .deepcopy() for
 easier usage and zen
In-Reply-To: <1606942654.49.0.938602064992.issue42546@roundup.psfhosted.org>
Message-ID: <20201202210402.GZ31170@ando.pearwood.info>


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

This would be a classic example of the "Flag argument" anti-pattern:

https://www.martinfowler.com/bliki/FlagArgument.html

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

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

From report at bugs.python.org  Wed Dec  2 16:06:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Dec 2020 21:06:04 +0000
Subject: [issue42536] test_itertools leaks sometimes references
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1606943164.53.0.151035607615.issue42536@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> nosy: + rhettinger, serhiy.storchaka

I wanted to bisect this test before annoying too many people with this random issue. So far, I managed to simplified test_itertools to:

def test_main(verbose=None):
    test_classes = (
        TestBasicOps,
        TestVariousIteratorArgs,
        TestGC,
    )
    support.run_unittest(*test_classes)

----------

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

From report at bugs.python.org  Wed Dec  2 16:15:50 2020
From: report at bugs.python.org (Mikhail Khvoinitsky)
Date: Wed, 02 Dec 2020 21:15:50 +0000
Subject: [issue42547] argparse: add_argument(... nargs='+',
 metavar=<tuple>) does not work with positional arguments
Message-ID: <1606943750.61.0.237402460323.issue42547@roundup.psfhosted.org>


New submission from Mikhail Khvoinitsky <bugs.python.org at khvoinitsky.org>:

Example which works:

    parser.add_argument('--test', nargs='+', metavar=('TEST', 'TEST2'))



Example which doesn't work:

    parser.add_argument('test', nargs='+', metavar=('TEST', 'TEST2'))

it raises:

    Traceback (most recent call last):
      File <omitted>
        args = parser.parse_args()
      File "/usr/lib/python3.8/argparse.py", line 1768, in parse_args
        args, argv = self.parse_known_args(args, namespace)
      File "/usr/lib/python3.8/argparse.py", line 1800, in parse_known_args
        namespace, args = self._parse_known_args(args, namespace)
      File "/usr/lib/python3.8/argparse.py", line 2006, in _parse_known_args
        start_index = consume_optional(start_index)
      File "/usr/lib/python3.8/argparse.py", line 1946, in consume_optional
        take_action(action, args, option_string)
      File "/usr/lib/python3.8/argparse.py", line 1874, in take_action
        action(self, namespace, argument_values, option_string)
      File "/usr/lib/python3.8/argparse.py", line 1044, in __call__
        parser.print_help()
      File "/usr/lib/python3.8/argparse.py", line 2494, in print_help
        self._print_message(self.format_help(), file)
      File "/usr/lib/python3.8/argparse.py", line 2471, in format_help
        formatter.add_arguments(action_group._group_actions)
      File "/usr/lib/python3.8/argparse.py", line 276, in add_arguments
        self.add_argument(action)
      File "/usr/lib/python3.8/argparse.py", line 261, in add_argument
        invocations = [get_invocation(action)]
      File "/usr/lib/python3.8/argparse.py", line 549, in _format_action_invocation
        metavar, = self._metavar_formatter(action, default)(1)
    ValueError: too many values to unpack (expected 1)


Expected result: help message should look like this:

    usage: test_argparse [-h] TEST [TEST2 ...]

    positional arguments:
      TEST

    optional arguments:
      -h, --help  show this help message and exit

----------
components: Library (Lib)
messages: 382341
nosy: m_khvoinitsky
priority: normal
severity: normal
status: open
title: argparse: add_argument(... nargs='+', metavar=<tuple>) does not work with positional arguments
type: crash
versions: Python 3.10

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

From report at bugs.python.org  Wed Dec  2 16:17:39 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 02 Dec 2020 21:17:39 +0000
Subject: [issue42536] test_itertools leaks sometimes references
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1606943859.47.0.753855083067.issue42536@roundup.psfhosted.org>


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

You can get a list of all tests with --list-cases and then run them in separate processes.

----------

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

From report at bugs.python.org  Wed Dec  2 16:21:42 2020
From: report at bugs.python.org (Mikhail Khvoinitsky)
Date: Wed, 02 Dec 2020 21:21:42 +0000
Subject: [issue42547] argparse: add_argument(... nargs='+',
 metavar=<tuple>) does not work with positional arguments
In-Reply-To: <1606943750.61.0.237402460323.issue42547@roundup.psfhosted.org>
Message-ID: <1606944102.75.0.536318148462.issue42547@roundup.psfhosted.org>


Change by Mikhail Khvoinitsky <bugs.python.org at khvoinitsky.org>:


----------
keywords: +patch
pull_requests: +22485
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23617

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

From report at bugs.python.org  Wed Dec  2 16:25:18 2020
From: report at bugs.python.org (Irit Katriel)
Date: Wed, 02 Dec 2020 21:25:18 +0000
Subject: [issue30701] Exception parsing certain invalid email address headers
In-Reply-To: <1497864347.44.0.160991763633.issue30701@psf.upfronthosting.co.za>
Message-ID: <1606944318.04.0.3010632463.issue30701@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

I don't see the error now, I think this has been fixed.

----------
nosy: +iritkatriel
status: open -> pending

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

From report at bugs.python.org  Wed Dec  2 16:32:03 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 02 Dec 2020 21:32:03 +0000
Subject: [issue42536] test_itertools leaks sometimes references
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1606944723.9.0.993878058899.issue42536@roundup.psfhosted.org>


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

Thanks.  I'll work on it this evening.  If this is new, pairwise() is the most likely cause.

----------
assignee:  -> rhettinger

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

From report at bugs.python.org  Wed Dec  2 16:42:27 2020
From: report at bugs.python.org (Daniel Rose)
Date: Wed, 02 Dec 2020 21:42:27 +0000
Subject: [issue42546] copy - Allow dict.copy(deep=True) alongside
 copy.deepcopy() for easier usage and zen
In-Reply-To: <1606942654.49.0.938602064992.issue42546@roundup.psfhosted.org>
Message-ID: <1606945347.33.0.0487130732408.issue42546@roundup.psfhosted.org>


Change by Daniel Rose <daniel at whitehatcat.net>:


----------
title: copy - Allow .copy(deep=True) alongside .deepcopy() for easier usage and zen -> copy - Allow dict.copy(deep=True) alongside copy.deepcopy() for easier usage and zen

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

From report at bugs.python.org  Wed Dec  2 16:43:10 2020
From: report at bugs.python.org (Daniel Rose)
Date: Wed, 02 Dec 2020 21:43:10 +0000
Subject: [issue42546] copy - Allow dict.copy(deep=True) alongside
 copy.deepcopy() for easier usage and zen
In-Reply-To: <1606942654.49.0.938602064992.issue42546@roundup.psfhosted.org>
Message-ID: <1606945390.43.0.763012836086.issue42546@roundup.psfhosted.org>


Daniel Rose <daniel at whitehatcat.net> added the comment:

My apologies. I worded that wrong, I meant adding `deep=True` to `dict.copy()`. Otherwise, you're absolutely right.

----------

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

From report at bugs.python.org  Wed Dec  2 16:46:26 2020
From: report at bugs.python.org (Irit Katriel)
Date: Wed, 02 Dec 2020 21:46:26 +0000
Subject: [issue38283] sys._getframe(1).f_lineno changed behavior in 3.8
In-Reply-To: <1569489054.37.0.072331097916.issue38283@roundup.psfhosted.org>
Message-ID: <1606945586.82.0.345010787679.issue38283@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


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

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

From report at bugs.python.org  Wed Dec  2 16:59:40 2020
From: report at bugs.python.org (Marco Sulla)
Date: Wed, 02 Dec 2020 21:59:40 +0000
Subject: [issue36964] `python3 -m venv NAME`: virtualenv is not portable
In-Reply-To: <1558267639.25.0.0700835222258.issue36964@roundup.psfhosted.org>
Message-ID: <1606946380.69.0.721279235473.issue36964@roundup.psfhosted.org>


Marco Sulla <launchpad.net at marco.sulla.e4ward.com> added the comment:

The PR will probably be rejected... you can do something like this:

1. in the venv on our machine, do `pip freeze`. This gives you the whole list of installed dependencies
2. download all the packages using `pip download`
3. copy all the packages on the cloud, create the venv and install them using `pip install $PATH_TO_PACKAGE`

----------

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

From report at bugs.python.org  Wed Dec  2 16:59:45 2020
From: report at bugs.python.org (Irit Katriel)
Date: Wed, 02 Dec 2020 21:59:45 +0000
Subject: [issue42546] copy - Allow dict.copy(deep=True) alongside
 copy.deepcopy() for easier usage and zen
In-Reply-To: <1606942654.49.0.938602064992.issue42546@roundup.psfhosted.org>
Message-ID: <1606946385.24.0.811018468419.issue42546@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

Deprecating an API is a big project. To justify the time people would have to put into this, it needs to have significant benefits. I don't see them and the OP didn't explain what they are. 

Suggestions like this should ideally be brought up for discussion on the python-ideas mailing list before submitted here.

----------
nosy: +iritkatriel
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Dec  2 16:59:51 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 02 Dec 2020 21:59:51 +0000
Subject: [issue42545] Check that all symbols in the limited ABI are exported
In-Reply-To: <1606942339.51.0.833109264536.issue42545@roundup.psfhosted.org>
Message-ID: <1606946391.87.0.828486945661.issue42545@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Wed Dec  2 17:01:27 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 02 Dec 2020 22:01:27 +0000
Subject: [issue42521] Debug (-d) mode not working in 3.9
In-Reply-To: <1606821339.69.0.708367922333.issue42521@roundup.psfhosted.org>
Message-ID: <1606946487.65.0.106072557632.issue42521@roundup.psfhosted.org>


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


New changeset 9b34f34aa929941576a69a6f7de77f1fb0b96ed6 by Miss Islington (bot) in branch '3.9':
bpo-42521: Add note about 'Python -d' only working on debug builds (GH-23607)
https://github.com/python/cpython/commit/9b34f34aa929941576a69a6f7de77f1fb0b96ed6


----------

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

From report at bugs.python.org  Wed Dec  2 17:23:43 2020
From: report at bugs.python.org (Irit Katriel)
Date: Wed, 02 Dec 2020 22:23:43 +0000
Subject: [issue23805] _hashlib compile error?
In-Reply-To: <1427631801.6.0.245894260937.issue23805@psf.upfronthosting.co.za>
Message-ID: <1606947823.19.0.765274629757.issue23805@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

Freddy, this issue is 5 years old with no activity and no indicated action for the python devs, so I am closing it. If you are still seeing compilation errors, please create a new one and update it with more details.

----------
nosy: +iritkatriel
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Dec  2 17:25:09 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 02 Dec 2020 22:25:09 +0000
Subject: [issue42531] importlib.resources.path() raises TypeError for packages
 without __file__
In-Reply-To: <1606890702.39.0.177441013455.issue42531@roundup.psfhosted.org>
Message-ID: <1606947909.36.0.00370531878557.issue42531@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Thanks William for the detailed problem description.

If the issue has been fixed on Python 3.9 but not on 3.8, then it was likely a redesign that enabled the improved behavior, a redesign that won't be ported back to Python 3.8 and earlier. In these situations, the best recommendation is often to just rely on importlib_resources (the backport) for those older Python versions.

In this case, you've identified a fairly surgical fix that may be suitable to apply to these older affected Pythons, so I'll consider that, but before I do, have you considered using importlib_resources for Python 3.8 and earlier? That would likely also address the issue and you could adopt it sooner.

To some extent, the behavior you've described could be considered a bug or could be considered a feature request (add support for path on packages that have no __spec__.origin). I am not aware whether this limitation was by design or incidental.

----------

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

From report at bugs.python.org  Wed Dec  2 17:36:25 2020
From: report at bugs.python.org (Andy S)
Date: Wed, 02 Dec 2020 22:36:25 +0000
Subject: [issue42548] debugger stops at breakpoint of `pass` that is not
 actually reached
Message-ID: <1606948585.89.0.450511023817.issue42548@roundup.psfhosted.org>


New submission from Andy S <gatekeeper.mail at gmail.com>:

The python (3.6) doc states (https://docs.python.org/3/reference/simple_stmts.html#the-pass-statement):

pass is a null operation...

So since this is still an operation one could expect that it can be used as an op to breakpoint on while debugging some scripts.

Nevertheless:

$ pdb3.7 ./debug_bug.py 
> /...play/debug_bug.py(1)<module>()
-> a = None
(Pdb) list
  1  -> a = None
  2  
  3  
  4     def fun():
  5         b = False
  6         if a is None:
  7             b = True
  8             pass
  9         else:
 10             pass
 11  
(Pdb) 
 12  
 13     fun()
 14     pass
[EOF]
(Pdb) b 10
Breakpoint 1 at /...play/debug_bug.py:10
(Pdb) run
Restarting ./debug_bug.py with arguments:
        ./debug_bug.py
> /...play/debug_bug.py(1)<module>()
-> a = None
(Pdb) continue
> /...play/debug_bug.py(10)fun()
-> pass
(Pdb) bt
  /usr/lib/python3.7/bdb.py(585)run()
-> exec(cmd, globals, locals)
  <string>(1)<module>()
  /...play/debug_bug.py(13)<module>()
-> fun()
> /...play/debug_bug.py(10)fun()
-> pass
(Pdb) p b
True
(Pdb)

----------
components: Interpreter Core, Library (Lib)
files: debug_bug.py
messages: 382351
nosy: gatekeeper.mail
priority: normal
severity: normal
status: open
title: debugger stops at breakpoint of `pass` that is not actually reached
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file49649/debug_bug.py

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

From report at bugs.python.org  Wed Dec  2 17:47:22 2020
From: report at bugs.python.org (Kevin Walzer)
Date: Wed, 02 Dec 2020 22:47:22 +0000
Subject: [issue42541] Tkinter colours wrong on MacOS universal2
In-Reply-To: <1606920595.63.0.665509072103.issue42541@roundup.psfhosted.org>
Message-ID: <1606949242.3.0.829013272937.issue42541@roundup.psfhosted.org>


Kevin Walzer <wordtech at users.sourceforge.net> added the comment:

This bug is not present in IDLE 3.9.0 when built against the tip of Tk core-8-6-branch. Marc Culler has done some work to fix the visual artifacts, and the work continues. The problem here is that Apple's API churn continually breaks parts of Tk with each new OS release, and there is large amount of work just to keep things working reasonably.

----------
nosy: +wordtech

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

From report at bugs.python.org  Wed Dec  2 18:00:30 2020
From: report at bugs.python.org (Irit Katriel)
Date: Wed, 02 Dec 2020 23:00:30 +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: <1606950030.96.0.814246934956.issue8535@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


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

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

From report at bugs.python.org  Wed Dec  2 18:08:53 2020
From: report at bugs.python.org (Irit Katriel)
Date: Wed, 02 Dec 2020 23:08:53 +0000
Subject: [issue35342] email "default" policy raises exception iterating over
 unparseable date headers
In-Reply-To: <1543426629.99.0.788709270274.issue35342@psf.upfronthosting.co.za>
Message-ID: <1606950533.87.0.561054187347.issue35342@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

I get this. Was the bug fixed?

>>> email.message_from_string('Date: not a parseable date', policy=email.policy.default).items()
[('Date', 'not a parseable date')]

----------
nosy: +iritkatriel
status: open -> pending

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

From report at bugs.python.org  Wed Dec  2 18:10:28 2020
From: report at bugs.python.org (Julien Palard)
Date: Wed, 02 Dec 2020 23:10:28 +0000
Subject: [issue36675] Doctest directives and comments missing from code samples
In-Reply-To: <1555757030.56.0.8094269644.issue36675@roundup.psfhosted.org>
Message-ID: <1606950628.25.0.892937490011.issue36675@roundup.psfhosted.org>


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


----------
pull_requests: +22488
pull_request: https://github.com/python/cpython/pull/23620

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

From report at bugs.python.org  Wed Dec  2 18:11:21 2020
From: report at bugs.python.org (Dieter Maurer)
Date: Wed, 02 Dec 2020 23:11:21 +0000
Subject: [issue42549] "quopri" line endings not standard conform
Message-ID: <1606950681.46.0.919700601419.issue42549@roundup.psfhosted.org>


New submission from Dieter Maurer <dieter at handshake.de>:

RFC 1521 and "https://tools.ietf.org/html/rfc2045#section-6.7"
stipulate that the quoted printable encoding uses CRLF line endings. Python's "quopri" implementation does not honor this.

----------
components: Library (Lib)
messages: 382354
nosy: dmaurer
priority: normal
severity: normal
status: open
title: "quopri" line endings not standard conform
type: behavior

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

From report at bugs.python.org  Wed Dec  2 18:15:42 2020
From: report at bugs.python.org (Julien Palard)
Date: Wed, 02 Dec 2020 23:15:42 +0000
Subject: [issue42324] Doctest: directives
In-Reply-To: <1605095870.49.0.104658534517.issue42324@roundup.psfhosted.org>
Message-ID: <1606950942.23.0.641856642708.issue42324@roundup.psfhosted.org>


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

Thanks for reporting!

This will be fixed soon: https://github.com/python/cpython/pull/23620

I'm marking issue42324 as duplicate of issue36675.

----------
nosy: +mdk
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Doctest directives and comments missing from code samples

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

From report at bugs.python.org  Wed Dec  2 18:43:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Dec 2020 23:43:56 +0000
Subject: [issue42536] test_itertools leaks sometimes references
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1606952636.01.0.834530690587.issue42536@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I reproduce the leak with attached test_zip.py by running:

$ ./python -m test -R 3:3 test_zip_leak -j4 -m test.test_zip_leak.TestGC.test_permutations -m test.test_zip_leak.TestGC.test_zip

The problem is that the builtin zip class keeps an internal tuple alive. See zip_next) and zipobject.result member (tuple).

----------
Added file: https://bugs.python.org/file49650/test_zip_leak.py

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

From report at bugs.python.org  Wed Dec  2 18:45:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Dec 2020 23:45:17 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1606952717.98.0.329485214133.issue42536@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: test_itertools leaks sometimes references -> Iterating on a zip keeps objects alive longer than expected (test_itertools leaks sometimes references)

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

From report at bugs.python.org  Wed Dec  2 18:50:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Dec 2020 23:50:25 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1606953025.93.0.400102099548.issue42536@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Raymond Hettinger:
> If this is new, pairwise() is the most likely cause.

I reproduced the issue without involving the itertools module. It seems to be a zip_next() micro-optimization which keeps an object alive longer than epxected. This micro-optimization is not new. It's just really hard to trigger the issue.

It seems to depend if the zip object is deleted or not. The builtin zip type implements a traverse function which visits Py_VISIT(lz->result). The GC is supposed to be able to break such cycle, no?

----------

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

From report at bugs.python.org  Wed Dec  2 18:53:43 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 02 Dec 2020 23:53:43 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1606953223.61.0.331843948549.issue42536@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> The GC is supposed to be able to break such cycle, no?

In zip_new(), lz->result tuple is *not* always tracked by the GC.

----------

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

From report at bugs.python.org  Wed Dec  2 18:59:25 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Wed, 02 Dec 2020 23:59:25 +0000
Subject: [issue38520] There is no proper way to know if a process is the main
 one
In-Reply-To: <1571431695.05.0.294533702536.issue38520@roundup.psfhosted.org>
Message-ID: <1606953565.9.0.488701152901.issue38520@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 4.0 -> 5.0
pull_requests: +22489
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23621

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

From report at bugs.python.org  Wed Dec  2 19:07:42 2020
From: report at bugs.python.org (Sara Kelley)
Date: Thu, 03 Dec 2020 00:07:42 +0000
Subject: [issue31990] Pickling deadlocks in thread with python -m
In-Reply-To: <1510222459.1.0.213398074469.issue31990@psf.upfronthosting.co.za>
Message-ID: <1606954062.03.0.772962093621.issue31990@roundup.psfhosted.org>


Sara Kelley <serakeri at gmail.com> added the comment:

https://docs.python.org/3/using/cmdline.html#cmdoption-m

The documentation says you must not give a file extension with the module option. Because the extension was given the thread is deadlocking in importlib._bootstrap when trying to acquire the module lock. The hang occurs in the script because join() is waiting for the deadlocked thread.

----------

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

From report at bugs.python.org  Wed Dec  2 19:13:57 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 03 Dec 2020 00:13:57 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1606954437.02.0.908394157537.issue42536@roundup.psfhosted.org>


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

Adding Brandt because he recently worked on the zip() code.

----------
nosy: +brandtbucher

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

From report at bugs.python.org  Wed Dec  2 19:20:29 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 03 Dec 2020 00:20:29 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1606954829.68.0.223580948017.issue42536@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/issue42536>
_______________________________________

From report at bugs.python.org  Wed Dec  2 19:59:11 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 03 Dec 2020 00:59:11 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1606957151.79.0.198416844122.issue42536@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

It looks like the GC untracks the None-filled result tuple in untrack_tuples, and it's never re-tracked again. This can also happen if it's filled with atomic values on an early iteration and the GC visits it.

Perhaps a simple fix is to call _PyObject_GC_TRACK on the result tuple inside of each zip_next call if it's not tracked anymore?

if (!_PyObject_GC_IS_TRACKED(result)) {
    _PyObject_GC_TRACK(result);
}
_PyTuple_MaybeUntrack(result);  // Worth it?
return result;

Although I'm not sure how much of a win we're getting from the result tuple reuse here - maybe it's easier to just not do that.

----------

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

From report at bugs.python.org  Wed Dec  2 20:14:54 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 03 Dec 2020 01:14:54 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1606958094.05.0.739981144948.issue42536@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

Simple demo:

>>> import gc
>>> gc.disable()
>>> z = zip([[]])
>>> gc.is_tracked(next(z))
True
>>> z = zip([[]])
>>> gc.collect()
0
>>> gc.is_tracked(next(z))
False

----------

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

From report at bugs.python.org  Wed Dec  2 20:16:45 2020
From: report at bugs.python.org (Ned Deily)
Date: Thu, 03 Dec 2020 01:16:45 +0000
Subject: [issue42541] Tkinter colours wrong on MacOS universal2
In-Reply-To: <1606920595.63.0.665509072103.issue42541@roundup.psfhosted.org>
Message-ID: <1606958205.23.0.673913227592.issue42541@roundup.psfhosted.org>


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

Thanks for checking, Kevin. Is there any update on when we can expect a Tk 8.6.11?  It's been over a year now since 8.6.10 and there have been so many macOS-related changes that have gone into Tk since then. It's really not fair to ask downstream packagers, like us for the python.org installers, or end users to build with an arbitrary checkpoint of the development branch. Even a beta 8.6.11 would be an improvement.

----------

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

From report at bugs.python.org  Wed Dec  2 20:20:08 2020
From: report at bugs.python.org (Ned Deily)
Date: Thu, 03 Dec 2020 01:20:08 +0000
Subject: [issue42507] test_ttk_guionly test failures on macOS with Tcl/Tk
 8.6.10
In-Reply-To: <1606704400.88.0.0493725264205.issue42507@roundup.psfhosted.org>
Message-ID: <1606958408.63.0.21263266661.issue42507@roundup.psfhosted.org>


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

Terry:
> It might be the tk/tkinter build, not the tests, that is at fault.

Can you elaborate?

----------

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

From report at bugs.python.org  Wed Dec  2 21:02:03 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 03 Dec 2020 02:02:03 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1606960923.31.0.257464955997.issue42536@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

Some quick benchmarks on a normal build with CPU isolation, tuned with pyperf. No PGO/LTO.

$ ./python -m pyperf timeit --rigorous --setup 'i = (None,) * 10_000_000' 'for _, _ in zip(i, i): pass'  # Current master.
.........................................
Mean +- std dev: 279 ms +- 11 ms

$ ./python -m pyperf timeit --rigorous --setup 'i = (None,) * 10_000_000' 'for _, _ in zip(i, i): pass'  # With above fix.
.........................................
Mean +- std dev: 369 ms +- 20 ms

$ ./python -m pyperf timeit --rigorous --setup 'i = (None,) * 10_000_000' 'for _, _ in zip(i, i): pass'  # With above fix (no _PyTuple_MaybeUntrack).
.........................................
Mean +- std dev: 284 ms +- 17 ms

$ ./python -m pyperf timeit --rigorous --setup 'i = (None,) * 10_000_000' 'for _, _ in zip(i, i): pass'  # With no tuple reuse.
.........................................
Mean +- std dev: 526 ms +- 51 ms

Note that this example reuses the result tuple for *every* iteration.

----------

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

From report at bugs.python.org  Wed Dec  2 21:06:16 2020
From: report at bugs.python.org (Kevin Walzer)
Date: Thu, 03 Dec 2020 02:06:16 +0000
Subject: [issue42541] Tkinter colours wrong on MacOS universal2
In-Reply-To: <1606920595.63.0.665509072103.issue42541@roundup.psfhosted.org>
Message-ID: <1606961176.55.0.867131057406.issue42541@roundup.psfhosted.org>


Kevin Walzer <wordtech at users.sourceforge.net> added the comment:

Ned, I wish I knew. Marc and I are both now members of the TCT, and have had a few conversations around the release schedule, but the release schedule is more or less determined when one or two senior members of the TCT decide things are ready. We had some momentum toward an RC of 8.6.11 a few months ago, but that seems to have stalled out.

----------

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

From report at bugs.python.org  Wed Dec  2 21:38:33 2020
From: report at bugs.python.org (ye andy)
Date: Thu, 03 Dec 2020 02:38:33 +0000
Subject: =?utf-8?b?W2lzc3VlNDI1NTBdIHJl5bqT5Yy56YWN6Zeu6aKY?=
Message-ID: <1606963113.63.0.536238231027.issue42550@roundup.psfhosted.org>


New submission from ye andy <andy.ye.jx at gmail.com>:

import re
a = """0xd26935a5ee4cd542e8a3a7e74fb7a99855975b59\n"""

eth_re = re.compile(r'^0x[0-9a-fA-F]{40}$')

print(eth_re.match(a))
print(len(a)) # ??43

----------
components: Library (Lib)
messages: 382367
nosy: andy.ye.jx
priority: normal
severity: normal
status: open
title: re?????
type: security
versions: Python 3.6

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

From report at bugs.python.org  Wed Dec  2 21:48:49 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 03 Dec 2020 02:48:49 +0000
Subject: [issue42547] argparse: add_argument(... nargs='+',
 metavar=<tuple>) does not work with positional arguments
In-Reply-To: <1606943750.61.0.237402460323.issue42547@roundup.psfhosted.org>
Message-ID: <1606963729.19.0.715222140453.issue42547@roundup.psfhosted.org>


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


----------
nosy: +paul.j3, rhettinger

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

From report at bugs.python.org  Wed Dec  2 21:57:52 2020
From: report at bugs.python.org (paul j3)
Date: Thu, 03 Dec 2020 02:57:52 +0000
Subject: [issue42547] argparse: add_argument(... nargs='+',
 metavar=<tuple>) does not work with positional arguments
In-Reply-To: <1606943750.61.0.237402460323.issue42547@roundup.psfhosted.org>
Message-ID: <1606964272.49.0.00475426907356.issue42547@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

Duplicate of

https://bugs.python.org/issue14074

argparse allows nargs>1 for positional arguments but doesn't allow metavar to be a tuple

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

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

From report at bugs.python.org  Wed Dec  2 22:00:28 2020
From: report at bugs.python.org (paul j3)
Date: Thu, 03 Dec 2020 03:00:28 +0000
Subject: [issue42547] argparse: add_argument(... nargs='+',
 metavar=<tuple>) does not work with positional arguments
In-Reply-To: <1606943750.61.0.237402460323.issue42547@roundup.psfhosted.org>
Message-ID: <1606964428.22.0.29315091599.issue42547@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

I'll reopen it - your patch, while not a complete resolution, does take care of the immediate error.

----------
resolution: duplicate -> 
status: closed -> open

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

From report at bugs.python.org  Wed Dec  2 22:09:14 2020
From: report at bugs.python.org (Sara Kelley)
Date: Thu, 03 Dec 2020 03:09:14 +0000
Subject: [issue31990] Pickling deadlocks in thread with python -m
In-Reply-To: <1510222459.1.0.213398074469.issue31990@psf.upfronthosting.co.za>
Message-ID: <1606964954.62.0.999062036924.issue31990@roundup.psfhosted.org>


Sara Kelley <serakeri at gmail.com> added the comment:

After looking a little more I don't believe the extension is the problem, but it is an easier way to see the problem. When testqueuepickle3 is run as a script you don't see the error. When it is imported as a module, even from another script with valid syntax, it does deadlock.

----------

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

From report at bugs.python.org  Wed Dec  2 22:20:51 2020
From: report at bugs.python.org (Ned Deily)
Date: Thu, 03 Dec 2020 03:20:51 +0000
Subject: [issue42504] Failure to build with MACOSX_DEPLOYMENT_TARGET=11 on Big
 Sur
In-Reply-To: <1606662964.61.0.531913261121.issue42504@roundup.psfhosted.org>
Message-ID: <1606965651.02.0.504608365397.issue42504@roundup.psfhosted.org>


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


New changeset 5291639e611dc3f55a34666036f2c3424648ba50 by FX Coudert in branch 'master':
bpo-42504: fix for MACOSX_DEPLOYMENT_TARGET=11 (GH-23556)
https://github.com/python/cpython/commit/5291639e611dc3f55a34666036f2c3424648ba50


----------

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

From report at bugs.python.org  Wed Dec  2 22:20:56 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Dec 2020 03:20:56 +0000
Subject: [issue42504] Failure to build with MACOSX_DEPLOYMENT_TARGET=11 on Big
 Sur
In-Reply-To: <1606662964.61.0.531913261121.issue42504@roundup.psfhosted.org>
Message-ID: <1606965656.51.0.159506277997.issue42504@roundup.psfhosted.org>


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


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +22490
pull_request: https://github.com/python/cpython/pull/23622

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

From report at bugs.python.org  Wed Dec  2 22:23:53 2020
From: report at bugs.python.org (Ned Deily)
Date: Thu, 03 Dec 2020 03:23:53 +0000
Subject: [issue42504] Failure to build with MACOSX_DEPLOYMENT_TARGET=11 on Big
 Sur
In-Reply-To: <1606662964.61.0.531913261121.issue42504@roundup.psfhosted.org>
Message-ID: <1606965833.17.0.949399537447.issue42504@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
versions: +Python 3.10, Python 3.8

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

From report at bugs.python.org  Wed Dec  2 22:43:15 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Dec 2020 03:43:15 +0000
Subject: [issue42504] Failure to build with MACOSX_DEPLOYMENT_TARGET=11 on Big
 Sur
In-Reply-To: <1606662964.61.0.531913261121.issue42504@roundup.psfhosted.org>
Message-ID: <1606966995.4.0.0181517269167.issue42504@roundup.psfhosted.org>


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


New changeset 09a698b4743c669983d606595a1b2daeff6c3cf8 by Miss Islington (bot) in branch '3.9':
bpo-42504: fix for MACOSX_DEPLOYMENT_TARGET=11 (GH-23556)
https://github.com/python/cpython/commit/09a698b4743c669983d606595a1b2daeff6c3cf8


----------

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

From report at bugs.python.org  Wed Dec  2 23:29:39 2020
From: report at bugs.python.org (Matthew Suozzo)
Date: Thu, 03 Dec 2020 04:29:39 +0000
Subject: [issue42551] Generator `yield`s counted as primitive calls by cProfile
Message-ID: <1606969779.69.0.0674581941893.issue42551@roundup.psfhosted.org>


New submission from Matthew Suozzo <matthew.suozzo at gmail.com>:

# Issue

When profiling a generator function, the initial call and all subsequent yields are aggregated into the same "ncalls" metric by cProfile.

## Example

>>> cProfile.run("""
... def foo():
...   yield 1
...   yield 2
... assert tuple(foo()) == (1, 2)
... """)
   <snip>
   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
      ...
        3    0.000    0.000    0.000    0.000 <string>:2(foo)
      ...

This was unexpected behavior since it *looks* like a single call from the code. This also complicates basic analysis about the frequency of a codepath's execution where a generator might yield a variable number of times depending on the input.

The profile interface can and does differentiate between call types: Normal calls and "primitive" calls, i.e. those that are not induced via recursion, are displayed as "all_calls/primitive_calls" e.g. "3/1" for a single initial calls with 2 recursed calls (comparable to the example above).

This seems like an appropriate abstraction to apply in the generator case: Each yield is better modeled as an 'interior' call to the generator, not as a call on its own.

# Possible fix

I have two ideas that seem like they might address the problem:

* Add a new PyTrace_YIELD constant (and handle it in [3])
* Track some state from the `frame->f_gen` in the ProfilerEntry (injected in [3], used in [4]) to determine whether this is the first or a subsequent call.

I've not been poking around for long so I don't have an intuition about which would be less invasive (nor really whether either would work in practice).

As background, this seems to be the call chain from trace invocation to callcount increment:
[0]: https://github.com/python/cpython/blob/4e7a69bdb63a104587759d7784124492dcdd496e/Python/ceval.c#L4106-L4107
[1]: https://github.com/python/cpython/blob/4e7a69bdb63a104587759d7784124492dcdd496e/Python/ceval.c#L4937
[2]: https://github.com/python/cpython/blob/4e7a69bdb63a104587759d7784124492dcdd496e/Python/ceval.c#L4961
[3]: https://github.com/python/cpython/blob/4e7a69bdb63a104587759d7784124492dcdd496e/Modules/_lsprof.c#L419
[4]: https://github.com/python/cpython/blob/4e7a69bdb63a104587759d7784124492dcdd496e/Modules/_lsprof.c#L389
[5]: https://github.com/python/cpython/blob/4e7a69bdb63a104587759d7784124492dcdd496e/Modules/_lsprof.c#L311-L316

----------
components: C API
messages: 382373
nosy: matthew.suozzo
priority: normal
severity: normal
status: open
title: Generator `yield`s counted as primitive calls by cProfile
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Wed Dec  2 23:32:59 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 03 Dec 2020 04:32:59 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1606969979.61.0.129986167289.issue42536@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
keywords: +patch
pull_requests: +22491
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23623

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

From report at bugs.python.org  Thu Dec  3 00:03:44 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 03 Dec 2020 05:03:44 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1606971824.99.0.62834969918.issue42536@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

It looks like Victor's original issue is unrelated to zip, though. That test run is clean after adding the same fix to:

- itertools.product
- itertools.combinations
- itertools.combinations_with_replacement
- itertools.permutations
- itertools.zip_longest

...all of which use the same tuple-recycling speed trick.

If my zip PR looks good, I can create another one fixing these as well.

----------

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

From report at bugs.python.org  Thu Dec  3 00:06:38 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 03 Dec 2020 05:06:38 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1606971998.85.0.736909431586.issue42536@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

(By the way, I didn't know that -F runs the tests forever... so I was waiting *almost* forever for it to finish!)

----------

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

From report at bugs.python.org  Thu Dec  3 00:10:36 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 03 Dec 2020 05:10:36 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1606972236.18.0.8144913643.issue42536@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

Also, it appears enumerate is affected as well.

----------

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

From report at bugs.python.org  Thu Dec  3 00:31:20 2020
From: report at bugs.python.org (Ma Lin)
Date: Thu, 03 Dec 2020 05:31:20 +0000
Subject: =?utf-8?b?W2lzc3VlNDI1NTBdIHJl5bqT5Yy56YWN6Zeu6aKY?=
In-Reply-To: <1606963113.63.0.536238231027.issue42550@roundup.psfhosted.org>
Message-ID: <1606973480.48.0.385441525988.issue42550@roundup.psfhosted.org>


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

This issue can be closed.

'0x'  2
'd26935a5ee4cd542e8a3a7e74fb7a99855975b59'  40
'\n'  1

2+40+1 = 43

----------
nosy: +malin

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

From report at bugs.python.org  Thu Dec  3 00:53:19 2020
From: report at bugs.python.org (ye andy)
Date: Thu, 03 Dec 2020 05:53:19 +0000
Subject: =?utf-8?b?W2lzc3VlNDI1NTBdIHJl5bqT5Yy56YWN6Zeu6aKY?=
In-Reply-To: <1606963113.63.0.536238231027.issue42550@roundup.psfhosted.org>
Message-ID: <1606974799.29.0.444185406267.issue42550@roundup.psfhosted.org>


ye andy <andy.ye.jx at gmail.com> added the comment:

What I mean by that is that the regex That I wrote should match successfully is a 42-bit string, but it is also successful when we add more newlines

----------

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

From report at bugs.python.org  Thu Dec  3 00:57:47 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Thu, 03 Dec 2020 05:57:47 +0000
Subject: =?utf-8?b?W2lzc3VlNDI1NTBdIHJl5bqT5Yy56YWN6Zeu6aKY?=
In-Reply-To: <1606963113.63.0.536238231027.issue42550@roundup.psfhosted.org>
Message-ID: <1606975067.17.0.0240140250392.issue42550@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

Maybe you're looking for re.fullmatch:

https://docs.python.org/3/library/re.html#re.fullmatch

----------
nosy: +Dennis Sweeney

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

From report at bugs.python.org  Thu Dec  3 01:02:20 2020
From: report at bugs.python.org (ye andy)
Date: Thu, 03 Dec 2020 06:02:20 +0000
Subject: =?utf-8?b?W2lzc3VlNDI1NTBdIHJl5bqT5Yy56YWN6Zeu6aKY?=
In-Reply-To: <1606963113.63.0.536238231027.issue42550@roundup.psfhosted.org>
Message-ID: <1606975340.45.0.197448602137.issue42550@roundup.psfhosted.org>


ye andy <andy.ye.jx at gmail.com> added the comment:

My regex requires ending with 0-9a-fa-f, and I now end with a line break, which in theory should not work. Why did it work?

----------
nosy:  -Dennis Sweeney

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

From report at bugs.python.org  Thu Dec  3 01:07:15 2020
From: report at bugs.python.org (ye andy)
Date: Thu, 03 Dec 2020 06:07:15 +0000
Subject: =?utf-8?b?W2lzc3VlNDI1NTBdIHJl5bqT5Yy56YWN6Zeu6aKY?=
In-Reply-To: <1606963113.63.0.536238231027.issue42550@roundup.psfhosted.org>
Message-ID: <1606975635.82.0.141527389728.issue42550@roundup.psfhosted.org>


ye andy <andy.ye.jx at gmail.com> added the comment:

My regulus requires the beginning of 0x, the end of 0-9A-fa-f, my ending \n, he also shows success, my expected result is failure, I wrote the problem?

----------

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

From report at bugs.python.org  Thu Dec  3 01:12:38 2020
From: report at bugs.python.org (Jack O'Connor)
Date: Thu, 03 Dec 2020 06:12:38 +0000
Subject: [issue38630] subprocess.Popen.send_signal() should poll the process
In-Reply-To: <1572347906.82.0.50492662575.issue38630@roundup.psfhosted.org>
Message-ID: <1606975958.04.0.733462373776.issue38630@roundup.psfhosted.org>


Jack O'Connor <oconnor663 at gmail.com> added the comment:

This change caused a crash in the Duct library in Python 3.9. Duct uses the waitid(NOWAIT) strategy that Nathaniel Smith has described in this thread. With this change, the child process is reaped by kill() in a spot we didn't expect, and a subsequent call to os.waitid() raises a ChildProcessError. This is a race condition that only triggers if the child happens to exit before kill() is called.

I just pushed https://github.com/oconnor663/duct.py/commit/5dfae70cc9481051c5e53da0c48d9efa8ff71507 to work around this, which I'll release shortly as Duct version 0.6.4.

Broadly speaking, this change could break any program that uses Popen.kill() together with os.waitpid() or os.waitid(). Checking Popen.returncode before calling the os functions is a good workaround for the single-threaded case, but it doesn't fix the multithreaded case. Duct is going to avoid calling Popen.kill() entirely. There are some longer comments about race conditions in that commit I linked.

I don't feel strongly one way the other about keeping this new behavior, but we should probably document it clearly in Popen.send_signal() and all of its callers that these functions might reap the child.

----------
nosy: +oconnor663

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

From report at bugs.python.org  Thu Dec  3 01:25:51 2020
From: report at bugs.python.org (hongweipeng)
Date: Thu, 03 Dec 2020 06:25:51 +0000
Subject: =?utf-8?b?W2lzc3VlNDI1NTBdIHJl5bqT5Yy56YWN6Zeu6aKY?=
In-Reply-To: <1606963113.63.0.536238231027.issue42550@roundup.psfhosted.org>
Message-ID: <1606976751.07.0.893934151051.issue42550@roundup.psfhosted.org>


hongweipeng <hongweichen8888 at sina.com> added the comment:

Maybe you need use `eth_re.match(a, re.MULTILINE)` or `eth_re.fullmatch(a)` .

----------
nosy: +hongweipeng

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

From report at bugs.python.org  Thu Dec  3 01:29:37 2020
From: report at bugs.python.org (ye andy)
Date: Thu, 03 Dec 2020 06:29:37 +0000
Subject: =?utf-8?b?W2lzc3VlNDI1NTBdIHJl5bqT5Yy56YWN6Zeu6aKY?=
In-Reply-To: <1606963113.63.0.536238231027.issue42550@roundup.psfhosted.org>
Message-ID: <1606976977.83.0.776251082513.issue42550@roundup.psfhosted.org>


ye andy <andy.ye.jx at gmail.com> added the comment:

Okay, I just thought it was weird

----------

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

From report at bugs.python.org  Thu Dec  3 01:30:40 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 03 Dec 2020 06:30:40 +0000
Subject: =?utf-8?b?W2lzc3VlNDI1NTBdIHJl5bqT5Yy56YWN6Zeu6aKY?=
In-Reply-To: <1606963113.63.0.536238231027.issue42550@roundup.psfhosted.org>
Message-ID: <1606977040.86.0.109556298512.issue42550@roundup.psfhosted.org>


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

https://docs.python.org/3/howto/regex.html#more-metacharacters

$
Matches at the end of a line, which is defined as either the end of the string, or any location followed by a newline character.

\Z
Matches only at the end of the string.

>>> eth_re = re.compile(r'^0x[0-9a-fA-F]{40}\Z')
>>> print(eth_re.match(a))
None
>>> eth_re = re.compile(r'^0x[0-9a-fA-F]{40}$')
>>> print(eth_re.match(a))
<re.Match object; span=(0, 42), match='0xd26935a5ee4cd542e8a3a7e74fb7a99855975b59'>

You can also use re.DEBUG to see the difference


>>> re.match(r'^0x[0-9a-fA-F]{40}$', a, re.DEBUG)
AT AT_BEGINNING
LITERAL 48
LITERAL 120
MAX_REPEAT 40 40
  IN
    RANGE (48, 57)
    RANGE (97, 102)
    RANGE (65, 70)
AT AT_END

 0. INFO 4 0b0 42 42 (to 5)
 5: AT BEGINNING
 7. LITERAL 0x30 ('0')
 9. LITERAL 0x78 ('x')
11. REPEAT_ONE 16 40 40 (to 28)
15.   IN 11 (to 27)
17.     CHARSET [0x00000000, 0x03ff0000, 0x0000007e, 0x0000007e, 0x00000000, 0x00000000, 0x00000000, 0x00000000]
26.     FAILURE
27:   SUCCESS
28: AT END
30. SUCCESS
<re.Match object; span=(0, 42), match='0xd26935a5ee4cd542e8a3a7e74fb7a99855975b59'>


>>> re.match(r'^0x[0-9a-fA-F]{40}\Z', a, re.DEBUG)
AT AT_BEGINNING
LITERAL 48
LITERAL 120
MAX_REPEAT 40 40
  IN
    RANGE (48, 57)
    RANGE (97, 102)
    RANGE (65, 70)
AT AT_END_STRING

 0. INFO 4 0b0 42 42 (to 5)
 5: AT BEGINNING
 7. LITERAL 0x30 ('0')
 9. LITERAL 0x78 ('x')
11. REPEAT_ONE 16 40 40 (to 28)
15.   IN 11 (to 27)
17.     CHARSET [0x00000000, 0x03ff0000, 0x0000007e, 0x0000007e, 0x00000000, 0x00000000, 0x00000000, 0x00000000]
26.     FAILURE
27:   SUCCESS
28: AT END_STRING
30. SUCCESS

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

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

From report at bugs.python.org  Thu Dec  3 01:41:40 2020
From: report at bugs.python.org (ye andy)
Date: Thu, 03 Dec 2020 06:41:40 +0000
Subject: =?utf-8?b?W2lzc3VlNDI1NTBdIHJl5bqT5Yy56YWN6Zeu6aKY?=
In-Reply-To: <1606963113.63.0.536238231027.issue42550@roundup.psfhosted.org>
Message-ID: <1606977700.53.0.559599745239.issue42550@roundup.psfhosted.org>


Change by ye andy <andy.ye.jx at gmail.com>:


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

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

From report at bugs.python.org  Thu Dec  3 03:48:54 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Dec 2020 08:48:54 +0000
Subject: [issue42328] ttk style.map function incorrectly handles the default
 state for element options.
In-Reply-To: <1605140874.05.0.0614253934034.issue42328@roundup.psfhosted.org>
Message-ID: <1606985334.34.0.531802855522.issue42328@roundup.psfhosted.org>


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


----------
pull_requests: +22493
pull_request: https://github.com/python/cpython/pull/23625

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

From report at bugs.python.org  Thu Dec  3 03:48:46 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 03 Dec 2020 08:48:46 +0000
Subject: [issue42328] ttk style.map function incorrectly handles the default
 state for element options.
In-Reply-To: <1605140874.05.0.0614253934034.issue42328@roundup.psfhosted.org>
Message-ID: <1606985326.71.0.173532835905.issue42328@roundup.psfhosted.org>


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


New changeset f3c3ea91a76526edff928c95b9c6767e077b7448 by Serhiy Storchaka in branch 'master':
bpo-42328: Skip some tests with themes vista and xpnative on Windows 7 (GH-23612)
https://github.com/python/cpython/commit/f3c3ea91a76526edff928c95b9c6767e077b7448


----------

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

From report at bugs.python.org  Thu Dec  3 03:48:46 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Dec 2020 08:48:46 +0000
Subject: [issue42328] ttk style.map function incorrectly handles the default
 state for element options.
In-Reply-To: <1605140874.05.0.0614253934034.issue42328@roundup.psfhosted.org>
Message-ID: <1606985326.87.0.557503316163.issue42328@roundup.psfhosted.org>


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


----------
pull_requests: +22492
pull_request: https://github.com/python/cpython/pull/23624

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

From report at bugs.python.org  Thu Dec  3 03:57:06 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 03 Dec 2020 08:57:06 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1606985826.98.0.212708958096.issue42536@roundup.psfhosted.org>


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

Why there are cycles at all? In normal case there should not be cycle and the result tuple should be destroyed when the iteration ends.

----------

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

From report at bugs.python.org  Thu Dec  3 03:59:50 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Dec 2020 08:59:50 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1606985990.48.0.871202919362.issue42536@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Extract of Brandt's PR:

// The GC may have untracked this result tuple if its elements were all
// untracked. Since we're recycling it, make sure it's tracked again:
if (!_PyObject_GC_IS_TRACKED(result)) {
    _PyObject_GC_TRACK(result);
}

I would like to understand why the tuple is no longer tracked, whereas PyTuple_New() creates a newly created tuple which is tracked.

Using gdb, I found that gc_collect_main() calls untrack_tuples(young) which untracks all tuples of the young generation.

I understand that (when the issue happens):

* a zip() object is created with lz->result = (None, None)
* A GC collection happens
* The GC untracks (None, None) tuple
* next(zip) is called: lz->result has a reference count of 1 and so can be reused.

Problem: the tuple is no longer tracked, whereas its content changed and so the newly filled tuple might be part of a reference cycle. Since the tuple is not tracked, the GC can no longer break the reference cycle involving the zip object internal tuple.

Example of code where the zip tuple is untracked before zip_next() is called on the zip object:

    def test_product(self):
        gc.set_threshold(5)
        pools = [(0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12),
                 ('a', 'b', 'c'),
                 (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12),
                 (0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12)]
        indices = [0, 2, 10, 11]
        print(indices)
        print(pools)
        list(None for a, b in zip(pools, indices))

----------

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

From report at bugs.python.org  Thu Dec  3 04:07:22 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Dec 2020 09:07:22 +0000
Subject: [issue42328] ttk style.map function incorrectly handles the default
 state for element options.
In-Reply-To: <1605140874.05.0.0614253934034.issue42328@roundup.psfhosted.org>
Message-ID: <1606986442.43.0.88241380665.issue42328@roundup.psfhosted.org>


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


New changeset 12d2306a1db48f71b15ceaecf3d5ce06dbbe06c1 by Miss Islington (bot) in branch '3.8':
bpo-42328: Skip some tests with themes vista and xpnative on Windows 7 (GH-23612)
https://github.com/python/cpython/commit/12d2306a1db48f71b15ceaecf3d5ce06dbbe06c1


----------

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

From report at bugs.python.org  Thu Dec  3 04:10:31 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Dec 2020 09:10:31 +0000
Subject: [issue42328] ttk style.map function incorrectly handles the default
 state for element options.
In-Reply-To: <1605140874.05.0.0614253934034.issue42328@roundup.psfhosted.org>
Message-ID: <1606986631.73.0.596358882374.issue42328@roundup.psfhosted.org>


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


New changeset ae67db6b314e297a1b67ed15c0bb560b8ce5b856 by Miss Islington (bot) in branch '3.9':
bpo-42328: Skip some tests with themes vista and xpnative on Windows 7 (GH-23612)
https://github.com/python/cpython/commit/ae67db6b314e297a1b67ed15c0bb560b8ce5b856


----------

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

From report at bugs.python.org  Thu Dec  3 04:16:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Dec 2020 09:16:40 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1606987000.48.0.186265496124.issue42536@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

test_zip_leak2.py: simplified example to trigger the GC issue.

Copy it to Lib/test/ and reproduce the leak with:

    ./python -m test -R 3:3 test_zip_leak2

Extract of the code:
---
container = []
iterator = zip([container], [container])

# untrack the internal zip->result=(None, None)
gc.collect()

# create a reference cycle: container -> iterator -> container
container.append(iterator)

next(iterator)
# zip->result=(container, container)

del container, iterator

# Try to break the reference cycle
gc.collect()
---

----------
Added file: https://bugs.python.org/file49651/test_zip_leak2.py

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

From report at bugs.python.org  Thu Dec  3 04:22:50 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Dec 2020 09:22:50 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1606987370.05.0.242005564381.issue42536@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Serhiy Storchaka:
> Why there are cycles at all? In normal case there should not be cycle and the result tuple should be destroyed when the iteration ends.

test_itertools creates a reference cycle *on purpose*. See test_zip_leak2.py  simplified code, it comes from test_itertools.

----------

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

From report at bugs.python.org  Thu Dec  3 04:23:11 2020
From: report at bugs.python.org (Werner Smidt)
Date: Thu, 03 Dec 2020 09:23:11 +0000
Subject: [issue31990] Pickling deadlocks in thread with python -m
In-Reply-To: <1510222459.1.0.213398074469.issue31990@psf.upfronthosting.co.za>
Message-ID: <1606987391.13.0.138857350445.issue31990@roundup.psfhosted.org>


Werner Smidt <werner.smidt at gmail.com> added the comment:

Thanks for going to the trouble, Sara. 


Curiosity remains, but I'll mark this as closed.

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

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

From report at bugs.python.org  Thu Dec  3 04:23:32 2020
From: report at bugs.python.org (Yurii Karabas)
Date: Thu, 03 Dec 2020 09:23:32 +0000
Subject: [issue42525] Optimize class/module level annotation
In-Reply-To: <1606836637.51.0.505503737654.issue42525@roundup.psfhosted.org>
Message-ID: <1606987412.92.0.413267628735.issue42525@roundup.psfhosted.org>


Yurii Karabas <1998uriyyo at gmail.com> added the comment:

As all annotations are known at compilation time we can optimize annotations creating.

For instance, we have such code:
```
a: int
b: int
```

With the current implementation, we will have such bytecode:
```
  1           0 SETUP_ANNOTATIONS
              2 LOAD_CONST               0 ('int')
              4 LOAD_NAME                0 (__annotations__)
              6 LOAD_CONST               1 ('a')
              8 STORE_SUBSCR

  2          10 LOAD_CONST               0 ('int')
             12 LOAD_NAME                0 (__annotations__)
             14 LOAD_CONST               2 ('b')
             16 STORE_SUBSCR
             18 LOAD_CONST               3 (None)
             20 RETURN_VALUE
```

I would suggest using `BUILD_CONST_KEY_MAP` and bytecode will look like this:
```
 2           0 LOAD_CONST               0 ('int')
 3           2 LOAD_CONST               0 ('int')
 1           4 LOAD_CONST               1 (('a', 'b'))
             6 BUILD_CONST_KEY_MAP      2
             8 SETUP_ANNOTATIONS
             10 LOAD_CONST              2 (None)
             12 RETURN_VALUE
```

So `SETUP_ANNOTATIONS` bytecode will accept a dictionary with annotations of a current module/class.

I will look more like micro-optimization, I can implement this feature and run benchmarks to check performance boost.

I believe this optimization won't require a lot to change.

----------

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

From report at bugs.python.org  Thu Dec  3 04:23:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Dec 2020 09:23:59 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1606987439.15.0.730268527701.issue42536@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I add Pablo and Tim who love GC puzzles.

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

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

From report at bugs.python.org  Thu Dec  3 04:34:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Dec 2020 09:34:11 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1606988051.71.0.00879387302039.issue42536@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The zip bug is quite old and was already tested by test_itertools for a very long time. Suddenly, it started to fail on more and more Refleaks buildbots. It may be because the GC must be triggered at a very specific point, and the default GC threshold triggers the issue with latest test_itertools changes.

----------

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

From report at bugs.python.org  Thu Dec  3 04:42:54 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Dec 2020 09:42:54 +0000
Subject: [issue38630] subprocess.Popen.send_signal() should poll the process
In-Reply-To: <1572347906.82.0.50492662575.issue38630@roundup.psfhosted.org>
Message-ID: <1606988574.7.0.626676984683.issue38630@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

On Linux, a pidfd file descriptor can be created with os.pidfd_open() (added to Python 3.9). It would avoid even more race conditions. The best would be to request a pidfd file descriptor directly when we spawn the process which is possible on recent Linux kernel versions.

> we should probably document it clearly in Popen.send_signal() and all of its callers that these functions might reap the child.

Feel free to propose a PR to document the behavior.

I'm not sure of what you mean by send_signal() which "reaps" the child process.

See also bpo-40550.

Anyway, this issue and bpo-40550 are closed. I suggest to open a new issue to enhance the documentation.

----------

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

From report at bugs.python.org  Thu Dec  3 04:49:23 2020
From: report at bugs.python.org (gaborjbernat)
Date: Thu, 03 Dec 2020 09:49:23 +0000
Subject: [issue42552] Automatically set parent thread idents on thread start
Message-ID: <1606988963.46.0.590267410194.issue42552@roundup.psfhosted.org>


New submission from gaborjbernat <gaborjbernat at gmail.com>:

I want to request automatically adding the current thread ident on the thread start as parent_ident. I would like this to be able to implement thread-local variables that inherit their values from the parent thread. See https://gist.github.com/gaborbernat/67b653f1d3ce4857a065a3bd81e424df#file-thread_inheritence_sol_1-py-L1 for such an example.

----------
messages: 382398
nosy: gaborjbernat
priority: normal
severity: normal
status: open
title: Automatically set parent thread idents on thread start
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Thu Dec  3 05:02:50 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 03 Dec 2020 10:02:50 +0000
Subject: [issue42525] Optimize class/module level annotation
In-Reply-To: <1606836637.51.0.505503737654.issue42525@roundup.psfhosted.org>
Message-ID: <1606989770.99.0.831744145689.issue42525@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

> For instance, we have such code:

But what about this, what would the bytecode will look like in this case (where the annotations don't exactly follow each other?)

a: int
T = TypeVar('T')
b: T
b1: Gen[T]
X = TypeVar('X')
c: X
d: str

Do you propose to build 2/3 different dicts and apply them one by one to allow calls to access that frame and recover the annotations?

> I will look more like micro-optimization, I can implement this feature and run benchmarks to check performance boost.

What kind of optimization do you target? It would be really cool if you could get us some numbers with a draft patch (like comparing to test the import time of a module heavy with annotations, or even maybe some real-world examples. Here is a list of heavily-typed projects: https://github.com/hauntsaninja/mypy_primer/blob/2d14b20fa782896cc3d6ad2548a70c024b0f4e8a/mypy_primer.py#L900

Would love to see an import time comparison, or something similiar.

----------

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

From report at bugs.python.org  Thu Dec  3 05:03:03 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 03 Dec 2020 10:03:03 +0000
Subject: [issue42525] Optimize class/module level annotation
In-Reply-To: <1606836637.51.0.505503737654.issue42525@roundup.psfhosted.org>
Message-ID: <1606989783.94.0.930574067643.issue42525@roundup.psfhosted.org>


Change by Batuhan Taskaya <isidentical at gmail.com>:


----------
nosy: +pablogsal

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

From report at bugs.python.org  Thu Dec  3 05:46:20 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 03 Dec 2020 10:46:20 +0000
Subject: [issue42431] Fix outdated bytes comments
In-Reply-To: <1606037892.77.0.133839812824.issue42431@roundup.psfhosted.org>
Message-ID: <1606992380.56.0.733718790631.issue42431@roundup.psfhosted.org>


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


New changeset 2ad93821a69e6efac3b0efe1d205d6e5ef030791 by Serhiy Storchaka in branch 'master':
bpo-42431: Fix outdated bytes comments (GH-23458)
https://github.com/python/cpython/commit/2ad93821a69e6efac3b0efe1d205d6e5ef030791


----------

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

From report at bugs.python.org  Thu Dec  3 05:46:40 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 03 Dec 2020 10:46:40 +0000
Subject: [issue42431] Fix outdated bytes comments
In-Reply-To: <1606037892.77.0.133839812824.issue42431@roundup.psfhosted.org>
Message-ID: <1606992400.34.0.52142567989.issue42431@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/issue42431>
_______________________________________

From report at bugs.python.org  Thu Dec  3 06:10:51 2020
From: report at bugs.python.org (Qingyao Sun)
Date: Thu, 03 Dec 2020 11:10:51 +0000
Subject: [issue42537] Implement built-in shorthand b() for breakpoint()
In-Reply-To: <1606909944.93.0.455067472723.issue42537@roundup.psfhosted.org>
Message-ID: <1606993851.87.0.72802559812.issue42537@roundup.psfhosted.org>


Qingyao Sun <sunqingyao19970825 at icloud.com> added the comment:

See https://mail.python.org/archives/list/python-ideas at python.org/thread/6UAJRDKVJNZ7EACXUTUCKSGAEYPJHME5/

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

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

From report at bugs.python.org  Thu Dec  3 06:32:11 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 03 Dec 2020 11:32:11 +0000
Subject: [issue42504] Failure to build with MACOSX_DEPLOYMENT_TARGET=11 on Big
 Sur
In-Reply-To: <1606662964.61.0.531913261121.issue42504@roundup.psfhosted.org>
Message-ID: <1606995131.11.0.384697244196.issue42504@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

FWIW I don't agree with this fix. 

sys.get_config_var('MACOSX_DEPLOYMENT_TARGET') has always resulted in a string value. There's bound to be someone relying on this.

As I wrote in comment on the PR a nicer fix is to teach sysconfig (and distutils.sysconfig) to not convert the value of this key to an integer.

----------

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

From report at bugs.python.org  Thu Dec  3 06:43:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Dec 2020 11:43:10 +0000
Subject: [issue42262] [C API] Add Py_NewRef() function to get a new strong
 reference to an object
In-Reply-To: <1604506834.94.0.230929451807.issue42262@roundup.psfhosted.org>
Message-ID: <1606995790.31.0.265346509712.issue42262@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22494
pull_request: https://github.com/python/cpython/pull/23626

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

From report at bugs.python.org  Thu Dec  3 07:20:26 2020
From: report at bugs.python.org (Idan Weiss)
Date: Thu, 03 Dec 2020 12:20:26 +0000
Subject: [issue42532] spec_arg's __bool__ is called while initializing
 NonCallableMock
Message-ID: <1606998026.09.0.31549028921.issue42532@roundup.psfhosted.org>


New submission from Idan Weiss <idanweiss97 at gmail.com>:

To reproduce:
import unittest.mock


class LogicInBool:
    def __bool__(self):
        print("In Bool!")
        return True

class SomeClass:
    def __init__(self):
        self.logic_in_bool = LogicInBool()

obj = SomeClass()
with unittest.mock.patch.object(obj, 'logic_in_bool', autospec=True):
    # "In Bool! is printed
    pass

----------

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

From report at bugs.python.org  Thu Dec  3 07:30:02 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Dec 2020 12:30:02 +0000
Subject: [issue42553] test_asyncio: test_call_later() fails on Windows x64
 GitHub Action
Message-ID: <1606998602.75.0.120891089578.issue42553@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

FAIL: test_call_later (test.test_asyncio.test_events.SelectEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\a\cpython\cpython\lib\test\test_asyncio\test_events.py", line 301, in test_call_later
    self.assertTrue(0.08 <= t1-t0 <= 0.8, t1-t0)
AssertionError: False is not true : 0.07799999999997453

https://github.com/python/cpython/pull/23626/checks?check_run_id=1492411421

----------
components: Tests
messages: 382404
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_asyncio: test_call_later() fails on Windows x64 GitHub Action
versions: Python 3.10

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

From report at bugs.python.org  Thu Dec  3 07:31:18 2020
From: report at bugs.python.org (Igor Skochinsky)
Date: Thu, 03 Dec 2020 12:31:18 +0000
Subject: [issue42545] Check that all symbols in the limited ABI are exported
In-Reply-To: <1606942339.51.0.833109264536.issue42545@roundup.psfhosted.org>
Message-ID: <1606998678.02.0.192169444286.issue42545@roundup.psfhosted.org>


Change by Igor Skochinsky <skochinsky at gmail.com>:


----------
nosy: +Igor.Skochinsky

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

From report at bugs.python.org  Thu Dec  3 07:34:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Dec 2020 12:34:59 +0000
Subject: [issue42553] test_asyncio: test_call_later() fails on Windows x64
 GitHub Action
In-Reply-To: <1606998602.75.0.120891089578.issue42553@roundup.psfhosted.org>
Message-ID: <1606998899.73.0.205167114423.issue42553@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +22495
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23627

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

From report at bugs.python.org  Thu Dec  3 07:52:36 2020
From: report at bugs.python.org (Carlos Alexandro Becker)
Date: Thu, 03 Dec 2020 12:52:36 +0000
Subject: [issue42411] respect cgroups limits when trying to allocate memory
In-Reply-To: <1605806290.38.0.199386148713.issue42411@roundup.psfhosted.org>
Message-ID: <1606999956.03.0.791772143883.issue42411@roundup.psfhosted.org>


Carlos Alexandro Becker <caarlos0 at gmail.com> added the comment:

Any updates?

----------

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

From report at bugs.python.org  Thu Dec  3 07:57:05 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Dec 2020 12:57:05 +0000
Subject: [issue42553] test_asyncio: test_call_later() fails on Windows x64
 GitHub Action
In-Reply-To: <1606998602.75.0.120891089578.issue42553@roundup.psfhosted.org>
Message-ID: <1607000225.45.0.809272882827.issue42553@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 7e5e13d113798117d5ef25c5ffdbd0eb39420f98 by Victor Stinner in branch 'master':
bpo-42553: Fix test_asyncio.test_call_later() (GH-23627)
https://github.com/python/cpython/commit/7e5e13d113798117d5ef25c5ffdbd0eb39420f98


----------

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

From report at bugs.python.org  Thu Dec  3 07:57:15 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Dec 2020 12:57:15 +0000
Subject: [issue42553] test_asyncio: test_call_later() fails on Windows x64
 GitHub Action
In-Reply-To: <1606998602.75.0.120891089578.issue42553@roundup.psfhosted.org>
Message-ID: <1607000235.16.0.657981468019.issue42553@roundup.psfhosted.org>


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


----------
nosy: +miss-islington
nosy_count: 1.0 -> 2.0
pull_requests: +22496
pull_request: https://github.com/python/cpython/pull/23628

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

From report at bugs.python.org  Thu Dec  3 07:57:25 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Dec 2020 12:57:25 +0000
Subject: [issue42553] test_asyncio: test_call_later() fails on Windows x64
 GitHub Action
In-Reply-To: <1606998602.75.0.120891089578.issue42553@roundup.psfhosted.org>
Message-ID: <1607000245.46.0.0289759886383.issue42553@roundup.psfhosted.org>


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


----------
pull_requests: +22497
pull_request: https://github.com/python/cpython/pull/23629

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

From report at bugs.python.org  Thu Dec  3 08:01:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Dec 2020 13:01:17 +0000
Subject: [issue42262] [C API] Add Py_NewRef() function to get a new strong
 reference to an object
In-Reply-To: <1604506834.94.0.230929451807.issue42262@roundup.psfhosted.org>
Message-ID: <1607000477.9.0.438256010811.issue42262@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 8b6c4a921af6d5d0a9640211ac93d7886a55a8f3 by Victor Stinner in branch 'master':
bpo-42262: Py_NewRef() casts its argument to PyObject* (GH-23626)
https://github.com/python/cpython/commit/8b6c4a921af6d5d0a9640211ac93d7886a55a8f3


----------

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

From report at bugs.python.org  Thu Dec  3 08:11:48 2020
From: report at bugs.python.org (FX Coudert)
Date: Thu, 03 Dec 2020 13:11:48 +0000
Subject: [issue42554] distutils.util.get_platform() depends on minor version
 for macOS 11
Message-ID: <1607001108.52.0.506559643874.issue42554@roundup.psfhosted.org>


New submission from FX Coudert <fxcoudert at gmail.com>:

On macOS Big Sur (11.y.z), the return value of distutils.util.get_platform() records in some cases the minor version of OS. For example:

- with a Python 3.9 built on macOS 10.0.1, distutils.util.get_platform() will return macosx-11.0-x86_64
- with a Python 3.9 built on macOS 10.1.0, distutils.util.get_platform() will return macosx-11.1-x86_64
- if MACOSX_DEPLOYMENT_TARGET=11.1 was set at build time, then distutils.util.get_platform() will return macosx-11.1-x86_64
- if MACOSX_DEPLOYMENT_TARGET=11 was set at build time, then distutils.util.get_platform() will return macosx-11-x86_64

This has important consequences for wheel and pip, which use the return value to determine platform tags: https://github.com/pypa/wheel/issues/385

>From the API Reference (https://docs.python.org/3/distutils/apiref.html), it is not clear what the expect return value is. Given that previously, the return value of distutils.util.get_platform() was dependent only on the macOS major version, I would expect this to be the case. Therefore, distutils.util.get_platform() should return macosx-11-x86_64 on all Big Sur (macOS 11.x.y) versions.

PS: This is not directly related to another issue with MACOSX_DEPLOYMENT_TARGET
https://bugs.python.org/issue42504

----------
components: Build
messages: 382408
nosy: fxcoudert
priority: normal
severity: normal
status: open
title: distutils.util.get_platform() depends on minor version for macOS 11
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Thu Dec  3 08:13:46 2020
From: report at bugs.python.org (FX Coudert)
Date: Thu, 03 Dec 2020 13:13:46 +0000
Subject: [issue42554] distutils.util.get_platform() depends on minor version
 for macOS 11
In-Reply-To: <1607001108.52.0.506559643874.issue42554@roundup.psfhosted.org>
Message-ID: <1607001226.73.0.117772251289.issue42554@roundup.psfhosted.org>


FX Coudert <fxcoudert at gmail.com> added the comment:

What I think should be the logical solution to this bug:
make distutils.util.get_platform() return "macosx-11-x86_64" on all Big Sur (macOS 11.x.y) versions, independent of the minor OS version.

However, if the Python developers decide that this should not (for some reason) be the case, then this should be clearly documented. But I believe that would create trouble for other packages downstream.

----------

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

From report at bugs.python.org  Thu Dec  3 08:15:36 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Dec 2020 13:15:36 +0000
Subject: [issue42553] test_asyncio: test_call_later() fails on Windows x64
 GitHub Action
In-Reply-To: <1606998602.75.0.120891089578.issue42553@roundup.psfhosted.org>
Message-ID: <1607001336.42.0.0139579770454.issue42553@roundup.psfhosted.org>


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


New changeset 930d5377c5877a631c3c23929e2cb6211bb0e2fb by Miss Islington (bot) in branch '3.8':
bpo-42553: Fix test_asyncio.test_call_later() (GH-23627)
https://github.com/python/cpython/commit/930d5377c5877a631c3c23929e2cb6211bb0e2fb


----------

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

From report at bugs.python.org  Thu Dec  3 08:16:11 2020
From: report at bugs.python.org (Alessio Bogon)
Date: Thu, 03 Dec 2020 13:16:11 +0000
Subject: [issue38780] SysLogHandler crash atexit
In-Reply-To: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>
Message-ID: <1607001371.31.0.948876711018.issue38780@roundup.psfhosted.org>


Change by Alessio Bogon <youtux at gmail.com>:


----------
nosy: +youtux

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

From report at bugs.python.org  Thu Dec  3 08:16:51 2020
From: report at bugs.python.org (mike dalrymple)
Date: Thu, 03 Dec 2020 13:16:51 +0000
Subject: [issue42555] math function sqrt() not working in 3.9
Message-ID: <1607001411.31.0.73323583323.issue42555@roundup.psfhosted.org>


New submission from mike dalrymple <linmike2 at msn.com>:

Downloaded Python 3.9.0
Documentation indicates:
math.sqrt(x)
Return the square root of x.

When I use in IDLE shell 3.9.0, I receive error:
>>> sqrt(25)
Traceback (most recent call last):
  File "<pyshell#11>", line 1, in <module>
    sqrt(25)
NameError: name 'sqrt' is not defined

What is the problem?

----------
assignee: terry.reedy
components: IDLE
messages: 382411
nosy: mikeuser_01, terry.reedy
priority: normal
severity: normal
status: open
title: math function sqrt() not working in 3.9
versions: Python 3.9

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

From report at bugs.python.org  Thu Dec  3 08:20:05 2020
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 03 Dec 2020 13:20:05 +0000
Subject: [issue42555] math function sqrt() not working in 3.9
In-Reply-To: <1607001411.31.0.73323583323.issue42555@roundup.psfhosted.org>
Message-ID: <1607001605.32.0.122017206392.issue42555@roundup.psfhosted.org>


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

You have to import the math module first and then reference the sqrt function of the math module.

>>> import math
>>> math.sqrt(25)
5.0

----------
nosy: +christian.heimes
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Dec  3 08:20:12 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Dec 2020 13:20:12 +0000
Subject: [issue42553] test_asyncio: test_call_later() fails on Windows x64
 GitHub Action
In-Reply-To: <1606998602.75.0.120891089578.issue42553@roundup.psfhosted.org>
Message-ID: <1607001612.42.0.0239966625553.issue42553@roundup.psfhosted.org>


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


New changeset 9f26833cedd33439b11059d423f599982abeb180 by Miss Islington (bot) in branch '3.9':
bpo-42553: Fix test_asyncio.test_call_later() (GH-23627)
https://github.com/python/cpython/commit/9f26833cedd33439b11059d423f599982abeb180


----------

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

From report at bugs.python.org  Thu Dec  3 08:27:18 2020
From: report at bugs.python.org (Ned Deily)
Date: Thu, 03 Dec 2020 13:27:18 +0000
Subject: [issue42554] distutils.util.get_platform() depends on minor version
 for macOS 11
In-Reply-To: <1607001108.52.0.506559643874.issue42554@roundup.psfhosted.org>
Message-ID: <1607002038.0.0.0751103782748.issue42554@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
components: +Distutils, macOS
nosy: +dstufft, eric.araujo, ned.deily, ronaldoussoren

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

From report at bugs.python.org  Thu Dec  3 08:28:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 03 Dec 2020 13:28:24 +0000
Subject: [issue42553] test_asyncio: test_call_later() fails on Windows x64
 GitHub Action
In-Reply-To: <1606998602.75.0.120891089578.issue42553@roundup.psfhosted.org>
Message-ID: <1607002104.45.0.590136220473.issue42553@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


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

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

From report at bugs.python.org  Thu Dec  3 08:30:12 2020
From: report at bugs.python.org (FX Coudert)
Date: Thu, 03 Dec 2020 13:30:12 +0000
Subject: [issue42554] distutils.util.get_platform() depends on minor version
 for macOS 11
In-Reply-To: <1607001108.52.0.506559643874.issue42554@roundup.psfhosted.org>
Message-ID: <1607002212.0.0.0688059047452.issue42554@roundup.psfhosted.org>


FX Coudert <fxcoudert at gmail.com> added the comment:

Actually, I can find some distribution of Python where the minor version is returned, for example on Apple macOS 10.15.4:

/usr/bin/python3 -c 'import distutils.util; print(distutils.util.get_platform())' 
macosx-10.14.6-x86_64

Therefore maybe I misunderstand and there is no guarantee on the form of this return value

----------

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

From report at bugs.python.org  Thu Dec  3 09:41:06 2020
From: report at bugs.python.org (Pierre Ossman)
Date: Thu, 03 Dec 2020 14:41:06 +0000
Subject: [issue42556] unittest.mock.patch() cannot properly mock methods
Message-ID: <1607006466.6.0.505250389966.issue42556@roundup.psfhosted.org>


New submission from Pierre Ossman <ossman at cendio.se>:

unittest.mock.patch() as it currently works cannot properly mock a method as it currently replaces it with something more mimicking a function. I.e. the descriptor magic that includes "self" isn't properly set up.

In most cases this doesn't really matter, but there are a few use cases where this is important:

1. Calling base classes where you need to make sure it works regardless of super() or direct reference to the base class.

2. Multiple objects calling the same base class using super(). Without the self argument you can't tell the calls apart.

3. Setting up a side_effect that needs access to the object. In some cases you can pass the object using some side channel, but not all. E.g. not when mocking a base class' __init__(). (already reported as Issue35577).

Right now you can work around this by using autospec, as that has the undocumented side-effect of properly setting up methods. So don't fix Issue41915 before this one or we lose that workaround. :)

----------
components: Library (Lib)
messages: 382415
nosy: CendioOssman
priority: normal
severity: normal
status: open
title: unittest.mock.patch() cannot properly mock methods
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Thu Dec  3 09:59:31 2020
From: report at bugs.python.org (Irit Katriel)
Date: Thu, 03 Dec 2020 14:59:31 +0000
Subject: [issue42116] Inspect library ignore comments at the end of a function
 (inspect.getsource)
In-Reply-To: <1603363723.99.0.873580527867.issue42116@roundup.psfhosted.org>
Message-ID: <1607007571.22.0.411067403063.issue42116@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
keywords: +patch
nosy: +iritkatriel
nosy_count: 2.0 -> 3.0
pull_requests: +22498
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23630

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

From report at bugs.python.org  Thu Dec  3 10:01:40 2020
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 03 Dec 2020 15:01:40 +0000
Subject: [issue36094] When using an SMTP SSL connection,, get ValueError.
In-Reply-To: <1550943841.97.0.129283187576.issue36094@roundup.psfhosted.org>
Message-ID: <1607007700.9.0.464769539747.issue36094@roundup.psfhosted.org>


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


----------
nosy: +python-dev
nosy_count: 8.0 -> 9.0
pull_requests: +22499
pull_request: https://github.com/python/cpython/pull/23490

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

From report at bugs.python.org  Thu Dec  3 10:12:06 2020
From: report at bugs.python.org (Irit Katriel)
Date: Thu, 03 Dec 2020 15:12:06 +0000
Subject: [issue42116] Inspect library ignore comments at the end of a function
 (inspect.getsource)
In-Reply-To: <1603363723.99.0.873580527867.issue42116@roundup.psfhosted.org>
Message-ID: <1607008326.05.0.988807661285.issue42116@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

1. For a comment line, the tokenizer emits a COMMENT token followed by an NL token for the newline. The inspect.BlockFinder.tokeneater increments its "last" field to the last line it identified as belonging to the code block. Currently it increments it when it sees a NEWLINE token, but not for an NL token.

2. For a comment line, the tokenizer does not emit an INDENT/DEDENT token, so the indentation level when it is processes is assumed to be equal to that of the previous line.

PR 23630 aims to include comment lines in the block if their start column is after the start column of the opening line of the block:

   def f():
      return 42

     # this is a part of f
   # this is not a part of f

----------
nosy: +taleinat
versions: +Python 3.10, Python 3.9

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

From report at bugs.python.org  Thu Dec  3 10:16:05 2020
From: report at bugs.python.org (Irit Katriel)
Date: Thu, 03 Dec 2020 15:16:05 +0000
Subject: [issue42116] Inspect library ignore comments at the end of a function
 (inspect.getsource)
In-Reply-To: <1603363723.99.0.873580527867.issue42116@roundup.psfhosted.org>
Message-ID: <1607008565.59.0.327056712961.issue42116@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

For reference - this script:
---------------------------------------------
import inspect
import tokenize
from pprint import pprint as pp

src=[
 'def f():\n',
 '    return 1\n',
 '    #that was fun',
 '\n',
 '#Now comes g\n',
 'def g():\n',
 '    return 2\n']

pp(list(tokenize.generate_tokens(iter(src).__next__)))
---------------------------------------------

Outputs:
---------------------------------------------
[TokenInfo(type=1 (NAME), string='def', start=(1, 0), end=(1, 3), line='def f():\n'),
 TokenInfo(type=1 (NAME), string='f', start=(1, 4), end=(1, 5), line='def f():\n'),
 TokenInfo(type=54 (OP), string='(', start=(1, 5), end=(1, 6), line='def f():\n'),
 TokenInfo(type=54 (OP), string=')', start=(1, 6), end=(1, 7), line='def f():\n'),
 TokenInfo(type=54 (OP), string=':', start=(1, 7), end=(1, 8), line='def f():\n'),
 TokenInfo(type=4 (NEWLINE), string='\n', start=(1, 8), end=(1, 9), line='def f():\n'),
 TokenInfo(type=5 (INDENT), string='    ', start=(2, 0), end=(2, 4), line='    return 1\n'),
 TokenInfo(type=1 (NAME), string='return', start=(2, 4), end=(2, 10), line='    return 1\n'),
 TokenInfo(type=2 (NUMBER), string='1', start=(2, 11), end=(2, 12), line='    return 1\n'),
 TokenInfo(type=4 (NEWLINE), string='\n', start=(2, 12), end=(2, 13), line='    return 1\n'),
 TokenInfo(type=60 (COMMENT), string='#that was fun', start=(3, 4), end=(3, 17), line='    #that was fun'),
 TokenInfo(type=61 (NL), string='', start=(3, 17), end=(3, 17), line='    #that was fun'),
 TokenInfo(type=61 (NL), string='\n', start=(4, 0), end=(4, 1), line='\n'),
 TokenInfo(type=60 (COMMENT), string='#Now comes g', start=(5, 0), end=(5, 12), line='#Now comes g\n'),
 TokenInfo(type=61 (NL), string='\n', start=(5, 12), end=(5, 13), line='#Now comes g\n'),
 TokenInfo(type=6 (DEDENT), string='', start=(6, 0), end=(6, 0), line='def g():\n'),
 TokenInfo(type=1 (NAME), string='def', start=(6, 0), end=(6, 3), line='def g():\n'),
 TokenInfo(type=1 (NAME), string='g', start=(6, 4), end=(6, 5), line='def g():\n'),
 TokenInfo(type=54 (OP), string='(', start=(6, 5), end=(6, 6), line='def g():\n'),
 TokenInfo(type=54 (OP), string=')', start=(6, 6), end=(6, 7), line='def g():\n'),
 TokenInfo(type=54 (OP), string=':', start=(6, 7), end=(6, 8), line='def g():\n'),
 TokenInfo(type=4 (NEWLINE), string='\n', start=(6, 8), end=(6, 9), line='def g():\n'),
 TokenInfo(type=5 (INDENT), string='    ', start=(7, 0), end=(7, 4), line='    return 2\n'),
 TokenInfo(type=1 (NAME), string='return', start=(7, 4), end=(7, 10), line='    return 2\n'),
 TokenInfo(type=2 (NUMBER), string='2', start=(7, 11), end=(7, 12), line='    return 2\n'),
 TokenInfo(type=4 (NEWLINE), string='\n', start=(7, 12), end=(7, 13), line='    return 2\n'),
 TokenInfo(type=6 (DEDENT), string='', start=(8, 0), end=(8, 0), line=''),
 TokenInfo(type=0 (ENDMARKER), string='', start=(8, 0), end=(8, 0), line='')]

----------

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

From report at bugs.python.org  Thu Dec  3 10:30:57 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 03 Dec 2020 15:30:57 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1607009457.87.0.474262026448.issue42536@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

> I add Pablo and Tim who love GC puzzles.

Well, I don?t think the GC is really doing anything wrong here... untracking these sort of tuples likely results in a noticeable reduction in collection times. This code is definitely testing the limits of what is ?okay? for us to do with a tuple, and it?s breaking the GC?s (reasonable) assumptions.

I kept digging around, and it appears dict.items() is affected, too (which is a bit scarier). The same fix still works, though.

----------

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

From report at bugs.python.org  Thu Dec  3 10:34:45 2020
From: report at bugs.python.org (Berry Schoenmakers)
Date: Thu, 03 Dec 2020 15:34:45 +0000
Subject: [issue42557] Make asyncio.__main__ reusable,
 also adding a preamble feature.
Message-ID: <1607009685.51.0.588770537577.issue42557@roundup.psfhosted.org>


New submission from Berry Schoenmakers <l.a.m.schoenmakers at tue.nl>:

The async REPL introduced in Python 3.8 is very nice for quick tests and experiments, supporting top-level "await" (see https://bugs.python.org/issue37028). I'm using it often when developing code that heavily relies on Python's asyncio module.

A drawback of the basic interface when launching it with "python -m asyncio" is that one usually still needs to enter a couple of statements to load the package you're working on, etc. To overcome this I've added a __main__.py to the mpyc package such that entering "python -m mpyc" will launch the async REPL like this: 

	asyncio REPL 3.10.0a2 (tags/v3.10.0a2:114ee5d, Nov  3 2020, 00:37:42) [MSC v.1927 64 bit (AMD64)] on win32
	Use "await" directly instead of "asyncio.run()".
	Type "help", "copyright", "credits" or "license" for more information.
	>>> import asyncio
	>>> from mpyc.runtime import mpc
	>>> secint = mpc.SecInt()
	>>> secfxp = mpc.SecFxp()
	>>> secfld256 = mpc.SecFld(256)
	>>>

This enables the async REPL but also a "preamble" with some additional code is executed.

To program mpyc.__main__.py, however, I basically had to copy asyncio.__main__.py and make a few changes throughout the code. It works alright, but to take advantage of future improvements to asyncio.__main__.py it would be very convenient if asyncio.__main__.py becomes reusable. 

With the added feature for specifying a "preamble", programming something like mpyc.__main__.py requires just a few lines of code:

    import asyncio.__main__
	
    if __name__ == '__main__':
        preamble = ('from mpyc.runtime import mpc',
                    'secint = mpc.SecInt()',
                    'secfxp = mpc.SecFxp()',
                    'secfld256 = mpc.SecFld(256)')
     asyncio.__main__.main(preamble)

The attachment contains the current version of mpyc.__main__.py, which to a large extent duplicates code from asyncio.__main__.py. A couple of, I think, minor changes are applied to make the code reusable, and to add the preamble feature.

Would be nice if asyncio.__main__.py is updated in this manner in Python 3.10 such that package developers can tailor it to their needs?

----------
components: asyncio
files: __main__.py
messages: 382419
nosy: asvetlov, lschoe, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: Make asyncio.__main__ reusable, also adding a preamble feature.
type: enhancement
versions: Python 3.10
Added file: https://bugs.python.org/file49652/__main__.py

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

From report at bugs.python.org  Thu Dec  3 10:53:54 2020
From: report at bugs.python.org (FX Coudert)
Date: Thu, 03 Dec 2020 15:53:54 +0000
Subject: [issue42504] Failure to build with MACOSX_DEPLOYMENT_TARGET=11 on Big
 Sur
In-Reply-To: <1606662964.61.0.531913261121.issue42504@roundup.psfhosted.org>
Message-ID: <1607010834.48.0.111520695225.issue42504@roundup.psfhosted.org>


FX Coudert <fxcoudert at gmail.com> added the comment:

"It has always resulted in a string value": only MACOSX_DEPLOYMENT_TARGET always took the form of a non-integer. The code for sysconfig.get_config_var() has a pretty clear intent: it will try to cast its return value to an int.

I don't have a strong opinion whether this is fixed this way or another. I would think, however, that there are surely places in existing code that expect and rely on sysconfig.get_config_var() returning an int for integer-type values.

----------

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

From report at bugs.python.org  Thu Dec  3 10:55:58 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 03 Dec 2020 15:55:58 +0000
Subject: [issue42541] Tkinter colours wrong on MacOS universal2
In-Reply-To: <1606920595.63.0.665509072103.issue42541@roundup.psfhosted.org>
Message-ID: <1607010958.53.0.612205289688.issue42541@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This is a duplicate of #38261.  I'm closing that other issue because this issue has more discussion.

----------

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

From report at bugs.python.org  Thu Dec  3 10:57:12 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 03 Dec 2020 15:57:12 +0000
Subject: [issue38261] Tkinter CheckButton default label white in macOS dark
 mode
In-Reply-To: <1569299740.39.0.742587153558.issue38261@roundup.psfhosted.org>
Message-ID: <1607011032.31.0.960898281841.issue38261@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This is a duplicate of #42541.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Tkinter colours wrong on MacOS universal2

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

From report at bugs.python.org  Thu Dec  3 11:07:46 2020
From: report at bugs.python.org (William Schwartz)
Date: Thu, 03 Dec 2020 16:07:46 +0000
Subject: [issue42531] importlib.resources.path() raises TypeError for packages
 without __file__
In-Reply-To: <1606890702.39.0.177441013455.issue42531@roundup.psfhosted.org>
Message-ID: <1607011666.47.0.977434034308.issue42531@roundup.psfhosted.org>


William Schwartz <wkschwartz at gmail.com> added the comment:

> If the issue has been fixed on Python 3.9 but not on 3.8, then it was likely a redesign that enabled the improved behavior

That appears to be the case: path() shares code with files().

> a redesign that won't be ported back to Python 3.8 and earlier.

Nor should it.

> In these situations, the best recommendation is often to just rely on importlib_resources (the backport) for those older Python versions.

I do not need the files() API or anything else added in 3.9 at this time. I just need the existing 3.7/3.8 functionality to work as documented.

> have you considered using importlib_resources for Python 3.8 and earlier? That would likely also address the issue and you could adopt it sooner.

My application is sensitive to the size of the installed site-packages both in bytes and in just the number of packages. Yes, importlib_resources would very likely solve the problem reported in the OP. However I don't need the files() API, so adding an extra requirement feels like a heavy solution.

> To some extent, the behavior you've described could be considered a bug or could be considered a feature request (add support for path on packages that have no __spec__.origin). I am not aware whether this limitation was by design or incidental.

I agree there should be a high bar for patching old versions, but I posit that the behavior is an unintentional bug. In particular, I believe the behavior contradicts the documentation. Below I link and quote relevant documentation.

The function in question:

> importlib.resources.path(package, resource)?
>     ...package is either a name or a module object which conforms to the
>     Package requirements.
https://docs.python.org/3.8/library/importlib.html#importlib.resources.path

So we jump to Package:

> importlib.resources.Package
>     The Package type is defined as Union[str, ModuleType]. This means that
>     where the function describes accepting a Package, you can pass in either a
>     string or a module. Module objects must have a resolvable
>     __spec__.submodule_search_locations that is not None.
https://docs.python.org/3.8/library/importlib.html#importlib.resources.Package


The Package type restricts the types of modules based on __spec__.submodule_search_locations. This suggests to me that the original author thought about which __spec__s to accept and which to reject but chose not to say anything about __spec__.origin, which is documented as possibly being None:

> class importlib.machinery.ModuleSpec(...)
>     ...module.__spec__.origin == module.__file__.... Normally ?origin? should
>     be set, but it may be None (the default) which indicates it is unspecified
>     (e.g. for namespace packages).
https://docs.python.org/3.8/library/importlib.html#importlib.machinery.ModuleSpec.origin

In particular, __spec__.origin *should* be None in certain situations:

> __file__
>     __file__ is optional.... The import system may opt to leave __file__ unset
>     if it has no semantic meaning (e.g. a module loaded from a database).
https://docs.python.org/3.8/reference/import.html#__file__

Taken together, the foregoing passages describe an `import` API in which path() works for all modules that are packages (i.e., __spec__.submodule_search_locations is not None), and in which some packages' __spec__.origin is None. That path() fails in practice to support some packages is therefore a bug not a the absence of a feature.

Regardless of whether PR 23611 is accepted, the test that it adds should be added to Python master to guard against regressions. I can submit that as a separate PR. Before I do that, do I need to create a new bpo ticket, or can I just reference this one?

----------

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

From report at bugs.python.org  Thu Dec  3 11:16:33 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 03 Dec 2020 16:16:33 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1607012193.76.0.754249652783.issue42536@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

functools.reduce looks affected, too.

----------

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

From report at bugs.python.org  Thu Dec  3 11:21:42 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 03 Dec 2020 16:21:42 +0000
Subject: [issue42555] math function sqrt() not working in 3.9
In-Reply-To: <1607001411.31.0.73323583323.issue42555@roundup.psfhosted.org>
Message-ID: <1607012502.25.0.740105847974.issue42555@roundup.psfhosted.org>


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

Mike, please ask questions on question forums such as python-list (mail.python.org) or stackoverflow.com, where other beginners can see the answer.  Also, IDLE is not Python.  In particular, python's response to code you send to python usually has nothing to do with IDLE.

----------
assignee: terry.reedy -> 

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

From report at bugs.python.org  Thu Dec  3 11:30:18 2020
From: report at bugs.python.org (E. Paine)
Date: Thu, 03 Dec 2020 16:30:18 +0000
Subject: [issue42541] Tkinter colours wrong on MacOS universal2
In-Reply-To: <1606920595.63.0.665509072103.issue42541@roundup.psfhosted.org>
Message-ID: <1607013018.0.0.671452701215.issue42541@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

> we should at least opt out of dark mode for IDLE
That still leaves tkinter almost unusable when dark mode is turned on. I am looking into solutions but am not hopeful (maybe we should ask Marc?).

@Ned, what are the alternatives if we decide 8.6.10 is not the way to go (do we go back to 8.6.8/9 or forward and use an arbitrary checkpoint assuming 8.6.11 is not happening soon)? Also, are we intending to provide a universal2 installer for 3.9.1 (i.e. we need to sort this asap)?

----------

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

From report at bugs.python.org  Thu Dec  3 11:32:27 2020
From: report at bugs.python.org (Jack O'Connor)
Date: Thu, 03 Dec 2020 16:32:27 +0000
Subject: [issue40550] Popen.terminate fails with ProcessLookupError under
 certain conditions
In-Reply-To: <1588881684.43.0.416849020134.issue40550@roundup.psfhosted.org>
Message-ID: <1607013147.06.0.648027742453.issue40550@roundup.psfhosted.org>


Jack O'Connor <oconnor663 at gmail.com> added the comment:

I'm late to the party, but I want to explain what's going on here in case it's helpful to folks. The issue you're seeing here has to do with whether a child processs has been "reaped". (Windows is different from Unix here, because the parent keeps an open handle to the child, so this is mostly a Unix thing.) In short, when a child exits, it leaves a "zombie" process whose only job is to hold some metadata and keep the child's PID reserved.  When the parent calls wait/waitpid/waitid or similar, that zombie process is cleaned up. That means that waiting has important correctness properties apart from just blocking the parent -- signaling after wait returns is unsafe, and forgetting to wait also leaks kernel resources.

Here's a short example demonstrating this:

```
  import signal                                                                                                                                                                                
  import subprocess                                                                                                                                                                            
  import time                                                                                                                                                                                  
                                                                                                                                                                                               
  # Start a child process and sleep a little bit so that we know it's exited.                                                                                                                              
  child = subprocess.Popen(["true"])                                                                                                                                                           
  time.sleep(1)                                                                                                                                                                                
                                                                                                                                                                                               
  # Signal it. Even though it's definitely exited, this is not an error.                                                                                                                                  
  os.kill(child.pid, signal.SIGKILL)                                                                                                                                                           
  print("signaling before waiting works fine")                                                                                                                                                 
                                                                                                                                                                                               
  # Now wait on it. We could also use os.waitpid or os.waitid here. This reaps                                                                                                                 
  # the zombie child.                                                                                                                                                                          
  child.wait()                                                                                                                                                                                 
                                                                                                                                                                                               
  # Try to signal it again. This raises ProcessLookupError, because the child's                                                                                                                
  # PID has been freed. But note that Popen.kill() would be a no-op here,
  # because it knows the child has already been waited on.                                                                                                                                                    
  os.kill(child.pid, signal.SIGKILL)                                                                                                                                                           
```

With that in mind, the original behavior with communicate() that started this bug is expected. The docs say that communicate() "waits for process to terminate and sets the returncode attribute." That means internally it calls waitpid, so your terminate() thread is racing against process exit. Catching the exception thrown by terminate() will hide the problem, but the underlying race condition means your program might end up killing an unrelated process that just happens to reuse the same PID at the wrong time. Doing this properly requires using waitid(WNOWAIT), which is...tricky.

----------
nosy: +oconnor663

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

From report at bugs.python.org  Thu Dec  3 11:40:25 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 03 Dec 2020 16:40:25 +0000
Subject: [issue42507] test_ttk_guionly test failures on macOS with Tcl/Tk
 8.6.10
In-Reply-To: <1606704400.88.0.0493725264205.issue42507@roundup.psfhosted.org>
Message-ID: <1607013625.94.0.558207779612.issue42507@roundup.psfhosted.org>


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

The test may be correctly detecting a change in widget behavior.  This is less surprising to me than some keypresses acting like two keypresses a millesecond apart.

----------

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

From report at bugs.python.org  Thu Dec  3 12:05:29 2020
From: report at bugs.python.org (Jack O'Connor)
Date: Thu, 03 Dec 2020 17:05:29 +0000
Subject: [issue42558] waitpid/waitid race caused by change to
 Popen.send_signal in Python 3.9
Message-ID: <1607015129.26.0.150065141179.issue42558@roundup.psfhosted.org>


New submission from Jack O'Connor <oconnor663 at gmail.com>:

In Python 3.9, Popen.send_signal() was changed to call Popen.poll() internally before signaling. (Tracking bug: https://bugs.python.org/issue38630.) This is a best-effort check for the famous kill/wait race condition. However, because this can now reap an already-exited child process as a side effect, it can cause previously working programs to crash. Here's a simple example:

```
import os
import subprocess
import time

child = subprocess.Popen(["true"])
time.sleep(1)
child.kill()
os.waitpid(child.pid, 0)
```

The program above exits cleanly in Python 3.8 but crashes with ChildProcessError in Python 3.9. It's a race against child process exit, so in practice (without the sleep) it's a heisenbug.

There's a deeper race here that's harder to demonstrate in an example, but parallel to the original wait/kill issue: If the child PID happens to be reused by another parent thread in this same process, the call to waitpid might *succeed* and reap the unrelated child process. That would export the crash to that thread, and possibly create more kill/wait races.

In short, the question of when exactly a child process is reaped is important for correct signaling on Unix, and changing that behavior can break programs in confusing ways. This change affected the Duct library, and I might not've caught it if not for a lucky failing doctest: https://github.com/oconnor663/duct.py/commit/5dfae70cc9481051c5e53da0c48d9efa8ff71507

I haven't searched for more instances of this bug in the wild, but one way to find them would be to look for code that calls both os.waitpid/waitid and also Popen.send_signal/kill/terminate. Duct found itself in this position because it was using waitid(WNOWAIT) on Unix only, to solve this same race condition, and also using Popen.kill on both Unix and Windows.

----------
messages: 382429
nosy: oconnor663
priority: normal
severity: normal
status: open
title: waitpid/waitid race caused by change to Popen.send_signal in Python 3.9
type: crash
versions: Python 3.9

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

From report at bugs.python.org  Thu Dec  3 12:05:56 2020
From: report at bugs.python.org (Jack O'Connor)
Date: Thu, 03 Dec 2020 17:05:56 +0000
Subject: [issue38630] subprocess.Popen.send_signal() should poll the process
In-Reply-To: <1572347906.82.0.50492662575.issue38630@roundup.psfhosted.org>
Message-ID: <1607015156.45.0.796997785296.issue38630@roundup.psfhosted.org>


Jack O'Connor <oconnor663 at gmail.com> added the comment:

Filed separately as https://bugs.python.org/issue42558.

----------

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

From report at bugs.python.org  Thu Dec  3 12:22:30 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 03 Dec 2020 17:22:30 +0000
Subject: [issue42523] using windows doc incorrectly states version support
In-Reply-To: <1606826036.29.0.083322027972.issue42523@roundup.psfhosted.org>
Message-ID: <1607016150.18.0.972777083376.issue42523@roundup.psfhosted.org>


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


New changeset db68544122f5a0c7b80f69c0e643049efa6699c6 by Zackery Spytz in branch 'master':
bpo-42523: Fix supported versions in "Using Python on Windows" (GH-23603)
https://github.com/python/cpython/commit/db68544122f5a0c7b80f69c0e643049efa6699c6


----------

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

From report at bugs.python.org  Thu Dec  3 12:22:30 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Dec 2020 17:22:30 +0000
Subject: [issue42523] using windows doc incorrectly states version support
In-Reply-To: <1606826036.29.0.083322027972.issue42523@roundup.psfhosted.org>
Message-ID: <1607016150.4.0.0918211463134.issue42523@roundup.psfhosted.org>


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


----------
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +22500
pull_request: https://github.com/python/cpython/pull/23631

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

From report at bugs.python.org  Thu Dec  3 12:43:04 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 03 Dec 2020 17:43:04 +0000
Subject: [issue42523] using windows doc incorrectly states version support
In-Reply-To: <1606826036.29.0.083322027972.issue42523@roundup.psfhosted.org>
Message-ID: <1607017384.21.0.866108006798.issue42523@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/issue42523>
_______________________________________

From report at bugs.python.org  Thu Dec  3 12:47:10 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 03 Dec 2020 17:47:10 +0000
Subject: [issue42523] using windows doc incorrectly states version support
In-Reply-To: <1606826036.29.0.083322027972.issue42523@roundup.psfhosted.org>
Message-ID: <1607017630.21.0.54774336965.issue42523@roundup.psfhosted.org>


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


New changeset 3689c25a1010c2acdb05f1b1b0229f4766b4440a by Miss Islington (bot) in branch '3.9':
bpo-42523: Fix supported versions in "Using Python on Windows" (GH-23603)
https://github.com/python/cpython/commit/3689c25a1010c2acdb05f1b1b0229f4766b4440a


----------

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

From report at bugs.python.org  Thu Dec  3 12:49:52 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 03 Dec 2020 17:49:52 +0000
Subject: [issue42541] Tkinter colours wrong on MacOS universal2
In-Reply-To: <1606920595.63.0.665509072103.issue42541@roundup.psfhosted.org>
Message-ID: <1607017792.28.0.586163337559.issue42541@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

It is possible to opt out of dark mode using a key in the Info.plist file. This can also be used in the Python.app hidden in the framework to globally disable support for dark mode.

I wouldn't switch back to 8.6.9, if only because that doesn't build properly on macOS 11 (and hence would make building the "univeral2" installer a lot harder). 

I'd rather use the tip of the 8.6.x branch for Tk to get the latest bug fixes (probably picking a specific commit to be able to reproduce the build).

----------

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

From report at bugs.python.org  Thu Dec  3 12:53:56 2020
From: report at bugs.python.org (Paul Sokolovsky)
Date: Thu, 03 Dec 2020 17:53:56 +0000
Subject: [issue42559] random.getrandbits: Should it be explicit that it
 returns unsigned/non-negative integer?
Message-ID: <1607018036.1.0.534167707073.issue42559@roundup.psfhosted.org>


New submission from Paul Sokolovsky <pfalcon at users.sourceforge.net>:

Current docs for random.getrandbits() ( https://docs.python.org/3/library/random.html#random.getrandbits ) read (3.9.1rc1 at the top of the page):

Returns a Python integer with k random bits. This method is supplied with the MersenneTwister generator and some other generators may also provide it as an optional part of the API. When available, getrandbits() enables randrange() to handle arbitrarily large ranges.

So, based that it talks about "bits", it's easy to imagine that the result is unsigned. But it's interesting that it mentions "a Python integer", not even just "integer". And Python integers are known to be signed.

So I'd say, there's enough of ambiguity in there, and would be nice to explicitly specify that it's "unsigned (non-negative) Python integer".


If there's interest for the background of concern, some implementations may have "small" and "large" integers underlyingly (which used to be exposed at the user-level in Python2). "Small" integers would be cheaper, but of course, they would be signed. So, at certain value of getrandbits() parameter, there may be a temptation to use up a sign bit of a small integer, instead of going straight to allocating expensive large integer. It should be clear this is NOT a valid "optimization", and result should be always non-negative.

----------
messages: 382434
nosy: pfalcon
priority: normal
severity: normal
status: open
title: random.getrandbits: Should it be explicit that it returns unsigned/non-negative integer?
versions: Python 3.9

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

From report at bugs.python.org  Thu Dec  3 12:57:15 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 03 Dec 2020 17:57:15 +0000
Subject: [issue41915] unittest.mock.create_autospec(Obj,
 instance=True) has self keyword in _spec_signature if Obj implements
 __call__
In-Reply-To: <1601688227.96.0.0965935424623.issue41915@roundup.psfhosted.org>
Message-ID: <1607018235.27.0.243088882255.issue41915@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/issue41915>
_______________________________________

From report at bugs.python.org  Thu Dec  3 13:16:18 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 03 Dec 2020 18:16:18 +0000
Subject: [issue42508] macOS IDLE with Tk 8.6.10 in 3.9.1rc1 universal2
 installer fails smoke test
In-Reply-To: <1606706274.22.0.163331071262.issue42508@roundup.psfhosted.org>
Message-ID: <1607019378.24.0.983241791598.issue42508@roundup.psfhosted.org>


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

The new commit to PR 23577 works around the double run_module_event call.  Removing the delay changed timings, so I instead measured the time between closing the errorbox and the 2nd call.  The allowed difference had to be increased to .015, so I selected .05 to be safer.

----------

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

From report at bugs.python.org  Thu Dec  3 13:21:46 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 03 Dec 2020 18:21:46 +0000
Subject: [issue42543] case sensitivity in open() arguments
In-Reply-To: <1606925370.25.0.425660398835.issue42543@roundup.psfhosted.org>
Message-ID: <1607019706.28.0.636245290756.issue42543@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Although I'm not sure the existing message needs changing, if a change is going to be made I think listing the valid option characters might be more useful.

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

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

From report at bugs.python.org  Thu Dec  3 13:35:37 2020
From: report at bugs.python.org (Mason Ginter)
Date: Thu, 03 Dec 2020 18:35:37 +0000
Subject: [issue42560] Improve Tkinter Documentation
Message-ID: <1607020537.02.0.420924180434.issue42560@roundup.psfhosted.org>


New submission from Mason Ginter <mason at dagint.com>:

Online python Tkinter documentation (https://docs.python.org/3/library/tkinter.html) lacks many features. The main part I find lacking is documentation on methods, as many of them either aren't listed in the documentation and/or take *args as the only parameter, rather than defined parameters. 

Not sure how in-depth docs from effbot were, but those are not currently available.

Existing documentation in the source code (https://github.com/python/cpython/blob/3.9/Lib/tkinter/__init__.py) seems to be a good start to adding to the online documentation.

----------
assignee: docs at python
components: Documentation
messages: 382437
nosy: docs at python, mason2
priority: normal
severity: normal
status: open
title: Improve Tkinter Documentation
type: enhancement

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

From report at bugs.python.org  Thu Dec  3 13:35:56 2020
From: report at bugs.python.org (Irit Katriel)
Date: Thu, 03 Dec 2020 18:35:56 +0000
Subject: [issue26582] asyncio documentation links to wrong CancelledError
In-Reply-To: <1458225953.38.0.399231880747.issue26582@psf.upfronthosting.co.za>
Message-ID: <1607020556.44.0.1897038586.issue26582@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

I think this has been fixed in the docs by now. See for instance:

https://docs.python.org/3/library/asyncio-task.html#asyncio.gather
https://docs.python.org/3/library/asyncio-future.html#asyncio.Future.result

----------
nosy: +iritkatriel

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

From report at bugs.python.org  Thu Dec  3 13:53:15 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 03 Dec 2020 18:53:15 +0000
Subject: [issue42504] Failure to build with MACOSX_DEPLOYMENT_TARGET=11 on Big
 Sur
In-Reply-To: <1606662964.61.0.531913261121.issue42504@roundup.psfhosted.org>
Message-ID: <1607021595.9.0.973677855257.issue42504@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The value *for this key* is a dot separated sequence of integer labels in a string. The limit of that is a single integer label that could be converted to a Python int. 

With the current patch get_config_var('MACOSX_DEPLOYMENT_TARGET') mostly returns a string, but sometimes an integer.  And the last part is new behaviour, which means existing consumers of this won't be prepared to handle a non-string value (other than None).

I'll probably create an alternative PR this weekend.


sysconfig converts config values that look like integers to python ints because that's often useful, but in this case it isn't. This part of the code base is old and has not very well defined semantics.

----------

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

From report at bugs.python.org  Thu Dec  3 13:57:22 2020
From: report at bugs.python.org (Ned Deily)
Date: Thu, 03 Dec 2020 18:57:22 +0000
Subject: [issue42504] Failure to build with MACOSX_DEPLOYMENT_TARGET=11 on Big
 Sur
In-Reply-To: <1606662964.61.0.531913261121.issue42504@roundup.psfhosted.org>
Message-ID: <1607021842.6.0.143368603044.issue42504@roundup.psfhosted.org>


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

I agree with Ronald that it would be safest if the sysconfigs (all of them) always returned deployment target as a string and I would be fine with a PR that did that. That doesn't mean that the already applied PR needs to be changed, though, right? Just extra insurance.

----------

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

From report at bugs.python.org  Thu Dec  3 13:59:33 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 03 Dec 2020 18:59:33 +0000
Subject: [issue42116] Inspect library ignore comments at the end of a function
 (inspect.getsource)
In-Reply-To: <1603363723.99.0.873580527867.issue42116@roundup.psfhosted.org>
Message-ID: <1607021973.18.0.471385556274.issue42116@roundup.psfhosted.org>


Change by Batuhan Taskaya <isidentical at gmail.com>:


----------
nosy: +BTaskaya

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

From report at bugs.python.org  Thu Dec  3 14:05:16 2020
From: report at bugs.python.org (Ned Deily)
Date: Thu, 03 Dec 2020 19:05:16 +0000
Subject: [issue42507] test_ttk_guionly test failures on macOS with Tcl/Tk
 8.6.10
In-Reply-To: <1606704400.88.0.0493725264205.issue42507@roundup.psfhosted.org>
Message-ID: <1607022316.67.0.774765855492.issue42507@roundup.psfhosted.org>


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

OK, thanks for the clarification, Terry. Considering that our tkinter tests make assumptions about the underlying Tk widgets behavior, assumptions not necessarily shared by the Tk developers :), these kind of version-dependent failures are a risk of and shortcoming of having extensive tests like these. I'm not overly concerned about the failures other than it is not good to have failing tests.

Serihy: "Can I get a remote access to machine with macOS?" Sorry, that's difficult for me to provide right now; perhaps later.  Anyone else?

----------

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

From report at bugs.python.org  Thu Dec  3 14:07:49 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 03 Dec 2020 19:07:49 +0000
Subject: [issue42504] Failure to build with MACOSX_DEPLOYMENT_TARGET=11 on Big
 Sur
In-Reply-To: <1606662964.61.0.531913261121.issue42504@roundup.psfhosted.org>
Message-ID: <1607022469.3.0.266316929317.issue42504@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'd prefer to (effectively) revert the PR and treat MACOSX_DEPLOYMENT_TARGET=11 the same as MACOSX_DEPLOYMENT_TARGET=11.0.

The same issue has crept up on the wheel and packaging repos (in the context of changing the platform tag in wheel names).  As I wrote there: the ship has sailed w.r.t. those tags, there are already "macosx_11_0_univeral2" wheels on PyPI.

----------

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

From report at bugs.python.org  Thu Dec  3 14:12:49 2020
From: report at bugs.python.org (Ned Deily)
Date: Thu, 03 Dec 2020 19:12:49 +0000
Subject: [issue42541] Tkinter colours wrong on MacOS universal2
In-Reply-To: <1606920595.63.0.665509072103.issue42541@roundup.psfhosted.org>
Message-ID: <1607022769.9.0.980146648755.issue42541@roundup.psfhosted.org>


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

I agree that moving forward (using an unreleased 8.6.10+ snapshot) is better than moving backwards (back to 8.6.9).  Perhaps Marc or Kevin can suggest Tcl and Tk dev heads to use.

----------
nosy: +culler

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

From report at bugs.python.org  Thu Dec  3 14:33:08 2020
From: report at bugs.python.org (Irit Katriel)
Date: Thu, 03 Dec 2020 19:33:08 +0000
Subject: [issue17735] inspect.findsource raises IndexError
In-Reply-To: <1366030340.02.0.51431850328.issue17735@psf.upfronthosting.co.za>
Message-ID: <1607023988.55.0.97827529463.issue17735@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

I'm unable to reproduce it now. Has it been fixed?

>>> import x
>>> help(x)
Help on module x:

NAME
    x

FUNCTIONS
    func()

FILE
    c:\users\user\src\cpython\x.py


>>> from importlib import reload
>>> reload(x)
<module 'x' from 'C:\\Users\\User\\src\\cpython\\x.py'>
>>> help(x)
Help on module x:

NAME
    x

FUNCTIONS
    func()

    newfunc()

FILE
    c:\users\user\src\cpython\x.py

----------
nosy: +iritkatriel

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

From report at bugs.python.org  Thu Dec  3 14:35:33 2020
From: report at bugs.python.org (Irit Katriel)
Date: Thu, 03 Dec 2020 19:35:33 +0000
Subject: [issue17735] inspect.findsource raises IndexError
In-Reply-To: <1366030340.02.0.51431850328.issue17735@psf.upfronthosting.co.za>
Message-ID: <1607024133.83.0.40597132216.issue17735@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

Sorry, you're right - now the issue is when you remove functions from the module:

>>> reload(x)
<module 'x' from 'C:\\Users\\User\\src\\cpython\\x.py'>
>>> help(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\User\src\cpython\\lib\_sitebuiltins.py", line 103, in __call__
    return pydoc.help(*args, **kwds)
  File "C:\Users\User\src\cpython\lib\pydoc.py", line 2000, in __call__
    self.help(request)
  File "C:\Users\User\src\cpython\lib\pydoc.py", line 2059, in help
    else: doc(request, 'Help on %s:', output=self._output)
  File "C:\Users\User\src\cpython\lib\pydoc.py", line 1779, in doc
    pager(render_doc(thing, title, forceload))
  File "C:\Users\User\src\cpython\lib\pydoc.py", line 1772, in render_doc
    return title % desc + '\n\n' + renderer.document(object, name)
  File "C:\Users\User\src\cpython\lib\pydoc.py", line 472, in document
    if inspect.ismodule(object): return self.docmodule(*args)
  File "C:\Users\User\src\cpython\lib\pydoc.py", line 1273, in docmodule
    contents.append(self.document(value, key, name))
  File "C:\Users\User\src\cpython\lib\pydoc.py", line 474, in document
    if inspect.isroutine(object): return self.docroutine(*args)
  File "C:\Users\User\src\cpython\lib\pydoc.py", line 1510, in docroutine
    doc = getdoc(object) or ''
  File "C:\Users\User\src\cpython\lib\pydoc.py", line 187, in getdoc
    result = _getdoc(object) or inspect.getcomments(object)
  File "C:\Users\User\src\cpython\lib\inspect.py", line 882, in getcomments
    lines, lnum = findsource(object)
  File "C:\Users\User\src\cpython\lib\inspect.py", line 871, in findsource
    if pat.match(lines[lnum]): break
IndexError: list index out of range

----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.3

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

From report at bugs.python.org  Thu Dec  3 14:46:27 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 03 Dec 2020 19:46:27 +0000
Subject: [issue42507] test_ttk_guionly test failures on macOS with Tcl/Tk
 8.6.10
In-Reply-To: <1606704400.88.0.0493725264205.issue42507@roundup.psfhosted.org>
Message-ID: <1607024787.58.0.702480317714.issue42507@roundup.psfhosted.org>


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

All these failures point not on some details of appearance, but that the widget is not rendered at all.

----------

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

From report at bugs.python.org  Thu Dec  3 15:12:27 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 03 Dec 2020 20:12:27 +0000
Subject: [issue42507] test_ttk_guionly test failures on macOS with Tcl/Tk
 8.6.10
In-Reply-To: <1606704400.88.0.0493725264205.issue42507@roundup.psfhosted.org>
Message-ID: <1607026347.82.0.756893715672.issue42507@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I might be able to debug during the weekend, but my main focus will be on back porting the changes in #41100 to the 3.8 branch (or at least parts of it).

----------

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

From report at bugs.python.org  Thu Dec  3 15:19:31 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 03 Dec 2020 20:19:31 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1607026771.46.0.156521374198.issue42536@roundup.psfhosted.org>


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

I added some comments in the PR regarding the possibility of forcing the tracking on the visiting function to redirect the cost to gc passes instead of when calling next() but there is another option: not untracking tuples that have refcount == 1.

----------

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

From report at bugs.python.org  Thu Dec  3 15:24:22 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 03 Dec 2020 20:24:22 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1607027062.93.0.80758513143.issue42536@roundup.psfhosted.org>


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

> not untracking tuples that have refcount == 1.

Actually, this may not be a good idea as well: running test_list shows that there are 14786 tuples with refcount == 1 that would have been untracked. This is a non-trivial workload to the gc passes that we will lose if we do this.

Performance-wise, I think the best alternative is to force the tracking before visiting in tp_traverse.

----------

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

From report at bugs.python.org  Thu Dec  3 15:24:18 2020
From: report at bugs.python.org (sds)
Date: Thu, 03 Dec 2020 20:24:18 +0000
Subject: [issue42561] better error reporting in ast
Message-ID: <1607027058.31.0.3436923935.issue42561@roundup.psfhosted.org>


New submission from sds <sds at gnu.org>:

ast parsing error locations are hard to pinpoint.
See https://stackoverflow.com/q/46933995/850781.

----------
components: Library (Lib)
files: ast.diff
keywords: patch
messages: 382449
nosy: sam-s
priority: normal
severity: normal
status: open
title: better error reporting in ast
type: enhancement
versions: Python 3.10
Added file: https://bugs.python.org/file49653/ast.diff

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

From report at bugs.python.org  Thu Dec  3 15:27:56 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 03 Dec 2020 20:27:56 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1607027276.71.0.808160797489.issue42536@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

> I added some comments in the PR regarding the possibility of forcing the tracking on the visiting function to redirect the cost to gc passes instead of when calling next()...

Yep, I agree that this approach is better.

> ...but there is another option: not untracking tuples that have refcount == 1.

I do like the idea of not having to fix this in ~10 different places, but I'm not sure this is enough. The GC visit may happen when the refcount of the result tuple is > 1, but it may drop back to 1 before __next__ called again

z = zip([42, []])
item = next(zip)
gc.collect()  # Refcount of item == 2, untracked by GC.
del item  # Refcount of item == 1, ready to be recycled.
next(zip)  # This should be tracked, but won't be.

----------

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

From report at bugs.python.org  Thu Dec  3 15:34:37 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 03 Dec 2020 20:34:37 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1607027677.99.0.137950719486.issue42536@roundup.psfhosted.org>


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

> The GC visit may happen when the refcount of the result tuple is > 1, but it may drop back to 1 before __next__ called again

Good point. Also, is it possible that a more complex cycle ends having more than one reference to that result, so indeed that is not enough.

----------

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

From report at bugs.python.org  Thu Dec  3 15:38:17 2020
From: report at bugs.python.org (Yurii Karabas)
Date: Thu, 03 Dec 2020 20:38:17 +0000
Subject: [issue42562] dis failed to parse function that has only annotations
Message-ID: <1607027897.93.0.00454445674539.issue42562@roundup.psfhosted.org>


New submission from Yurii Karabas <1998uriyyo at gmail.com>:

`dis` module failed when trying to parse function that has only annotations at the function body:
```
def foo():
    a: int
```

Failed with stacktrace:
```
  1           0 LOAD_CONST               0 (<code object foo at 0x10847ebe0, file "test.py", line 1>)
              2 LOAD_CONST               1 ('foo')
              4 MAKE_FUNCTION            0
              6 STORE_NAME               0 (foo)
              8 LOAD_CONST               2 (None)
             10 RETURN_VALUE

Disassembly of <code object foo at 0x10847ebe0, file "test.py", line 1>:
Traceback (most recent call last):
  File "/Users/yuriikarabas/my-projects/temp-cpython/Lib/runpy.py", line 197, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/Users/yuriikarabas/my-projects/temp-cpython/Lib/runpy.py", line 87, in _run_code
    exec(code, run_globals)
  File "/Users/yuriikarabas/my-projects/temp-cpython/Lib/dis.py", line 536, in <module>
    _test()
  File "/Users/yuriikarabas/my-projects/temp-cpython/Lib/dis.py", line 533, in _test
    dis(code)
  File "/Users/yuriikarabas/my-projects/temp-cpython/Lib/dis.py", line 79, in dis
    _disassemble_recursive(x, file=file, depth=depth)
  File "/Users/yuriikarabas/my-projects/temp-cpython/Lib/dis.py", line 381, in _disassemble_recursive
    _disassemble_recursive(x, file=file, depth=depth)
  File "/Users/yuriikarabas/my-projects/temp-cpython/Lib/dis.py", line 373, in _disassemble_recursive
    disassemble(co, file=file)
  File "/Users/yuriikarabas/my-projects/temp-cpython/Lib/dis.py", line 369, in disassemble
    _disassemble_bytes(co.co_code, lasti, co.co_varnames, co.co_names,
  File "/Users/yuriikarabas/my-projects/temp-cpython/Lib/dis.py", line 389, in _disassemble_bytes
    maxlineno = max(linestarts.values()) + line_offset
ValueError: max() arg is an empty sequence
```

----------
components: Library (Lib)
messages: 382453
nosy: uriyyo
priority: normal
severity: normal
status: open
title: dis failed to parse function that has only annotations
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Thu Dec  3 15:43:26 2020
From: report at bugs.python.org (Yurii Karabas)
Date: Thu, 03 Dec 2020 20:43:26 +0000
Subject: [issue42562] dis failed to parse function that has only annotations
In-Reply-To: <1607027897.93.0.00454445674539.issue42562@roundup.psfhosted.org>
Message-ID: <1607028206.38.0.0353054666609.issue42562@roundup.psfhosted.org>


Change by Yurii Karabas <1998uriyyo at gmail.com>:


----------
keywords: +patch
pull_requests: +22501
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23632

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

From report at bugs.python.org  Thu Dec  3 15:47:49 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 03 Dec 2020 20:47:49 +0000
Subject: [issue42562] dis failed to parse function that has only annotations
In-Reply-To: <1607027897.93.0.00454445674539.issue42562@roundup.psfhosted.org>
Message-ID: <1607028469.76.0.953098042397.issue42562@roundup.psfhosted.org>


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


----------
nosy: +Mark.Shannon

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

From report at bugs.python.org  Thu Dec  3 16:07:43 2020
From: report at bugs.python.org (Marc Culler)
Date: Thu, 03 Dec 2020 21:07:43 +0000
Subject: [issue42541] Tkinter colours wrong on MacOS universal2
In-Reply-To: <1606920595.63.0.665509072103.issue42541@roundup.psfhosted.org>
Message-ID: <1607029663.11.0.813341898525.issue42541@roundup.psfhosted.org>


Marc Culler <marc.culler at gmail.com> added the comment:

Yes, I can provide a good commit ID to work with.  Please give me a couple of days.  The current tip is almost an ideal choice.  There have been no Aqua bug reports for quite some time.  But now there is one new one (from Kevin) so I'd like to fix that, discuss with Kevin, and test.

----------

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

From report at bugs.python.org  Thu Dec  3 17:13:17 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 03 Dec 2020 22:13:17 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1607033597.17.0.388795887836.issue42536@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

> I added some comments in the PR regarding the possibility of forcing the tracking on the visiting function

Thinking about this more, I'm a bit hesitant to put the re-tracking code in the traverse function (mostly stemming from my lack of knowledge about our GC algorithm). I have no idea how problematic tracking and untracking objects *during* collections can be. Consider the following reference chain:

-> z -> r -> o -> r

Here, z is a zip iterator, r is its result tuple, and o is some object. Let's say r was untracked in the previous collection (I believe untrack_tuples happens *after* all of the traverse functions are called).

I'm worried that the GC may not be able to detect the cycle if it visits o, then z (which *then* starts tracking r), then r.

Or, if this group is determined to be unreachable, untrack_tuples untracks r *before* the cycle is cleaned up. That seems like it could be a problem.

Or, if z's refcount drops to zero and it's cleaned up, its traverse function may *never* be called, which leaves the untracked r -> o -> r cycle.

I guess I'm just not sure how resilient the GC is to these sorts of things. Re-tracking the result tuple in __next__ sidesteps all of these potential issues, with no significant performance impact. So I think I might slightly prefer that.

----------

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

From report at bugs.python.org  Thu Dec  3 17:19:15 2020
From: report at bugs.python.org (Irit Katriel)
Date: Thu, 03 Dec 2020 22:19:15 +0000
Subject: [issue17735] inspect.findsource raises IndexError
In-Reply-To: <1366030340.02.0.51431850328.issue17735@psf.upfronthosting.co.za>
Message-ID: <1607033955.82.0.438427054975.issue17735@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
keywords: +patch
pull_requests: +22502
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23633

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

From report at bugs.python.org  Thu Dec  3 17:44:32 2020
From: report at bugs.python.org (Jan Tojnar)
Date: Thu, 03 Dec 2020 22:44:32 +0000
Subject: [issue36906] Compile time textwrap.dedent() equivalent for str or
 bytes literals
In-Reply-To: <1557772831.22.0.440689390024.issue36906@roundup.psfhosted.org>
Message-ID: <1607035472.12.0.717943352634.issue36906@roundup.psfhosted.org>


Jan Tojnar <jtojnar at gmail.com> added the comment:

One benefit of using a compile time feature over a runtime method is that the former allows for more predictable dedenting by first dedenting and only then interpolating variables.

For example, the following code does not dedent the test string at all:

```python
import textwrap

foo = "\n".join(["aaa", "bbb"])

test = textwrap.dedent(
    f"""
    block xxx:
        {foo}
    """
)
```

It would be much nicer if we had syntactical dedents based on the leftmost non-whitespace column in the string, as supported by Nix language, for example.

```python
test = (
    df"""
    block xxx:
    {textwrap.indent(foo, ' '*4)}
    """
)
```

It would be even nicer if the interpolated strings could be indented based on the column the interpolation occurs in but that can at least be done at runtime with only minor inconvenience.

----------
nosy: +jtojnar

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

From report at bugs.python.org  Thu Dec  3 18:32:26 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 03 Dec 2020 23:32:26 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1607038346.96.0.920178922272.issue42536@roundup.psfhosted.org>


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

> Or, if z's refcount drops to zero and it's cleaned up, its traverse function may *never* be called, which leaves the untracked r -> o -> r cycle.

This is a real problem, indeed. We would need to add the tracking to the tp_dealloc of the zip object as well.

> I have no idea how problematic tracking and untracking objects *during* collections can be.

It is indeed tricky: the most problematic part of the "surprise tracking" is the validity of the pointers, but the key here is that the traverse function will be called BEFORE (update_refs()) the pointers start being invalid (because of the bit reuse).

> Or, if this group is determined to be unreachable, untrack_tuples untracks r *before* the cycle is cleaned up. That seems like it could be a problem.

It is not: untrack_tuples is called over the reachable set after the gc knows what part of the linked list is isolated garbage. If the group is in the unreachable set, then untrack_tuples won't touch it. 

> I'm worried that the GC may not be able to detect the cycle if it visits o, then z (which *then* starts tracking r), then r.

This is not a problem IMO: if the gc does not see the cycle in that collection, it will in the next ones. Wat will happen is that at the beginning the gc does not see r so it iterates over the linked list of the generation being collected, decrementing the gc refcounts. When it reaches z, it starts decrementing the refcounts of z and that calls the traverse function of z, that tracks r AND decrements its gc refcounts but also it adds "r" to the end of the linked list of the young generation. This means that (assuming we are collecting the middle generation) in this collection the cycle will not be seen, but in a future collection where the young generation is collected then "r" will be visited normally (notice that the gc can see "r" without needing to visit "z" before). Also, notice that untrack_tuples() is called over the reachable set, but "r" is in the young generation so it won't be untracked. Also, if we are collecting the younger generation, then the cycle will be found and it will be cleaned nicely.

----------

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

From report at bugs.python.org  Thu Dec  3 18:34:18 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 03 Dec 2020 23:34:18 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1607038458.29.0.560963162751.issue42536@roundup.psfhosted.org>


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

I forgot to mention the conclusion: my conclusion is that although the GC is resilient to these shenanigans (it was also extensive validation along with the algorithm), I still prefer to track it on the next() call because is technically the right thing to do: A tuple has been mutated so it must be (potentially) tracked because it needs to behave "AS IF" the tuple was being created from scratch.

----------

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

From report at bugs.python.org  Thu Dec  3 18:51:36 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 03 Dec 2020 23:51:36 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1607039496.72.0.673089077298.issue42536@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

Thanks for that detailed explanation, Pablo.

If nobody objects to the current zip fix, I'll merge it and move on to similar PRs for the other affected stuff:

- dict.items
- enumerate
- functools.reduce
- itertools.product
- itertools.combinations
- itertools.combinations_with_replacement
- itertools.permutations
- itertools.zip_longest

----------

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

From report at bugs.python.org  Thu Dec  3 18:54:49 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 03 Dec 2020 23:54:49 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1607039689.84.0.601640976061.issue42536@roundup.psfhosted.org>


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

>  I'll merge it and move on to similar PRs for the other affected stuff:

Not sure if is more ergonomic, but I would prefer to fix this in one PR so the buildbots don't test the partial fixes. Also is easier to revert if something goes wrong with the approach as that would affect all. But being said that, if you prefer multiple ones, I am also fine :)

----------

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

From report at bugs.python.org  Thu Dec  3 19:18:22 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Fri, 04 Dec 2020 00:18:22 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1607041102.26.0.0957127437083.issue42536@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

Yeah, I'm fine with that.

----------

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

From report at bugs.python.org  Thu Dec  3 19:44:15 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Fri, 04 Dec 2020 00:44:15 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1607042655.5.0.696210332437.issue42536@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

Adding:

- collections.OrderedDict.items

----------

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

From report at bugs.python.org  Thu Dec  3 19:57:36 2020
From: report at bugs.python.org (Nicholas Kobald)
Date: Fri, 04 Dec 2020 00:57:36 +0000
Subject: [issue42563] max function reports type errors in incorrect order
Message-ID: <1607043456.77.0.380335998391.issue42563@roundup.psfhosted.org>


New submission from Nicholas Kobald <nkobald at tableau.com>:

I'm not _sure_ this is a bug, but I thought the behaviour was a bit odd. If you run max with a str and an int in different orders, you get this behaviour: 

>>> max(123, 'hello')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: '>' not supported between instances of 'str' and 'int'
>>> max(123, 'hello')

>>> max('hello', 123)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: '>' not supported between instances of 'int' and 'str'

Note that order of the error message: 'int' and 'str' is the inverse of the order the str and int really are. 

Did a search for max and didn't find this.

----------
messages: 382463
nosy: nkobald
priority: normal
severity: normal
status: open
title: max function reports type errors in incorrect order
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu Dec  3 21:11:52 2020
From: report at bugs.python.org (Gregory Szorc)
Date: Fri, 04 Dec 2020 02:11:52 +0000
Subject: [issue42564] "from .__init__ import ..." syntax imports a duplicate
 module
Message-ID: <1607047912.32.0.654567376337.issue42564@roundup.psfhosted.org>


New submission from Gregory Szorc <gregory.szorc at gmail.com>:

(Rereporting from https://github.com/indygreg/PyOxidizer/issues/317.)

$ mkdir foo
$ cat > foo/__init__.py <<EOF
> test = True
> EOF
$ cat > foo/bar.py <<EOF
> from .__init__ import test
> EOF
$ python3.9
Python 3.9.0 (default, Nov  1 2020, 22:40:00)
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import foo.bar
>>> import sys
>>> sys.modules['foo']
<module 'foo' from '/home/gps/tmp/pyinit-test/foo/__init__.py'>
>>> sys.modules['foo.__init__']
<module 'foo.__init__' from '/home/gps/tmp/pyinit-test/foo/__init__.py'>

I am surprised that `from .__init__` even works, as `__init__` isn't a valid module name.

What appears to be happening is the path based importer doesn't recognize the `__init__` as special and it falls back to its regular file probing technique to locate a module derive from the path. It finds the `__init__.py[c]` file and imports it.

A consequence of this is that the explicit `__init__` import/module exists as a separate module object under `sys.modules`. So you can effectively have the same file imported as 2 module objects living under 2 names. This could of course result in subtle software bugs, like module-level variables not updating when you expect them to. (This could also be a feature for code relying on this behavior, of course.)

I only attempted to reproduce with 3.9. But this behavior has likely existed for years.

----------
components: Interpreter Core
messages: 382464
nosy: indygreg
priority: normal
severity: normal
status: open
title: "from .__init__ import ..." syntax imports a duplicate module
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Thu Dec  3 21:51:26 2020
From: report at bugs.python.org (Siva Krishna Giri Babu Avvaru)
Date: Fri, 04 Dec 2020 02:51:26 +0000
Subject: [issue42565] Traceback (most recent call last):   File "<stdin>",
 line 1, in <module> NameError: name 'python' is not defined
Message-ID: <1607050286.4.0.671884194813.issue42565@roundup.psfhosted.org>


Change by Siva Krishna Giri Babu Avvaru <sivakrishna.avvaru at aol.com>:


----------
nosy: sivakrishnaavvaru
priority: normal
severity: normal
status: open
title: Traceback (most recent call last):   File "<stdin>", line 1, in <module> NameError: name 'python' is not defined
type: compile error
versions: Python 3.9

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

From report at bugs.python.org  Fri Dec  4 00:09:28 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 04 Dec 2020 05:09:28 +0000
Subject: [issue42565] Traceback (most recent call last):   File "<stdin>",
 line 1, in <module> NameError: name 'python' is not defined
Message-ID: <1607058568.23.0.920174193073.issue42565@roundup.psfhosted.org>


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

Please attach the program to reproduce the issue along with the full traceback in the issue body. It looks like you are trying to use a variable named 'python' which is not present at the given scope during execution.

----------
nosy: +xtreak
type: compile error -> behavior

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

From report at bugs.python.org  Fri Dec  4 01:47:29 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 04 Dec 2020 06:47:29 +0000
Subject: [issue42559] random.getrandbits: Should it be explicit that it
 returns unsigned/non-negative integer?
In-Reply-To: <1607018036.1.0.534167707073.issue42559@roundup.psfhosted.org>
Message-ID: <1607064449.95.0.470533896827.issue42559@roundup.psfhosted.org>


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

Do you care to propose a minimal PR adding the word "unsigned"?

Marking as low priority because the referenced docs are over a decade old and we've not seen a single case of someone being confused by it.

----------
assignee:  -> rhettinger
components: +Documentation
nosy: +rhettinger
priority: normal -> low
versions: +Python 3.10

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

From report at bugs.python.org  Fri Dec  4 02:32:11 2020
From: report at bugs.python.org (Josh Rosenberg)
Date: Fri, 04 Dec 2020 07:32:11 +0000
Subject: [issue42565] Traceback (most recent call last):   File "<stdin>",
 line 1, in <module> NameError: name 'python' is not defined
In-Reply-To: <1607058568.23.0.920174193073.issue42565@roundup.psfhosted.org>
Message-ID: <1607067130.99.0.647010670176.issue42565@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Looks like someone tried to run python inside an interactive Python shell, rather than the command line. I'm moving to pending and will eventually close unless they add a repro for some actual bug.

----------
nosy: +josh.r
status: open -> pending

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

From report at bugs.python.org  Fri Dec  4 02:46:13 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 04 Dec 2020 07:46:13 +0000
Subject: [issue42564] "from .__init__ import ..." syntax imports a duplicate
 module
In-Reply-To: <1607047912.32.0.654567376337.issue42564@roundup.psfhosted.org>
Message-ID: <1607067973.06.0.133232854034.issue42564@roundup.psfhosted.org>


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

Other example is:

>>> import sys
>>> import xml
>>> import xml.__init__
>>> sys.modules['xml']
<module 'xml' from '/home/serhiy/py/cpython/Lib/xml/__init__.py'>
>>> sys.modules['xml.__init__']
<module 'xml.__init__' from '/home/serhiy/py/cpython/Lib/xml/__init__.py'>
>>> sys.modules['xml'] is sys.modules['xml.__init__']
False

I'm not sure we should do anything about it other than say "Don't do this."

----------
nosy: +brett.cannon, eric.snow, ncoghlan, serhiy.storchaka

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

From report at bugs.python.org  Fri Dec  4 02:53:27 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 04 Dec 2020 07:53:27 +0000
Subject: [issue42563] max function reports type errors in incorrect order
In-Reply-To: <1607043456.77.0.380335998391.issue42563@roundup.psfhosted.org>
Message-ID: <1607068407.9.0.52542072909.issue42563@roundup.psfhosted.org>


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

This is because the code of the main() function is roughly equivalent to

    result = next(iter)
    for item in iter:
        if item > result:
            result = item

It can be changed to use "result < item" instead of "item > result", but it can has subtle differences in behavior. I am not sure what is better.

If we change it, it can only be in 3.10, because of the risk of affecting user code.

----------
nosy: +serhiy.storchaka
priority: normal -> low
versions: +Python 3.10 -Python 3.8

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

From report at bugs.python.org  Fri Dec  4 03:06:53 2020
From: report at bugs.python.org (Pierre Ossman)
Date: Fri, 04 Dec 2020 08:06:53 +0000
Subject: [issue41915] unittest.mock.create_autospec(Obj,
 instance=True) has self keyword in _spec_signature if Obj implements
 __call__
In-Reply-To: <1601688227.96.0.0965935424623.issue41915@roundup.psfhosted.org>
Message-ID: <1607069213.02.0.850435119927.issue41915@roundup.psfhosted.org>


Pierre Ossman <ossman at cendio.se> added the comment:

autospec's behaviour for methods is currently needed to work around Issue42556, so be careful with any fixes here so they don't break that workaround.

----------
nosy: +CendioOssman

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

From report at bugs.python.org  Fri Dec  4 03:17:57 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 04 Dec 2020 08:17:57 +0000
Subject: [issue26582] asyncio documentation links to wrong CancelledError
In-Reply-To: <1458225953.38.0.399231880747.issue26582@psf.upfronthosting.co.za>
Message-ID: <1607069877.64.0.333835858429.issue26582@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Moreover, the issue is outdated.

asyncio.CancelledError is not an alias of concurrent.futures.CancelledError starting from Python 3.8

Unfortunately, we should make this not 100% backward compatible change.

----------
nosy: +asvetlov

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

From report at bugs.python.org  Fri Dec  4 03:18:12 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Fri, 04 Dec 2020 08:18:12 +0000
Subject: [issue26582] asyncio documentation links to wrong CancelledError
In-Reply-To: <1458225953.38.0.399231880747.issue26582@psf.upfronthosting.co.za>
Message-ID: <1607069892.95.0.77368053785.issue26582@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
resolution:  -> out of date
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Dec  4 03:46:49 2020
From: report at bugs.python.org (zerotypic)
Date: Fri, 04 Dec 2020 08:46:49 +0000
Subject: [issue42566] Clearing stack frame of suspended coroutine causes
 coroutine to malfunction
Message-ID: <1607071609.18.0.760361961347.issue42566@roundup.psfhosted.org>


New submission from zerotypic <zerotypic at gmail.com>:

When a stack frame belonging to a coroutine that is currently suspended is cleared, via the frame.clear() function, the coroutine appears to stop working properly and hangs forever pending some callback.

I've put up an example program that exhibits this problem here: https://gist.github.com/zerotypic/74ac1a7d6b4b946c14c1ebd86de6027b (and also attached it)

In this example, the stack frame comes from the traceback object associated with an Exception that was raised inside the coroutine, which was passed to another coroutine.

I've included some sample output from the program below. In this run, we do not trigger the bug:

$ python3 async_bug.py
foo: raising exception
foo: waiting for ev
bar: exn = TypeError('blah',)
bar: setting ev
foo: ev set, quitting now.
bar: foo_task = <Task finished coro=<foo() done, defined at async_bug.py:9> result='quit successfully'>

The result is that the task running the coroutine "foo" quits successfully.

In this run, we trigger the bug by providing the "bad" commandline argument:

$ python3 async_bug.py bad
foo: raising exception
foo: waiting for ev
bar: exn = TypeError('blah',)
bar: Clearing frame.
bar: setting ev
bar: foo_task = <Task pending coro=<foo() done, defined at async_bug.py:9> wait_for=<Future pending cb=[<TaskWakeupMethWrapper object at 0x7faf08aa9378>()]>>
Task was destroyed but it is pending!
task: <Task pending coro=<foo() done, defined at async_bug.py:9> wait_for=<Future pending cb=[<TaskWakeupMethWrapper object at 0x7faf08aa9378>()]>>


The task running "foo" is still pending, waiting on some callback, even though it should have awakened and completed.

This also happens with generators:

>>> def gen():
...    try:
...       raise TypeError("blah")
...    except Exception as e:
...       yield e
...    print("Completing generator.")
...    yield "done"
... 
>>> gen()
<generator object gen at 0x7f562b6847d8>
>>> list(gen())
Completing generator.
[TypeError('blah',), 'done']
>>> g = gen()
>>> exn = next(g)
>>> exn.__traceback__.tb_frame.clear()
>>> next(g)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
StopIteration
>>> 

This isn't surprising since you shouldn't be able to clear frames of code that is still running. It seems to me that the frame.clear() function should check that the frame belongs to a suspended coroutine/generator, and refuse to clear the frame if so. In frame_clear() (frameobject.c:676), the frame is checked to see if it is currently executing using _PyFrame_IsExecuting(), and raises a RuntimeError if so. Perhaps this should be changed to use _PyFrameHasCompleted()? I am not familiar with the internals of CPython so I'm not sure if this is the right thing to do.

I've been testing this on 3.6.9, but looking at the code for 3.9, this is likely to still be an issue.

Also, I first discovered this due to a call to traceback.clear_frames() from unittest.TestCase.assertRaises(); so if the problem isn't fixed, perhaps unittest should be modified to optionally not clear frames.

Thanks!

----------
components: Interpreter Core
files: async_bug.py
messages: 382472
nosy: zerotypic
priority: normal
severity: normal
status: open
title: Clearing stack frame of suspended coroutine causes coroutine to malfunction
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file49654/async_bug.py

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

From report at bugs.python.org  Fri Dec  4 05:04:16 2020
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 04 Dec 2020 10:04:16 +0000
Subject: [issue36094] When using an SMTP SSL connection,, get ValueError.
In-Reply-To: <1550943841.97.0.129283187576.issue36094@roundup.psfhosted.org>
Message-ID: <1607076256.91.0.46594613252.issue36094@roundup.psfhosted.org>


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


----------
pull_requests: +22503
pull_request: https://github.com/python/cpython/pull/23635

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

From report at bugs.python.org  Fri Dec  4 05:33:02 2020
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 04 Dec 2020 10:33:02 +0000
Subject: [issue42246] Implement PEP 626
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1607077982.28.0.384204127033.issue42246@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +22504
pull_request: https://github.com/python/cpython/pull/23636

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

From report at bugs.python.org  Fri Dec  4 05:42:23 2020
From: report at bugs.python.org (haoyixing)
Date: Fri, 04 Dec 2020 10:42:23 +0000
Subject: [issue42461] os.statvfs_result doesn't show f_fsid
In-Reply-To: <1606298815.17.0.951829865382.issue42461@roundup.psfhosted.org>
Message-ID: <1607078543.91.0.230489975501.issue42461@roundup.psfhosted.org>


haoyixing <359062468 at qq.com> added the comment:

hi christian, is there any future suggestions?

----------

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

From report at bugs.python.org  Fri Dec  4 05:47:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Dec 2020 10:47:37 +0000
Subject: [issue41473] test_gdb fails on AMD64 Fedora Rawhide 3.x [gdb 9.2 bug]
In-Reply-To: <1596550767.43.0.215651378336.issue41473@roundup.psfhosted.org>
Message-ID: <1607078857.87.0.604907085519.issue41473@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22505
pull_request: https://github.com/python/cpython/pull/23637

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

From report at bugs.python.org  Fri Dec  4 06:07:14 2020
From: report at bugs.python.org (Matteo Dell'Amico)
Date: Fri, 04 Dec 2020 11:07:14 +0000
Subject: [issue42240] Add Maxheap version of a heappush into heapq module
In-Reply-To: <1604298584.59.0.170869406843.issue42240@roundup.psfhosted.org>
Message-ID: <1607080034.71.0.856024034827.issue42240@roundup.psfhosted.org>


Matteo Dell'Amico <della at linux.it> added the comment:

Personally, I'd find a maxheap in the standard library helpful, and a quick Google search tells me I'm not alone.

I generally have to deal with numeric values, so I have these choices:
 - ugly code (e.g., `minus_distance, elem = heappop(heap)`, `distance = -minus_distance`)
 - slow code (e.g., wrapping heapq in a class)

Since most of maxheap is already implemented in the library, I wonder what is the rationale for not including it.

A couple of use cases for max-heap that I ran into:
 - maintaining k-nearest-neighbor structures (the farthest known one is at the top of the queue)
 - running median (requires both a minheap and a maxheap)

----------
nosy: +della

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

From report at bugs.python.org  Fri Dec  4 06:08:55 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Dec 2020 11:08:55 +0000
Subject: [issue42558] waitpid/waitid race caused by change to
 Popen.send_signal in Python 3.9
In-Reply-To: <1607015129.26.0.150065141179.issue42558@roundup.psfhosted.org>
Message-ID: <1607080135.02.0.987277529156.issue42558@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The script fails with "ChildProcessError: [Errno 10] No child processes" on line:

> os.waitpid(child.pid, 0)

The line before, you call child.kill() which sends SIGKILL signal to the process. So it's likely that the process will complete (killed by SIGKILL) soon.

I don't think that it's a good idea to attempt reading the process status directly (by calling os.waitpid), since subprocess already tracks the process status.

There is the public child.poll() API which calls os.waitpid(child.pid, 0) in a safe way for you. Why not using this API?

IMO this issue is not a bug.

Note: Python 3.8 behaves differently, but it doesn't mean that calling directly os.waitpid() was a good idea in Python 3.8 and older ;-)

----------
nosy: +gregory.p.smith, vstinner

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

From report at bugs.python.org  Fri Dec  4 06:13:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Dec 2020 11:13:41 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1607080421.5.0.536049401674.issue42536@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Would it be possible to push a quick & dirty workaround for test_itertools? I'm getting more and more buildbot Refleaks failures.

For example, always skip TestGC.test_zip() for now.

This issue seems quite complex and I would prefer to have time to think about it to design a proper fix, rather than having to work under pressure.

----------

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

From report at bugs.python.org  Fri Dec  4 06:16:01 2020
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 04 Dec 2020 11:16:01 +0000
Subject: [issue42562] dis failed to parse function that has only annotations
In-Reply-To: <1607027897.93.0.00454445674539.issue42562@roundup.psfhosted.org>
Message-ID: <1607080561.37.0.671076680586.issue42562@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

There are two issues here.
1. The compiler is not following PEP 626 for functions with no executable code
2. dis is not robust in the case that there are no line numbers.

I want to fix 1. first, then 2.

----------

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

From report at bugs.python.org  Fri Dec  4 06:30:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Dec 2020 11:30:27 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1607081427.14.0.674653022525.issue42536@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Would it be possible to push a quick & dirty workaround for test_itertools? I'm getting more and more buildbot Refleaks failures.

Oh, I looked at PR 23623 and it got many approvals. I'm fine with waiting for a few days until PR 23623 is merged.

----------

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

From report at bugs.python.org  Fri Dec  4 06:32:43 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 04 Dec 2020 11:32:43 +0000
Subject: [issue42554] distutils.util.get_platform() depends on minor version
 for macOS 11
In-Reply-To: <1607001108.52.0.506559643874.issue42554@roundup.psfhosted.org>
Message-ID: <1607081563.58.0.486406627542.issue42554@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

IMHO sysconfig.get_platform() and distutilis.util.get_platform() should always return a version with a major and minor number on macOS.

Could you add more information on the system where you get a version number that includes the micro version?

And to repeat myself: having "11.0" as the version a number is ship that has sailed, this is already used on PyPI (see PyObjC's latest wheels).

----------
versions: +Python 3.10

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

From report at bugs.python.org  Fri Dec  4 06:57:22 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 04 Dec 2020 11:57:22 +0000
Subject: [issue5054] CGIHTTPRequestHandler.run_cgi() HTTP_ACCEPT improperly
 parsed
In-Reply-To: <1232897403.01.0.0399148938595.issue5054@psf.upfronthosting.co.za>
Message-ID: <1607083042.43.0.704277970106.issue5054@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
pull_requests: +22506
pull_request: https://github.com/python/cpython/pull/23638

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

From report at bugs.python.org  Fri Dec  4 07:11:47 2020
From: report at bugs.python.org (Madhusudhan Kasula)
Date: Fri, 04 Dec 2020 12:11:47 +0000
Subject: [issue40529] Auto Completions with case insensitive
In-Reply-To: <1588768459.35.0.455156839892.issue40529@roundup.psfhosted.org>
Message-ID: <1607083907.65.0.984112350728.issue40529@roundup.psfhosted.org>


Madhusudhan Kasula <kasula.madhusudhan at gmail.com> added the comment:

Thanks for your suggestion Tal Einat.
I have created an discussion topic @ https://discuss.python.org/t/autocompletion-with-case-insensitive-option/6017

Please do support.

----------

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

From report at bugs.python.org  Fri Dec  4 07:16:56 2020
From: report at bugs.python.org (=?utf-8?b?6ZuF6Zuv?=)
Date: Fri, 04 Dec 2020 12:16:56 +0000
Subject: [issue40529] Auto Completions with case insensitive
In-Reply-To: <1588768459.35.0.455156839892.issue40529@roundup.psfhosted.org>
Message-ID: <1607084216.74.0.370695512557.issue40529@roundup.psfhosted.org>


?? <zhtw1234 at gmail.com> added the comment:

???

----------
nosy: +zhtw1234

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

From report at bugs.python.org  Fri Dec  4 07:18:56 2020
From: report at bugs.python.org (=?utf-8?b?6ZuF6Zuv?=)
Date: Fri, 04 Dec 2020 12:18:56 +0000
Subject: [issue40529] Auto Completions with case insensitive
In-Reply-To: <1588768459.35.0.455156839892.issue40529@roundup.psfhosted.org>
Message-ID: <1607084336.53.0.766942124149.issue40529@roundup.psfhosted.org>


?? <zhtw1234 at gmail.com> added the comment:

???

----------
Added file: https://bugs.python.org/file49655/IMAG0215.jpg

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

From report at bugs.python.org  Fri Dec  4 07:32:18 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 04 Dec 2020 12:32:18 +0000
Subject: [issue40529] Auto Completions with case insensitive
In-Reply-To: <1588768459.35.0.455156839892.issue40529@roundup.psfhosted.org>
Message-ID: <1607085138.21.0.211533696685.issue40529@roundup.psfhosted.org>


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


Removed file: https://bugs.python.org/file49655/IMAG0215.jpg

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

From report at bugs.python.org  Fri Dec  4 07:48:02 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 04 Dec 2020 12:48:02 +0000
Subject: [issue42532] spec_arg's __bool__ is called while initializing
 NonCallableMock
In-Reply-To: <1606998026.09.0.31549028921.issue42532@roundup.psfhosted.org>
Message-ID: <1607086082.9.0.527694707968.issue42532@roundup.psfhosted.org>


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

The fix to check for None seems straightforward to me and is only needed for AsyncMock. I would wait for others thoughts on this.

----------
nosy: +cjw296, lisroach, mariocj89, michael.foord, xtreak

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

From report at bugs.python.org  Fri Dec  4 07:58:50 2020
From: report at bugs.python.org (Alessio Bogon)
Date: Fri, 04 Dec 2020 12:58:50 +0000
Subject: [issue38780] SysLogHandler crash atexit
In-Reply-To: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>
Message-ID: <1607086730.25.0.472838734932.issue38780@roundup.psfhosted.org>


Alessio Bogon <youtux at gmail.com> added the comment:

Is there any update on this issue? I'm experiencing the same problem on macos.

----------

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

From report at bugs.python.org  Fri Dec  4 08:14:12 2020
From: report at bugs.python.org (Xavier Morel)
Date: Fri, 04 Dec 2020 13:14:12 +0000
Subject: [issue42470] DeprecationWarning triggers for sequences which happen
 to be sets as well
In-Reply-To: <1606379035.36.0.842330798084.issue42470@roundup.psfhosted.org>
Message-ID: <1607087652.82.0.757979978582.issue42470@roundup.psfhosted.org>


Xavier Morel <xavier.morel at masklinn.net> added the comment:

I was preparing to open the PR but now I'm doubting: should I open the PR against master and miss islington will backport it, or should I open the PR against 3.9?

----------

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

From report at bugs.python.org  Fri Dec  4 08:17:11 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 04 Dec 2020 13:17:11 +0000
Subject: [issue42470] DeprecationWarning triggers for sequences which happen
 to be sets as well
In-Reply-To: <1606379035.36.0.842330798084.issue42470@roundup.psfhosted.org>
Message-ID: <1607087831.55.0.0661983815945.issue42470@roundup.psfhosted.org>


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

Open it against master.

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

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

From report at bugs.python.org  Fri Dec  4 08:21:24 2020
From: report at bugs.python.org (FX Coudert)
Date: Fri, 04 Dec 2020 13:21:24 +0000
Subject: [issue42554] distutils.util.get_platform() depends on minor version
 for macOS 11
In-Reply-To: <1607001108.52.0.506559643874.issue42554@roundup.psfhosted.org>
Message-ID: <1607088084.61.0.800815631352.issue42554@roundup.psfhosted.org>


FX Coudert <fxcoudert at gmail.com> added the comment:

> having "11.0" as the version a number is ship that has sailed

I understand. What is needed is consistency and predictability.

Now, the next minor releases will be 11.0.1 (that has shipped already), 11.1.0 (will ship soon), then either 11.1.1 or 11.2.0 (we don't know). The next major version will of course be 12.0.0.

The question is: for 11.1.x or 11.2.x, which are minor updates, should the pypi/wheel tags increase to 11_1 and 11_2, or stay at 11_0? Has that been decided, and will be applied consistently? (11_0 makes more sense, and it is what wheel is currently applying)

----------

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

From report at bugs.python.org  Fri Dec  4 08:30:19 2020
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 04 Dec 2020 13:30:19 +0000
Subject: [issue42470] DeprecationWarning triggers for sequences which happen
 to be sets as well
In-Reply-To: <1606379035.36.0.842330798084.issue42470@roundup.psfhosted.org>
Message-ID: <1607088619.23.0.194651722869.issue42470@roundup.psfhosted.org>


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


----------
keywords: +patch
nosy: +python-dev
nosy_count: 4.0 -> 5.0
pull_requests: +22507
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23639

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

From report at bugs.python.org  Fri Dec  4 09:21:20 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 04 Dec 2020 14:21:20 +0000
Subject: [issue42554] distutils.util.get_platform() depends on minor version
 for macOS 11
In-Reply-To: <1607001108.52.0.506559643874.issue42554@roundup.psfhosted.org>
Message-ID: <1607091680.71.0.447213747193.issue42554@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

> Now, the next minor releases will be 11.0.1 (that has shipped already), 
> 11.1.0 (will ship soon), then either 11.1.1 or 11.2.0 (we don't know). The 
> next major version will of course be 12.0.0.
> 
> The question is: for 11.1.x or 11.2.x, which are minor updates, should 
> the pypi/wheel tags increase to 11_1 and 11_2, or stay at 11_0? Has 
> that been decided, and will be applied consistently? (11_0 makes more 
> sense, and it is what wheel is currently applying)

It depends :-)

We should advise everyone to build for deployment target 11.0 (and or 12.0 next year *if necessary*), but IMHO we shouldn't enforce this is in the stdlib.

If someone decides they want to build with MACOSX_DEPLOYMENT_TARGET=11.3 that's their choice and should be reflected in the result of get_platform(). We shouldn't default to that though just because you're building on macOS 11.3. 

Something we can work on is an informational PEP that describes the best way to build wheels on macOS, in cooperation with the PyPA, delocate, ciwheelbuild, and whoever else is interested in this.  And then try to teach the tooling to do the right thing.

In most cases it should be fairly easy to create wheels that target an earlier version of macOS (like the installers on Python.org).  The annoying part are (C) libraries with configure scripts that can detect and use functions that aren't available on the deployment target. For most libraries that I've created bindings for (most of them in-house) this hasn't been a problem in practice, but that's a very limited sample. 

Sorry about going of on a tangent, none of this is relevant for this particular issue ;-)

----------

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

From report at bugs.python.org  Fri Dec  4 09:51:03 2020
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 04 Dec 2020 14:51:03 +0000
Subject: [issue42567] Enum: manually call __init_subclass__ after members are
 added
Message-ID: <1607093463.71.0.994675423727.issue42567@roundup.psfhosted.org>


New submission from Ethan Furman <ethan at stoneleaf.us>:

__init_subclass__ is being automatically called when the initial Enum is created, but before the members have been added, greatly reducing that method's usefulness.

----------
assignee: ethan.furman
components: Library (Lib)
messages: 382489
nosy: ethan.furman
priority: normal
severity: normal
stage: needs patch
status: open
title: Enum: manually call __init_subclass__ after members are added
type: behavior
versions: Python 3.10

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

From report at bugs.python.org  Fri Dec  4 10:03:14 2020
From: report at bugs.python.org (Alexey Izbyshev)
Date: Fri, 04 Dec 2020 15:03:14 +0000
Subject: [issue42568] Python can't run .pyc files with non-ASCII path on
 Windows
Message-ID: <1607094194.36.0.301843698023.issue42568@roundup.psfhosted.org>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

> python ????.pyc
python: Can't reopen .pyc file

The issue is caused by _Py_fopen() being used as though it can deal with paths encoded in FS-default encoding (UTF-8 by default on Windows), but in fact it's just a simple wrapper around fopen() from the C runtime, so it uses the current ANSI code page, breaking if PYTHONLEGACYWINDOWSFSENCODING is not enabled.

I could find only two callers if _Py_fopen() on Windows:

* https://github.com/python/cpython/blob/db68544122f5/Python/pythonrun.c#L380 (which caused this issue)

* https://github.com/python/cpython/blob/db68544122f5/Python/errors.c#L1708

PyErr_ProgramText() doesn't seem to be called in CPython, but https://github.com/python/cpython/blob/db68544122f5/Include/pyerrors.h#L243 claims that filename is "decoded from the filesystem encoding", which doesn't match the code.

----------
components: Interpreter Core, Windows
messages: 382490
nosy: izbyshev, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
priority: normal
severity: normal
status: open
title: Python can't run .pyc files with non-ASCII path on Windows
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Dec  4 10:21:03 2020
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 04 Dec 2020 15:21:03 +0000
Subject: [issue42562] dis failed to parse function that has only annotations
In-Reply-To: <1607027897.93.0.00454445674539.issue42562@roundup.psfhosted.org>
Message-ID: <1607095263.18.0.590683309453.issue42562@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset f24b8101a01fa98b1e3ec042ba896aeb4c24d4bc by Yurii Karabas in branch 'master':
bpo-42562: Fix issue when dis failed to parse function that has no line numbers (GH-23632)
https://github.com/python/cpython/commit/f24b8101a01fa98b1e3ec042ba896aeb4c24d4bc


----------

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

From report at bugs.python.org  Fri Dec  4 10:22:22 2020
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 04 Dec 2020 15:22:22 +0000
Subject: [issue42246] Implement PEP 626
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1607095342.84.0.516541670993.issue42246@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset eaccc12aa986f92ea05f3f0a63cedbff78dd67f1 by Mark Shannon in branch 'master':
bpo-42246: Don't forget the entry block when ensuring that all exits have a line number (GH-23636)
https://github.com/python/cpython/commit/eaccc12aa986f92ea05f3f0a63cedbff78dd67f1


----------

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

From report at bugs.python.org  Fri Dec  4 10:23:25 2020
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 04 Dec 2020 15:23:25 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1607095405.66.0.399198041868.issue32381@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
versions: +Python 3.10

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

From report at bugs.python.org  Fri Dec  4 10:23:45 2020
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 04 Dec 2020 15:23:45 +0000
Subject: [issue42562] dis failed to parse function that has only annotations
In-Reply-To: <1607027897.93.0.00454445674539.issue42562@roundup.psfhosted.org>
Message-ID: <1607095425.71.0.189743831647.issue42562@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Thanks Yurii

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

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

From report at bugs.python.org  Fri Dec  4 10:24:00 2020
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 04 Dec 2020 15:24:00 +0000
Subject: [issue42568] Python can't run .pyc files with non-ASCII path on
 Windows
In-Reply-To: <1607094194.36.0.301843698023.issue42568@roundup.psfhosted.org>
Message-ID: <1607095440.88.0.0697810119812.issue42568@roundup.psfhosted.org>


Change by Eryk Sun <eryksun at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Python 3.6 cannot reopen .pyc file with non-ASCII path

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

From report at bugs.python.org  Fri Dec  4 10:24:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Dec 2020 15:24:04 +0000
Subject: [issue41473] test_gdb fails on AMD64 Fedora Rawhide 3.x [gdb 9.2 bug]
In-Reply-To: <1596550767.43.0.215651378336.issue41473@roundup.psfhosted.org>
Message-ID: <1607095444.55.0.872414297433.issue41473@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 066394018a8463643cc63d933493f0afa99d72cc by Victor Stinner in branch 'master':
bpo-41473: Reenable test_gdb on gdb 9.2 and newer (GH-23637)
https://github.com/python/cpython/commit/066394018a8463643cc63d933493f0afa99d72cc


----------

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

From report at bugs.python.org  Fri Dec  4 10:24:59 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 04 Dec 2020 15:24:59 +0000
Subject: [issue41473] test_gdb fails on AMD64 Fedora Rawhide 3.x [gdb 9.2 bug]
In-Reply-To: <1596550767.43.0.215651378336.issue41473@roundup.psfhosted.org>
Message-ID: <1607095499.31.0.360389467073.issue41473@roundup.psfhosted.org>


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


----------
pull_requests: +22508
pull_request: https://github.com/python/cpython/pull/23640

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

From report at bugs.python.org  Fri Dec  4 10:25:09 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 04 Dec 2020 15:25:09 +0000
Subject: [issue41473] test_gdb fails on AMD64 Fedora Rawhide 3.x [gdb 9.2 bug]
In-Reply-To: <1596550767.43.0.215651378336.issue41473@roundup.psfhosted.org>
Message-ID: <1607095509.95.0.674286249893.issue41473@roundup.psfhosted.org>


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


----------
pull_requests: +22509
pull_request: https://github.com/python/cpython/pull/23641

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

From report at bugs.python.org  Fri Dec  4 10:41:16 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 04 Dec 2020 15:41:16 +0000
Subject: [issue41473] test_gdb fails on AMD64 Fedora Rawhide 3.x [gdb 9.2 bug]
In-Reply-To: <1596550767.43.0.215651378336.issue41473@roundup.psfhosted.org>
Message-ID: <1607096476.55.0.803147565502.issue41473@roundup.psfhosted.org>


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


New changeset 8e8f82dd9459b9f62c21480528d737cffd6146bc by Miss Islington (bot) in branch '3.8':
bpo-41473: Reenable test_gdb on gdb 9.2 and newer (GH-23637)
https://github.com/python/cpython/commit/8e8f82dd9459b9f62c21480528d737cffd6146bc


----------

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

From report at bugs.python.org  Fri Dec  4 10:47:52 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 04 Dec 2020 15:47:52 +0000
Subject: [issue41473] test_gdb fails on AMD64 Fedora Rawhide 3.x [gdb 9.2 bug]
In-Reply-To: <1596550767.43.0.215651378336.issue41473@roundup.psfhosted.org>
Message-ID: <1607096872.07.0.242005709553.issue41473@roundup.psfhosted.org>


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


New changeset c7cf66d2fe1b85cc02153be6422dfc5e34811638 by Miss Islington (bot) in branch '3.9':
bpo-41473: Reenable test_gdb on gdb 9.2 and newer (GH-23637)
https://github.com/python/cpython/commit/c7cf66d2fe1b85cc02153be6422dfc5e34811638


----------

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

From report at bugs.python.org  Fri Dec  4 10:50:25 2020
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Fri, 04 Dec 2020 15:50:25 +0000
Subject: [issue38352] In typing docs,
 note explicit import needed for IO and Pattern/Match
In-Reply-To: <1570041077.58.0.399304866649.issue38352@roundup.psfhosted.org>
Message-ID: <1607097025.89.0.0438707438213.issue38352@roundup.psfhosted.org>


Walter D?rwald <walter at livinglogic.de> added the comment:

Shadowing the real modules `re` and `io` by

   from typing import *

would indeed be bad, but that argument IMHO doesn't hold for the types `IO`, `TextIO` and `BinaryIO`, yet they are not listed in `typing.__all__`. Is there a reason for that? And if not, could `IO`, `TextIO` and `BinaryIO` be added to `typing.__all__`?

----------
nosy: +doerwalter

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

From report at bugs.python.org  Fri Dec  4 11:11:53 2020
From: report at bugs.python.org (Jack O'Connor)
Date: Fri, 04 Dec 2020 16:11:53 +0000
Subject: [issue42558] waitpid/waitid race caused by change to
 Popen.send_signal in Python 3.9
In-Reply-To: <1607015129.26.0.150065141179.issue42558@roundup.psfhosted.org>
Message-ID: <1607098313.18.0.925016762901.issue42558@roundup.psfhosted.org>


Jack O'Connor <oconnor663 at gmail.com> added the comment:

Right, the example above is contrived to demonstrate the race and the crash.

In real life code, the good reason I know of to write code like this is to use os.waidid(WNOWAIT) to solve the wait/kill race properly. This is what Duct has been doing, and Nathaniel Smith also described this strategy in https://bugs.python.org/issue38630. The idea is that a waiting thread follows these steps:

1. waitid() with WNOWAIT set, without locking the child
2. after waitid returns, indicating the child has exited, lock the child
3. waitid() without WNOWAIT, or just waitpid(), to reap the zombie child
4. stash the exit status and unlock

Meanwhile a killing thread follows these steps:

1. lock the child
2. check the stashed exit status, and unlock and exit early if it's set
3. otherwise, signal the child and unlock

This strategy solves the race. The killing thread is free to signal while the waiting thread is blocked in step 1. If the killing thread happens to race in between when waitid() returns and when the waiting thread acquires the child lock, the child is a zombie and the kill signal has no effect. This is safe even if other threads (or e.g. the OOM killer) can randomly kill our child: *they* might have to worry about PID reuse, but their signals can never cause *us* to kill an unrelated process. What breaks this scheme is if some thread calls waitpid() and reaps the child outside of the lock, but normally that'd be a pretty unreasonable thing to do, especially since it can only be done by other threads in the parent process. (There's also some complexity around whether multiple threads are allowed to call waitid(WNOWAIT) on the same PID at the same time. I've just had one thread call it, and had other blocking waiters block on a second lock, but maybe that's overcautious.)

So anyway, if you use the strategy above -- precisely because you care about the PID reuse race and want to solve it properly -- and you also happen to use Popen.kill(), then changing Popen.send_signal to reap the child can break you.

I don't think this is a bug per se, but it's a behavior change, which matters to a small set of (abnormally) correct programs. But then again, if Duct is the only project that hits this in practice, maybe I'm making a mountain out of a molehill :)

----------

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

From report at bugs.python.org  Fri Dec  4 11:12:33 2020
From: report at bugs.python.org (Alexey Izbyshev)
Date: Fri, 04 Dec 2020 16:12:33 +0000
Subject: [issue42569] Callers of _Py_fopen/_Py_wfopen may be broken after
 addition of audit hooks
Message-ID: <1607098353.32.0.624763724813.issue42569@roundup.psfhosted.org>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

Before addition of audit hooks in 3.8, _Py_fopen() and _Py_wfopen() were simple wrappers around corresponding C runtime functions. They didn't require GIL, reported errors via errno and could be safely called during early interpreter initialization.

With the addition of PySys_Audit() calls, they can also raise an exception, which makes it unclear how they should be used. At least one caller[1] is confused, so an early-added hook (e.g. from sitecustomize.py) that raises a RuntimeError on at attempt to open the main file causes the following:

$ ./python /home/test/test.py
./python: can't open file '/home/test/test.py': [Errno 22] Invalid argument
Traceback (most recent call last):
  File "/home/test/.local/lib/python3.10/site-packages/sitecustomize.py", line 10, in hook
    raise RuntimeError("XXX")
RuntimeError: XXX

"Invalid argument" is reported by pymain_run_file() due to a bogus errno, and the real problem (exception from the hook) is noticed only later.

Could somebody share the current intended status/role of these helpers? Understanding that seems to be required to deal with issue 32381.

[1] https://github.com/python/cpython/blob/066394018a84/Modules/main.c#L314

----------
components: Interpreter Core
messages: 382499
nosy: izbyshev, steve.dower, vstinner
priority: normal
severity: normal
status: open
title: Callers of _Py_fopen/_Py_wfopen may be broken after addition of audit hooks
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Fri Dec  4 11:14:01 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 04 Dec 2020 16:14:01 +0000
Subject: [issue38352] In typing docs,
 note explicit import needed for IO and Pattern/Match
In-Reply-To: <1570041077.58.0.399304866649.issue38352@roundup.psfhosted.org>
Message-ID: <1607098441.33.0.808195194445.issue38352@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Wait, is the OP maybe that there?s a difference between typeshed an the stdlib typing.py?

----------

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

From report at bugs.python.org  Fri Dec  4 11:18:21 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 04 Dec 2020 16:18:21 +0000
Subject: [issue42563] max function reports type errors in incorrect order
In-Reply-To: <1607043456.77.0.380335998391.issue42563@roundup.psfhosted.org>
Message-ID: <1607098701.37.0.454091762564.issue42563@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I don't think making a change would be worth the risk.

----------
nosy: +eric.smith
priority: low -> normal
versions: +Python 3.8 -Python 3.10

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

From report at bugs.python.org  Fri Dec  4 11:22:33 2020
From: report at bugs.python.org (Alexey Izbyshev)
Date: Fri, 04 Dec 2020 16:22:33 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1607098953.82.0.51549109686.issue32381@roundup.psfhosted.org>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

Thanks, Eryk, for catching the dup, I missed it somehow.

@ZackerySpytz: do you plan to proceed with your PR? If not, I can pick it up -- this issue broke the software I develop after upgrade to 3.8.

I filed issue 42569 to hopefully clarify the status of _Py_fopen() which became murky to me.

----------
nosy: +izbyshev

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

From report at bugs.python.org  Fri Dec  4 11:26:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Dec 2020 16:26:10 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1607099170.06.0.512847939773.issue32381@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22510
pull_request: https://github.com/python/cpython/pull/23642

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

From report at bugs.python.org  Fri Dec  4 11:39:38 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Dec 2020 16:39:38 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1607099978.84.0.000241005240972.issue32381@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I can reproduce the issue on Python 3.10 with a script called ???.py which contains: print("hello").

c:\> python ???.py
hello

c:\>python __pycache__\???.cpython-310.pyc
python: Can't reopen .pyc file

And with my PR 23642 fix, it works as expected:

C:\>python __pycache__\???.cpython-310.pyc
hello

----------

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

From report at bugs.python.org  Fri Dec  4 11:43:54 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Dec 2020 16:43:54 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1607100234.82.0.872441528902.issue32381@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

bpo-42568 is marked as a duplicate of this issue.

----------

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

From report at bugs.python.org  Fri Dec  4 11:45:46 2020
From: report at bugs.python.org (Tal Einat)
Date: Fri, 04 Dec 2020 16:45:46 +0000
Subject: [issue42116] Inspect library ignore comments at the end of a function
 (inspect.getsource)
In-Reply-To: <1603363723.99.0.873580527867.issue42116@roundup.psfhosted.org>
Message-ID: <1607100346.7.0.132075425835.issue42116@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:


New changeset 6e1eec71f59c344fb23c7977061dc2c97b77d51b by Irit Katriel in branch 'master':
bpo-42116: Fix inspect.getsource handling of trailing comments (GH-23630)
https://github.com/python/cpython/commit/6e1eec71f59c344fb23c7977061dc2c97b77d51b


----------

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

From report at bugs.python.org  Fri Dec  4 11:46:04 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 04 Dec 2020 16:46:04 +0000
Subject: [issue42116] Inspect library ignore comments at the end of a function
 (inspect.getsource)
In-Reply-To: <1603363723.99.0.873580527867.issue42116@roundup.psfhosted.org>
Message-ID: <1607100364.95.0.0561569047651.issue42116@roundup.psfhosted.org>


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


----------
pull_requests: +22512
pull_request: https://github.com/python/cpython/pull/23644

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

From report at bugs.python.org  Fri Dec  4 11:45:54 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 04 Dec 2020 16:45:54 +0000
Subject: [issue42116] Inspect library ignore comments at the end of a function
 (inspect.getsource)
In-Reply-To: <1603363723.99.0.873580527867.issue42116@roundup.psfhosted.org>
Message-ID: <1607100354.24.0.905832475212.issue42116@roundup.psfhosted.org>


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


----------
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +22511
pull_request: https://github.com/python/cpython/pull/23643

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

From report at bugs.python.org  Fri Dec  4 11:46:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Dec 2020 16:46:33 +0000
Subject: [issue42558] waitpid/waitid race caused by change to
 Popen.send_signal in Python 3.9
In-Reply-To: <1607015129.26.0.150065141179.issue42558@roundup.psfhosted.org>
Message-ID: <1607100393.64.0.300302124149.issue42558@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

If you care about race conditions in send_signal(), I suggest you to write a PR to use the newly added os.pidfd_open() in subprocess:
https://docs.python.org/dev/library/os.html#os.pidfd_open

----------

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

From report at bugs.python.org  Fri Dec  4 11:49:26 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Dec 2020 16:49:26 +0000
Subject: [issue42569] Callers of _Py_fopen/_Py_wfopen may be broken after
 addition of audit hooks
In-Reply-To: <1607098353.32.0.624763724813.issue42569@roundup.psfhosted.org>
Message-ID: <1607100566.95.0.502874680465.issue42569@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Could somebody share the current intended status/role of these helpers?

To implement PEP 446: create non-inheritable file descriptors.

----------

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

From report at bugs.python.org  Fri Dec  4 11:51:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Dec 2020 16:51:24 +0000
Subject: [issue42569] Callers of _Py_fopen/_Py_wfopen may be broken after
 addition of audit hooks
In-Reply-To: <1607098353.32.0.624763724813.issue42569@roundup.psfhosted.org>
Message-ID: <1607100684.78.0.918925550675.issue42569@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Understanding that seems to be required to deal with issue 32381.

I wrote PR 23642 to fix bpo-32381.

----------

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

From report at bugs.python.org  Fri Dec  4 11:55:19 2020
From: report at bugs.python.org (Alexey Izbyshev)
Date: Fri, 04 Dec 2020 16:55:19 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1607100919.28.0.475299374064.issue32381@roundup.psfhosted.org>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

Thanks for the patch, Victor, it looks good.

Just so it doesn't get lost: the problem with the contract of PyErr_ProgramText() which I mentioned in my dup 42568 is still there.

----------

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

From report at bugs.python.org  Fri Dec  4 12:01:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Dec 2020 17:01:06 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1607101266.2.0.846014049247.issue32381@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Just so it doesn't get lost: the problem with the contract of PyErr_ProgramText() which I mentioned in my dup 42568 is still there.

It seems like PyErr_ProgramText() is no longer used in Python. PyErr_ProgramTextObject() is used and it pass the filename as Python object to _Py_fopen_obj().

----------

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

From report at bugs.python.org  Fri Dec  4 12:08:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Dec 2020 17:08:17 +0000
Subject: [issue42545] Check that all symbols in the limited ABI are exported
In-Reply-To: <1606942339.51.0.833109264536.issue42545@roundup.psfhosted.org>
Message-ID: <1607101697.02.0.418318517846.issue42545@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

My collection of links about the Python stable ABI:
https://pythoncapi.readthedocs.io/stable_abi.html

----------

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

From report at bugs.python.org  Fri Dec  4 12:12:39 2020
From: report at bugs.python.org (Alexey Izbyshev)
Date: Fri, 04 Dec 2020 17:12:39 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1607101959.4.0.573299744539.issue32381@roundup.psfhosted.org>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

> It seems like PyErr_ProgramText() is no longer used in Python.

Isn't it a part of the public API? I can't find it in the docs, but it seems to be declared in the public header.

----------

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

From report at bugs.python.org  Fri Dec  4 12:13:47 2020
From: report at bugs.python.org (Alexey Izbyshev)
Date: Fri, 04 Dec 2020 17:13:47 +0000
Subject: [issue42569] Callers of _Py_fopen/_Py_wfopen may be broken after
 addition of audit hooks
In-Reply-To: <1607098353.32.0.624763724813.issue42569@roundup.psfhosted.org>
Message-ID: <1607102027.61.0.631555856073.issue42569@roundup.psfhosted.org>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

> To implement PEP 446: create non-inheritable file descriptors.

Yes, I understand that was the original role. But currently there is no easy way to deal with errors from the helpers because of exception vs. errno conundrum. Maybe they should be split to two functions each (one that always reports errors via an exception, and the other is a low-level one)? Or, alternatively, keep only exception-reporting variants but check all callers so that they don't use errno and call them from the right context (with GIL, etc.)?

----------

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

From report at bugs.python.org  Fri Dec  4 12:16:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Dec 2020 17:16:40 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1607102200.18.0.03515878266.issue32381@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Isn't it a part of the public API? I can't find it in the docs, but it seems to be declared in the public header.

The Python C API has a strange history...

----------

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

From report at bugs.python.org  Fri Dec  4 12:53:40 2020
From: report at bugs.python.org (Kshitish)
Date: Fri, 04 Dec 2020 17:53:40 +0000
Subject: [issue42570] Try and Except doesn't work properly
Message-ID: <1607104420.61.0.0601519357686.issue42570@roundup.psfhosted.org>


New submission from Kshitish <nishantgautam930 at gmail.com>:

Try & Except doesn't work probably. 
In the except continue keyword doesn't work probably.

----------
files: main.py
messages: 382515
nosy: blue555
priority: normal
severity: normal
status: open
title: Try and Except doesn't work properly
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49656/main.py

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

From report at bugs.python.org  Fri Dec  4 12:56:35 2020
From: report at bugs.python.org (Peter Ludemann)
Date: Fri, 04 Dec 2020 17:56:35 +0000
Subject: [issue36541] Make lib2to3 grammar better match Python,
 support the := walrus
In-Reply-To: <1554514880.92.0.277848417721.issue36541@roundup.psfhosted.org>
Message-ID: <1607104595.01.0.440660812066.issue36541@roundup.psfhosted.org>


Peter Ludemann <peter.ludemann at gmail.com> added the comment:

I made a suggestion for augmenting ast.parse with some of lib2to3's features; but nobody seemed interested. 

RIP lib2to3. Like many pieces of software, it was used for far more than for what it was originally intended.

https://mail.python.org/archives/list/python-ideas at python.org/thread/X2HJ6I6XLIGRZDB27HRHIVQC3RXNZAY4/

----------

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

From report at bugs.python.org  Fri Dec  4 12:57:00 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 04 Dec 2020 17:57:00 +0000
Subject: [issue42570] Try and Except doesn't work properly
In-Reply-To: <1607104420.61.0.0601519357686.issue42570@roundup.psfhosted.org>
Message-ID: <1607104620.37.0.450221324515.issue42570@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

You've not said what happens, nor what you're expecting to happen, so we cannot help you.

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

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

From report at bugs.python.org  Fri Dec  4 13:02:26 2020
From: report at bugs.python.org (Irit Katriel)
Date: Fri, 04 Dec 2020 18:02:26 +0000
Subject: [issue37166] inspect.findsource doesn't handle shortened files
 gracefully
In-Reply-To: <1559763986.42.0.903204336475.issue37166@roundup.psfhosted.org>
Message-ID: <1607104946.06.0.0772030767897.issue37166@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
resolution:  -> duplicate
superseder:  -> inspect.findsource raises IndexError

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

From report at bugs.python.org  Fri Dec  4 13:06:31 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 04 Dec 2020 18:06:31 +0000
Subject: [issue42564] "from .__init__ import ..." syntax imports a duplicate
 module
In-Reply-To: <1607047912.32.0.654567376337.issue42564@roundup.psfhosted.org>
Message-ID: <1607105191.93.0.644285377964.issue42564@roundup.psfhosted.org>


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

I agree with Serhiy; don't do this. The only way we could fix this would be to always set a `__init__` module for every package implicitly, but then that would break anyone who wanted to clear out a package in sys.modules as the `__init__` reference in sys.modules becomes a dangling reference.

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

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

From report at bugs.python.org  Fri Dec  4 13:31:08 2020
From: report at bugs.python.org (Gregory Szorc)
Date: Fri, 04 Dec 2020 18:31:08 +0000
Subject: [issue42564] "from .__init__ import ..." syntax imports a duplicate
 module
In-Reply-To: <1607047912.32.0.654567376337.issue42564@roundup.psfhosted.org>
Message-ID: <1607106668.74.0.188156502062.issue42564@roundup.psfhosted.org>


Gregory Szorc <gregory.szorc at gmail.com> added the comment:

I worked around this in PyOxidizer by stripping a trailing `.__init__` from module names when resolving the indexed resource data. This allows the import to work since it can find the data now, but it also preserves the double module object, which isn't ideal IMO.

My preferred solution would be to either ban `__init__` in module name components or strip trailing `.__init__` from the name in `find_spec()`, effectively normalizing it away. Either of these would be backwards incompatible. Could either of these be considered for 3.10?

It's worth noting that `__init__` could potentially occur in the interior of the module name. e.g. `foo.__init__.bar`. This would require filenames like `foo/__init__/bar.py`. I wouldn't be surprised if this exists somewhere in the wild.

----------

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

From report at bugs.python.org  Fri Dec  4 13:54:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Dec 2020 18:54:52 +0000
Subject: [issue30459] PyList_SET_ITEM  could be safer
In-Reply-To: <1495638852.56.0.0790136948712.issue30459@psf.upfronthosting.co.za>
Message-ID: <1607108092.51.0.682709838058.issue30459@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22513
pull_request: https://github.com/python/cpython/pull/23645

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

From report at bugs.python.org  Fri Dec  4 14:28:43 2020
From: report at bugs.python.org (Irit Katriel)
Date: Fri, 04 Dec 2020 19:28:43 +0000
Subject: [issue24711] Document getpass.getpass behavior on ^C
In-Reply-To: <1437779531.88.0.954988782388.issue24711@psf.upfronthosting.co.za>
Message-ID: <1607110123.8.0.109428781123.issue24711@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

I don't see a difference between getpass and input in this respect:

----------------
import getpass

try:
    getpass.getpass('getpass: ')
except:
    pass
print('goodbye getpass')


try:
    input('input: ')
except:
    pass
print('goodbye input')

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

If I run that script and ^C after each prompt, I get this:

>python.bat x.py
Running Release|x64 interpreter...
getpass: goodbye getpass
input: goodbye input

----------
nosy: +iritkatriel
resolution:  -> works for me
status: open -> pending

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

From report at bugs.python.org  Fri Dec  4 14:53:33 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 04 Dec 2020 19:53:33 +0000
Subject: [issue42569] Callers of _Py_fopen/_Py_wfopen may be broken after
 addition of audit hooks
In-Reply-To: <1607098353.32.0.624763724813.issue42569@roundup.psfhosted.org>
Message-ID: <1607111613.65.0.554128111938.issue42569@roundup.psfhosted.org>


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

If the GIL is not held, no exception should be raised, so the fact that you've got one there means that the GIL is held and the main.c-specific error message is the bit that's wrong.

So it should be, "if they fail and you're in a context where exceptions are allowed, raise an exception" (which will chain back to the one raised from an audit hook".

----------

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

From report at bugs.python.org  Fri Dec  4 15:02:40 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 04 Dec 2020 20:02:40 +0000
Subject: [issue42564] "from .__init__ import ..." syntax imports a duplicate
 module
In-Reply-To: <1607047912.32.0.654567376337.issue42564@roundup.psfhosted.org>
Message-ID: <1607112160.02.0.938308378298.issue42564@roundup.psfhosted.org>


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

What is the problem? What real code imports __init__?

----------

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

From report at bugs.python.org  Fri Dec  4 15:09:11 2020
From: report at bugs.python.org (Gerald Dalley)
Date: Fri, 04 Dec 2020 20:09:11 +0000
Subject: [issue42248] Raised exception in Enum keeping user objects alive
 unnecessarily
In-Reply-To: <1604350009.17.0.208770748804.issue42248@roundup.psfhosted.org>
Message-ID: <1607112551.6.0.316297768776.issue42248@roundup.psfhosted.org>


Gerald Dalley <gerald.dalley at gmail.com> added the comment:

I and a few others have run into issues with the Enum constructors producing spurious reference cycles. This can cause memory explosions if large objects like numpy arrays are held in any of the relevant stack frames. Based on https://bugs.python.org/issue36820, it looks like the maintainers of CPython are open to fixing similar issues, and PRs look like the way to make progress.

----------
nosy: +gerald.dalley2
type:  -> enhancement

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

From report at bugs.python.org  Fri Dec  4 15:16:42 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 04 Dec 2020 20:16:42 +0000
Subject: [issue42558] waitpid/waitid race caused by change to
 Popen.send_signal in Python 3.9
In-Reply-To: <1607015129.26.0.150065141179.issue42558@roundup.psfhosted.org>
Message-ID: <1607113002.26.0.664620930539.issue42558@roundup.psfhosted.org>


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

I agree with Victor.  When code launches a process with subprocess APIs, it is expected that the subprocess module manages the process.

Calling os.waitpid directly instead of using subprocess's APIs breaks that expectation.

Also, WNOWAIT and waitid() (not waitpid()) are not available on all platforms.  Nor is pidfd_open().  Code using any of those for such a PR needs to be conditional on their runtime availability.

----------

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

From report at bugs.python.org  Fri Dec  4 15:19:40 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 04 Dec 2020 20:19:40 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1607113180.31.0.331867626329.issue31904@roundup.psfhosted.org>


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


New changeset 8d4f57dbd10846ffb4881b6509a511be0ab3b913 by pxinwr in branch 'master':
bpo-31904: fix test_doctest.py failures for VxWorks (GH-23419)
https://github.com/python/cpython/commit/8d4f57dbd10846ffb4881b6509a511be0ab3b913


----------
nosy: +gregory.p.smith

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

From report at bugs.python.org  Fri Dec  4 15:20:12 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 04 Dec 2020 20:20:12 +0000
Subject: [issue42116] Inspect library ignore comments at the end of a function
 (inspect.getsource)
In-Reply-To: <1603363723.99.0.873580527867.issue42116@roundup.psfhosted.org>
Message-ID: <1607113212.79.0.457427431088.issue42116@roundup.psfhosted.org>


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


New changeset 81ac030d03bdaedd724603af6f89f9248a5f2700 by Miss Islington (bot) in branch '3.9':
bpo-42116: Fix inspect.getsource handling of trailing comments (GH-23630)
https://github.com/python/cpython/commit/81ac030d03bdaedd724603af6f89f9248a5f2700


----------

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

From report at bugs.python.org  Fri Dec  4 15:20:13 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 04 Dec 2020 20:20:13 +0000
Subject: [issue42116] Inspect library ignore comments at the end of a function
 (inspect.getsource)
In-Reply-To: <1603363723.99.0.873580527867.issue42116@roundup.psfhosted.org>
Message-ID: <1607113213.08.0.26509020647.issue42116@roundup.psfhosted.org>


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


New changeset 3b14f18205b17d1634e21bd7bc48152247590d9f by Miss Islington (bot) in branch '3.8':
bpo-42116: Fix inspect.getsource handling of trailing comments (GH-23630)
https://github.com/python/cpython/commit/3b14f18205b17d1634e21bd7bc48152247590d9f


----------

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

From report at bugs.python.org  Fri Dec  4 15:21:43 2020
From: report at bugs.python.org (Tal Einat)
Date: Fri, 04 Dec 2020 20:21:43 +0000
Subject: [issue42116] Inspect library ignore comments at the end of a function
 (inspect.getsource)
In-Reply-To: <1603363723.99.0.873580527867.issue42116@roundup.psfhosted.org>
Message-ID: <1607113303.71.0.747350259522.issue42116@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

Thank you for reporting this, Noureddine Hamid!

Thanks for the PR, Irit!

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

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

From report at bugs.python.org  Fri Dec  4 15:57:46 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 04 Dec 2020 20:57:46 +0000
Subject: [issue42482] TracebackException should not hold reference to the
 exception traceback
In-Reply-To: <1606471868.96.0.673168968518.issue42482@roundup.psfhosted.org>
Message-ID: <1607115466.9.0.366207504197.issue42482@roundup.psfhosted.org>


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


New changeset 40b92f1cc06f9aaba813ae38266f424e0969b089 by Miss Islington (bot) in branch '3.9':
[3.9] bpo-42482: remove reference to exc_traceback from TracebackException (GH-23531) (GH-23578)
https://github.com/python/cpython/commit/40b92f1cc06f9aaba813ae38266f424e0969b089


----------

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

From report at bugs.python.org  Fri Dec  4 16:11:08 2020
From: report at bugs.python.org (Frederic Gagnon)
Date: Fri, 04 Dec 2020 21:11:08 +0000
Subject: [issue42571] [docs] add links to Glossary#parameter in libraries
Message-ID: <1607116268.54.0.585771365964.issue42571@roundup.psfhosted.org>


New submission from Frederic Gagnon <gagnonfrederic9 at gmail.com>:

Could be helpful to make it so that, in libraries, / * *<param> and **<param>  (i.e. positional-only, keyword-only, var-positional and var-keyword indicators) link to https://docs.python.org/3/glossary.html#term-parameter

This come from someone relatively new to python that had a somewhat hard time understanding what the ", *," stood for in https://docs.python.org/3/library/glob.html#glob.glob

----------
assignee: docs at python
components: Documentation
messages: 382530
nosy: docs at python, fredg1
priority: normal
severity: normal
status: open
title: [docs] add links to Glossary#parameter in libraries
type: enhancement

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

From report at bugs.python.org  Fri Dec  4 16:22:28 2020
From: report at bugs.python.org (Tal Einat)
Date: Fri, 04 Dec 2020 21:22:28 +0000
Subject: [issue17735] inspect.findsource raises IndexError
In-Reply-To: <1366030340.02.0.51431850328.issue17735@psf.upfronthosting.co.za>
Message-ID: <1607116948.59.0.239566591909.issue17735@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:


New changeset 2e0760bb2edb595050aff82f236cd32b44d3dfb3 by Irit Katriel in branch 'master':
bpo-17735: inspect.findsource now raises OSError when co_lineno is out of range (GH-23633)
https://github.com/python/cpython/commit/2e0760bb2edb595050aff82f236cd32b44d3dfb3


----------
nosy: +taleinat

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

From report at bugs.python.org  Fri Dec  4 16:23:25 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 04 Dec 2020 21:23:25 +0000
Subject: [issue17735] inspect.findsource raises IndexError
In-Reply-To: <1366030340.02.0.51431850328.issue17735@psf.upfronthosting.co.za>
Message-ID: <1607117005.86.0.52458739513.issue17735@roundup.psfhosted.org>


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


----------
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +22514
pull_request: https://github.com/python/cpython/pull/23646

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

From report at bugs.python.org  Fri Dec  4 16:23:33 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 04 Dec 2020 21:23:33 +0000
Subject: [issue17735] inspect.findsource raises IndexError
In-Reply-To: <1366030340.02.0.51431850328.issue17735@psf.upfronthosting.co.za>
Message-ID: <1607117013.25.0.551765487027.issue17735@roundup.psfhosted.org>


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


----------
pull_requests: +22515
pull_request: https://github.com/python/cpython/pull/23647

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

From report at bugs.python.org  Fri Dec  4 16:36:33 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 04 Dec 2020 21:36:33 +0000
Subject: [issue42570] Try and Except doesn't work properly
In-Reply-To: <1607104420.61.0.0601519357686.issue42570@roundup.psfhosted.org>
Message-ID: <1607117793.65.0.396870096475.issue42570@roundup.psfhosted.org>


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

Code is working correctly, not a bug. Perhaps you are mistaking `continue` for `break`.

Kshitish, we keep telling you not to use the bug tracker as a help desk. This is now your eighth "bug report" that was 100% your misunderstanding. There are many other resources where you can ask for help:

https://mail.python.org/mailman/listinfo/tutor

https://www.reddit.com/r/learnpython/

are good places to start. There are many others, which we have already suggested to you in previous issues. Please stop wasting our time.

----------
nosy: +steven.daprano
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Dec  4 16:45:15 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 04 Dec 2020 21:45:15 +0000
Subject: [issue17735] inspect.findsource raises IndexError
In-Reply-To: <1366030340.02.0.51431850328.issue17735@psf.upfronthosting.co.za>
Message-ID: <1607118315.25.0.609735097165.issue17735@roundup.psfhosted.org>


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


New changeset a4e7d5f750e06e31a80a83c2af02b1a40cecd0ff by Miss Islington (bot) in branch '3.8':
bpo-17735: inspect.findsource now raises OSError when co_lineno is out of range (GH-23633)
https://github.com/python/cpython/commit/a4e7d5f750e06e31a80a83c2af02b1a40cecd0ff


----------

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

From report at bugs.python.org  Fri Dec  4 16:51:45 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Dec 2020 21:51:45 +0000
Subject: [issue39573] [C API] Make PyObject an opaque structure in the limited
 C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1607118705.57.0.905568299583.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Status:

* Py_SET_REFCNT(), Py_SET_TYPE() and Py_SET_SIZE() functions added to Python 3.9.
* Python and Cython have been modified to use Py_TYPE(), Py_SET_REFCNT(), Py_IS_TYPE(), etc.
* pythoncapi_compat.h header file has been created to provide new functions to Python 3.6: https://github.com/pythoncapi/pythoncapi_compat
* Script has been created to upgrade C extensions to add support for Python 3.10 without losing support for old Python versions: https://github.com/pythoncapi/pythoncapi_compat
* PEP 620 "Hide implementation details from the C API" written
* Py_TYPE() and Py_SIZE() were converted to a static inline function to deny "Py_TYPE(obj) = type;" syntax, but this change has been reverted during Python 3.10 development cycle since it broke too many C extension modules. (msg381337)

TODO:

* Maybe add a new formatter for type names (msg361523)
* Avoid sizeof(PyObject) in PyType_FromSpec() (msg366473)

The purpose of this issue is only to fix the API part. Replacing static inline functions with opaque function calls (stable ABI) is not in the scope of this issue.

----------

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

From report at bugs.python.org  Fri Dec  4 16:54:33 2020
From: report at bugs.python.org (=?utf-8?b?TWlyb3NsYXYgxaBlZGl2w70=?=)
Date: Fri, 04 Dec 2020 21:54:33 +0000
Subject: [issue29249] Pathlib glob ** bug
In-Reply-To: <1484216394.04.0.57434547579.issue29249@psf.upfronthosting.co.za>
Message-ID: <1607118873.1.0.657268493328.issue29249@roundup.psfhosted.org>


Miroslav ?ediv? <miro at sedivy.de> added the comment:

Today when porting some random project from os.path to pathlib I encountered a homemade filename matching method that I wanted to port to pathlib.Path.match. Unfortunately

>>> pathlib.Path('x').match('**/x')
False

although if I have a file called `x` in the current directory, both

>>> pathlib.Path('.').glob('**/x')

and zsh's

$ ls **/x

can find it. It would be really nice to have analogous .glob and .match methods.

----------
nosy: +eumiro

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

From report at bugs.python.org  Fri Dec  4 17:06:07 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 04 Dec 2020 22:06:07 +0000
Subject: [issue42545] Check that all symbols in the limited ABI are exported
In-Reply-To: <1606942339.51.0.833109264536.issue42545@roundup.psfhosted.org>
Message-ID: <1607119567.02.0.866701329727.issue42545@roundup.psfhosted.org>


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


New changeset 85f1dedb8d05774e0d3739be0a11cd970b98097f by Pablo Galindo in branch 'master':
bpo-42545: Check that all symbols in the limited ABI are exported (GH-23616)
https://github.com/python/cpython/commit/85f1dedb8d05774e0d3739be0a11cd970b98097f


----------

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

From report at bugs.python.org  Fri Dec  4 17:09:27 2020
From: report at bugs.python.org (Mark Roseman)
Date: Fri, 04 Dec 2020 22:09:27 +0000
Subject: [issue14111] IDLE Debugger should handle interrupts
In-Reply-To: <1330112839.68.0.0096879566667.issue14111@psf.upfronthosting.co.za>
Message-ID: <1607119767.29.0.283206101282.issue14111@roundup.psfhosted.org>


Mark Roseman <mark at markroseman.com> added the comment:

Terry, I agree that Ctrl-C should act just as an interrupt when the debugger is active. I also agree that a way to interrupt the debugger through the user interface is needed (in the revised UI, there's an explicit 'stop' button for that).

----------

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

From report at bugs.python.org  Fri Dec  4 17:10:48 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 04 Dec 2020 22:10:48 +0000
Subject: [issue42545] Check that all symbols in the limited ABI are exported
In-Reply-To: <1606942339.51.0.833109264536.issue42545@roundup.psfhosted.org>
Message-ID: <1607119848.98.0.970870287631.issue42545@roundup.psfhosted.org>


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

I want to make some tweaks to the script, so I will leave this open

----------

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

From report at bugs.python.org  Fri Dec  4 17:12:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Dec 2020 22:12:15 +0000
Subject: [issue39573] [C API] Make PyObject an opaque structure in the limited
 C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1607119935.58.0.844344863574.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> immutables: https://github.com/MagicStack/immutables/issues/46

I proposed a fix: https://github.com/MagicStack/immutables/pull/52

> mercurial https://bugzilla.redhat.com/show_bug.cgi?id=1897178

I proposed a fix: https://bz.mercurial-scm.org/show_bug.cgi?id=6451

----------

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

From report at bugs.python.org  Fri Dec  4 17:19:54 2020
From: report at bugs.python.org (Irit Katriel)
Date: Fri, 04 Dec 2020 22:19:54 +0000
Subject: [issue42482] TracebackException should not hold reference to the
 exception traceback
In-Reply-To: <1606471868.96.0.673168968518.issue42482@roundup.psfhosted.org>
Message-ID: <1607120394.94.0.821836092465.issue42482@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


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

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

From report at bugs.python.org  Fri Dec  4 17:35:14 2020
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 04 Dec 2020 22:35:14 +0000
Subject: [issue42569] Callers of _Py_fopen/_Py_wfopen may be broken after
 addition of audit hooks
In-Reply-To: <1607098353.32.0.624763724813.issue42569@roundup.psfhosted.org>
Message-ID: <1607121314.41.0.595806743841.issue42569@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> To implement PEP 446: create non-inheritable file descriptors.

Side note. That aspect is still wonky in Windows, for which set_inheritable() cannot be implemented reliably since there's no way to change whether an existing CRT file descriptor is inheritable. The current implementation just puts the combination of CRT fd and OS handle in a bad state (discussed in more detail in bpo-32865, an issue about fixing os.pipe, but related). In Windows, the fopen() and _wfopen() calls here should use the non-standard "N" flag [1] to open a non-inheritable file descriptor and skip calling set_inheritable().

---

[1] https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/fopen-wfopen?view=msvc-160

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

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

From report at bugs.python.org  Fri Dec  4 17:42:06 2020
From: report at bugs.python.org (Tal Einat)
Date: Fri, 04 Dec 2020 22:42:06 +0000
Subject: [issue17735] inspect.findsource raises IndexError
In-Reply-To: <1366030340.02.0.51431850328.issue17735@psf.upfronthosting.co.za>
Message-ID: <1607121726.64.0.103675636.issue17735@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:


New changeset d1f07419c7560ed3ba52ba4f667f4eec9b5fe95d by Miss Islington (bot) in branch '3.9':
bpo-17735: inspect.findsource now raises OSError when co_lineno is out of range (GH-23633)
https://github.com/python/cpython/commit/d1f07419c7560ed3ba52ba4f667f4eec9b5fe95d


----------

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

From report at bugs.python.org  Fri Dec  4 17:42:15 2020
From: report at bugs.python.org (Austin Scola)
Date: Fri, 04 Dec 2020 22:42:15 +0000
Subject: [issue42572] Better path handling with argparse
Message-ID: <1607121735.85.0.926277593776.issue42572@roundup.psfhosted.org>


New submission from Austin Scola <austinscola at gmail.com>:

One of the types of arguments that I find myself most often passing to `argparse.ArgumentParser` is paths. I think that I am probably not alone in frequent usage of paths as arguments. Given this, it would be extremely helpful to have an `argparse.Action` in `argparse` or an type similar to `FileType` that converted the string to a path. A path type factory could also have an arguments to optionally check if the path exists, or is a directory, or other similar predicates.

----------
components: Library (Lib)
messages: 382542
nosy: ascola
priority: normal
severity: normal
status: open
title: Better path handling with argparse
type: enhancement

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

From report at bugs.python.org  Fri Dec  4 17:43:17 2020
From: report at bugs.python.org (Tal Einat)
Date: Fri, 04 Dec 2020 22:43:17 +0000
Subject: [issue17735] inspect.findsource raises IndexError
In-Reply-To: <1366030340.02.0.51431850328.issue17735@psf.upfronthosting.co.za>
Message-ID: <1607121797.35.0.495267144954.issue17735@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:

Thanks for reporting this, Kyle!

Thanks for the PR, Irit!

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

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

From report at bugs.python.org  Fri Dec  4 17:53:54 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 04 Dec 2020 22:53:54 +0000
Subject: [issue42545] Check that all symbols in the limited ABI are exported
In-Reply-To: <1606942339.51.0.833109264536.issue42545@roundup.psfhosted.org>
Message-ID: <1607122434.33.0.102440473925.issue42545@roundup.psfhosted.org>


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


----------
pull_requests: +22516
pull_request: https://github.com/python/cpython/pull/23648

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

From report at bugs.python.org  Fri Dec  4 17:58:40 2020
From: report at bugs.python.org (Irit Katriel)
Date: Fri, 04 Dec 2020 22:58:40 +0000
Subject: [issue37166] inspect.findsource doesn't handle shortened files
 gracefully
In-Reply-To: <1559763986.42.0.903204336475.issue37166@roundup.psfhosted.org>
Message-ID: <1607122720.82.0.205915588505.issue37166@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

Fixed under issue17735.

----------
nosy: +iritkatriel
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Dec  4 18:19:39 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 04 Dec 2020 23:19:39 +0000
Subject: [issue42545] Check that all symbols in the limited ABI are exported
In-Reply-To: <1606942339.51.0.833109264536.issue42545@roundup.psfhosted.org>
Message-ID: <1607123979.0.0.461944684263.issue42545@roundup.psfhosted.org>


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


New changeset 79c1849b9e5b635bd36b13e1be9dc7cbc2bd6312 by Pablo Galindo in branch 'master':
bpo-42545: Improve the error message in the stable API script (GH-23648)
https://github.com/python/cpython/commit/79c1849b9e5b635bd36b13e1be9dc7cbc2bd6312


----------

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

From report at bugs.python.org  Fri Dec  4 18:27:51 2020
From: report at bugs.python.org (Irit Katriel)
Date: Fri, 04 Dec 2020 23:27:51 +0000
Subject: [issue20415] Could method "isinstance" take a list as parameter?
In-Reply-To: <1390901274.15.0.0556662587348.issue20415@psf.upfronthosting.co.za>
Message-ID: <1607124471.32.0.266947877225.issue20415@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

Interesting discussion, and the reason seems to be here:
https://mail.python.org/pipermail/python-ideas/2011-July/010642.html

Lists need to be checked for cycles, tuples don't.

----------
nosy: +iritkatriel
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Dec  4 18:37:31 2020
From: report at bugs.python.org (Irit Katriel)
Date: Fri, 04 Dec 2020 23:37:31 +0000
Subject: [issue30858] Keyword can't be an expression?
In-Reply-To: <1499275280.43.0.372385518137.issue30858@psf.upfronthosting.co.za>
Message-ID: <1607125051.76.0.990215468246.issue30858@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

I get this now on 3.10:


>>> print(end1 + end2 + end3 + end4 + end5 + end6 + end=' ')
  File "<stdin>", line 1
    print(end1 + end2 + end3 + end4 + end5 + end6 + end=' ')
          ^
SyntaxError: expression cannot contain assignment, perhaps you meant "=="?

----------
nosy: +iritkatriel

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

From report at bugs.python.org  Fri Dec  4 18:39:35 2020
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 04 Dec 2020 23:39:35 +0000
Subject: [issue26131] Raise ImportWarning when loader.load_module() is used
In-Reply-To: <1452894244.92.0.478987355259.issue26131@psf.upfronthosting.co.za>
Message-ID: <1607125175.07.0.700520018274.issue26131@roundup.psfhosted.org>


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


New changeset 2de5097ba4c50eba90df55696a7b2e74c93834d4 by Brett Cannon in branch 'master':
bpo-26131: Deprecate usage of load_module() (GH-23469)
https://github.com/python/cpython/commit/2de5097ba4c50eba90df55696a7b2e74c93834d4


----------

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

From report at bugs.python.org  Fri Dec  4 18:40:13 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Dec 2020 23:40:13 +0000
Subject: [issue32865] os.pipe creates inheritable FDs with a bad internal
 state on Windows
In-Reply-To: <1518882714.97.0.467229070634.issue32865@psf.upfronthosting.co.za>
Message-ID: <1607125213.14.0.284064750041.issue32865@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


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

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

From report at bugs.python.org  Fri Dec  4 18:48:09 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 04 Dec 2020 23:48:09 +0000
Subject: [issue42569] Callers of _Py_fopen/_Py_wfopen may be broken after
 addition of audit hooks
In-Reply-To: <1607098353.32.0.624763724813.issue42569@roundup.psfhosted.org>
Message-ID: <1607125689.63.0.920801910909.issue42569@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> In Windows, the fopen() and _wfopen() calls here should use the non-standard "N" flag [1] to open a non-inheritable file descriptor and skip calling set_inheritable().

Interesting. Do you want to propose a PR to enhance the Python implementation?

----------

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

From report at bugs.python.org  Fri Dec  4 19:33:08 2020
From: report at bugs.python.org (Mark Shannon)
Date: Sat, 05 Dec 2020 00:33:08 +0000
Subject: [issue42373] PEP 626 does not specify behavior of tracing for
 keywords.
In-Reply-To: <1605540658.6.0.769594046154.issue42373@roundup.psfhosted.org>
Message-ID: <1607128388.93.0.996538349939.issue42373@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


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

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

From report at bugs.python.org  Fri Dec  4 20:28:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 05 Dec 2020 01:28:33 +0000
Subject: [issue30459] PyList_SET_ITEM  could be safer
In-Reply-To: <1495638852.56.0.0790136948712.issue30459@psf.upfronthosting.co.za>
Message-ID: <1607131713.14.0.578731712611.issue30459@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I propose to merge my PR 23645 change right now. If it breaks too many C extensions, we still have time before Python 3.10.0 final scheduled at Monday, 2021-10-04, to revert the change.


"if (obj == NULL || PyList_SET_ITEM (l, i, obj) < 0)"

Well, this is obviously a bug in py-qt4 and it's a good thing to get a compiler error on such code. I guess that the intent was to use PyList_SetItem().

It's also an issue for Python implementation other than CPython which does not behave exactly like CPython C API. I prefer to fix the C API to make it respect its own documentation (return "void").


Espie Marc: "Well, there is not going to be a lot of breakage. This problem is the only instance I've encountered in the full OpenBSD ports tree."

Oh, thanks for providing this very useful feedback! That's very promising.

Did you report the issue to py-qt4 upstream? If yes, can you please copy here the link to your report?

----------

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

From report at bugs.python.org  Fri Dec  4 20:34:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 05 Dec 2020 01:34:51 +0000
Subject: [issue39947] [C API] Make the PyThreadState structure opaque (move it
 to the internal C API)
In-Reply-To: <1584035214.47.0.672795796186.issue39947@roundup.psfhosted.org>
Message-ID: <1607132091.52.0.848821541195.issue39947@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> bpo-35949 lists Py_ALLOW_RECURSION and Py_END_ALLOW_RECURSION which access PyThreadState.recursion_critical member directly.

Oh, problem solved by:

commit dcc54215ac1eb4b6fab2a9ffe1abcdf3ac4bb77e
Author: Serhiy Storchaka <storchaka at gmail.com>
Date:   Mon Oct 5 12:32:00 2020 +0300

    bpo-41936. Remove macros Py_ALLOW_RECURSION/Py_END_ALLOW_RECURSION (GH-22552)

----------

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

From report at bugs.python.org  Fri Dec  4 21:49:21 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 05 Dec 2020 02:49:21 +0000
Subject: [issue42572] Better path handling with argparse
In-Reply-To: <1607121735.85.0.926277593776.issue42572@roundup.psfhosted.org>
Message-ID: <1607136561.37.0.880159847717.issue42572@roundup.psfhosted.org>


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


----------
nosy: +paul.j3, rhettinger

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

From report at bugs.python.org  Fri Dec  4 22:37:33 2020
From: report at bugs.python.org (Ned Deily)
Date: Sat, 05 Dec 2020 03:37:33 +0000
Subject: [issue41116] build on macOS 11 (beta) does not find system-supplied
 third-party libraries
In-Reply-To: <1593100264.48.0.613850075185.issue41116@roundup.psfhosted.org>
Message-ID: <1607139453.41.0.415831937947.issue41116@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
pull_requests: +22517
pull_request: https://github.com/python/cpython/pull/23649

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

From report at bugs.python.org  Fri Dec  4 22:46:00 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Sat, 05 Dec 2020 03:46:00 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1607139960.78.0.871889237785.issue42536@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:


New changeset 226a012d1cd61f42ecd3056c554922f359a1a35d by Brandt Bucher in branch 'master':
bpo-42536: GC track recycled tuples (GH-23623)
https://github.com/python/cpython/commit/226a012d1cd61f42ecd3056c554922f359a1a35d


----------

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

From report at bugs.python.org  Fri Dec  4 23:02:19 2020
From: report at bugs.python.org (Ned Deily)
Date: Sat, 05 Dec 2020 04:02:19 +0000
Subject: [issue41116] build on macOS 11 (beta) does not find system-supplied
 third-party libraries
In-Reply-To: <1593100264.48.0.613850075185.issue41116@roundup.psfhosted.org>
Message-ID: <1607140939.21.0.837286107255.issue41116@roundup.psfhosted.org>


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


New changeset 29afab6c5f656f07ac85c9b2cf089631b2557a11 by Ned Deily in branch 'master':
bpo-41116: Fix setup.py test for macOS Tcl/Tk frameworks (GH-23649)
https://github.com/python/cpython/commit/29afab6c5f656f07ac85c9b2cf089631b2557a11


----------

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

From report at bugs.python.org  Fri Dec  4 23:02:26 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 05 Dec 2020 04:02:26 +0000
Subject: [issue41116] build on macOS 11 (beta) does not find system-supplied
 third-party libraries
In-Reply-To: <1593100264.48.0.613850075185.issue41116@roundup.psfhosted.org>
Message-ID: <1607140946.97.0.879766577077.issue41116@roundup.psfhosted.org>


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


----------
pull_requests: +22518
pull_request: https://github.com/python/cpython/pull/23650

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

From report at bugs.python.org  Fri Dec  4 23:27:20 2020
From: report at bugs.python.org (Ned Deily)
Date: Sat, 05 Dec 2020 04:27:20 +0000
Subject: [issue41116] build on macOS 11 (beta) does not find system-supplied
 third-party libraries
In-Reply-To: <1593100264.48.0.613850075185.issue41116@roundup.psfhosted.org>
Message-ID: <1607142440.9.0.347063654489.issue41116@roundup.psfhosted.org>


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


New changeset 06002b3f0d4570424feef37103c7e9b7d16bd63d by Miss Islington (bot) in branch '3.9':
[3.9] bpo-41116: Fix setup.py test for macOS Tcl/Tk frameworks (GH-23649) (GH-23650)
https://github.com/python/cpython/commit/06002b3f0d4570424feef37103c7e9b7d16bd63d


----------

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

From report at bugs.python.org  Fri Dec  4 23:30:19 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 05 Dec 2020 04:30:19 +0000
Subject: [issue13966] Add disable_interspersed_args() to
 argparse.ArgumentParser
In-Reply-To: <1328687368.18.0.265955669963.issue13966@psf.upfronthosting.co.za>
Message-ID: <1607142619.72.0.526005147431.issue13966@roundup.psfhosted.org>


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


----------
assignee: rhettinger -> 
versions: +Python 3.10 -Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri Dec  4 23:51:57 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 05 Dec 2020 04:51:57 +0000
Subject: [issue9334] argparse does not accept options taking arguments
 beginning with dash (regression from optparse)
In-Reply-To: <1279836939.11.0.811316280273.issue9334@psf.upfronthosting.co.za>
Message-ID: <1607143917.37.0.984547411223.issue9334@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/issue9334>
_______________________________________

From report at bugs.python.org  Fri Dec  4 23:55:18 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Sat, 05 Dec 2020 04:55:18 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1607144118.13.0.62126761436.issue42536@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
pull_requests: +22519
pull_request: https://github.com/python/cpython/pull/23651

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

From report at bugs.python.org  Fri Dec  4 23:57:03 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Sat, 05 Dec 2020 04:57:03 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1607144223.58.0.82741568393.issue42536@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
pull_requests: +22520
pull_request: https://github.com/python/cpython/pull/23652

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

From report at bugs.python.org  Sat Dec  5 00:15:24 2020
From: report at bugs.python.org (tosunilmathew@yahoo.com)
Date: Sat, 05 Dec 2020 05:15:24 +0000
Subject: [issue42573] Installation of Python 3.9 failing with message "User
 cancelled installation"
Message-ID: <1607145324.41.0.931574881737.issue42573@roundup.psfhosted.org>


Change by tosunilmathew at yahoo.com <tosunilmathew at yahoo.com>:


----------
components: Installation
nosy: tosunilmathew
priority: normal
severity: normal
status: open
title: Installation of Python 3.9 failing with message "User cancelled installation"
type: crash
versions: Python 3.9

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

From report at bugs.python.org  Sat Dec  5 00:22:23 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 05 Dec 2020 05:22:23 +0000
Subject: [issue38843] Document argparse behaviour when custom namespace object
 already has the field set
In-Reply-To: <1574130223.67.0.390215742489.issue38843@roundup.psfhosted.org>
Message-ID: <1607145743.41.0.404527888772.issue38843@roundup.psfhosted.org>


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


----------
keywords: +patch
pull_requests: +22521
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23653

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

From report at bugs.python.org  Sat Dec  5 01:30:39 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Sat, 05 Dec 2020 06:30:39 +0000
Subject: [issue42574] Travis can't build the 3.8 branch right now
Message-ID: <1607149839.2.0.378125476647.issue42574@roundup.psfhosted.org>


New submission from Brandt Bucher <brandtbucher at gmail.com>:

Travis seems to be using the wrong Python executable for (at least) the "make -j4 regen-all" step on the 3.8 branch. I have a hunch it's using the system python3 executable (3.5?). It causes the following failure when building:

...
python3 ./Tools/scripts/update_file.py ./Include/graminit.h ./Include/graminit.h.new
  File "./Tools/clinic/clinic.py", line 1772
    filename_new = f"{filename}.new"
                                   ^
SyntaxError: invalid syntax
Makefile:574: recipe for target 'clinic' failed
make: *** [clinic] Error 1

Recent examples:

https://travis-ci.com/github/python/cpython/jobs/454447280
https://travis-ci.com/github/python/cpython/jobs/454551266
https://travis-ci.com/github/python/cpython/jobs/454650029
https://travis-ci.com/github/python/cpython/jobs/454907763

I know Travis has been fairly problematic for us in the past.

----------
components: Build
messages: 382555
nosy: brandtbucher
priority: normal
severity: normal
status: open
title: Travis can't build the 3.8 branch right now
versions: Python 3.8

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

From report at bugs.python.org  Sat Dec  5 01:31:18 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 05 Dec 2020 06:31:18 +0000
Subject: [issue17005] Add a topological sort algorithm
In-Reply-To: <1358717952.33.0.209682941713.issue17005@psf.upfronthosting.co.za>
Message-ID: <1607149878.14.0.363901224751.issue17005@roundup.psfhosted.org>


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


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

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

From report at bugs.python.org  Sat Dec  5 01:32:11 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Sat, 05 Dec 2020 06:32:11 +0000
Subject: [issue42574] Travis can't build the 3.8 branch right now
In-Reply-To: <1607149839.2.0.378125476647.issue42574@roundup.psfhosted.org>
Message-ID: <1607149931.77.0.413596719191.issue42574@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
keywords: +patch
pull_requests: +22522
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23652

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

From report at bugs.python.org  Sat Dec  5 01:32:56 2020
From: report at bugs.python.org (Kshitish)
Date: Sat, 05 Dec 2020 06:32:56 +0000
Subject: [issue42570] Try and Except doesn't work properly
In-Reply-To: <1607104420.61.0.0601519357686.issue42570@roundup.psfhosted.org>
Message-ID: <1607149976.96.0.0976222221104.issue42570@roundup.psfhosted.org>


Kshitish <nishantgautam930 at gmail.com> added the comment:

for i in range(1,11):
    try:
        if i == i:
            print(i)
            if i == 5:
                continue
                print(i,'poc')
    except:
        print("Out")

Output:

1
2
3
4
5
6
7
8
9
10


As you can see the continue keyword is not working. The out put should be like that:

1
2
3
4
6
7
9
10

But it is not and this is the bug because every keyword must work as their task. if they they not then may be the code will be affected by this vulnerability. 

Thank you

----------
status: closed -> open
Added file: https://bugs.python.org/file49657/main.py

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

From report at bugs.python.org  Sat Dec  5 01:35:39 2020
From: report at bugs.python.org (Sam Yan)
Date: Sat, 05 Dec 2020 06:35:39 +0000
Subject: [issue42575] Suggest to add an LinkedList data structure to python
Message-ID: <1607150139.15.0.868707735034.issue42575@roundup.psfhosted.org>


New submission from Sam Yan <jiangyuey at student.unimelb.edu.au>:

There has been no LinkedList data structure for Python. Therefore suggest adding a LinkedList data structure.

----------
components: C API
files: LinkedList.py
messages: 382557
nosy: SamUnimelb
priority: normal
severity: normal
status: open
title: Suggest to add an LinkedList data structure to python
type: enhancement
versions: Python 3.10
Added file: https://bugs.python.org/file49658/LinkedList.py

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

From report at bugs.python.org  Sat Dec  5 01:50:52 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 05 Dec 2020 06:50:52 +0000
Subject: [issue42570] Try and Except doesn't work properly
In-Reply-To: <1607104420.61.0.0601519357686.issue42570@roundup.psfhosted.org>
Message-ID: <1607151052.85.0.0780023172253.issue42570@roundup.psfhosted.org>


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

Kshitish, it was inappropriate to reopen this issue.  This forum is for tracking actual bugs in Python as opposed to bugs in a user's understanding of Python.  My suggestion is that you post on StackOverflow so that the helpers there can explain what is going on with the posted example.

----------
nosy: +rhettinger
resolution: works for me -> not a bug
status: open -> closed

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

From report at bugs.python.org  Sat Dec  5 02:19:06 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 05 Dec 2020 07:19:06 +0000
Subject: [issue18943] argparse: default args in mutually exclusive groups
In-Reply-To: <1378458002.17.0.371205806782.issue18943@psf.upfronthosting.co.za>
Message-ID: <1607152746.92.0.154456983257.issue18943@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/issue18943>
_______________________________________

From report at bugs.python.org  Sat Dec  5 03:11:36 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 05 Dec 2020 08:11:36 +0000
Subject: [issue42575] Suggest to add an LinkedList data structure to python
In-Reply-To: <1607150139.15.0.868707735034.issue42575@roundup.psfhosted.org>
Message-ID: <1607155896.23.0.625483313145.issue42575@roundup.psfhosted.org>


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

The class you have provided is awkward to use, random access is inefficient, it is not compatible with lists or offer a sequence API, it's not subscriptable or iterable, the API exposes an unnecessary "Proxy" class, and the API is more like what I would expect from Java code than Python code.

But even if every one of those problems was fixed, there is still the question, why would somebody choose this LinkedList instead of the fast, efficient built-in list? What advantages does this have?

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

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

From report at bugs.python.org  Sat Dec  5 04:20:31 2020
From: report at bugs.python.org (Espie Marc)
Date: Sat, 05 Dec 2020 09:20:31 +0000
Subject: [issue30459] PyList_SET_ITEM  could be safer
In-Reply-To: <1607131713.14.0.578731712611.issue30459@roundup.psfhosted.org>
Message-ID: <X8tQ3BAsJowPd0xt@nausicaa.home>


Espie Marc <espie at nerim.net> added the comment:

On Sat, Dec 05, 2020 at 01:28:33AM +0000, STINNER Victor wrote:
> 
> STINNER Victor <vstinner at python.org> added the comment:
> 
> I propose to merge my PR 23645 change right now. If it breaks too many C extensions, we still have time before Python 3.10.0 final scheduled at Monday, 2021-10-04, to revert the change.
> 
> 
> "if (obj == NULL || PyList_SET_ITEM (l, i, obj) < 0)"
> 
> Well, this is obviously a bug in py-qt4 and it's a good thing to get a compiler error on such code. I guess that the intent was to use PyList_SetItem().
> 
> It's also an issue for Python implementation other than CPython which does not behave exactly like CPython C API. I prefer to fix the C API to make it respect its own documentation (return "void").
> 
> 
> Espie Marc: "Well, there is not going to be a lot of breakage. This problem is the only instance I've encountered in the full OpenBSD ports tree."
> 
> Oh, thanks for providing this very useful feedback! That's very promising.
> 
> Did you report the issue to py-qt4 upstream? If yes, can you please copy here the link to your report?

I'm sorry, it's been so long ago, I can't remember.

I've been dealing with 10s of other bugs since.

----------

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

From report at bugs.python.org  Sat Dec  5 04:38:39 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 05 Dec 2020 09:38:39 +0000
Subject: [issue30459] PyList_SET_ITEM  could be safer
In-Reply-To: <1495638852.56.0.0790136948712.issue30459@psf.upfronthosting.co.za>
Message-ID: <1607161119.46.0.309397147069.issue30459@roundup.psfhosted.org>


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

I prefer PR 19975 to PR 23645. It solves the initial issue and is much simpler.

----------

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

From report at bugs.python.org  Sat Dec  5 05:35:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 05 Dec 2020 10:35:20 +0000
Subject: [issue30459] PyList_SET_ITEM  could be safer
In-Reply-To: <1495638852.56.0.0790136948712.issue30459@psf.upfronthosting.co.za>
Message-ID: <1607164520.69.0.764602745767.issue30459@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 556d97f473fa538cef780f84bd29239ecf57d9c5 by Zackery Spytz in branch 'master':
bpo-30459: Cast the result of PyList_SET_ITEM() to void (GH-19975)
https://github.com/python/cpython/commit/556d97f473fa538cef780f84bd29239ecf57d9c5


----------

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

From report at bugs.python.org  Sat Dec  5 05:41:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 05 Dec 2020 10:41:46 +0000
Subject: [issue30459] PyList_SET_ITEM  could be safer
In-Reply-To: <1495638852.56.0.0790136948712.issue30459@psf.upfronthosting.co.za>
Message-ID: <1607164906.39.0.764405263665.issue30459@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22523
pull_request: https://github.com/python/cpython/pull/23654

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

From report at bugs.python.org  Sat Dec  5 06:22:28 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 05 Dec 2020 11:22:28 +0000
Subject: [issue42573] Installation of Python 3.9 failing with message "User
 cancelled installation"
Message-ID: <1607167348.75.0.906880980974.issue42573@roundup.psfhosted.org>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

Which OS and version are you trying to install on?

----------
nosy: +ronaldoussoren

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

From report at bugs.python.org  Sat Dec  5 07:04:57 2020
From: report at bugs.python.org (tosunilmathew@yahoo.com)
Date: Sat, 05 Dec 2020 12:04:57 +0000
Subject: [issue42573] Installation of Python 3.9 failing with message "User
 cancelled installation"
In-Reply-To: <1607167348.75.0.906880980974.issue42573@roundup.psfhosted.org>
Message-ID: <1607169897.47.0.875013697347.issue42573@roundup.psfhosted.org>


tosunilmathew at yahoo.com <tosunilmathew at yahoo.com> added the comment:

Windows 10, Python 3.9

----------

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

From report at bugs.python.org  Sat Dec  5 07:43:31 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 05 Dec 2020 12:43:31 +0000
Subject: [issue42573] Installation of Python 3.9 failing with message "User
 cancelled installation"
In-Reply-To: <1607167348.75.0.906880980974.issue42573@roundup.psfhosted.org>
Message-ID: <1607172211.95.0.45304358557.issue42573@roundup.psfhosted.org>


Change by Ronald Oussoren <ronaldoussoren at mac.com>:


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

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

From report at bugs.python.org  Sat Dec  5 09:31:19 2020
From: report at bugs.python.org (Ken Jin)
Date: Sat, 05 Dec 2020 14:31:19 +0000
Subject: [issue42576] Passing keyword arguments to types.GenericAlias causes a
 hard crash
Message-ID: <1607178679.27.0.947659385701.issue42576@roundup.psfhosted.org>


New submission from Ken Jin <kenjin4096 at gmail.com>:

I noticed that passing keyword arguments to types.GenericAlias's __new__ causes the interpreter to hard crash and exit due to an assertion failure:

import types
types.GenericAlias(bad=float)


Result:
Assertion failed: PyTuple_CheckExact(kwnames), file ....\cpython\Python\getargs.c, line 2767

A simple fix is to just use _PyArg_NoKeywords instead of _PyArg_NoKwnames. 

Looking through the rest of the C code, it seems that apart from GenericAlias, only vectorcalls for various builtins use _PyArg_NoKwnames. However, they don't seem to be affected by the bug.

----------
components: Interpreter Core
messages: 382565
nosy: gvanrossum, kj
priority: normal
severity: normal
status: open
title: Passing keyword arguments to types.GenericAlias causes a hard crash
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Sat Dec  5 09:38:42 2020
From: report at bugs.python.org (Ken Jin)
Date: Sat, 05 Dec 2020 14:38:42 +0000
Subject: [issue42576] Passing keyword arguments to types.GenericAlias causes a
 hard crash
In-Reply-To: <1607178679.27.0.947659385701.issue42576@roundup.psfhosted.org>
Message-ID: <1607179122.36.0.62083235214.issue42576@roundup.psfhosted.org>


Change by Ken Jin <kenjin4096 at gmail.com>:


----------
keywords: +patch
pull_requests: +22524
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23656

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

From report at bugs.python.org  Sat Dec  5 09:57:01 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 05 Dec 2020 14:57:01 +0000
Subject: [issue5054] CGIHTTPRequestHandler.run_cgi() HTTP_ACCEPT improperly
 parsed
In-Reply-To: <1232897403.01.0.0399148938595.issue5054@psf.upfronthosting.co.za>
Message-ID: <1607180221.91.0.737939538289.issue5054@roundup.psfhosted.org>


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


----------
nosy: +miss-islington
nosy_count: 7.0 -> 8.0
pull_requests: +22525
pull_request: https://github.com/python/cpython/pull/23657

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

From report at bugs.python.org  Sat Dec  5 10:10:38 2020
From: report at bugs.python.org (Christoph Reiter)
Date: Sat, 05 Dec 2020 15:10:38 +0000
Subject: [issue42577] Unhelpful syntax error when expression spans multiple
 lines
Message-ID: <1607181038.72.0.910363231446.issue42577@roundup.psfhosted.org>


New submission from Christoph Reiter <reiter.christoph at gmail.com>:

I don't know if the bug tracker is the right place for this, please point me to the right place if not.

Someone faced to the following code (simplified example here) and asked for help:

```
if 3:
    if 1:
        print(((123))

if 2:
    print(123)
```

This results in the following error:

```
File "error.py", line 5
  if 2:
      ^
SyntaxError: invalid syntax
```

which is very confusing to users not familiar with generator expressions.

I'm wondering if python could improve syntax errors in this case by adding more context, like point to where it started parsing the current thing and where it gave up instead to just the later.

----------
messages: 382566
nosy: lazka
priority: normal
severity: normal
status: open
title: Unhelpful syntax error when expression spans multiple lines
versions: Python 3.9

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

From report at bugs.python.org  Sat Dec  5 10:22:35 2020
From: report at bugs.python.org (wyz23x2)
Date: Sat, 05 Dec 2020 15:22:35 +0000
Subject: [issue42578] Add tip when encountering UnicodeDecode/Encode Error in
 open()
Message-ID: <1607181755.9.0.464136103954.issue42578@roundup.psfhosted.org>


New submission from wyz23x2 <wyz23x2 at 163.com>:

Programmers often stumble over UnicodeDecode/EncodeError during open(), and especially beginners don't know what to do.
There are lots of questions on Stackoverflow:
https://stackoverflow.com/questions/16528468/while-reading-file-on-python-i-got-a-unicodedecodeerror-what-can-i-do-to-resol
https://stackoverflow.com/questions/38186847/python-line-replace-returns-unicodeencodeerror
https://stackoverflow.com/questions/3224268/python-unicode-encode-error
https://stackoverflow.com/questions/50331257/python3-unicodeencodingerror
https://stackoverflow.com/questions/24717808/python-cant-write-to-file-unicodeencodeerror
......
Maybe a helpful tip can be added to the error message.
We have done this before:
>>> (1,)(2, 3)                                                                                                                <stdin>:1: SyntaxWarning: 'tuple' object is not callable; perhaps you missed a comma?
>>> print 3                                                                                                                     
  File "<stdin>", line 1                                                                                                          
    print 3                                                                                                                             
          ^                                                                                                                   SyntaxError: Missing parentheses in call to 'print'. Did you mean print(3)?

----------
components: IO
messages: 382567
nosy: wyz23x2
priority: normal
severity: normal
status: open
title: Add tip when encountering UnicodeDecode/Encode Error in open()
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Sat Dec  5 10:23:29 2020
From: report at bugs.python.org (wyz23x2)
Date: Sat, 05 Dec 2020 15:23:29 +0000
Subject: [issue42578] Add tip when encountering UnicodeDecode/Encode Error in
 open()
In-Reply-To: <1607181755.9.0.464136103954.issue42578@roundup.psfhosted.org>
Message-ID: <1607181809.65.0.0637859656731.issue42578@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

>>> (1,)(2, 3)
<stdin>:1: SyntaxWarning: 'tuple' object is not callable; perhaps you missed a comma?

----------

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

From report at bugs.python.org  Sat Dec  5 10:24:43 2020
From: report at bugs.python.org (wyz23x2)
Date: Sat, 05 Dec 2020 15:24:43 +0000
Subject: [issue42578] Add tip when encountering UnicodeDecode/EncodeError in
 open()
In-Reply-To: <1607181755.9.0.464136103954.issue42578@roundup.psfhosted.org>
Message-ID: <1607181883.38.0.291669106374.issue42578@roundup.psfhosted.org>


Change by wyz23x2 <wyz23x2 at 163.com>:


----------
title: Add tip when encountering UnicodeDecode/Encode Error in open() -> Add tip when encountering UnicodeDecode/EncodeError in open()

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

From report at bugs.python.org  Sat Dec  5 10:26:44 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 05 Dec 2020 15:26:44 +0000
Subject: [issue5054] CGIHTTPRequestHandler.run_cgi() HTTP_ACCEPT improperly
 parsed
In-Reply-To: <1232897403.01.0.0399148938595.issue5054@psf.upfronthosting.co.za>
Message-ID: <1607182004.81.0.929455420312.issue5054@roundup.psfhosted.org>


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


New changeset b630ca7bc13ba9bdf95cd7dce0ac8e1578fb53a0 by Miss Islington (bot) in branch '3.9':
[3.9] bpo-5054: CGIHTTPRequestHandler.run_cgi() HTTP_ACCEPT improperly parsed (GH-23638) (GH-23657)
https://github.com/python/cpython/commit/b630ca7bc13ba9bdf95cd7dce0ac8e1578fb53a0


----------

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

From report at bugs.python.org  Sat Dec  5 10:59:51 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 05 Dec 2020 15:59:51 +0000
Subject: [issue5054] CGIHTTPRequestHandler.run_cgi() HTTP_ACCEPT improperly
 parsed
In-Reply-To: <1232897403.01.0.0399148938595.issue5054@psf.upfronthosting.co.za>
Message-ID: <1607183991.28.0.655681625192.issue5054@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


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

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

From report at bugs.python.org  Sat Dec  5 11:00:36 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 05 Dec 2020 16:00:36 +0000
Subject: [issue5054] CGIHTTPRequestHandler.run_cgi() HTTP_ACCEPT improperly
 parsed
In-Reply-To: <1232897403.01.0.0399148938595.issue5054@psf.upfronthosting.co.za>
Message-ID: <1607184036.0.0.486898070833.issue5054@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:

This was also resolved in 3.10 https://github.com/python/cpython/pull/23638

----------

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

From report at bugs.python.org  Sat Dec  5 11:00:51 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 05 Dec 2020 16:00:51 +0000
Subject: [issue42576] Passing keyword arguments to types.GenericAlias causes a
 hard crash
In-Reply-To: <1607178679.27.0.947659385701.issue42576@roundup.psfhosted.org>
Message-ID: <1607184051.35.0.135010072265.issue42576@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Oh, this looks like I copied the wrong idiom. Good catch!

----------

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

From report at bugs.python.org  Sat Dec  5 11:01:57 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 05 Dec 2020 16:01:57 +0000
Subject: [issue42578] Add tip when encountering UnicodeDecode/EncodeError in
 open()
In-Reply-To: <1607181755.9.0.464136103954.issue42578@roundup.psfhosted.org>
Message-ID: <1607184117.3.0.228590044719.issue42578@roundup.psfhosted.org>


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

4 of 5 linked questions do not have relation to open(). Half of them are Python 2 specific, and other half is Windows specific and should be fixed in recent Python releases on new Windows.

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

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

From report at bugs.python.org  Sat Dec  5 11:02:23 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 05 Dec 2020 16:02:23 +0000
Subject: [issue42576] Passing keyword arguments to types.GenericAlias causes a
 hard crash
In-Reply-To: <1607178679.27.0.947659385701.issue42576@roundup.psfhosted.org>
Message-ID: <1607184143.6.0.846135084103.issue42576@roundup.psfhosted.org>


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


New changeset 804d6893b801e8f30318afc38c20d4d0e6161db3 by kj in branch 'master':
bpo-42576: Raise TypeError when passing in keyword arguments to GenericAlias (GH-23656)
https://github.com/python/cpython/commit/804d6893b801e8f30318afc38c20d4d0e6161db3


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

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

From report at bugs.python.org  Sat Dec  5 11:02:29 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 05 Dec 2020 16:02:29 +0000
Subject: [issue42576] Passing keyword arguments to types.GenericAlias causes a
 hard crash
In-Reply-To: <1607178679.27.0.947659385701.issue42576@roundup.psfhosted.org>
Message-ID: <1607184149.37.0.745688199341.issue42576@roundup.psfhosted.org>


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


----------
pull_requests: +22526
pull_request: https://github.com/python/cpython/pull/23659

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

From report at bugs.python.org  Sat Dec  5 11:24:41 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 05 Dec 2020 16:24:41 +0000
Subject: [issue42576] Passing keyword arguments to types.GenericAlias causes a
 hard crash
In-Reply-To: <1607178679.27.0.947659385701.issue42576@roundup.psfhosted.org>
Message-ID: <1607185481.69.0.0495702561531.issue42576@roundup.psfhosted.org>


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


New changeset d5c029b1a9b47737efb8966f804d28b99a2de239 by Miss Islington (bot) in branch '3.9':
bpo-42576: Raise TypeError when passing in keyword arguments to GenericAlias (GH-23656)
https://github.com/python/cpython/commit/d5c029b1a9b47737efb8966f804d28b99a2de239


----------

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

From report at bugs.python.org  Sat Dec  5 11:28:26 2020
From: report at bugs.python.org (Ken Jin)
Date: Sat, 05 Dec 2020 16:28:26 +0000
Subject: [issue42576] Passing keyword arguments to types.GenericAlias causes a
 hard crash
In-Reply-To: <1607178679.27.0.947659385701.issue42576@roundup.psfhosted.org>
Message-ID: <1607185706.89.0.173421443756.issue42576@roundup.psfhosted.org>


Change by Ken Jin <kenjin4096 at gmail.com>:


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

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

From report at bugs.python.org  Sat Dec  5 11:46:53 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 05 Dec 2020 16:46:53 +0000
Subject: [issue42578] Add tip when encountering UnicodeDecode/EncodeError in
 open()
In-Reply-To: <1607181755.9.0.464136103954.issue42578@roundup.psfhosted.org>
Message-ID: <1607186813.01.0.720550654575.issue42578@roundup.psfhosted.org>


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

"Maybe a helpful tip can be added to the error message."

What sort of helpful tip do you have in mind?

Remember that the error doesn't occur when the file is opened, but some time later.

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

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

From report at bugs.python.org  Sat Dec  5 11:50:56 2020
From: report at bugs.python.org (Irit Katriel)
Date: Sat, 05 Dec 2020 16:50:56 +0000
Subject: [issue42577] Unhelpful syntax error when expression spans multiple
 lines
In-Reply-To: <1607181038.72.0.910363231446.issue42577@roundup.psfhosted.org>
Message-ID: <1607187056.44.0.312739565644.issue42577@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
resolution:  -> duplicate
superseder:  -> Line number of SyntaxError

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

From report at bugs.python.org  Sat Dec  5 12:49:50 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 05 Dec 2020 17:49:50 +0000
Subject: [issue38780] SysLogHandler crash atexit
In-Reply-To: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>
Message-ID: <1607190590.22.0.792781974462.issue38780@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I'll take a look at the patch and convert it to a PR.

----------
assignee:  -> jaraco

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

From report at bugs.python.org  Sat Dec  5 13:01:26 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 05 Dec 2020 18:01:26 +0000
Subject: [issue38780] SysLogHandler crash atexit
In-Reply-To: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>
Message-ID: <1607191286.91.0.70688144701.issue38780@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I've applied the patches and pushed them to https://github.com/jaraco/cpython/tree/bugfix/bpo-38780.

```
cpython master $ http https://bugs.python.org/file48933/0001-bpo-38780-Harden-socket-use-in-logging.handlers.patch | git apply
cpython master $ git commit -a -m "bpo-38780: Initialize self.socket to None early in __init__() and check for None in close() and e
mit()" --author "Erlend E. Aasland <erlend.aasland at innova.no>" --date '28 Feb 2020 22:38:12 +0100'
[master e05b7d6c52] bpo-38780: Initialize self.socket to None early in __init__() and check for None in close() and emit()
 Author: Erlend E. Aasland <erlend.aasland at innova.no>
 Date: Fri Feb 28 22:38:12 2020 +0100
 1 file changed, 7 insertions(+), 2 deletions(-)
cpython master $ http https://bugs.python.org/file48934/0002-Improve-emit.patch | git apply
cpython master $ git commit -a -m "bpo-38780: Address uncertainty in handling of emit() case." --author "Erlend E. Aasland <erlend.a
asland at innova.no>" --date '28 Feb 2020 23:22:58 +0100'
[master 045b6381b5] bpo-38780: Address uncertainty in handling of emit() case.
 Author: Erlend E. Aasland <erlend.aasland at innova.no>
 Date: Fri Feb 28 23:22:58 2020 +0100
 1 file changed, 7 insertions(+), 5 deletions(-)
cpython master $ git checkout -b bugfix/bpo-38780
Switched to a new branch 'bugfix/bpo-38780'
cpython bugfix/bpo-38780 $ gpj
To https://github.com/jaraco/cpython
 * [new branch]            bugfix/bpo-38780 -> bugfix/bpo-38780
 * [new tag]               v3.10.0a2 -> v3.10.0a2
Branch 'bugfix/bpo-38780' set up to track remote branch 'bugfix/bpo-38780' from 'jaraco'.
```

----------

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

From report at bugs.python.org  Sat Dec  5 13:08:26 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 05 Dec 2020 18:08:26 +0000
Subject: [issue38780] SysLogHandler crash atexit
In-Reply-To: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>
Message-ID: <1607191706.45.0.821859005416.issue38780@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
pull_requests: +22527
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23661

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

From report at bugs.python.org  Sat Dec  5 13:10:06 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 05 Dec 2020 18:10:06 +0000
Subject: [issue38780] SysLogHandler crash atexit
In-Reply-To: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>
Message-ID: <1607191806.84.0.885718333586.issue38780@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


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

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

From report at bugs.python.org  Sat Dec  5 13:18:08 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 05 Dec 2020 18:18:08 +0000
Subject: [issue42576] Passing keyword arguments to types.GenericAlias causes a
 hard crash
In-Reply-To: <1607178679.27.0.947659385701.issue42576@roundup.psfhosted.org>
Message-ID: <1607192288.49.0.925103656461.issue42576@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Thanks for the quick fix!

----------

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

From report at bugs.python.org  Sat Dec  5 13:29:14 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 05 Dec 2020 18:29:14 +0000
Subject: [issue38780] SysLogHandler crash atexit
In-Reply-To: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>
Message-ID: <1607192954.94.0.810562004228.issue38780@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Erlend, inspired by your patches, I created https://github.com/python/cpython/pull/23661/commits/e9723003d49c722d57a69e5016b442d4d752fc6d, which uses a NullSocket instance instead of None, allowing the behavior-suppression to be encapsulated in a single place and swapped out by creation of a proper socket instance.

I do believe this approach addresses the issue. Are you still willing to put together a test case or more?

----------

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

From report at bugs.python.org  Sat Dec  5 13:36:13 2020
From: report at bugs.python.org (Irit Katriel)
Date: Sat, 05 Dec 2020 18:36:13 +0000
Subject: [issue17612] hooks/mail.py requires [smtp] host to be set,
 despite a comment to the contrary
In-Reply-To: <1364853655.88.0.718145768613.issue17612@psf.upfronthosting.co.za>
Message-ID: <1607193373.13.0.234911152323.issue17612@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

This seems out of date (pre github?)  I couldn't find that comment in the current codebase.

----------
nosy: +iritkatriel
status: open -> pending

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

From report at bugs.python.org  Sat Dec  5 14:02:01 2020
From: report at bugs.python.org (Florian Klink)
Date: Sat, 05 Dec 2020 19:02:01 +0000
Subject: [issue42433] mailbox.mbox fails on non ASCII characters
In-Reply-To: <1606039772.66.0.933443286563.issue42433@roundup.psfhosted.org>
Message-ID: <1607194921.31.0.0186767132456.issue42433@roundup.psfhosted.org>


Florian Klink <flokli at flokli.de> added the comment:

Based on https://bugs.python.org/issue42433#msg382169 I added back the versions that bug is present.

The PR is up to and appropriately linked (I think?) - let me know if there's anything left to be done from my side.

----------
versions: +Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Dec  5 14:58:24 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Sat, 05 Dec 2020 19:58:24 +0000
Subject: [issue42575] Suggest to add an LinkedList data structure to python
In-Reply-To: <1607150139.15.0.868707735034.issue42575@roundup.psfhosted.org>
Message-ID: <1607198304.62.0.0476485863925.issue42575@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

I'll add that for 98% of the use cases of a linked list (where you just want fast access at the ends), you can use a `collections.deque` instead, and it will be faster (fewer dereferences) and more memory-efficient (fewer pointers to store).

In the remaining 2% where a linked list is genuinely better (say in CPython's internal garbage collector), you're in a situation where you are already holding a node and you want to delete it or insert around it in constant time. (If you need to do a linear scan before deleting things, list comprehensions will already do what you need). In such situations, the construction is highly specialized for the application, so it's difficult to generalize the construction to an abstract data structure -- in particular, the "data" may need to access the next/previous "data" directly. It's also not inaccessibly hard to re-do every time you need it.

----------
nosy: +Dennis Sweeney

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

From report at bugs.python.org  Sat Dec  5 15:02:36 2020
From: report at bugs.python.org (Irit Katriel)
Date: Sat, 05 Dec 2020 20:02:36 +0000
Subject: [issue17243] The changes made for issue 4074 should be documented
In-Reply-To: <1361305487.48.0.247163585293.issue17243@psf.upfronthosting.co.za>
Message-ID: <1607198556.71.0.631640836794.issue17243@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

I think this has been fixed here in PR21703.

----------
nosy: +iritkatriel
resolution:  -> duplicate
status: open -> pending
superseder:  -> Python Devguide differs from python docs

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

From report at bugs.python.org  Sat Dec  5 15:44:11 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 05 Dec 2020 20:44:11 +0000
Subject: [issue42433] mailbox.mbox fails on non ASCII characters
In-Reply-To: <1606039772.66.0.933443286563.issue42433@roundup.psfhosted.org>
Message-ID: <1607201051.93.0.674746446253.issue42433@roundup.psfhosted.org>


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

3.7 only gets security fixes.  If and when someone merges something, that person will decide whether to backport.

----------
versions:  -Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Dec  5 16:47:14 2020
From: report at bugs.python.org (Matej Cepl)
Date: Sat, 05 Dec 2020 21:47:14 +0000
Subject: [issue42579] Solution from gh#python/cpython#13236 unnecessarily
 binds building of documentation to the latest version of Sphinx
Message-ID: <1607204834.85.0.284068397188.issue42579@roundup.psfhosted.org>


New submission from Matej Cepl <mcepl at cepl.eu>:

I think the solution in gh#python/cpython#13236 is the suboptimal one, because it makes Python dependent on the latest version of Sphinx unnecessarily. There are many situations where Python can be built on the older platform and it is too bothersome to require update of Sphinx (and all its dependencies) as well.

----------
assignee: docs at python
components: Documentation
messages: 382585
nosy: docs at python, mcepl, pablogsal
priority: normal
severity: normal
status: open
title: Solution from gh#python/cpython#13236 unnecessarily binds building of documentation to the latest version of Sphinx
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

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

From report at bugs.python.org  Sat Dec  5 16:58:31 2020
From: report at bugs.python.org (Matej Cepl)
Date: Sat, 05 Dec 2020 21:58:31 +0000
Subject: [issue42579] Solution from gh#python/cpython#13236 unnecessarily
 binds building of documentation to the latest version of Sphinx
In-Reply-To: <1607204834.85.0.284068397188.issue42579@roundup.psfhosted.org>
Message-ID: <1607205511.22.0.968196196586.issue42579@roundup.psfhosted.org>


Change by Matej Cepl <mcepl at cepl.eu>:


----------
keywords: +patch
pull_requests: +22529
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23662

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

From report at bugs.python.org  Sat Dec  5 19:29:31 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 06 Dec 2020 00:29:31 +0000
Subject: [issue17612] hooks/mail.py requires [smtp] host to be set,
 despite a comment to the contrary
In-Reply-To: <1364853655.88.0.718145768613.issue17612@psf.upfronthosting.co.za>
Message-ID: <1607214571.56.0.153860977585.issue17612@roundup.psfhosted.org>


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


----------
resolution:  -> out of date
stage:  -> resolved
status: pending -> closed

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

From report at bugs.python.org  Sat Dec  5 21:10:02 2020
From: report at bugs.python.org (Irit Katriel)
Date: Sun, 06 Dec 2020 02:10:02 +0000
Subject: [issue21627] Concurrently closing files and iterating over the open
 files directory is not well specified
In-Reply-To: <1401643353.39.0.53304722389.issue21627@psf.upfronthosting.co.za>
Message-ID: <1607220602.38.0.182030333047.issue21627@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

I can't find _posixsubmodules.c or _close_open_fd_range_safe in the codebase. Is this issue out of date?

----------
nosy: +iritkatriel
resolution:  -> out of date
status: open -> pending

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

From report at bugs.python.org  Sun Dec  6 02:08:33 2020
From: report at bugs.python.org (mattip)
Date: Sun, 06 Dec 2020 07:08:33 +0000
Subject: [issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)
In-Reply-To: <1481025303.32.0.218031723176.issue28884@psf.upfronthosting.co.za>
Message-ID: <1607238513.56.0.202586475908.issue28884@roundup.psfhosted.org>


mattip <matti.picus at gmail.com> added the comment:

It seems (B6) is still failing (both on PyPy3.7 and on CPython3.8.6)

----------
nosy: +mattip

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

From report at bugs.python.org  Sun Dec  6 02:13:44 2020
From: report at bugs.python.org (mattip)
Date: Sun, 06 Dec 2020 07:13:44 +0000
Subject: [issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)
In-Reply-To: <1481025303.32.0.218031723176.issue28884@psf.upfronthosting.co.za>
Message-ID: <1607238824.42.0.3748069448.issue28884@roundup.psfhosted.org>


mattip <matti.picus at gmail.com> added the comment:

No, my bad, B6 passes now on CPython

----------

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

From report at bugs.python.org  Sun Dec  6 03:15:29 2020
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sun, 06 Dec 2020 08:15:29 +0000
Subject: [issue42569] Callers of _Py_fopen/_Py_wfopen may be broken after
 addition of audit hooks
In-Reply-To: <1607098353.32.0.624763724813.issue42569@roundup.psfhosted.org>
Message-ID: <1607242529.39.0.873450211624.issue42569@roundup.psfhosted.org>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

> So it should be, "if they fail and you're in a context where exceptions are allowed, raise an exception" (which will chain back to the one raised from an audit hook".

What exception should be raised if _Py_fopen() fails (returns NULL)? We can't just check errno anymore because _Py_fopen() might have failed because of the audit hook and thus didn't set errno. So it seems to me that addition of audit hooks broke the implicit contract of _Py_fopen()/_Py_wfopen(), and callers were not fixed.

----------

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

From report at bugs.python.org  Sun Dec  6 04:59:59 2020
From: report at bugs.python.org (Chris Withers)
Date: Sun, 06 Dec 2020 09:59:59 +0000
Subject: [issue42532] spec_arg's __bool__ is called while initializing
 NonCallableMock
In-Reply-To: <1606998026.09.0.31549028921.issue42532@roundup.psfhosted.org>
Message-ID: <1607248799.96.0.582834764594.issue42532@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:


New changeset c598a04dd29b89ad072245ddaf738badcfb41ac7 by idanw206 in branch 'master':
bpo-42532: Check if NonCallableMock's spec_arg is not None instead of call its __bool__ function (GH23613)
https://github.com/python/cpython/commit/c598a04dd29b89ad072245ddaf738badcfb41ac7


----------

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

From report at bugs.python.org  Sun Dec  6 05:48:56 2020
From: report at bugs.python.org (Ken Jin)
Date: Sun, 06 Dec 2020 10:48:56 +0000
Subject: [issue42576] Passing keyword arguments to types.GenericAlias causes a
 hard crash
In-Reply-To: <1607178679.27.0.947659385701.issue42576@roundup.psfhosted.org>
Message-ID: <1607251736.32.0.291367758756.issue42576@roundup.psfhosted.org>


Ken Jin <kenjin4096 at gmail.com> added the comment:

Thanks for taking the time to review this! I forgot to specify this only affects debug builds in the news entry.  I'm opening a PR to edit that because I don't want people to mistake it for an actual interpreter-crashing bug in the release build (that would probably cause some amount of unneeded worry).

----------

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

From report at bugs.python.org  Sun Dec  6 05:50:33 2020
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 06 Dec 2020 10:50:33 +0000
Subject: [issue42580] ctypes.util.find_library("libc") fails
Message-ID: <1607251833.68.0.530621101082.issue42580@roundup.psfhosted.org>


New submission from Matthias Klose <doko at debian.org>:

regression compared to 3.8:

$ python3.9
Python 3.9.1rc1 (default, Nov 27 2020, 19:38:39) 
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> ctypes.util.find_library("libc")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'ctypes' is not defined
>>> import ctypes.util
>>> ctypes.util.find_library("libc")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.9/ctypes/util.py", line 341, in find_library
    _get_soname(_findLib_gcc(name)) or _get_soname(_findLib_ld(name))
  File "/usr/lib/python3.9/ctypes/util.py", line 147, in _findLib_gcc
    if not _is_elf(file):
  File "/usr/lib/python3.9/ctypes/util.py", line 99, in _is_elf
    with open(filename, 'br') as thefile:
FileNotFoundError: [Errno 2] No such file or directory: b'liblibc.a'

also note that the shared library is installed.

----------
components: ctypes
keywords: 3.9regression
messages: 382592
nosy: doko
priority: normal
severity: normal
status: open
title: ctypes.util.find_library("libc") fails
versions: Python 3.9

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

From report at bugs.python.org  Sun Dec  6 05:57:14 2020
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 06 Dec 2020 10:57:14 +0000
Subject: [issue42580] ctypes.util.find_library("libc") fails
In-Reply-To: <1607251833.68.0.530621101082.issue42580@roundup.psfhosted.org>
Message-ID: <1607252234.14.0.279501286116.issue42580@roundup.psfhosted.org>


Matthias Klose <doko at debian.org> added the comment:

ctypes.util.find_library("c") works in both 3.8 and 3.9

----------

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

From report at bugs.python.org  Sun Dec  6 05:57:13 2020
From: report at bugs.python.org (Ken Jin)
Date: Sun, 06 Dec 2020 10:57:13 +0000
Subject: [issue42576] Passing keyword arguments to types.GenericAlias causes a
 hard crash
In-Reply-To: <1607178679.27.0.947659385701.issue42576@roundup.psfhosted.org>
Message-ID: <1607252233.04.0.882437276714.issue42576@roundup.psfhosted.org>


Change by Ken Jin <kenjin4096 at gmail.com>:


----------
pull_requests: +22530
pull_request: https://github.com/python/cpython/pull/23663

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

From report at bugs.python.org  Sun Dec  6 07:01:27 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sun, 06 Dec 2020 12:01:27 +0000
Subject: [issue36541] Make lib2to3 grammar better match Python,
 support the := walrus
In-Reply-To: <1554514880.92.0.277848417721.issue36541@roundup.psfhosted.org>
Message-ID: <1607256087.54.0.570854037478.issue36541@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

I don't see the point of augmenting the ast.parse, since we already have variants of proper CST implementations outside the core python. Such as github.com/davidhalter/parso/ or LibCST. 

Also for basic refactorings, it is so easy to use tokens for the refactoring and AST for the analysis! Even the ast.unparse() can be partially used (like first finding the related segment of the code through AST analysis, building the corresponding variant, unparsing it, finding the region of related tokens in the source code and replacing them). There are also quite a few libraries for using tokenize in different purposes (or wrappers) such as https://github.com/asottile/tokenize-rt or github.com/isidentical/brm.

----------
nosy: +BTaskaya

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

From report at bugs.python.org  Sun Dec  6 09:10:13 2020
From: report at bugs.python.org (Richard)
Date: Sun, 06 Dec 2020 14:10:13 +0000
Subject: [issue25024] Allow passing "delete=False" to TemporaryDirectory
In-Reply-To: <1441690580.39.0.270846340544.issue25024@psf.upfronthosting.co.za>
Message-ID: <1607263813.35.0.39023302923.issue25024@roundup.psfhosted.org>


Richard <nyuszika7h at gmail.com> added the comment:

Sorry for reviving a 9 months old issue, but IMO there was no good reason to reject this especially when a patch was provided. Even if the context manager can be replaced with 3 lines of code, I still don't consider that very user-friendly.

My use case would be passing `delete=False` temporarily while debugging my script, it would be much simpler than using a whole different hacky method when the end goal is to change it back to `delete=True` once it is completed anyway.

What issues exactly does the addition of a simple option cause? I don't think something as trivial as this causes a maintenance burden, and you can't call it feature creep either when TemporaryDirectory doesn't have *any* other optional keyword arguments.

----------
nosy: +nyuszika7h

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

From report at bugs.python.org  Sun Dec  6 10:04:00 2020
From: report at bugs.python.org (kaxing)
Date: Sun, 06 Dec 2020 15:04:00 +0000
Subject: [issue42581] Docs site redirection doesn't work for 3.9
Message-ID: <1607267040.29.0.292241641932.issue42581@roundup.psfhosted.org>


New submission from kaxing <kaxing at gmail.com>:

Following URL won't redirect(301) to /math.html
https://docs.python.org/3.9/library/math

Where the user sees 404 when they click from >>> help(math)

However, works fine in:
https://docs.python.org/3/library/math
https://docs.python.org/3.5/library/math
https://docs.python.org/2/library/math
https://docs.python.org/2.7/library/math

----------
assignee: docs at python
components: Documentation
messages: 382596
nosy: docs at python, kaxing
priority: normal
severity: normal
status: open
title: Docs site redirection doesn't work for 3.9

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

From report at bugs.python.org  Sun Dec  6 10:30:01 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 06 Dec 2020 15:30:01 +0000
Subject: [issue42582] Remove asyncio._all_tasks_compat()
Message-ID: <1607268601.54.0.121182893712.issue42582@roundup.psfhosted.org>


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

It was only used in _asynciomodule.c to implement now removed Task.all_tasks() method (see issue40967).

----------
components: asyncio
messages: 382597
nosy: asvetlov, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Remove asyncio._all_tasks_compat()
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Sun Dec  6 10:46:06 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 06 Dec 2020 15:46:06 +0000
Subject: [issue42582] Remove asyncio._all_tasks_compat()
In-Reply-To: <1607268601.54.0.121182893712.issue42582@roundup.psfhosted.org>
Message-ID: <1607269566.64.0.693114704546.issue42582@roundup.psfhosted.org>


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


----------
keywords: +patch
pull_requests: +22531
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23664

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

From report at bugs.python.org  Sun Dec  6 11:13:06 2020
From: report at bugs.python.org (Xavier Morel)
Date: Sun, 06 Dec 2020 16:13:06 +0000
Subject: [issue42470] DeprecationWarning triggers for sequences which happen
 to be sets as well
In-Reply-To: <1606379035.36.0.842330798084.issue42470@roundup.psfhosted.org>
Message-ID: <1607271186.7.0.615941464595.issue42470@roundup.psfhosted.org>


Change by Xavier Morel <xavier.morel at masklinn.net>:


----------
pull_requests: +22532
pull_request: https://github.com/python/cpython/pull/23665

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

From report at bugs.python.org  Sun Dec  6 11:16:48 2020
From: report at bugs.python.org (Xavier Morel)
Date: Sun, 06 Dec 2020 16:16:48 +0000
Subject: [issue42470] DeprecationWarning triggers for sequences which happen
 to be sets as well
In-Reply-To: <1606379035.36.0.842330798084.issue42470@roundup.psfhosted.org>
Message-ID: <1607271408.36.0.0810311662536.issue42470@roundup.psfhosted.org>


Xavier Morel <xavier.morel at masklinn.net> added the comment:

Tried patterning the PR after the one which originally added the warning. Wasn't too sure how the news item was supposed to be generated, and grepping the repository didn't reveal any clear script doing that, so I made up a date and copied an existing random bit (which I expect is just a deduplicator in case multiple NEWS items are created at the same instant?)

----------

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

From report at bugs.python.org  Sun Dec  6 11:19:09 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 06 Dec 2020 16:19:09 +0000
Subject: [issue42572] Better path handling with argparse
In-Reply-To: <1607121735.85.0.926277593776.issue42572@roundup.psfhosted.org>
Message-ID: <1607271549.71.0.473937779486.issue42572@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I think this would be a type, not an action.

I'm not sure this would pass the bar of something that should be added to the stdlib. But in any event, it should be developed on PyPI first, perhaps by adding it to argparse-types.

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

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

From report at bugs.python.org  Sun Dec  6 11:38:06 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 06 Dec 2020 16:38:06 +0000
Subject: [issue42576] Passing keyword arguments to types.GenericAlias causes a
 hard crash
In-Reply-To: <1607178679.27.0.947659385701.issue42576@roundup.psfhosted.org>
Message-ID: <1607272686.53.0.559819761183.issue42576@roundup.psfhosted.org>


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


New changeset 6a7fb9d31bce8590e30c44458d1fc1da4539743d by kj in branch 'master':
bpo-42576: Clarify only debug builds are affected in news (GH-23663)
https://github.com/python/cpython/commit/6a7fb9d31bce8590e30c44458d1fc1da4539743d


----------

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

From report at bugs.python.org  Sun Dec  6 11:38:31 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 06 Dec 2020 16:38:31 +0000
Subject: [issue42576] Passing keyword arguments to types.GenericAlias causes a
 hard crash
In-Reply-To: <1607178679.27.0.947659385701.issue42576@roundup.psfhosted.org>
Message-ID: <1607272711.09.0.58000162531.issue42576@roundup.psfhosted.org>


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


----------
pull_requests: +22533
pull_request: https://github.com/python/cpython/pull/23666

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

From report at bugs.python.org  Sun Dec  6 11:55:06 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 06 Dec 2020 16:55:06 +0000
Subject: [issue42582] Remove asyncio._all_tasks_compat()
In-Reply-To: <1607268601.54.0.121182893712.issue42582@roundup.psfhosted.org>
Message-ID: <1607273706.92.0.500779891907.issue42582@roundup.psfhosted.org>


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


New changeset 8a62887dfb4bb2835048780ad673362f7ee3c7bf by Serhiy Storchaka in branch 'master':
bpo-42582: Remove asyncio._all_tasks_compat(). (GH-23664)
https://github.com/python/cpython/commit/8a62887dfb4bb2835048780ad673362f7ee3c7bf


----------

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

From report at bugs.python.org  Sun Dec  6 12:01:05 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 06 Dec 2020 17:01:05 +0000
Subject: [issue42576] Passing keyword arguments to types.GenericAlias causes a
 hard crash
In-Reply-To: <1607178679.27.0.947659385701.issue42576@roundup.psfhosted.org>
Message-ID: <1607274065.98.0.00836498684744.issue42576@roundup.psfhosted.org>


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


New changeset 8502d46e3649bedf6b58a30b0a4b6b726e32b84b by Miss Islington (bot) in branch '3.9':
[3.9] bpo-42576: Clarify only debug builds are affected in news (GH-23663) (GH-23666)
https://github.com/python/cpython/commit/8502d46e3649bedf6b58a30b0a4b6b726e32b84b


----------

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

From report at bugs.python.org  Sun Dec  6 13:38:53 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 06 Dec 2020 18:38:53 +0000
Subject: [issue42382] No easy way to get the distribution which provided a
 importlib.metadata.EntryPoint
In-Reply-To: <1605596181.46.0.7808505308.issue42382@roundup.psfhosted.org>
Message-ID: <1607279933.97.0.210155462367.issue42382@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
assignee:  -> jaraco

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

From report at bugs.python.org  Sun Dec  6 13:39:44 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 06 Dec 2020 18:39:44 +0000
Subject: [issue42582] Remove asyncio._all_tasks_compat()
In-Reply-To: <1607268601.54.0.121182893712.issue42582@roundup.psfhosted.org>
Message-ID: <1607279984.24.0.737695184487.issue42582@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/issue42582>
_______________________________________

From report at bugs.python.org  Sun Dec  6 14:02:04 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 06 Dec 2020 19:02:04 +0000
Subject: [issue21627] Concurrently closing files and iterating over the open
 files directory is not well specified
In-Reply-To: <1401643353.39.0.53304722389.issue21627@psf.upfronthosting.co.za>
Message-ID: <1607281324.25.0.627081195802.issue21627@roundup.psfhosted.org>


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

It is Modules/_posixsubprocess.c.

We still do not have a reproducer, so I am not sure that the code has this problem.

----------
nosy: +serhiy.storchaka
status: pending -> open

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

From report at bugs.python.org  Sun Dec  6 14:57:26 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 06 Dec 2020 19:57:26 +0000
Subject: [issue38660] Checking if two regexes are equal should test if they
 are functionally equivalent
In-Reply-To: <1572589355.53.0.484947747448.issue38660@roundup.psfhosted.org>
Message-ID: <1607284646.15.0.889147986649.issue38660@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

https://math.stackexchange.com/questions/46975/how-to-prove-two-regular-expressions-are-identical-in-mathematical-way contains some references to proofs that checking if two regular expressions are equivalent is PSPACE-complete.  Another answer in that question mentions that its at least exponential in both space and time.  Either means that comparing two REs gets infeasible very fast, which makes this unsuited for an equality checking.

I propose closing this issue.

----------
nosy: +ronaldoussoren

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

From report at bugs.python.org  Sun Dec  6 15:02:50 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 06 Dec 2020 20:02:50 +0000
Subject: [issue38309] Avoid creating duplicate PATH entries with the macOS
 installer
In-Reply-To: <1569696052.2.0.379092871214.issue38309@roundup.psfhosted.org>
Message-ID: <1607284970.16.0.411780809385.issue38309@roundup.psfhosted.org>


Change by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
components: +macOS
nosy: +ronaldoussoren

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

From report at bugs.python.org  Sun Dec  6 15:13:00 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 06 Dec 2020 20:13:00 +0000
Subject: [issue42382] No easy way to get the distribution which provided a
 importlib.metadata.EntryPoint
In-Reply-To: <1605596181.46.0.7808505308.issue42382@roundup.psfhosted.org>
Message-ID: <1607285580.63.0.527936474993.issue42382@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I've ported the initial patch over to the backport and am exploring options in https://github.com/python/importlib_metadata/pull/266.

----------

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

From report at bugs.python.org  Sun Dec  6 15:50:10 2020
From: report at bugs.python.org (Peter Ludemann)
Date: Sun, 06 Dec 2020 20:50:10 +0000
Subject: [issue36541] Make lib2to3 grammar better match Python,
 support the := walrus
In-Reply-To: <1554514880.92.0.277848417721.issue36541@roundup.psfhosted.org>
Message-ID: <1607287810.72.0.93507034969.issue36541@roundup.psfhosted.org>


Peter Ludemann <peter.ludemann at gmail.com> added the comment:

Every piece of code that uses either lib2to3 or a parser derived from it (including parso and LibCST) will eventually not be able to upgrade the parser because PEG can handle grammars that LL(k) can't. That's why I proposed adding some functionality to ast.parse, to make the whitespace and token information easily available - this seems to be what @BTaskaya says is "easy" (maybe they mean it's easy using LibCST? It seems to be fiddly using ast.parse). The alternative is that all these projects (black, LibCST, yapf, etc.) will have to roll their own solutions, which doesn't seem a very productive use of people's time and makes version upgrades slow.

If people are interested in using ast.parse extensions as a replacement for lib2to3, I suggest discussing at https://mail.python.org/archives/list/python-ideas at python.org/thread/X2HJ6I6XLIGRZDB27HRHIVQC3RXNZAY4/

----------

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

From report at bugs.python.org  Sun Dec  6 16:05:44 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Sun, 06 Dec 2020 21:05:44 +0000
Subject: [issue38780] SysLogHandler crash atexit
In-Reply-To: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>
Message-ID: <1607288744.39.0.956791150314.issue38780@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Thanks, Jason! I won't have time to look at this until perhaps next week, however, feel free to add tests as you like.

N.B.: My patches might not be the best solution to the problem; it was just something I threw up based on my initial understanding of the problem.

----------

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

From report at bugs.python.org  Sun Dec  6 16:12:35 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sun, 06 Dec 2020 21:12:35 +0000
Subject: [issue36541] Make lib2to3 grammar better match Python,
 support the := walrus
In-Reply-To: <1554514880.92.0.277848417721.issue36541@roundup.psfhosted.org>
Message-ID: <1607289155.45.0.544141325452.issue36541@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

> Every piece of code that uses either lib2to3 or a parser derived from it (including parso and LibCST) will eventually not be able to upgrade the parser because PEG can handle grammars that LL(k) can't.

Since these projects are external, depending on the functionality they are free-to-roll their own parser implementations or make hacks to pass away things. Or fork the Grammar/python.gram to preserve all tokens and generate a Python parser from it.


> If people are interested in using ast.parse extensions as a replacement for lib2to3, I suggest discussing at

I don't quite get what you are proposing here, 

>I propose implementing an optional pass over the parse tree that records lib2to3's "prefix" with each leaf node. The interface would be something like:

How would you do that? By augmenting the AST with the information retrieved from tokens? If so, check this out; https://github.com/leo-editor/leo-editor/blob/master/leo/core/leoAst.py and asttokens.

Also, please move the discussion to somewhere else (like discuss.python.org etc.) since this is not the ideal place to discuss and people might be distracted! (feel free to cc me where you move the discussion)

----------

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

From report at bugs.python.org  Sun Dec  6 16:14:35 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sun, 06 Dec 2020 21:14:35 +0000
Subject: [issue36541] Make lib2to3 grammar better match Python,
 support the := walrus
In-Reply-To: <1554514880.92.0.277848417721.issue36541@roundup.psfhosted.org>
Message-ID: <1607289275.28.0.199072261137.issue36541@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

> Parsing support for `f(**mapping)` support is indeed still missing.
>
> as lib2to3 is pending deprecation at this point, i'm not going to work on this.  anyone is welcome to pick it up.  modifying the lib2to3 grammar, and any related code, and adding a test is what's needed to parse that syntax.

I'd also agree, and not supporting to add features from now on. If someone really needs this to be added [and backported], please re-open the issue.

----------
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Dec  6 16:54:12 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 06 Dec 2020 21:54:12 +0000
Subject: [issue42382] No easy way to get the distribution which provided a
 importlib.metadata.EntryPoint
In-Reply-To: <1605596181.46.0.7808505308.issue42382@roundup.psfhosted.org>
Message-ID: <1607291652.74.0.260709630492.issue42382@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

In discussion, I realized that I don't yet understand what use-cases drive this demand? What code is it that requires resolving a distribution from an entry point?

----------

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

From report at bugs.python.org  Sun Dec  6 17:06:39 2020
From: report at bugs.python.org (Pedro Algarvio)
Date: Sun, 06 Dec 2020 22:06:39 +0000
Subject: [issue42382] No easy way to get the distribution which provided a
 importlib.metadata.EntryPoint
In-Reply-To: <1605596181.46.0.7808505308.issue42382@roundup.psfhosted.org>
Message-ID: <1607292399.16.0.139162783907.issue42382@roundup.psfhosted.org>


Pedro Algarvio <pedro at algarvio.me> added the comment:

Our software uses a plug-in based approach.
Plugins are able to add/modify internal behavior, and, as part of bug submission process we have a CLI flag which provides information about the core app as well as any intervening plugins.

This is where we need to "map" an entry point to it's distribution, so we know the name and version of it to display on this report.

----------

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

From report at bugs.python.org  Sun Dec  6 17:11:00 2020
From: report at bugs.python.org (Steve Stagg)
Date: Sun, 06 Dec 2020 22:11:00 +0000
Subject: [issue42540] Debug pymalloc crash when using os.fork() [regression]
In-Reply-To: <1606918936.38.0.790172378115.issue42540@roundup.psfhosted.org>
Message-ID: <1607292660.02.0.762421252558.issue42540@roundup.psfhosted.org>


Steve Stagg <stestagg at gmail.com> added the comment:

Reproducible on master, but doesn't occur with a debug build.

My configure:

> ./configure --prefix=$PREFIX --exec-prefix=$EPREFIX --cache-file=../config.cache --without-ensurepip > /dev/null
> PYTHONMALLOC=pymalloc_debug $EPREFIX/bin/python3 ../test.py

Crash comes out of the child process, I modified example to invoke lldb for child:

```
import os
import time
import subprocess

def daemon():
    pid = os.fork()
    if pid != 0:
        subprocess.run(["lldb", '-p', str(pid)])
        time.sleep(10)
        os._exit(0)
    time.sleep(1)

daemon()
```


Attaching to the child gives this backtrace:

(lldb) bt
* thread #1, name = 'python3', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
    frame #0: 0x0000564a5a325f9c python3.10`_PyObject_DebugDumpAddress(p=0x0000564a5aa2c630) at obmalloc.c:2457:12
    frame #1: 0x0000564a5a326571 python3.10`_PyMem_DebugCheckAddress(func="_PyMem_DebugRawFree", api=<unavailable>, p=<unavailable>) at obmalloc.c:2375:9
  * frame #2: 0x0000564a5a326d29 python3.10`_PyMem_DebugRawFree at obmalloc.c:2208:5
    frame #3: 0x0000564a5a326d17 python3.10`_PyMem_DebugRawFree(ctx=0x0000564a5a5d37e0, p=0x0000564a5aa2c630) at obmalloc.c:2197
    frame #4: 0x0000564a5a3d4aa3 python3.10`PyInterpreterState_Delete(interp=0x0000564a5aa4e6b0) at pystate.c:396:9
    frame #5: 0x0000564a5a3d1921 python3.10`Py_FinalizeEx [inlined] finalize_interp_delete(tstate=<unavailable>) at pylifecycle.c:1633:5
    frame #6: 0x0000564a5a3d190b python3.10`Py_FinalizeEx at pylifecycle.c:1782
    frame #7: 0x0000564a5a2dab80 python3.10`Py_BytesMain at main.c:679:9
    frame #8: 0x0000564a5a2dab69 python3.10`Py_BytesMain at main.c:707
    frame #9: 0x0000564a5a2dab4f python3.10`Py_BytesMain(argc=<unavailable>, argv=<unavailable>) at main.c:731
    frame #10: 0x00007ff2e6251152 libc.so.6`__libc_start_main + 242
    frame #11: 0x0000564a5a2d978e python3.10`_start + 46


The call stack is trying to free an interpreter mutex:
    PyThread_free_lock(interp->id_mutex);

----------
nosy: +stestagg

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

From report at bugs.python.org  Sun Dec  6 17:34:49 2020
From: report at bugs.python.org (Steve Stagg)
Date: Sun, 06 Dec 2020 22:34:49 +0000
Subject: [issue42540] Debug pymalloc crash when using os.fork() [regression]
In-Reply-To: <1606918936.38.0.790172378115.issue42540@roundup.psfhosted.org>
Message-ID: <1607294089.67.0.0177608834018.issue42540@roundup.psfhosted.org>


Steve Stagg <stestagg at gmail.com> added the comment:

Something seems to be: breaking alignment, changing the allocator used, or trashing that memory.

In my case, the address of the mutex is: 0x5603a3666630  (*1) below
and the surrounding memory:

0x5603a3666610: n\0\0\03\0\0\0\0\0\0\0(*2)\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd1\0\0\0\0\0\0\0
0x5603a3666630: (*1)\x01\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd
0x5603a3666650: \xdd\xdd\xdd\xdd\xdd\xdd\xdd\xddQ\0\0\0\0\0\0\0\x90ds\xa3\x03V\0\0\xf0\xc4\xfbq\a\x7f\0\0

The fun thing is that the nbytes field lines up at (*2) which is full of DEADBYTEs, and thus tries to find the tail of the allocation at p + 15987178197214944733  (which happily segfaults)

----------

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

From report at bugs.python.org  Sun Dec  6 17:45:57 2020
From: report at bugs.python.org (Idan Weiss)
Date: Sun, 06 Dec 2020 22:45:57 +0000
Subject: [issue42532] spec_arg's __bool__ is called while initializing
 NonCallableMock
In-Reply-To: <1606998026.09.0.31549028921.issue42532@roundup.psfhosted.org>
Message-ID: <1607294757.47.0.116570818682.issue42532@roundup.psfhosted.org>


Change by Idan Weiss <idanweiss97 at gmail.com>:


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

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

From report at bugs.python.org  Sun Dec  6 18:01:11 2020
From: report at bugs.python.org (Steve Stagg)
Date: Sun, 06 Dec 2020 23:01:11 +0000
Subject: [issue42540] Debug pymalloc crash when using os.fork() [regression]
In-Reply-To: <1606918936.38.0.790172378115.issue42540@roundup.psfhosted.org>
Message-ID: <1607295671.14.0.0621001572983.issue42540@roundup.psfhosted.org>


Steve Stagg <stestagg at gmail.com> added the comment:

So, I'm not an allocator/init/teardown expert, but it looks like: When you fork, PyRuntimeState creates a new mutex, explicitly using the default allocator (without the debug allocator active)..


#ifdef HAVE_FORK
/* This function is called from PyOS_AfterFork_Child to ensure that
   newly created child processes do not share locks with the parent. */
PyStatus
_PyRuntimeState_ReInitThreads(_PyRuntimeState *runtime)
{
    // This was initially set in _PyRuntimeState_Init().
    runtime->main_thread = PyThread_get_thread_ident();

    /* Force default allocator, since _PyRuntimeState_Fini() must
       use the same allocator than this function. */
    PyMemAllocatorEx old_alloc;
    _PyMem_SetDefaultAllocator(PYMEM_DOMAIN_RAW, &old_alloc);

    int reinit_interp = _PyThread_at_fork_reinit(&runtime->interpreters.mutex);
    int reinit_main_id = _PyThread_at_fork_reinit(&runtime->interpreters.main->id_mutex);
    int reinit_xidregistry = _PyThread_at_fork_reinit(&runtime->xidregistry.mutex);

    PyMem_SetAllocator(PYMEM_DOMAIN_RAW, &old_alloc);

    if (reinit_interp < 0
        || reinit_main_id < 0
        || reinit_xidregistry < 0)
    {
        return _PyStatus_ERR("Failed to reinitialize runtime locks");

    }
    return _PyStatus_OK();
}
#endif


But the PyInterpreterState_Delete function does not do this:

if (interp->id_mutex != NULL) {
    PyThread_free_lock(interp->id_mutex);
}


Which causes it to try to use the debug allocator to free, and hence crash..

----------

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

From report at bugs.python.org  Sun Dec  6 19:09:50 2020
From: report at bugs.python.org (Irit Katriel)
Date: Mon, 07 Dec 2020 00:09:50 +0000
Subject: [issue42561] better error reporting in ast
In-Reply-To: <1607027058.31.0.3436923935.issue42561@roundup.psfhosted.org>
Message-ID: <1607299790.77.0.68739576045.issue42561@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
resolution:  -> duplicate
superseder:  -> AST literal_eval exceptions provide no information about line number

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

From report at bugs.python.org  Sun Dec  6 19:32:12 2020
From: report at bugs.python.org (Kjartan Hrafnkelsson)
Date: Mon, 07 Dec 2020 00:32:12 +0000
Subject: [issue42583] JSON.dumps() creates invalid JSON with single quotes
Message-ID: <1607301132.51.0.662814441179.issue42583@roundup.psfhosted.org>


New submission from Kjartan Hrafnkelsson <george at bund.lu>:

the JSON.dumps() function should create valid JSON using double quotes only, however when the function is run with an object as its argument it results in invalid JSON using single quotes. As defined in the ECMA-404 JSON Data Interchange Syntax (http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf) JSON should use double quotes not single quotes.

----------
components: Library (Lib)
messages: 382615
nosy: imeuropa
priority: normal
severity: normal
status: open
title: JSON.dumps() creates invalid JSON with single quotes
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sun Dec  6 19:56:56 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 07 Dec 2020 00:56:56 +0000
Subject: [issue42559] random.getrandbits: Should it be explicit that it
 returns unsigned/non-negative integer?
In-Reply-To: <1607018036.1.0.534167707073.issue42559@roundup.psfhosted.org>
Message-ID: <1607302616.79.0.727279212933.issue42559@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 2.0 -> 3.0
pull_requests: +22534
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23667

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

From report at bugs.python.org  Sun Dec  6 20:11:49 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 07 Dec 2020 01:11:49 +0000
Subject: [issue42581] Docs site redirection doesn't work for 3.9
In-Reply-To: <1607267040.29.0.292241641932.issue42581@roundup.psfhosted.org>
Message-ID: <1607303509.14.0.483960306255.issue42581@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +mdk

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

From report at bugs.python.org  Sun Dec  6 20:13:15 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 07 Dec 2020 01:13:15 +0000
Subject: [issue42579] Solution from gh#python/cpython#13236 unnecessarily
 binds building of documentation to the latest version of Sphinx
In-Reply-To: <1607204834.85.0.284068397188.issue42579@roundup.psfhosted.org>
Message-ID: <1607303595.95.0.444036725631.issue42579@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +mdk

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

From report at bugs.python.org  Sun Dec  6 21:26:07 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 07 Dec 2020 02:26:07 +0000
Subject: [issue42583] JSON.dumps() creates invalid JSON with single quotes
In-Reply-To: <1607301132.51.0.662814441179.issue42583@roundup.psfhosted.org>
Message-ID: <1607307967.06.0.65960475273.issue42583@roundup.psfhosted.org>


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

Example?

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

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

From report at bugs.python.org  Sun Dec  6 21:29:31 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 07 Dec 2020 02:29:31 +0000
Subject: [issue38843] Document argparse behaviour when custom namespace object
 already has the field set
In-Reply-To: <1574130223.67.0.390215742489.issue38843@roundup.psfhosted.org>
Message-ID: <1607308171.89.0.527740424656.issue38843@roundup.psfhosted.org>


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


----------
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +22535
pull_request: https://github.com/python/cpython/pull/23668

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

From report at bugs.python.org  Sun Dec  6 21:29:36 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 07 Dec 2020 02:29:36 +0000
Subject: [issue38843] Document argparse behaviour when custom namespace object
 already has the field set
In-Reply-To: <1574130223.67.0.390215742489.issue38843@roundup.psfhosted.org>
Message-ID: <1607308176.52.0.345992190153.issue38843@roundup.psfhosted.org>


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


New changeset 752cdf21eb2be0a26ea6a34a0de33a458459aead by Raymond Hettinger in branch 'master':
bpo-38843: Document behavior of default when the attribute is already set (GH-23653)
https://github.com/python/cpython/commit/752cdf21eb2be0a26ea6a34a0de33a458459aead


----------

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

From report at bugs.python.org  Sun Dec  6 22:11:12 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 07 Dec 2020 03:11:12 +0000
Subject: [issue21627] Concurrently closing files and iterating over the open
 files directory is not well specified
In-Reply-To: <1401643353.39.0.53304722389.issue21627@psf.upfronthosting.co.za>
Message-ID: <1607310672.27.0.355468213304.issue21627@roundup.psfhosted.org>


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

The Linux kernel code is not sufficiently easy to follow to understand if it has this issue or if it pre-creates the dirent structures for all fds at opendir time for /proc/self/fd or if it is iterating through the list of fds in sorted order so an older closed fd will not interfere with its internal iteration.

Regardless, I've yet to knowingly witness a problem from this come up in practice.  knowingly and yet being key words. :)

But I like the general theme of your patch to set CLOEXEC on all of the fd's rather than explicitly call close(fd) in the directory reading loop.

----------
assignee:  -> gregory.p.smith
components: +Library (Lib)
resolution: out of date -> 
type:  -> behavior
versions: +Python 3.10, Python 3.9 -Python 3.5

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

From report at bugs.python.org  Sun Dec  6 22:22:45 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 07 Dec 2020 03:22:45 +0000
Subject: [issue42508] macOS IDLE with Tk 8.6.10 in 3.9.1rc1 universal2
 installer fails smoke test
In-Reply-To: <1606706274.22.0.163331071262.issue42508@roundup.psfhosted.org>
Message-ID: <1607311365.12.0.0807887940666.issue42508@roundup.psfhosted.org>


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


New changeset 57e511361047895231f5ee7abfdfbbc60e11d2db by Terry Jan Reedy in branch 'master':
bpo-42508: Keep IDLE running on macOS (GH-23577)
https://github.com/python/cpython/commit/57e511361047895231f5ee7abfdfbbc60e11d2db


----------

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

From report at bugs.python.org  Sun Dec  6 22:22:50 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 07 Dec 2020 03:22:50 +0000
Subject: [issue42508] macOS IDLE with Tk 8.6.10 in 3.9.1rc1 universal2
 installer fails smoke test
In-Reply-To: <1606706274.22.0.163331071262.issue42508@roundup.psfhosted.org>
Message-ID: <1607311370.77.0.856986140951.issue42508@roundup.psfhosted.org>


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


----------
pull_requests: +22536
pull_request: https://github.com/python/cpython/pull/23669

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

From report at bugs.python.org  Sun Dec  6 22:23:02 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 07 Dec 2020 03:23:02 +0000
Subject: [issue42508] macOS IDLE with Tk 8.6.10 in 3.9.1rc1 universal2
 installer fails smoke test
In-Reply-To: <1606706274.22.0.163331071262.issue42508@roundup.psfhosted.org>
Message-ID: <1607311382.15.0.484232432233.issue42508@roundup.psfhosted.org>


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


----------
pull_requests: +22537
pull_request: https://github.com/python/cpython/pull/23670

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

From report at bugs.python.org  Sun Dec  6 22:49:05 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 07 Dec 2020 03:49:05 +0000
Subject: [issue42508] macOS IDLE with Tk 8.6.10 in 3.9.1rc1 universal2
 installer fails smoke test
In-Reply-To: <1606706274.22.0.163331071262.issue42508@roundup.psfhosted.org>
Message-ID: <1607312945.32.0.190215438462.issue42508@roundup.psfhosted.org>


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


New changeset 2a9a883d361d37b40fb0b0011dd300bb83ceb73c by Miss Islington (bot) in branch '3.9':
bpo-42508: Keep IDLE running on macOS (GH-23577) (GH-23669)
https://github.com/python/cpython/commit/2a9a883d361d37b40fb0b0011dd300bb83ceb73c


----------

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

From report at bugs.python.org  Mon Dec  7 00:17:17 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 07 Dec 2020 05:17:17 +0000
Subject: [issue38843] Document argparse behaviour when custom namespace object
 already has the field set
In-Reply-To: <1574130223.67.0.390215742489.issue38843@roundup.psfhosted.org>
Message-ID: <1607318237.26.0.163354473763.issue38843@roundup.psfhosted.org>


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


New changeset facca72eae3c0b59b4e89bab81c936dff10fb58a by Miss Islington (bot) in branch '3.9':
bpo-38843: Document behavior of default when the attribute is already set (GH-23653) (#23668)
https://github.com/python/cpython/commit/facca72eae3c0b59b4e89bab81c936dff10fb58a


----------

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

From report at bugs.python.org  Mon Dec  7 00:17:48 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 07 Dec 2020 05:17:48 +0000
Subject: [issue38843] Document argparse behaviour when custom namespace object
 already has the field set
In-Reply-To: <1574130223.67.0.390215742489.issue38843@roundup.psfhosted.org>
Message-ID: <1607318268.19.0.730902856368.issue38843@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/issue38843>
_______________________________________

From report at bugs.python.org  Mon Dec  7 03:01:08 2020
From: report at bugs.python.org (Paul Sokolovsky)
Date: Mon, 07 Dec 2020 08:01:08 +0000
Subject: [issue42559] random.getrandbits: Should it be explicit that it
 returns unsigned/non-negative integer?
In-Reply-To: <1607018036.1.0.534167707073.issue42559@roundup.psfhosted.org>
Message-ID: <1607328068.14.0.00989090290464.issue42559@roundup.psfhosted.org>


Paul Sokolovsky <pfalcon at users.sourceforge.net> added the comment:

Raymond Hettinger: Thanks for acking it would be a useful change!

ZackerySpytz: Thanks for making a patch!

----------

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

From report at bugs.python.org  Mon Dec  7 03:17:43 2020
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 07 Dec 2020 08:17:43 +0000
Subject: [issue41889] enum: Mixin and int base class regression in 3.8.6
In-Reply-To: <1601439696.58.0.28102514399.issue41889@roundup.psfhosted.org>
Message-ID: <1607329063.8.0.399822510653.issue41889@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset c266736ec1f9ebef38b134ceb4832df015711b38 by Ethan Furman in branch 'master':
bpo-41889: [Enum] fix multiple-inheritance regression (GH-22487)
https://github.com/python/cpython/commit/c266736ec1f9ebef38b134ceb4832df015711b38


----------

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

From report at bugs.python.org  Mon Dec  7 03:19:33 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 07 Dec 2020 08:19:33 +0000
Subject: [issue41889] enum: Mixin and int base class regression in 3.8.6
In-Reply-To: <1601439696.58.0.28102514399.issue41889@roundup.psfhosted.org>
Message-ID: <1607329173.29.0.95196496106.issue41889@roundup.psfhosted.org>


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


----------
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +22538
pull_request: https://github.com/python/cpython/pull/23672

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

From report at bugs.python.org  Mon Dec  7 03:19:40 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 07 Dec 2020 08:19:40 +0000
Subject: [issue41889] enum: Mixin and int base class regression in 3.8.6
In-Reply-To: <1601439696.58.0.28102514399.issue41889@roundup.psfhosted.org>
Message-ID: <1607329180.51.0.465900830081.issue41889@roundup.psfhosted.org>


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


----------
pull_requests: +22539
pull_request: https://github.com/python/cpython/pull/23673

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

From report at bugs.python.org  Mon Dec  7 03:49:31 2020
From: report at bugs.python.org (Inada Naoki)
Date: Mon, 07 Dec 2020 08:49:31 +0000
Subject: [issue42578] Add tip when encountering UnicodeDecode/EncodeError in
 open()
In-Reply-To: <1607181755.9.0.464136103954.issue42578@roundup.psfhosted.org>
Message-ID: <1607330971.56.0.224333872554.issue42578@roundup.psfhosted.org>


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

How do you think about PEP-597?
https://www.python.org/dev/peps/pep-0597/

----------
nosy: +methane

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

From report at bugs.python.org  Mon Dec  7 04:23:58 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 07 Dec 2020 09:23:58 +0000
Subject: [issue42583] JSON.dumps() creates invalid JSON with single quotes
In-Reply-To: <1607301132.51.0.662814441179.issue42583@roundup.psfhosted.org>
Message-ID: <1607333038.42.0.429491955353.issue42583@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/issue42583>
_______________________________________

From report at bugs.python.org  Mon Dec  7 04:27:22 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 07 Dec 2020 09:27:22 +0000
Subject: [issue38660] Checking if two regexes are equal should test if they
 are functionally equivalent
In-Reply-To: <1572589355.53.0.484947747448.issue38660@roundup.psfhosted.org>
Message-ID: <1607333242.49.0.851586359737.issue38660@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/issue38660>
_______________________________________

From report at bugs.python.org  Mon Dec  7 05:36:22 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 07 Dec 2020 10:36:22 +0000
Subject: [issue42584] Upgrade macOS and Windows installers to use SQLite 3.34.0
Message-ID: <1607337382.55.0.591359272905.issue42584@roundup.psfhosted.org>


New submission from Erlend Egeberg Aasland <erlend.aasland at innova.no>:

SQLite 3.34.0 was released 2020-12-01: https://www.sqlite.org/releaselog/3_34_0.html

Compiles fine on master, and tests are completing without error.

----------
components: Library (Lib)
messages: 382625
nosy: erlendaasland
priority: normal
severity: normal
status: open
title: Upgrade macOS and Windows installers to use SQLite 3.34.0
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Dec  7 05:39:14 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 07 Dec 2020 10:39:14 +0000
Subject: [issue42584] Upgrade macOS and Windows installers to use SQLite 3.34.0
In-Reply-To: <1607337382.55.0.591359272905.issue42584@roundup.psfhosted.org>
Message-ID: <1607337554.85.0.553070438097.issue42584@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
keywords: +patch
pull_requests: +22540
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23674

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

From report at bugs.python.org  Mon Dec  7 05:42:00 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 07 Dec 2020 10:42:00 +0000
Subject: [issue42584] Upgrade macOS and Windows installers to use SQLite 3.34.0
In-Reply-To: <1607337382.55.0.591359272905.issue42584@roundup.psfhosted.org>
Message-ID: <1607337720.08.0.561661564672.issue42584@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
pull_requests: +22541
pull_request: https://github.com/python/cpython/pull/23675

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

From report at bugs.python.org  Mon Dec  7 05:44:16 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 07 Dec 2020 10:44:16 +0000
Subject: [issue42584] Upgrade macOS and Windows installers to use SQLite 3.34.0
In-Reply-To: <1607337382.55.0.591359272905.issue42584@roundup.psfhosted.org>
Message-ID: <1607337856.79.0.857927103153.issue42584@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
nosy: +ned.deily, steve.dower

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

From report at bugs.python.org  Mon Dec  7 05:56:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Dec 2020 10:56:27 +0000
Subject: [issue30459] PyList_SET_ITEM  could be safer
In-Reply-To: <1495638852.56.0.0790136948712.issue30459@psf.upfronthosting.co.za>
Message-ID: <1607338587.9.0.460818867365.issue30459@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 0ef96c2b2a291c9d2d9c0ba42bbc1900a21e65f3 by Victor Stinner in branch 'master':
bpo-30459: Cast the result of PyCell_SET to void (GH-23654)
https://github.com/python/cpython/commit/0ef96c2b2a291c9d2d9c0ba42bbc1900a21e65f3


----------

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

From report at bugs.python.org  Mon Dec  7 05:57:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Dec 2020 10:57:33 +0000
Subject: [issue30459] PyList_SET_ITEM  could be safer
In-Reply-To: <1495638852.56.0.0790136948712.issue30459@psf.upfronthosting.co.za>
Message-ID: <1607338653.33.0.601713610741.issue30459@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks Espie Marc for the bug report, it's now fixed in the master branch. IMO not only clang users will benefit of a better defined API. For example, it should help other Python implementation to implement such API, without the weird side effects of a macro.

----------

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

From report at bugs.python.org  Mon Dec  7 05:57:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Dec 2020 10:57:40 +0000
Subject: [issue30459] PyList_SET_ITEM  could be safer
In-Reply-To: <1495638852.56.0.0790136948712.issue30459@psf.upfronthosting.co.za>
Message-ID: <1607338660.9.0.603128405858.issue30459@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10 -Python 3.9

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

From report at bugs.python.org  Mon Dec  7 06:01:51 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 07 Dec 2020 11:01:51 +0000
Subject: [issue42584] Upgrade macOS and Windows installers to use SQLite 3.34.0
In-Reply-To: <1607337382.55.0.591359272905.issue42584@roundup.psfhosted.org>
Message-ID: <1607338911.62.0.748747826128.issue42584@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Steve Dower: It should be fairly easy to add a CI check that validates the source checksums, so you don't need to do it manually every time. I can throw up a simple GH workflow for the sqlite branch if you want.

----------

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

From report at bugs.python.org  Mon Dec  7 06:08:45 2020
From: report at bugs.python.org (Stegle, Julien)
Date: Mon, 07 Dec 2020 11:08:45 +0000
Subject: [issue42585] Segmentation fault on Linux with multiprocess queue
Message-ID: <1607339325.06.0.835049890466.issue42585@roundup.psfhosted.org>


New submission from Stegle, Julien <Julien.Stegle at ge.com>:

Hi,

I'm experiencing segmentation fault issues when running inside a Docker container (tested with python:3.8.6, python:3.8.6-slim, python:3.6.8 & python:3.6.8-slim).

On windows everything works fine, but when running on Docker when I try to put a string into my queue I'm experiencing the following error:

GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from python...(no debugging symbols found)...done.
Starting program: /usr/local/bin/python -m ge.xxx.core.runners.exec basic reader /home/executor/xxx/exemple1.ini
warning: Error disabling address space randomization: Operation not permitted
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after fork from child process 12]
[New Thread 0x7f11f66c7700 (LWP 13)]
[New Thread 0x7f11f3ec6700 (LWP 14)]
[New Thread 0x7f11f16c5700 (LWP 15)]
[New Thread 0x7f11eeec4700 (LWP 16)]
[New Thread 0x7f11ec6c3700 (LWP 17)]
[New Thread 0x7f11e9ec2700 (LWP 18)]
[New Thread 0x7f11e76c1700 (LWP 19)]
[New Thread 0x7f11e4ec0700 (LWP 20)]
[New Thread 0x7f11e26bf700 (LWP 21)]
[New Thread 0x7f11dfebe700 (LWP 22)]
[New Thread 0x7f11df6bd700 (LWP 23)]
[Thread 0x7f11e9ec2700 (LWP 18) exited]
[Thread 0x7f11e76c1700 (LWP 19) exited]
[Thread 0x7f11ec6c3700 (LWP 17) exited]
[Thread 0x7f11eeec4700 (LWP 16) exited]
[Thread 0x7f11f16c5700 (LWP 15) exited]
[Thread 0x7f11f3ec6700 (LWP 14) exited]
[Thread 0x7f11f66c7700 (LWP 13) exited]
[Thread 0x7f11e26bf700 (LWP 21) exited]
[Thread 0x7f11dfebe700 (LWP 22) exited]
[Thread 0x7f11e4ec0700 (LWP 20) exited]
[Thread 0x7f11df6bd700 (LWP 23) exited]
[Detaching after fork from child process 24]
[Detaching after fork from child process 25]
[New Thread 0x7f11df6bd700 (LWP 26)]
[New Thread 0x7f11dfebe700 (LWP 27)]
[New Thread 0x7f11e26bf700 (LWP 28)]
[New Thread 0x7f11e4ec0700 (LWP 29)]
[New Thread 0x7f11cc893700 (LWP 30)]
[New Thread 0x7f11ca092700 (LWP 31)]
[New Thread 0x7f11c7891700 (LWP 32)]
[New Thread 0x7f11c5090700 (LWP 33)]
[New Thread 0x7f11c488f700 (LWP 34)]
[New Thread 0x7f11c208e700 (LWP 35)]
[New Thread 0x7f11bd88d700 (LWP 36)]
[New Thread 0x7f11b5def700 (LWP 37)]
[Thread 0x7f11e4ec0700 (LWP 29) exited]
[Thread 0x7f11c7891700 (LWP 32) exited]
[Thread 0x7f11ca092700 (LWP 31) exited]
[Thread 0x7f11c488f700 (LWP 34) exited]
[Thread 0x7f11c5090700 (LWP 33) exited]
[Thread 0x7f11cc893700 (LWP 30) exited]
[Thread 0x7f11e26bf700 (LWP 28) exited]
[Thread 0x7f11dfebe700 (LWP 27) exited]
[Thread 0x7f11df6bd700 (LWP 26) exited]
[Thread 0x7f11bd88d700 (LWP 36) exited]
[Thread 0x7f11c208e700 (LWP 35) exited]
[Detaching after fork from child process 38]
[Thread 0x7f11b5def700 (LWP 37) exited]
2020-12-07T09:16:12.760+0000 - ge.xxx.inputs - INFO - Filesystem input "ge.xxx.core.inputs.reader.dicom" initialized, target: /data/dicoms
2020-12-07T09:16:12.780+0000 - ge.xxx.parsers - INFO - Dicom data parser initialized
2020-12-07T09:16:12.918+0000 - alembic.env - INFO - Migrating database engine_data
2020-12-07T09:16:12.927+0000 - alembic.env - INFO - Migrating database engine_application
2020-12-07T09:16:12.933+0000 - alembic.env - INFO - Migrating database engine_enhancement
2020-12-07T09:16:12.956+0000 - ge.xxx.core - INFO - Duct 'default' initialized
2020-12-07T09:16:12.957+0000 - ge.xxx.inputs - INFO - Start filesystem input thread "ge.xxx.core.inputs.reader.dicom"
[Detaching after fork from child process 39]
[Detaching after fork from child process 40]
2020-12-07T09:16:13.639+0000 - ge.xxx.inputs - DEBUG - Start reading file system
2020-12-07T09:16:13.666+0000 - ge.xxx.inputs - DEBUG - File /data/dicoms/1/XXXXXXXXXXX.dcm did not match filters
2020-12-07T09:16:15.881+0000 - ge.xxx.inputs - DEBUG - ADDING DICOMREADER W/ TO QUEUE <multiprocessing.queues.Queue object at 0x7f0cafcc8c50>
Fatal Python error: Segmentation fault

Current thread 0x00007f0cb732f740 (most recent call first):
  File "/usr/local/lib/python3.6/multiprocessing/queues.py", line 82 in put
  File "/home/executor/ge.xxx.extractor/ge/xxx/extractor/input/filesystem/reader.py", line 36 in feed
  File "/home/executor/ge.xxx.duct/ge/xxx/duct/input/filesystem/reader.py", line 58 in scan
  File "/usr/local/lib/python3.6/multiprocessing/process.py", line 93 in run
  File "/usr/local/lib/python3.6/multiprocessing/process.py", line 258 in _bootstrap
  File "/usr/local/lib/python3.6/multiprocessing/spawn.py", line 118 in _main
  File "/usr/local/lib/python3.6/multiprocessing/spawn.py", line 105 in spawn_main
  File "<string>", line 1 in <module>
^C
Thread 1 "python" received signal SIGINT, Interrupt.
0x00007f11fac97037 in __GI___select (nfds=0, readfds=0x0, writefds=0x0, 
    exceptfds=0x0, timeout=0x7fff0c5d6970)
    at ../sysdeps/unix/sysv/linux/select.c:41
41      ../sysdeps/unix/sysv/linux/select.c: No such file or directory.
(gdb) bt full
#0  0x00007f11fac97037 in __GI___select (nfds=0, readfds=0x0, writefds=0x0, 
    exceptfds=0x0, timeout=0x7fff0c5d6970)
    at ../sysdeps/unix/sysv/linux/select.c:41
        resultvar = 18446744073709551102
        sc_cancel_oldtype = 0
        sc_ret = <optimized out>
#1  0x00007f11fb11360e in ?? () from /usr/local/lib/libpython3.6m.so.1.0
No symbol table info available.
#2  0x00007f11fb03f079 in _PyCFunction_FastCallDict ()
   from /usr/local/lib/libpython3.6m.so.1.0
No symbol table info available.
#3  0x00007f11fb08558d in ?? () from /usr/local/lib/libpython3.6m.so.1.0
No symbol table info available.
#4  0x00007f11fb07f49a in _PyEval_EvalFrameDefault ()
   from /usr/local/lib/libpython3.6m.so.1.0
No symbol table info available.
#5  0x00007f11fb08585a in ?? () from /usr/local/lib/libpython3.6m.so.1.0
No symbol table info available.
#6  0x00007f11fb0856b1 in ?? () from /usr/local/lib/libpython3.6m.so.1.0
No symbol table info available.
#7  0x00007f11fb07f49a in _PyEval_EvalFrameDefault ()
   from /usr/local/lib/libpython3.6m.so.1.0
No symbol table info available.
--Type <RET> for more, q to quit, c to continue without paging--c
#8  0x00007f11fb07eae5 in ?? () from /usr/local/lib/libpython3.6m.so.1.0
No symbol table info available.
#9  0x00007f11fb085c4b in _PyFunction_FastCallDict () from /usr/local/lib/libpython3.6m.so.1.0
No symbol table info available.
#10 0x00007f11fb0097be in _PyObject_FastCallDict () from /usr/local/lib/libpython3.6m.so.1.0
No symbol table info available.
#11 0x00007f11fb00a126 in _PyObject_Call_Prepend () from /usr/local/lib/libpython3.6m.so.1.0
No symbol table info available.
#12 0x00007f11fb009b07 in PyObject_Call () from /usr/local/lib/libpython3.6m.so.1.0
#8  0x00007f11fb07eae5 in ?? () from /usr/local/lib/libpython3.6m.so.1.0
No symbol table info available.
#9  0x00007f11fb085c4b in _PyFunction_FastCallDict () from /usr/local/lib/libpython3.6m.so.1.0
No symbol table info available.
#10 0x00007f11fb0097be in _PyObject_FastCallDict () from /usr/local/lib/libpython3.6m.so.1.0
No symbol table info available.
#11 0x00007f11fb00a126 in _PyObject_Call_Prepend () from /usr/local/lib/libpython3.6m.so.1.0
No symbol table info available.
#12 0x00007f11fb009b07 in PyObject_Call () from /usr/local/lib/libpython3.6m.so.1.0
No symbol table info available.
#13 0x00007f11fb0545ad in ?? () from /usr/local/lib/libpython3.6m.so.1.0
No symbol table info available.
#14 0x00007f11fb05236b in ?? () from /usr/local/lib/libpython3.6m.so.1.0
No symbol table info available.
#23 0x00007f11fb07e719 in ?? () from /usr/local/lib/libpython3.6m.so.1.0
No symbol table info available.
#24 0x00007f11fb0858e2 in ?? () from /usr/local/lib/libpython3.6m.so.1.0
No symbol table info available.
#25 0x00007f11fb0856b1 in ?? () from /usr/local/lib/libpython3.6m.so.1.0
No symbol table info available.
#26 0x00007f11fb07f49a in _PyEval_EvalFrameDefault () from /usr/local/lib/libpython3.6m.so.1.0
No symbol table info available.
#27 0x00007f11fb07da81 in PyEval_EvalCodeEx () from /usr/local/lib/libpython3.6m.so.1.0
No symbol table info available.
#28 0x00007f11fb01fa23 in ?? () from /usr/local/lib/libpython3.6m.so.1.0
No symbol table info available.
#29 0x00007f11fb009b07 in PyObject_Call () from /usr/local/lib/libpython3.6m.so.1.0
No symbol table info available.
#30 0x00007f11fb1063a1 in ?? () from /usr/local/lib/libpython3.6m.so.1.0
No symbol table info available.
#31 0x00007f11fb10620b in Py_Main () from /usr/local/lib/libpython3.6m.so.1.0
No symbol table info available.
#32 0x0000557b7762a37b in main ()
No symbol table info available.

Faulty code:

def feed(logger: logging.Logger, name: str, root: Path, filters: List[Filter], supported_extensions: List[str], queues: List[Queue]):
    if supported_extensions:
        for extension in supported_extensions:
            for filepath in root.rglob(f'*.{extension}'):
                if any([not x.validate(filepath) for x in filters]):
                    logger.debug(f'File {filepath} did not match filters')
                    continue
                for queue in queues:
                    logger.debug(f'ADDING DICOMREADER W/ TO QUEUE {queue}')
                    queue.put(str(filepath))                                           # CRASH HAPPENS HERE
                    logger.debug('DONE ADDING TO QUEUE')
                logger.debug(f'[{name}] New file created and add to queues {filepath}')
    else:
        for filepath in root.rglob(f'*.*'):
            if any([not x.validate(filepath) for x in filters]):
                logger.debug(f'File {filepath} did not match filters')
                continue
            for queue in queues:
                logger.debug('ADDING DICOMREADER W/O TO QUEUE')
                queue.put(str(filepath))
                logger.debug('DONE ADDING TO QUEUE')
            logger.debug(f'[{name}] New file created and add to queues {filepath}')

def scan(logger_name: str, logging_configuration: str, name: str,
         feed: Callable[[logging.Logger, Path, List[Filter], List[str], List[Queue]], None],
         directory: str, filters: List[Filter], supported_extensions: List[str], queues: List[Queue], done_event: Event):
    if logging_configuration:
        setup_logging(logging_configuration)
    logger = logging.getLogger(logger_name)
    logger.debug('Start reading file system')

    root = Path(directory)
    feed(logger, name, root, filters, supported_extensions, queues)

    logger.info("All folder read. Reader function ends now")
    done_event.clear()

Here's how the process is created:

def get_executor(self, args: tuple = (), kwargs: dict = {}):
    return get_context("spawn").Process(target=self._executor_target, args=args, kwargs=kwargs, daemon=True)

And here are the args used:

from multiprocessing import Queue
from ge.XXX import Filter

class Filter(ABC):

    def __init__(self, logger_name: str, logging_configuration: str):
        self.logger_name = logger_name
        self.logging_configuration = logging_configuration

    def get_logger(self):
        return logging.getLogger(self.logger_name)

    def validate(self, data: Any) -> bool:
        raise NotImplementedError

class Input(FileSystemBase):

    def __init__(self, logger_name: str, logging_configuration: str, name: str, output_queues: List[Queue],
                 directory: str, filters: List[Filter] = [], supported_extensions: List[str] = [],
                 feed: Callable[[logging.Logger, Path, List[Filter], List[str], List[Queue]], None] = feed):
        super().__init__(logger_name, logging_configuration, name, output_queues, directory, filters=filters)
        self._feed = feed
        self._executor_target = scan
        self._supported_extensions = supported_extensions
        self._executor = self.get_executor(
            args=(logger_name, logging_configuration, name,
                  feed, directory, filters, supported_extensions,
                  output_queues, self._running)
        )

After a quick lookup in the source code the issue seems to be related to this line in multiprocessing Queue:

File "/usr/local/lib/python3.6/multiprocessing/queues.py", line 82 in put

    def put(self, obj, block=True, timeout=None):
        assert not self._closed
        if not self._sem.acquire(block, timeout):     # THIS ONE
            raise Full

        with self._notempty:
            if self._thread is None:
                self._start_thread()
            self._buffer.append(obj)
            self._notempty.notify()

Is there a specific Linux behavior that i'm missing here ?
Just to be sure it wasn't coming from my consumer I didn't start the process consuming from the queue (in case it came from a Lock issue) so only this process runs and no other code is used for the test.

Best regards,
Julien Stegle

----------
messages: 382629
nosy: julien.stegle
priority: normal
severity: normal
status: open
title: Segmentation fault on Linux with multiprocess queue
type: crash
versions: Python 3.6, Python 3.8

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

From report at bugs.python.org  Mon Dec  7 07:50:41 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 07 Dec 2020 12:50:41 +0000
Subject: [issue42532] spec_arg's __bool__ is called while initializing
 NonCallableMock
In-Reply-To: <1606998026.09.0.31549028921.issue42532@roundup.psfhosted.org>
Message-ID: <1607345441.51.0.627264973321.issue42532@roundup.psfhosted.org>


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


----------
pull_requests: +22542
pull_request: https://github.com/python/cpython/pull/23676

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

From report at bugs.python.org  Mon Dec  7 08:10:34 2020
From: report at bugs.python.org (Irit Katriel)
Date: Mon, 07 Dec 2020 13:10:34 +0000
Subject: [issue28964] AST literal_eval exceptions provide no information about
 line number
In-Reply-To: <1481665664.26.0.256194535172.issue28964@psf.upfronthosting.co.za>
Message-ID: <1607346634.88.0.762017786947.issue28964@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
pull_requests: +22543
pull_request: https://github.com/python/cpython/pull/23677

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

From report at bugs.python.org  Mon Dec  7 08:14:54 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Mon, 07 Dec 2020 13:14:54 +0000
Subject: [issue28964] AST literal_eval exceptions provide no information about
 line number
In-Reply-To: <1481665664.26.0.256194535172.issue28964@psf.upfronthosting.co.za>
Message-ID: <1607346894.2.0.625831191491.issue28964@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

> Usually literal_eval() is used with short one-line input. For what large documents do you use it?

I kind of agree with Serhiy on this, nearly every use case I've encountered was simple, single-line expression. Though, by seeing Irit's patch I think the implementation is reasonable enough to do.

----------
nosy: +BTaskaya

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

From report at bugs.python.org  Mon Dec  7 08:16:04 2020
From: report at bugs.python.org (Irit Katriel)
Date: Mon, 07 Dec 2020 13:16:04 +0000
Subject: [issue28964] AST literal_eval exceptions provide no information about
 line number
In-Reply-To: <1481665664.26.0.256194535172.issue28964@psf.upfronthosting.co.za>
Message-ID: <1607346964.83.0.210026947065.issue28964@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

This just came up again in issue42561 so I went ahead and created the PR.

----------

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

From report at bugs.python.org  Mon Dec  7 08:16:41 2020
From: report at bugs.python.org (Alex Writer)
Date: Mon, 07 Dec 2020 13:16:41 +0000
Subject: [issue40452] Tkinter/IDLE: preserve clipboard on closure
In-Reply-To: <1588268147.56.0.852233274654.issue40452@roundup.psfhosted.org>
Message-ID: <1607347001.21.0.661492724761.issue40452@roundup.psfhosted.org>


Alex Writer <alexwriter2003 at gmail.com> added the comment:

Testing with a minimal tkinter app (see code below) gives similar behavior, so this appears to be an issue with tkinter https://goo.gl/2DqXGj and/or tcl/tk.


import tkinter
text = tkinter.Text()

----------
nosy: +alexwriter2003

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

From report at bugs.python.org  Mon Dec  7 08:31:06 2020
From: report at bugs.python.org (Stegle, Julien)
Date: Mon, 07 Dec 2020 13:31:06 +0000
Subject: [issue42585] Segmentation fault on Linux with multiprocess queue
In-Reply-To: <1607339325.06.0.835049890466.issue42585@roundup.psfhosted.org>
Message-ID: <1607347866.04.0.279267551736.issue42585@roundup.psfhosted.org>


Stegle, Julien <Julien.Stegle at ge.com> added the comment:

By removing the use the of "spawn" context for multiprocessing everything works fine.
Does the "spawn" context have a different behavior on Linux ?

----------

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

From report at bugs.python.org  Mon Dec  7 08:31:34 2020
From: report at bugs.python.org (Valeriu Predoi)
Date: Mon, 07 Dec 2020 13:31:34 +0000
Subject: [issue42586] unittest.mock.Mock spec can't be array/ndarray in Python
 3.9
Message-ID: <1607347894.15.0.455977385218.issue42586@roundup.psfhosted.org>


New submission from Valeriu Predoi <valeriu.predoi at gmail.com>:

Hey guys, the new unittest.mock.Mock for Python 3.9 can not accept a spec arg if it is a numpy array, it'll accept all other types but not ndarray, have a look at this quick minimal code:

import numpy as np

from unittest import mock as mg

ob = mg.Mock(spec=[4, 4])
print("spec is list, mock is", ob)

ob = mg.Mock(spec=["4", "4"])
print("spec is list of str, mock is", ob)

ob = mg.Mock(spec=(4, 4))
print("spec is tuple, mock is", ob)

ob = mg.Mock(spec="cow")
print("spec is string, mock is", ob)

ob = mg.Mock(spec=22)
print("spec is int, mock is", ob)

ob = mg.Mock(spec=np.array([4, 4]))
print("spec is ndarray, mock is", ob)

versions:
python  3.9.0 h2a148a8_4_cpython    conda-forge
pytest-mock 3.3.1  pypi_0    pypi

Is this intended or it's a buggy-bug?

Cheers muchly! V

----------
components: Tests
messages: 382634
nosy: valeriupredoi
priority: normal
severity: normal
status: open
title: unittest.mock.Mock spec can't be array/ndarray in Python 3.9
type: behavior
versions: Python 3.9

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

From report at bugs.python.org  Mon Dec  7 08:37:38 2020
From: report at bugs.python.org (E. Paine)
Date: Mon, 07 Dec 2020 13:37:38 +0000
Subject: [issue40452] Tkinter/IDLE: preserve clipboard on closure
In-Reply-To: <1588268147.56.0.852233274654.issue40452@roundup.psfhosted.org>
Message-ID: <1607348258.36.0.41057719439.issue40452@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

Removed Alex from nosy because the link was an advertisement for an essay writer.

----------
nosy:  -alexwriter2003

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

From report at bugs.python.org  Mon Dec  7 08:38:46 2020
From: report at bugs.python.org (Tal Einat)
Date: Mon, 07 Dec 2020 13:38:46 +0000
Subject: [issue40452] Tkinter/IDLE: preserve clipboard on closure
In-Reply-To: <1588268147.56.0.852233274654.issue40452@roundup.psfhosted.org>
Message-ID: <1607348326.79.0.183918735873.issue40452@roundup.psfhosted.org>


Change by Tal Einat <taleinat+python at gmail.com>:


----------
Removed message: https://bugs.python.org/msg382632

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

From report at bugs.python.org  Mon Dec  7 08:39:20 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 07 Dec 2020 13:39:20 +0000
Subject: [issue42586] unittest.mock.Mock spec can't be array/ndarray in Python
 3.9
In-Reply-To: <1607347894.15.0.455977385218.issue42586@roundup.psfhosted.org>
Message-ID: <1607348360.94.0.762547042385.issue42586@roundup.psfhosted.org>


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

I don't have Python 3.9 with numpy to test this. Does this used to work with python 3.8? Does using numpy produce any error or traceback in 3.9?

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

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

From report at bugs.python.org  Mon Dec  7 08:50:11 2020
From: report at bugs.python.org (Valeriu Predoi)
Date: Mon, 07 Dec 2020 13:50:11 +0000
Subject: [issue42586] unittest.mock.Mock spec can't be array/ndarray in Python
 3.9
In-Reply-To: <1607347894.15.0.455977385218.issue42586@roundup.psfhosted.org>
Message-ID: <1607349011.56.0.645840846775.issue42586@roundup.psfhosted.org>


Valeriu Predoi <valeriu.predoi at gmail.com> added the comment:

Hello mate, yes it used to work fine with Python 3.8, no issue with Python 3.9 and numpy if you call mock as 

ob = mg.Mock(spec=np.array([4, 4]))

this results in a nice exception being raised:

Traceback (most recent call last):
  File "/home/valeriu/ESMValCore/tmock.py", line 20, in <module>
    ob = mg.Mock(spec=np.array([4, 4]))
  File "/home/valeriu/miniconda3/envs/esmvalcore39/lib/python3.9/unittest/mock.py", line 409, in __new__
    if spec_arg and _is_async_obj(spec_arg):
ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()

which is pretty normal since that func performs an existence check on an array - hope this helps! Cheers

----------

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

From report at bugs.python.org  Mon Dec  7 09:01:24 2020
From: report at bugs.python.org (Irit Katriel)
Date: Mon, 07 Dec 2020 14:01:24 +0000
Subject: [issue28964] AST literal_eval exceptions provide no information about
 line number
In-Reply-To: <1481665664.26.0.256194535172.issue28964@psf.upfronthosting.co.za>
Message-ID: <1607349684.26.0.553537055712.issue28964@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


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

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

From report at bugs.python.org  Mon Dec  7 09:13:43 2020
From: report at bugs.python.org (Kjartan Hrafnkelsson)
Date: Mon, 07 Dec 2020 14:13:43 +0000
Subject: [issue42583] JSON.dumps() creates invalid JSON with single quotes
In-Reply-To: <1607301132.51.0.662814441179.issue42583@roundup.psfhosted.org>
Message-ID: <1607350423.7.0.126530607213.issue42583@roundup.psfhosted.org>


Change by Kjartan Hrafnkelsson <george at bund.lu>:


----------
stage:  -> resolved
status: pending -> closed

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

From report at bugs.python.org  Mon Dec  7 09:34:25 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 07 Dec 2020 14:34:25 +0000
Subject: [issue42586] unittest.mock.Mock spec can't be array/ndarray in Python
 3.9
In-Reply-To: <1607347894.15.0.455977385218.issue42586@roundup.psfhosted.org>
Message-ID: <1607351665.96.0.227056450866.issue42586@roundup.psfhosted.org>


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

Thanks, this looks like a duplicate of https://bugs.python.org/issue42532

----------

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

From report at bugs.python.org  Mon Dec  7 09:37:15 2020
From: report at bugs.python.org (mattip)
Date: Mon, 07 Dec 2020 14:37:15 +0000
Subject: [issue39825] EXT_SUFFIX inconsistent between sysconfig and
 distutils.sysconfig (Windows)
In-Reply-To: <1583156407.62.0.364374237882.issue39825@roundup.psfhosted.org>
Message-ID: <1607351835.37.0.349951558274.issue39825@roundup.psfhosted.org>


mattip <matti.picus at gmail.com> added the comment:

the PR is awaiting approval/merge

----------

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

From report at bugs.python.org  Mon Dec  7 09:40:15 2020
From: report at bugs.python.org (Valeriu Predoi)
Date: Mon, 07 Dec 2020 14:40:15 +0000
Subject: [issue42586] unittest.mock.Mock spec can't be array/ndarray in Python
 3.9
In-Reply-To: <1607347894.15.0.455977385218.issue42586@roundup.psfhosted.org>
Message-ID: <1607352015.26.0.362641063354.issue42586@roundup.psfhosted.org>


Valeriu Predoi <valeriu.predoi at gmail.com> added the comment:

Indeed so! Sorry, I only glossed over that one before posting mine, now that I looked at it more carefully you are right, it does need a check on None and not calling the __bool__ member, which is affecting functionally passing an ndarray as spec - what should I do with my issue, close it? Cheers muchly!

----------

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

From report at bugs.python.org  Mon Dec  7 09:45:50 2020
From: report at bugs.python.org (Valeriu Predoi)
Date: Mon, 07 Dec 2020 14:45:50 +0000
Subject: [issue42586] unittest.mock.Mock spec can't be array/ndarray in Python
 3.9
In-Reply-To: <1607347894.15.0.455977385218.issue42586@roundup.psfhosted.org>
Message-ID: <1607352350.16.0.45824916154.issue42586@roundup.psfhosted.org>


Valeriu Predoi <valeriu.predoi at gmail.com> added the comment:

Note however, that the need I have for my type of functionality is fulfilled and all works fine for Python 3.7 and 3.8, I noticed the problem only for 3.9 - the OP in that issue says their versions affected include 3.8 (maybe it creeps up for 3.8.6 or larger, I tested with 3.8.5). Cheers!

----------

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

From report at bugs.python.org  Mon Dec  7 09:56:17 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 07 Dec 2020 14:56:17 +0000
Subject: [issue42586] unittest.mock.Mock spec can't be array/ndarray in Python
 3.9
In-Reply-To: <1607347894.15.0.455977385218.issue42586@roundup.psfhosted.org>
Message-ID: <1607352977.96.0.782032970281.issue42586@roundup.psfhosted.org>


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

It's a problem with 3.9 only as far as I know. The fix has been merged to master (3.10) and 3.9 . I will check with 3.8 but I don't think it will be a problem since 3.8 has a different code path. You can check the PR merged for more discussion.

----------

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

From report at bugs.python.org  Mon Dec  7 10:00:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Dec 2020 15:00:21 +0000
Subject: [issue42587] test_buffer fails on Python built with GCC 11
Message-ID: <1607353221.74.0.500162368406.issue42587@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

PPC64LE Fedora Rawhide LTO 3.x:
https://buildbot.python.org/all/#/builders/448/builds/433

FAIL: test_memoryview_cast (test.test_buffer.TestBufferProtocol)
FAIL: test_memoryview_cast_1D_ND (test.test_buffer.TestBufferProtocol)
FAIL: test_memoryview_compare_random_formats (test.test_buffer.TestBufferProtocol)
FAIL: test_ndarray_format_shape (test.test_buffer.TestBufferProtocol)
FAIL: test_ndarray_format_strides (test.test_buffer.TestBufferProtocol)
FAIL: test_ndarray_getbuf (test.test_buffer.TestBufferProtocol)
FAIL: test_ndarray_index_getitem_single (test.test_buffer.TestBufferProtocol)
FAIL: test_ndarray_random (test.test_buffer.TestBufferProtocol)
FAIL: test_ndarray_slice_assign_single (test.test_buffer.TestBufferProtocol)

Example:

FAIL: test_ndarray_slice_assign_single (test.test_buffer.TestBufferProtocol)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.cstratak-fedora-rawhide-ppc64le.lto/build/Lib/test/test_buffer.py", line 1836, in test_ndarray_slice_assign_single
    self.assertEqual(mv, nd)
AssertionError: <memory at 0x7fff80e51dc0> != <ndarray object at 0x7fff80c35030>

----------
components: Tests
messages: 382643
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_buffer fails on Python built with GCC 11
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Mon Dec  7 10:05:07 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Dec 2020 15:05:07 +0000
Subject: [issue42587] test_buffer fails on Python built with GCC 11
In-Reply-To: <1607353221.74.0.500162368406.issue42587@roundup.psfhosted.org>
Message-ID: <1607353507.88.0.160919586795.issue42587@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

On Python 3.6/x86-64, Python does crash in libregrtest while loading test_code:

0:01:13 load avg: 2.23 [ 56/406] test_code

Fatal Python error: Segmentation fault
Current thread 0x00007f5a6864d740 (most recent call first):
  File "/builddir/build/BUILD/Python-3.6.12/Lib/test/test_code.py", line 288 in <module>
  File "<frozen importlib._bootstrap>", line 219 in _call_with_frames_removed
  File "<frozen importlib._bootstrap_external>", line 678 in exec_module
  File "<frozen importlib._bootstrap>", line 665 in _load_unlocked
  File "<frozen importlib._bootstrap>", line 955 in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 971 in _find_and_load
  File "<frozen importlib._bootstrap>", line 994 in _gcd_import
  File "/builddir/build/BUILD/Python-3.6.12/Lib/importlib/__init__.py", line 126 in import_module
  (...)

On Python 3.5/x86-64, test_ctypes.test_callbacks() crashs with a SIGSEGV:

test_callbacks (ctypes.test.test_as_parameter.AsParamPropertyWrapperTestCase) ...

Fatal Python error: Segmentation fault
Current thread 0x00007f5de8322740 (most recent call first):
  File "/builddir/build/BUILD/Python-3.5.10/Lib/ctypes/test/test_as_parameter.py", line 90 in test_callbacks

The strange part is that the test suite pass on some platforms depending on the Python version.

It might be a GCC 11 regression.

----------

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

From report at bugs.python.org  Mon Dec  7 10:08:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Dec 2020 15:08:16 +0000
Subject: [issue42587] test_buffer fails on Python built with GCC 11
In-Reply-To: <1607353221.74.0.500162368406.issue42587@roundup.psfhosted.org>
Message-ID: <1607353696.91.0.867908787083.issue42587@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Copy of Miro Hron?ok's email to Fedora python-devel list:

https://lists.fedoraproject.org/archives/list/python-devel at lists.fedoraproject.org/thread/ADKCB6HXGZHJPYX5LSJ7422FITYSOAL3/

----
Hello.

I've been notified that many of the Python interpreters started to fail with new 
GNU Toolchain (gcc 11, glibc 2.33).

https://koschei.fedoraproject.org/package/pythonX.Y (replace X.Y with version)

Python 3.5
  - test_buffer fails on aarch64
  - test_buffer+test_dbm_gnu fails on ppc64le
  - %check segafults on x86_64

Python 3.6
  - %check segafults on x86_64
  - test_buffer fails on aarch64

Python 3.7
  - test_buffer fails on aarch64+ppc64le

Python 3.8
  - seems to build fine

Python 3.9
  - test_buffer fails on aarch64+ppc64le

Python 3.10
  - seems to build fine

PyPys have not yet been collected by Koschei, Python 2.7 seems fine.
----


Python is built with LTO+PGO on Fedora.

----------

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

From report at bugs.python.org  Mon Dec  7 10:12:39 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Dec 2020 15:12:39 +0000
Subject: [issue42587] test_buffer fails on Python built with GCC 11
In-Reply-To: <1607353221.74.0.500162368406.issue42587@roundup.psfhosted.org>
Message-ID: <1607353959.11.0.717710512375.issue42587@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

test_buffer also fails with GCC 11 on Python 3.8 built without LTO nor PGO, just -Og (./configure --enable-pydebug).

PPC64LE Fedora Rawhide Refleaks 3.8:
https://buildbot.python.org/all/#/builders/398/builds/101

test.pythoninfo:

sysconfig[CFLAGS]: -Wno-unused-result -Wsign-compare -g -Og -Wall

sysconfig[PY_CFLAGS]: -Wno-unused-result -Wsign-compare -g -Og -Wall

sysconfig[PY_CFLAGS_NODIST]: -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -I./Include/internal

sysconfig[PY_STDMODULE_CFLAGS]: -Wno-unused-result -Wsign-compare -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

Note: I'm not sure why test.pythoninfo didn't log LDFLAGS? It's supposed to log them.

----------

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

From report at bugs.python.org  Mon Dec  7 10:13:10 2020
From: report at bugs.python.org (Ran Benita)
Date: Mon, 07 Dec 2020 15:13:10 +0000
Subject: [issue42588] Improvements to
 graphlib.TopologicalSorter.static_order() documentation
Message-ID: <1607353990.94.0.818492776719.issue42588@roundup.psfhosted.org>


New submission from Ran Benita <ran at unusedvar.com>:

One issue and one suggestion.

Issue:

The documentation of prepare() says:

> If any cycle is detected, CycleError will be raised

which is what happens. The documentation of static_order() says that static_order() is equivalent to:

def static_order(self):
    self.prepare()
    while self.is_active():
        node_group = self.get_ready()
        yield from node_group
        self.done(*node_group)

specifically it is said to call self.prepare(), and also says

> If any cycle is detected, CycleError will be raised.

But, this only happens when the result of static_order is *iterated*, not when it's called, unlike what is suggested by the code and the comment.

Ideally, I think the call should raise the CycleError already if possible; this way, only the call can be wrapped in a try/except instead of the entire iteration. But if not, it should be clarified in the documentation.


Suggestion:

The documentation of static_order() says

> Returns an iterable of nodes in a topological order. Using this method does not require to call TopologicalSorter.prepare() or TopologicalSorter.done().

I think the wording "does not require" still implies that they *can* be called, but really they can't. If prepare() is called before static_order(), then when static_order() is iterated, "ValueError: cannot prepare() more than once" is raised.

I suggest this wording:

Returns an iterable of nodes in a topological order. When using this method, TopologicalSorter.prepare() and TopologicalSorter.done() should not be called.

----------
assignee: docs at python
components: Documentation
messages: 382647
nosy: bluetech, docs at python
priority: normal
severity: normal
status: open
title: Improvements to graphlib.TopologicalSorter.static_order() documentation
versions: Python 3.10, Python 3.9

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

From report at bugs.python.org  Mon Dec  7 10:21:00 2020
From: report at bugs.python.org (Ran Benita)
Date: Mon, 07 Dec 2020 15:21:00 +0000
Subject: [issue42588] Improvements to
 graphlib.TopologicalSorter.static_order() documentation
In-Reply-To: <1607353990.94.0.818492776719.issue42588@roundup.psfhosted.org>
Message-ID: <1607354460.74.0.517862935123.issue42588@roundup.psfhosted.org>


Ran Benita <ran at unusedvar.com> added the comment:

Hmm I realize after the fact that since the equivalent code snippet (which is actually the implementation) is a generator, then it is actually correct that prepare() isn't called until it is iterated. So the documentation for this is not incorrect.

Still, I think it would be better if the prepare() executes immediately rather than in the first iteration.

----------

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

From report at bugs.python.org  Mon Dec  7 10:53:35 2020
From: report at bugs.python.org (Irit Katriel)
Date: Mon, 07 Dec 2020 15:53:35 +0000
Subject: [issue42589] doc: Wrong "from" keyword link in Exceptions doc
Message-ID: <1607356415.63.0.620558354489.issue42589@roundup.psfhosted.org>


New submission from Irit Katriel <iritkatriel at yahoo.com>:

In the Exceptions doc:
https://docs.python.org/3/library/exceptions.html#built-in-exceptions

In the sentence 
"The expression following from must be an exception or None."

"from" is a keyword which links to
https://docs.python.org/3/reference/simple_stmts.html#from

But that is related to the from in "from X import Y" rather than "raise X from Y".

----------
assignee: docs at python
components: Documentation
messages: 382649
nosy: docs at python, iritkatriel
priority: normal
severity: normal
status: open
title: doc: Wrong "from" keyword link in Exceptions doc
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

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

From report at bugs.python.org  Mon Dec  7 10:56:57 2020
From: report at bugs.python.org (Jakub Stasiak)
Date: Mon, 07 Dec 2020 15:56:57 +0000
Subject: =?utf-8?q?=5Bissue42590=5D_Something_like_Rust=27s_std=3A=3Async=3A=3AMut?=
 =?utf-8?q?ex_=E2=80=93_combining_a_mutex_primitive_and_a_piece_of_data_it?=
 =?utf-8?q?=27s_protecting?=
Message-ID: <1607356617.55.0.274484392105.issue42590@roundup.psfhosted.org>


New submission from Jakub Stasiak <jakub+python.org at stasiak.at>:

I've been wondering if it's worth it to have something like Rust's std::sync::Mutex[1] which is used like this:

    let data = Mutex::new(0);
    {
        let mut unlocked = data.lock().unwrap();
        *unlocked += 1;
    }
    // unlocked is no longer available here, we need to use data.lock() again


Our (Python) [R]Lock is typically used like this:

    data_to_protect = whatever()
    lock = Lock()

    # ...
    with lock:
        data_to_protect.do_something()


The inconvenience of this is obvious to me and it's more error prone if one forgets the lock when accessing data_to_protect. I wrote a quick prototype to get something like Mutex in Python:

    import threading
    from contextlib import contextmanager
    from typing import Any, cast, Dict, Generator, Generic, Optional, TypeVar

    T = TypeVar('T')


    class LockedData(Generic[T]):
        def __init__(self, data: T, lock: Any = None) -> None:
            self._data = data
            if lock is None:
                lock = threading.Lock()
            self._lock = lock

        @contextmanager
        def unlocked(self, timeout: float = -1.0) -> Generator[T, None, None]:
            acquired = None
            unlocked = None
            try:
                acquired = self._lock.acquire(timeout=timeout)
                if acquired is False:
                    raise LockTimeout()
                unlocked = UnlockResult(self._data)
                yield unlocked
            finally:
                if acquired is True:
                    if unlocked is not None:
                        unlocked._unlocked = False
                        self._data = unlocked._data
                        unlocked._data = None
                    self._lock.release()


    class UnlockResult(Generic[T]):
        _data: Optional[T]

        def __init__(self, data: T) -> None:
            self._data = data
            self._unlocked = True

        @property
        def data(self) -> T:
            assert self._unlocked
            return cast(T, self._data)

        @data.setter
        def data(self, data: T) -> None:
            assert self._unlocked
            self._data = data


    class LockTimeout(Exception):
        pass


    if __name__ == '__main__':
        locked_dict: LockedData[Dict[str, bool]] = LockedData({})

        # Mutating the dictionary
        with locked_dict.unlocked() as result:
            result.data['hello'] = True

        with locked_dict.unlocked() as result:
            print(result.data)

        # Replacing the dictionary
        with locked_dict.unlocked() as result:
            result.data = {'a': True, 'b': False}

        with locked_dict.unlocked() as result:
            print(result.data)

        # Trying to access data after context closes
        print(result._data)
        print(result.data)

Now this is obviously quite far from what Rust offers, as there's nothing to prevent a person from doing something like this:

        with locked_dict.unlocked() as result:
            data = result.data

        print('Oh no, look: %r' % (data,))
        
but it seems to me it's still an improvement.


[1] https://doc.rust-lang.org/std/sync/struct.Mutex.html

----------
components: Library (Lib)
messages: 382650
nosy: benjamin.peterson, jstasiak, pitrou, vstinner
priority: normal
severity: normal
status: open
title: Something like Rust's std::sync::Mutex ? combining a mutex primitive and a piece of data it's protecting
type: enhancement
versions: Python 3.10

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

From report at bugs.python.org  Mon Dec  7 11:00:33 2020
From: report at bugs.python.org (Christian Bachmaier)
Date: Mon, 07 Dec 2020 16:00:33 +0000
Subject: [issue42591] Method Py_FrozenMain missing in libpython3.9
Message-ID: <1607356833.89.0.498069278584.issue42591@roundup.psfhosted.org>


New submission from Christian Bachmaier <chris at infosun.fim.uni-passau.de>:

In Python 3.9.0 and 3.9.1rc1 (Packages from Ubuntu Devel Branch or Fedora) the Method
int Py_FrozenMain(int, char**)
is missing in libpython3.9.so

Thus, when trying the provided freeze example via
freeze.py hello.py & make
one gets the linker error
/usr/bin/ld: frozen.o: in function `main': frozen/frozen.c:681: undefined reference to `Py_FrozenMain' .

In previous Python 3.8.x the bug does not show.

Thanks,
Chris

----------
components: C API
messages: 382651
nosy: chba
priority: normal
severity: normal
status: open
title: Method Py_FrozenMain missing in libpython3.9
versions: Python 3.9

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

From report at bugs.python.org  Mon Dec  7 11:02:29 2020
From: report at bugs.python.org (Christian Bachmaier)
Date: Mon, 07 Dec 2020 16:02:29 +0000
Subject: [issue42591] Method Py_FrozenMain missing in libpython3.9
In-Reply-To: <1607356833.89.0.498069278584.issue42591@roundup.psfhosted.org>
Message-ID: <1607356949.69.0.00195052509681.issue42591@roundup.psfhosted.org>


Change by Christian Bachmaier <chris at infosun.fim.uni-passau.de>:


----------
components: +Library (Lib) -C API

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

From report at bugs.python.org  Mon Dec  7 11:13:30 2020
From: report at bugs.python.org (Valeriu Predoi)
Date: Mon, 07 Dec 2020 16:13:30 +0000
Subject: [issue42586] unittest.mock.Mock spec can't be array/ndarray in Python
 3.9
In-Reply-To: <1607347894.15.0.455977385218.issue42586@roundup.psfhosted.org>
Message-ID: <1607357610.31.0.769146539978.issue42586@roundup.psfhosted.org>


Valeriu Predoi <valeriu.predoi at gmail.com> added the comment:

Great, cheers mate, I read through the PR's (and sorry to have pestered you over at the mock backport GitHub too haha) - this looks it will fix the issue nicely. Do you know when will the release be available for us using Python from Anaconda etc.? Feel free to close this, and thanks for the assistance! Cheers, V

----------

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

From report at bugs.python.org  Mon Dec  7 11:18:11 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 07 Dec 2020 16:18:11 +0000
Subject: [issue42586] unittest.mock.Mock spec can't be array/ndarray in Python
 3.9
In-Reply-To: <1607347894.15.0.455977385218.issue42586@roundup.psfhosted.org>
Message-ID: <1607357891.04.0.826453749595.issue42586@roundup.psfhosted.org>


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

3.9.1 is in RC1 as per https://www.python.org/dev/peps/pep-0596/#lifespan . It will be available as part of 3.9.1 or 3.9.2 . I am not sure about anaconda packaging schedule though.

----------

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

From report at bugs.python.org  Mon Dec  7 11:20:19 2020
From: report at bugs.python.org (Valeriu Predoi)
Date: Mon, 07 Dec 2020 16:20:19 +0000
Subject: [issue42586] unittest.mock.Mock spec can't be array/ndarray in Python
 3.9
In-Reply-To: <1607347894.15.0.455977385218.issue42586@roundup.psfhosted.org>
Message-ID: <1607358019.61.0.326206142472.issue42586@roundup.psfhosted.org>


Valeriu Predoi <valeriu.predoi at gmail.com> added the comment:

Excellent, just gonna let my team know about this and we'll hold off on 3.9.0 then - good stuff, mate!

----------

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

From report at bugs.python.org  Mon Dec  7 11:24:29 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 07 Dec 2020 16:24:29 +0000
Subject: [issue42588] Improvements to
 graphlib.TopologicalSorter.static_order() documentation
In-Reply-To: <1607353990.94.0.818492776719.issue42588@roundup.psfhosted.org>
Message-ID: <1607358269.5.0.036033065115.issue42588@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +pablogsal, rhettinger, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42588>
_______________________________________

From report at bugs.python.org  Mon Dec  7 11:37:20 2020
From: report at bugs.python.org (Valeriu Predoi)
Date: Mon, 07 Dec 2020 16:37:20 +0000
Subject: [issue42586] unittest.mock.Mock spec can't be array/ndarray in Python
 3.9
In-Reply-To: <1607347894.15.0.455977385218.issue42586@roundup.psfhosted.org>
Message-ID: <1607359040.85.0.0310717958591.issue42586@roundup.psfhosted.org>


Change by Valeriu Predoi <valeriu.predoi at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42586>
_______________________________________

From report at bugs.python.org  Mon Dec  7 11:38:28 2020
From: report at bugs.python.org (Valeriu Predoi)
Date: Mon, 07 Dec 2020 16:38:28 +0000
Subject: [issue42586] unittest.mock.Mock spec can't be array/ndarray in Python
 3.9
In-Reply-To: <1607347894.15.0.455977385218.issue42586@roundup.psfhosted.org>
Message-ID: <1607359108.16.0.929999783959.issue42586@roundup.psfhosted.org>


Valeriu Predoi <valeriu.predoi at gmail.com> added the comment:

Changed status to pending, will close once we've had 3.9.1 in our env and tested proper, but should be OK, cheers!

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42586>
_______________________________________

From report at bugs.python.org  Mon Dec  7 11:44:42 2020
From: report at bugs.python.org (Irit Katriel)
Date: Mon, 07 Dec 2020 16:44:42 +0000
Subject: [issue23915] [doc] traceback set with BaseException.with_traceback()
 pushed back on raise
In-Reply-To: <1428769760.16.0.251757749986.issue23915@psf.upfronthosting.co.za>
Message-ID: <1607359482.76.0.79295659515.issue23915@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
nosy: +iritkatriel
nosy_count: 5.0 -> 6.0
pull_requests: +22544
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/23680

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23915>
_______________________________________

From report at bugs.python.org  Mon Dec  7 11:48:16 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 07 Dec 2020 16:48:16 +0000
Subject: [issue42573] Installation of Python 3.9 failing with message "User
 cancelled installation"
In-Reply-To: <1607167348.75.0.906880980974.issue42573@roundup.psfhosted.org>
Message-ID: <1607359696.14.0.778236501161.issue42573@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Can you try disabling any security/anti-malware software you have running? That's normally the only thing (besides a user) that will cause this error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42573>
_______________________________________

From report at bugs.python.org  Mon Dec  7 11:48:10 2020
From: report at bugs.python.org (Irit Katriel)
Date: Mon, 07 Dec 2020 16:48:10 +0000
Subject: [issue23915] [doc] traceback set with BaseException.with_traceback()
 pushed back on raise
In-Reply-To: <1428769760.16.0.251757749986.issue23915@psf.upfronthosting.co.za>
Message-ID: <1607359690.23.0.33985137185.issue23915@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

The new PR has an alternative suggestion for a change, where I tried to incorporate both Travis's and David's points: (1) there are better alternatives now for exception chaining (2) the current frame gets pushed on the traceback when the exception is raised.

----------
stage: patch review -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23915>
_______________________________________

From report at bugs.python.org  Mon Dec  7 11:50:01 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 07 Dec 2020 16:50:01 +0000
Subject: [issue42569] Callers of _Py_fopen/_Py_wfopen may be broken after
 addition of audit hooks
In-Reply-To: <1607098353.32.0.624763724813.issue42569@roundup.psfhosted.org>
Message-ID: <1607359801.04.0.414502910012.issue42569@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Good point, we can make it set errno as well. Any generic error is fine (I don't know them off the top of my head), because it will chain up to the one set by the hook.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42569>
_______________________________________

From report at bugs.python.org  Mon Dec  7 12:25:13 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Mon, 07 Dec 2020 17:25:13 +0000
Subject: [issue42574] Travis can't build the 3.8 branch right now
In-Reply-To: <1607149839.2.0.378125476647.issue42574@roundup.psfhosted.org>
Message-ID: <1607361913.26.0.765134031976.issue42574@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

Pablo, maybe you can shed some light on this. It looks like the PEG parser PR explicitly sets PYTHON_FOR_REGEN=python3.8 using pyenv in .travis.yml for the master (and now 3.9) branches. The change was made in the we-like-parsers repo here:

https://github.com/we-like-parsers/cpython/pull/88

Should we be doing this in the other branches as well?

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42574>
_______________________________________

From report at bugs.python.org  Mon Dec  7 12:33:36 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 07 Dec 2020 17:33:36 +0000
Subject: [issue39825] EXT_SUFFIX inconsistent between sysconfig and
 distutils.sysconfig (Windows)
In-Reply-To: <1583156407.62.0.364374237882.issue39825@roundup.psfhosted.org>
Message-ID: <1607362416.5.0.216846784989.issue39825@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:


New changeset c0afb7fa0ebd1c0e95c0760bbe75a99a8dd12ea6 by Matti Picus in branch 'master':
bpo-39825: Fixes sysconfig.get_config_var('EXT_SUFFIX') on Windows to match distutils (GH-22088)
https://github.com/python/cpython/commit/c0afb7fa0ebd1c0e95c0760bbe75a99a8dd12ea6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39825>
_______________________________________

From report at bugs.python.org  Mon Dec  7 12:33:58 2020
From: report at bugs.python.org (Steve Dower)
Date: Mon, 07 Dec 2020 17:33:58 +0000
Subject: [issue39825] EXT_SUFFIX inconsistent between sysconfig and
 distutils.sysconfig (Windows)
In-Reply-To: <1583156407.62.0.364374237882.issue39825@roundup.psfhosted.org>
Message-ID: <1607362438.56.0.857123192592.issue39825@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Thanks!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39825>
_______________________________________

From report at bugs.python.org  Mon Dec  7 12:34:09 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 07 Dec 2020 17:34:09 +0000
Subject: [issue39825] EXT_SUFFIX inconsistent between sysconfig and
 distutils.sysconfig (Windows)
In-Reply-To: <1583156407.62.0.364374237882.issue39825@roundup.psfhosted.org>
Message-ID: <1607362449.49.0.579578876089.issue39825@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 10.0 -> 11.0
pull_requests: +22545
pull_request: https://github.com/python/cpython/pull/23681

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39825>
_______________________________________

From report at bugs.python.org  Mon Dec  7 12:34:17 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 07 Dec 2020 17:34:17 +0000
Subject: [issue39825] EXT_SUFFIX inconsistent between sysconfig and
 distutils.sysconfig (Windows)
In-Reply-To: <1583156407.62.0.364374237882.issue39825@roundup.psfhosted.org>
Message-ID: <1607362457.99.0.813925464413.issue39825@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22546
pull_request: https://github.com/python/cpython/pull/23682

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39825>
_______________________________________

From report at bugs.python.org  Mon Dec  7 12:36:35 2020
From: report at bugs.python.org (Paul Bryan)
Date: Mon, 07 Dec 2020 17:36:35 +0000
Subject: [issue42592] TypedDict: total=False but still key required
Message-ID: <1607362595.41.0.679668494764.issue42592@roundup.psfhosted.org>


New submission from Paul Bryan <pbryan at anode.ca>:

I believe "a" below should be an optional key, not a required one.

Python 3.9.0 (default, Oct  7 2020, 23:09:01) 
[GCC 10.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import typing
>>> TD = typing.TypedDict("TD", {"a": str}, total=False)
>>> TD.__total__
False
>>> TD.__required_keys__
frozenset({'a'})
>>> TD.__optional_keys__
frozenset()
>>>

----------
components: Library (Lib)
messages: 382662
nosy: gvanrossum, pbryan
priority: normal
severity: normal
status: open
title: TypedDict: total=False but still key required
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42592>
_______________________________________

From report at bugs.python.org  Mon Dec  7 12:50:58 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 07 Dec 2020 17:50:58 +0000
Subject: [issue39825] EXT_SUFFIX inconsistent between sysconfig and
 distutils.sysconfig (Windows)
In-Reply-To: <1583156407.62.0.364374237882.issue39825@roundup.psfhosted.org>
Message-ID: <1607363458.16.0.745979226453.issue39825@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset ca52aa3ddd949ce2d259b4263344339b56db00b7 by Miss Islington (bot) in branch '3.8':
bpo-39825: Fixes sysconfig.get_config_var('EXT_SUFFIX') on Windows to match distutils (GH-22088)
https://github.com/python/cpython/commit/ca52aa3ddd949ce2d259b4263344339b56db00b7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39825>
_______________________________________

From report at bugs.python.org  Mon Dec  7 12:57:00 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 07 Dec 2020 17:57:00 +0000
Subject: [issue39825] EXT_SUFFIX inconsistent between sysconfig and
 distutils.sysconfig (Windows)
In-Reply-To: <1583156407.62.0.364374237882.issue39825@roundup.psfhosted.org>
Message-ID: <1607363820.21.0.879613808684.issue39825@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e9a6dcdefabb6c19074566f4ee0e02daaf57be18 by Miss Islington (bot) in branch '3.9':
bpo-39825: Fixes sysconfig.get_config_var('EXT_SUFFIX') on Windows to match distutils (GH-22088)
https://github.com/python/cpython/commit/e9a6dcdefabb6c19074566f4ee0e02daaf57be18


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39825>
_______________________________________

From report at bugs.python.org  Mon Dec  7 13:08:38 2020
From: report at bugs.python.org (hai shi)
Date: Mon, 07 Dec 2020 18:08:38 +0000
Subject: [issue40600] Add option to disallow > 1 instance of an extension
 module
In-Reply-To: <1589235149.46.0.0630975096351.issue40600@roundup.psfhosted.org>
Message-ID: <1607364518.91.0.59172596611.issue40600@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

>On the other side, defining a Py_mod_exec_once that supports execution > >for just once can be a way.
>Although the usage is little, it will be fine because the use case will >exist.

IMHO, `Py_mod_exec_once` is more like a slot control flag. MAYBE we need add a module flag in `PyModuleDef`.

----------
versions: +Python 3.10 -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40600>
_______________________________________

From report at bugs.python.org  Mon Dec  7 13:11:49 2020
From: report at bugs.python.org (hai shi)
Date: Mon, 07 Dec 2020 18:11:49 +0000
Subject: [issue40600] Add option to disallow > 1 instance of an extension
 module
In-Reply-To: <1589235149.46.0.0630975096351.issue40600@roundup.psfhosted.org>
Message-ID: <1607364709.63.0.963314212719.issue40600@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
keywords: +patch
pull_requests: +22547
stage: test needed -> patch review
pull_request: https://github.com/python/cpython/pull/23683

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40600>
_______________________________________

From report at bugs.python.org  Mon Dec  7 13:12:08 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Mon, 07 Dec 2020 18:12:08 +0000
Subject: [issue42592] TypedDict: total=False but still key required
In-Reply-To: <1607362595.41.0.679668494764.issue42592@roundup.psfhosted.org>
Message-ID: <1607364728.28.0.0866836016003.issue42592@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

It looks like the issue is that _TypedDictMeta only respects "total" as a keyword argument to __new__, but the TypedDict function passes it along by setting __total__ in the generated namespace instead.

This fixes it:

diff --git a/Lib/typing.py b/Lib/typing.py
index 46c54c4..bb0696b 100644
--- a/Lib/typing.py
+++ b/Lib/typing.py
@@ -2050,7 +2050,7 @@ class body be required.
     except (AttributeError, ValueError):
         pass
 
-    return _TypedDictMeta(typename, (), ns)
+    return _TypedDictMeta(typename, (), ns, total=total)
 
 _TypedDict = type.__new__(_TypedDictMeta, 'TypedDict', (), {})
 TypedDict.__mro_entries__ = lambda bases: (_TypedDict,)

----------
nosy: +brandtbucher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42592>
_______________________________________

From report at bugs.python.org  Mon Dec  7 13:13:40 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Mon, 07 Dec 2020 18:13:40 +0000
Subject: [issue42592] TypedDict: total=False but still key required
In-Reply-To: <1607362595.41.0.679668494764.issue42592@roundup.psfhosted.org>
Message-ID: <1607364820.82.0.586338745059.issue42592@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

I can fix this, Paul, unless you want to take it. Probably deserves a regression test or two as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42592>
_______________________________________

From report at bugs.python.org  Mon Dec  7 13:14:19 2020
From: report at bugs.python.org (hai shi)
Date: Mon, 07 Dec 2020 18:14:19 +0000
Subject: [issue40600] Add option to disallow > 1 instance of an extension
 module
In-Reply-To: <1589235149.46.0.0630975096351.issue40600@roundup.psfhosted.org>
Message-ID: <1607364859.1.0.0807827292954.issue40600@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

> MAYBE we need add a module flag in `PyModuleDef`.
I created a demo in PR 23683.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40600>
_______________________________________

From report at bugs.python.org  Mon Dec  7 13:30:17 2020
From: report at bugs.python.org (Paul Bryan)
Date: Mon, 07 Dec 2020 18:30:17 +0000
Subject: [issue42592] TypedDict: total=False but still key required
In-Reply-To: <1607362595.41.0.679668494764.issue42592@roundup.psfhosted.org>
Message-ID: <1607365817.79.0.348699471346.issue42592@roundup.psfhosted.org>


Paul Bryan <pbryan at anode.ca> added the comment:

Your patch LGTM, Brandt.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42592>
_______________________________________

From report at bugs.python.org  Mon Dec  7 13:36:02 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 07 Dec 2020 18:36:02 +0000
Subject: [issue42574] Travis can't build the 3.8 branch right now
In-Reply-To: <1607149839.2.0.378125476647.issue42574@roundup.psfhosted.org>
Message-ID: <1607366162.53.0.226858713456.issue42574@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I am a bit confused....why is this failing now?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42574>
_______________________________________

From report at bugs.python.org  Mon Dec  7 13:49:09 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Mon, 07 Dec 2020 18:49:09 +0000
Subject: [issue42574] Travis can't build the 3.8 branch right now
In-Reply-To: <1607149839.2.0.378125476647.issue42574@roundup.psfhosted.org>
Message-ID: <1607366949.88.0.157327611087.issue42574@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

It has been failing for some time. It's just not a required check, so it's easy to miss on a backport branch.

I think the addition of an f-string in PR 23371 a few weeks ago is what started making this fail (since the system python can't run clinic anymore). It looks like it has been failing ever since.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42574>
_______________________________________

From report at bugs.python.org  Mon Dec  7 13:56:12 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Mon, 07 Dec 2020 18:56:12 +0000
Subject: [issue42574] Travis can't build the 3.8 branch right now
In-Reply-To: <1607149839.2.0.378125476647.issue42574@roundup.psfhosted.org>
Message-ID: <1607367372.97.0.684026206663.issue42574@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

So I suppose we can either:

- set PYTHON_FOR_REGEN to something 3.6+ on these backport branches
- use some other string formatting for that one line

I sort of prefer the second, since I *think* this is the only thing keeping older Pythons from working here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42574>
_______________________________________

From report at bugs.python.org  Mon Dec  7 14:01:17 2020
From: report at bugs.python.org (Ammar Askar)
Date: Mon, 07 Dec 2020 19:01:17 +0000
Subject: [issue42574] Travis can't build the 3.8 branch right now
In-Reply-To: <1607149839.2.0.378125476647.issue42574@roundup.psfhosted.org>
Message-ID: <1607367677.16.0.992786543928.issue42574@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

>From a quick glance at https://github.com/python/cpython/pulls?page=2&q=base%3A3.8+-label%3Atype-documentation

It looks like travis on 3.8 last passed at https://github.com/python/cpython/pull/23364 around 19 days ago

The culprit commit is likely https://github.com/python/cpython/commit/66dd5338a1ca98921c8e6c51228541ef8ed8076a from 19 days ago since it added the first bit of f-string syntax to clinic.py, it was committed directly without a PR which is likely why this wasn't caught.

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42574>
_______________________________________

From report at bugs.python.org  Mon Dec  7 14:02:11 2020
From: report at bugs.python.org (Irit Katriel)
Date: Mon, 07 Dec 2020 19:02:11 +0000
Subject: [issue39625] Traceback needs more details
In-Reply-To: <1581595814.35.0.681093135233.issue39625@roundup.psfhosted.org>
Message-ID: <1607367731.33.0.321064717899.issue39625@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> stack tracebacks should give the relevant class name

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39625>
_______________________________________

From report at bugs.python.org  Mon Dec  7 14:03:14 2020
From: report at bugs.python.org (Ammar Askar)
Date: Mon, 07 Dec 2020 19:03:14 +0000
Subject: [issue42574] Travis can't build the 3.8 branch right now
In-Reply-To: <1607149839.2.0.378125476647.issue42574@roundup.psfhosted.org>
Message-ID: <1607367794.62.0.753870826662.issue42574@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Oh whoops, got sniped by Brandt while investigating :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42574>
_______________________________________

From report at bugs.python.org  Mon Dec  7 14:11:26 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Mon, 07 Dec 2020 19:11:26 +0000
Subject: [issue42592] TypedDict: total=False but still key required
In-Reply-To: <1607362595.41.0.679668494764.issue42592@roundup.psfhosted.org>
Message-ID: <1607368286.58.0.902798388717.issue42592@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
assignee:  -> brandtbucher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42592>
_______________________________________

From report at bugs.python.org  Mon Dec  7 14:26:22 2020
From: report at bugs.python.org (Alexey Izbyshev)
Date: Mon, 07 Dec 2020 19:26:22 +0000
Subject: [issue42585] Segmentation fault on Linux with multiprocess queue
In-Reply-To: <1607339325.06.0.835049890466.issue42585@roundup.psfhosted.org>
Message-ID: <1607369182.61.0.631831712005.issue42585@roundup.psfhosted.org>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
components: +Library (Lib)
nosy: +davin, pitrou
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42585>
_______________________________________

From report at bugs.python.org  Mon Dec  7 14:37:13 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 07 Dec 2020 19:37:13 +0000
Subject: [issue42592] TypedDict: total=False but still key required
In-Reply-To: <1607362595.41.0.679668494764.issue42592@roundup.psfhosted.org>
Message-ID: <1607369833.63.0.367463388927.issue42592@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Some notes on needed TypedDict doc fixes.

https://docs.python.org/3/library/typing.html#typing.TypedDict

"class typing.TypedDict(dict)"

The actual signature from inspect.signature is "(typename, fields=None, /, *, total=True, **kwargs)".  I presume fields not None and kwargs != {} are mutually exclusive.  AFAIK, the kwargs version of the call alternative is not in PEP 589.

"The type info for introspection can be accessed via Point2D.__annotations__ and Point2D.__total__."

'__total__' is not indexed.  __required_keys__ and __optional_keys__ are neither documented (including not in the PEP, which does not get revised) nor indexed.

----------
nosy: +terry.reedy
stage:  -> test needed
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42592>
_______________________________________

From report at bugs.python.org  Mon Dec  7 14:50:16 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Mon, 07 Dec 2020 19:50:16 +0000
Subject: [issue42592] TypedDict: total=False but still key required
In-Reply-To: <1607362595.41.0.679668494764.issue42592@roundup.psfhosted.org>
Message-ID: <1607370616.03.0.732426609925.issue42592@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

It looks like this is a duplicate of issue 42059. We should just use their existing PR instead (PR 22736).

----------
resolution:  -> duplicate
stage: test needed -> resolved
status: open -> closed
superseder:  -> TypedDict(...) as function does not respect "total" when setting __required_keys__ and __optional_keys__

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42592>
_______________________________________

From report at bugs.python.org  Mon Dec  7 15:05:37 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 07 Dec 2020 20:05:37 +0000
Subject: [issue42579] Solution from gh#python/cpython#13236 unnecessarily
 binds building of documentation to the latest version of Sphinx
In-Reply-To: <1607204834.85.0.284068397188.issue42579@roundup.psfhosted.org>
Message-ID: <1607371537.8.0.778482354489.issue42579@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/issue42579>
_______________________________________

From report at bugs.python.org  Mon Dec  7 15:05:42 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 07 Dec 2020 20:05:42 +0000
Subject: [issue42579] Solution from gh#python/cpython#13236 unnecessarily
 binds building of documentation to the latest version of Sphinx
In-Reply-To: <1607204834.85.0.284068397188.issue42579@roundup.psfhosted.org>
Message-ID: <1607371542.25.0.868997630812.issue42579@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset b63a620014b67a6e63d10783149c41baaf59def8 by Mat?j Cepl in branch 'master':
bpo-42579: Make workaround for various versions of Sphinx more robust (GH-23662)
https://github.com/python/cpython/commit/b63a620014b67a6e63d10783149c41baaf59def8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42579>
_______________________________________

From report at bugs.python.org  Mon Dec  7 15:07:52 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 07 Dec 2020 20:07:52 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1607371672.59.0.298633023791.issue42536@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 60463e8e4f79e5b5e96dc43fb83ded373b489e33 by Brandt Bucher in branch '3.9':
bpo-42536: GC track recycled tuples (GH-23623) (GH-23651)
https://github.com/python/cpython/commit/60463e8e4f79e5b5e96dc43fb83ded373b489e33


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42536>
_______________________________________

From report at bugs.python.org  Mon Dec  7 15:08:28 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 07 Dec 2020 20:08:28 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1607371708.4.0.514151449417.issue42536@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 7c797982383ebfd9cca39c480dcf6132979dd06f by Brandt Bucher in branch '3.8':
bpo-42536: GC track recycled tuples (GH-23623) (GH-23652)
https://github.com/python/cpython/commit/7c797982383ebfd9cca39c480dcf6132979dd06f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42536>
_______________________________________

From report at bugs.python.org  Mon Dec  7 15:08:38 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 07 Dec 2020 20:08:38 +0000
Subject: [issue42536] Iterating on a zip keeps objects alive longer than
 expected (test_itertools leaks sometimes references)
In-Reply-To: <1606909715.58.0.318966724927.issue42536@roundup.psfhosted.org>
Message-ID: <1607371718.0.0.00620510294033.issue42536@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/issue42536>
_______________________________________

From report at bugs.python.org  Mon Dec  7 15:11:00 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 07 Dec 2020 20:11:00 +0000
Subject: [issue42574] Travis can't build the 3.8 branch right now
In-Reply-To: <1607149839.2.0.378125476647.issue42574@roundup.psfhosted.org>
Message-ID: <1607371860.32.0.395099646694.issue42574@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I would suggest to use some other string formatting for that one line. The reason is that technically (although very unlikely) downstream consumers could be relying on some old PYTHON_FOR_REGEN in the Makefile for 3.8 and I would not like to change that in a patch release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42574>
_______________________________________

From report at bugs.python.org  Mon Dec  7 15:13:23 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 07 Dec 2020 20:13:23 +0000
Subject: [issue42574] Travis can't build the 3.8 branch right now
In-Reply-To: <1607149839.2.0.378125476647.issue42574@roundup.psfhosted.org>
Message-ID: <1607372003.09.0.259143907649.issue42574@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +22548
pull_request: https://github.com/python/cpython/pull/23685

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42574>
_______________________________________

From report at bugs.python.org  Mon Dec  7 15:18:22 2020
From: report at bugs.python.org (syl-nktaylor)
Date: Mon, 07 Dec 2020 20:18:22 +0000
Subject: [issue42593] Consistency in unicode string multiplication with an
 integer
Message-ID: <1607372302.54.0.511899594666.issue42593@roundup.psfhosted.org>


New submission from syl-nktaylor <syl.nktaylor at gmail.com>:

In https://github.com/python/cpython/blob/master/Objects/unicodeobject.c#L12930, unicode_repeat does string multiplication with an integer in 3 different ways:
1) one memset call, for utf-8 when string size is 1
2) linear 'for' loops, for utf-16 and utf-32 when string size is 1
3) logarithmic 'while' loop with memcpy calls, for utf-8/utf-16/utf-32 when string size > 1 

Is there a performance or correctness reason for which we can't also use the 3rd way for the second case? I realise depending on architecture, the second case could benefit from vectorization, but the memcpy calls will also be hardware optimised.

An example of using just the 1st and 3rd methods:

--- a/Objects/unicodeobject.c
+++ b/Objects/unicodeobject.c
@@ -12954,31 +12954,16 @@ unicode_repeat(PyObject *str, Py_ssize_t len)
     assert(PyUnicode_KIND(u) == PyUnicode_KIND(str));

-    if (PyUnicode_GET_LENGTH(str) == 1) {
-        int kind = PyUnicode_KIND(str);
-        Py_UCS4 fill_char = PyUnicode_READ(kind, PyUnicode_DATA(str), 0);
-        if (kind == PyUnicode_1BYTE_KIND) {
-            void *to = PyUnicode_DATA(u);
-            memset(to, (unsigned char)fill_char, len);
-        }
-        else if (kind == PyUnicode_2BYTE_KIND) {
-            Py_UCS2 *ucs2 = PyUnicode_2BYTE_DATA(u);
-            for (n = 0; n < len; ++n)
-                ucs2[n] = fill_char;
-        } else {
-            Py_UCS4 *ucs4 = PyUnicode_4BYTE_DATA(u);
-            assert(kind == PyUnicode_4BYTE_KIND);
-            for (n = 0; n < len; ++n)
-                ucs4[n] = fill_char;
-        }
-    }
-    else {
+    Py_ssize_t char_size = PyUnicode_KIND(str);
+    char *to = (char *) PyUnicode_DATA(u);
+    if (PyUnicode_GET_LENGTH(str) == 1 && char_size == PyUnicode_1BYTE_KIND) {
+        Py_UCS4 fill_char = PyUnicode_READ(char_size, PyUnicode_DATA(str), 0);
+        memset(to, fill_char, len);
+    } else {
         /* number of characters copied this far */
         Py_ssize_t done = PyUnicode_GET_LENGTH(str);
-        Py_ssize_t char_size = PyUnicode_KIND(str);
-        char *to = (char *) PyUnicode_DATA(u);
         memcpy(to, PyUnicode_DATA(str),
                   PyUnicode_GET_LENGTH(str) * char_size);
         while (done < nchars) {...

----------
components: Unicode
messages: 382681
nosy: ezio.melotti, syl-nktaylor, vstinner
priority: normal
severity: normal
status: open
title: Consistency in unicode string multiplication with an integer
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42593>
_______________________________________

From report at bugs.python.org  Mon Dec  7 15:37:13 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 07 Dec 2020 20:37:13 +0000
Subject: [issue42593] Consistency in unicode string multiplication with an
 integer
In-Reply-To: <1607372302.54.0.511899594666.issue42593@roundup.psfhosted.org>
Message-ID: <1607373433.88.0.0539287766668.issue42593@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

BTW, CPython does not use UTF-8 and UTF-16 encoding in internal representation of strings. It uses Latin1, UCS2 and UCS4 (UTF-32).

What benchmarks show? Is your code always faster and how much? If it is slower for some data, for what data and how much?

----------
nosy: +serhiy.storchaka
type: behavior -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42593>
_______________________________________

From report at bugs.python.org  Mon Dec  7 15:41:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Dec 2020 20:41:40 +0000
Subject: [issue41462] os.set_blocking() raises OSError on VxWorks RTOS
In-Reply-To: <1596448427.12.0.91446561871.issue41462@roundup.psfhosted.org>
Message-ID: <1607373700.51.0.0011007180291.issue41462@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 06afac6c5740bb81d2b7ab9639d2b08cccf77d33 by pxinwr in branch 'master':
bpo-41462: Add os.set_blocking() support for VxWorks RTOS (GH-21713)
https://github.com/python/cpython/commit/06afac6c5740bb81d2b7ab9639d2b08cccf77d33


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41462>
_______________________________________

From report at bugs.python.org  Mon Dec  7 16:27:33 2020
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 07 Dec 2020 21:27:33 +0000
Subject: [issue26131] Raise ImportWarning when loader.load_module() is used
In-Reply-To: <1452894244.92.0.478987355259.issue26131@psf.upfronthosting.co.za>
Message-ID: <1607376453.79.0.435431548146.issue26131@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/issue26131>
_______________________________________

From report at bugs.python.org  Mon Dec  7 16:29:09 2020
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 07 Dec 2020 21:29:09 +0000
Subject: [issue42564] "from .__init__ import ..." syntax imports a duplicate
 module
In-Reply-To: <1607047912.32.0.654567376337.issue42564@roundup.psfhosted.org>
Message-ID: <1607376549.95.0.0157687862818.issue42564@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

You could propose your backwards-incompatible proposals on python-ideas, Greg, and see if you get any uptake.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42564>
_______________________________________

From report at bugs.python.org  Mon Dec  7 16:49:07 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Dec 2020 21:49:07 +0000
Subject: [issue39825] EXT_SUFFIX inconsistent between sysconfig and
 distutils.sysconfig (Windows)
In-Reply-To: <1583156407.62.0.364374237882.issue39825@roundup.psfhosted.org>
Message-ID: <1607377747.85.0.291369689246.issue39825@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

This change broke the AMD64 FreeBSD Shared 3.x buildbot:
https://buildbot.python.org/all/#/builders/483/builds/513

FAIL: test_EXT_SUFFIX_in_vars (test.test_sysconfig.TestSysConfig)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-564d/build/Lib/test/test_sysconfig.py", line 368, in test_EXT_SUFFIX_in_vars
    self.assertEqual(vars['EXT_SUFFIX'], _imp.extension_suffixes()[0])
AssertionError: '.so' != '.cpython-310d.so'
- .so
+ .cpython-310d.so

----------
nosy: +vstinner
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39825>
_______________________________________

From report at bugs.python.org  Mon Dec  7 16:50:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Dec 2020 21:50:33 +0000
Subject: [issue39825] EXT_SUFFIX inconsistent between sysconfig and
 distutils.sysconfig (Windows)
In-Reply-To: <1583156407.62.0.364374237882.issue39825@roundup.psfhosted.org>
Message-ID: <1607377833.03.0.312084462254.issue39825@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It also broke POWER6 AIX 3.8:
https://buildbot.python.org/all/#builders/138/builds/125

Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.8.aixtools-aix-power6/build/Lib/test/test_sysconfig.py", line 366, in test_EXT_SUFFIX_in_vars
    self.assertEqual(vars['EXT_SUFFIX'], _imp.extension_suffixes()[0])
AssertionError: '.so' != '.cpython-38d.so'
- .so
+ .cpython-38d.so

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39825>
_______________________________________

From report at bugs.python.org  Mon Dec  7 16:53:49 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Dec 2020 21:53:49 +0000
Subject: [issue41462] os.set_blocking() raises OSError on VxWorks RTOS
In-Reply-To: <1596448427.12.0.91446561871.issue41462@roundup.psfhosted.org>
Message-ID: <1607378029.16.0.804392333135.issue41462@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41462>
_______________________________________

From report at bugs.python.org  Mon Dec  7 16:53:35 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Dec 2020 21:53:35 +0000
Subject: [issue42593] Consistency in unicode string multiplication with an
 integer
In-Reply-To: <1607372302.54.0.511899594666.issue42593@roundup.psfhosted.org>
Message-ID: <1607378015.19.0.382903265909.issue42593@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

+        Py_UCS4 fill_char = PyUnicode_READ(char_size, PyUnicode_DATA(str), 0);
+        memset(to, fill_char, len);

The second parameter of memset() is a byte (8-bit "octet"). You cannot pass Py_UCS4 to memset(), it doesn't work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42593>
_______________________________________

From report at bugs.python.org  Mon Dec  7 16:57:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Dec 2020 21:57:16 +0000
Subject: =?utf-8?q?=5Bissue42590=5D_Something_like_Rust=27s_std=3A=3Async=3A=3AMut?=
 =?utf-8?q?ex_=E2=80=93_combining_a_mutex_primitive_and_a_piece_of_data_it?=
 =?utf-8?q?=27s_protecting?=
In-Reply-To: <1607356617.55.0.274484392105.issue42590@roundup.psfhosted.org>
Message-ID: <1607378236.47.0.981317798379.issue42590@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42590>
_______________________________________

From report at bugs.python.org  Mon Dec  7 16:57:54 2020
From: report at bugs.python.org (mattip)
Date: Mon, 07 Dec 2020 21:57:54 +0000
Subject: [issue39825] EXT_SUFFIX inconsistent between sysconfig and
 distutils.sysconfig (Windows)
In-Reply-To: <1583156407.62.0.364374237882.issue39825@roundup.psfhosted.org>
Message-ID: <1607378274.82.0.192225839635.issue39825@roundup.psfhosted.org>


mattip <matti.picus at gmail.com> added the comment:

I submitted PR 23684 to try to skip tests to fix this. I don't understand why this wasn't caught before merge, and where AIX and FREEBSD are setting EXT_SUFFIX improperly.

----------
message_count: 9.0 -> 10.0
pull_requests: +22549
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/23684

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39825>
_______________________________________

From report at bugs.python.org  Mon Dec  7 17:06:03 2020
From: report at bugs.python.org (syl-nktaylor)
Date: Mon, 07 Dec 2020 22:06:03 +0000
Subject: [issue42593] Consistency in unicode string multiplication with an
 integer
In-Reply-To: <1607372302.54.0.511899594666.issue42593@roundup.psfhosted.org>
Message-ID: <1607378763.26.0.383524646757.issue42593@roundup.psfhosted.org>


syl-nktaylor <syl.nktaylor at gmail.com> added the comment:

The build did seem to run, despite memset using fillchar without the explicit casting, so I assumed it did an implicit casting, but the original casting can be kept of course. With this build, my sample tests for 1-byte, 2-byte and 4-byte chars also ran ok, so again, I assumed memset did the casting.

As for the benchmarks, I haven't run them, but yes, it's likely the best way to find out the performance considerations I was asking about.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42593>
_______________________________________

From report at bugs.python.org  Mon Dec  7 17:27:24 2020
From: report at bugs.python.org (Irit Katriel)
Date: Mon, 07 Dec 2020 22:27:24 +0000
Subject: [issue33066] raise an exception from multiple positions break the
 traceback frames
In-Reply-To: <1520932782.62.0.467229070634.issue33066@psf.upfronthosting.co.za>
Message-ID: <1607380044.57.0.295643659993.issue33066@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

When an exception has a __traceback__ and you raise it, the current frame is added to that traceback. What do you expect the behavior to be when you raise the same exception instance twice, from two different locations?

----------
nosy: +iritkatriel

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33066>
_______________________________________

From report at bugs.python.org  Mon Dec  7 17:40:05 2020
From: report at bugs.python.org (Bart Robinson)
Date: Mon, 07 Dec 2020 22:40:05 +0000
Subject: [issue42594] Provide a way to skip magic-number search in
 ZipFile(mode='a')
Message-ID: <1607380805.75.0.407394534884.issue42594@roundup.psfhosted.org>


New submission from Bart Robinson <bart at bartrobinson.com>:

When a ZipFile object is created with mode='a', the existing file contents are checked for the magic number b"PK\005\006" near the end of the file.  If a non-zipfile just happens to contain this magic number, it can confuse the library into assuming the file is a zipfile when it is not.  It would be great if ZipFile.__init__() provided a way to skip the magic-number check and force a new central directory to be appended to the file.

This could take the form of an additional named argument like ZipFile.__init__(force_append=True), or an additional character in the mode string, like 'a+'.  Either of these options should be backward-compatible with existing code.

Currently, my company has code that uses monkey-patching to work around the lack of this feature in the standard library.  We use mode='a' to append metadata to files in existing formats that can contain arbitrary binary data and so occasionally include the magic number.

----------
components: Library (Lib)
messages: 382691
nosy: Bart Robinson
priority: normal
severity: normal
status: open
title: Provide a way to skip magic-number search in ZipFile(mode='a')
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42594>
_______________________________________

From report at bugs.python.org  Mon Dec  7 17:41:02 2020
From: report at bugs.python.org (Austin Scola)
Date: Mon, 07 Dec 2020 22:41:02 +0000
Subject: [issue42572] Better path handling with argparse
In-Reply-To: <1607121735.85.0.926277593776.issue42572@roundup.psfhosted.org>
Message-ID: <1607380862.49.0.936679315401.issue42572@roundup.psfhosted.org>


Austin Scola <austinscola at gmail.com> added the comment:

Hey Eric,

Thanks for the response. I'm unfamiliar with the process of adding features to the language. Would you mind explaining to me what some of the qualifications are for getting something added to the stdlib? And also what role packages on PyPI play in that process?

I am also willing (and interested) in helping out in implementing this, but I don't want to step on anyone's toes so if the offer for help is rejected I will not be upset.

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42572>
_______________________________________

From report at bugs.python.org  Mon Dec  7 18:00:01 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 07 Dec 2020 23:00:01 +0000
Subject: [issue42587] test_buffer fails on Python built with GCC 11
In-Reply-To: <1607353221.74.0.500162368406.issue42587@roundup.psfhosted.org>
Message-ID: <1607382001.32.0.396724582356.issue42587@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> FAIL: test_memoryview_cast (test.test_buffer.TestBufferProtocol)

It might be related to _Bool. See also bpo-39689.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42587>
_______________________________________

From report at bugs.python.org  Mon Dec  7 18:01:36 2020
From: report at bugs.python.org (Irit Katriel)
Date: Mon, 07 Dec 2020 23:01:36 +0000
Subject: [issue31299] Add "ignore_modules" option to
 TracebackException.format()
In-Reply-To: <1503992745.47.0.33675937395.issue31299@psf.upfronthosting.co.za>
Message-ID: <1607382096.58.0.255764862747.issue31299@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

In issue42247 the unit test framework uses limit as a hack to remove its own frame, and then the traceback module applies the limit to the chained exception as well.

If the filter suggested here existed, unit test could use that instead of limit.

----------
nosy: +iritkatriel

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31299>
_______________________________________

From report at bugs.python.org  Mon Dec  7 18:02:15 2020
From: report at bugs.python.org (Irit Katriel)
Date: Mon, 07 Dec 2020 23:02:15 +0000
Subject: [issue31299] Add "ignore_modules" option to
 TracebackException.format()
In-Reply-To: <1503992745.47.0.33675937395.issue31299@psf.upfronthosting.co.za>
Message-ID: <1607382135.89.0.409953110275.issue31299@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
versions: +Python 3.10 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31299>
_______________________________________

From report at bugs.python.org  Mon Dec  7 18:09:56 2020
From: report at bugs.python.org (pmp-p)
Date: Mon, 07 Dec 2020 23:09:56 +0000
Subject: [issue3770] test_multiprocessing fails on systems with HAVE_SEM_OPEN=0
In-Reply-To: <1220487838.93.0.477905681389.issue3770@psf.upfronthosting.co.za>
Message-ID: <1607382596.65.0.21964142176.issue3770@roundup.psfhosted.org>


Change by pmp-p <pmpp.pub at gmail.com>:


----------
nosy: +pmpp

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3770>
_______________________________________

From report at bugs.python.org  Mon Dec  7 18:11:11 2020
From: report at bugs.python.org (Sofian Brabez)
Date: Mon, 07 Dec 2020 23:11:11 +0000
Subject: [issue42422] Py_Decref on value crash the interpreter in
 Python/ceval.c:1104
In-Reply-To: <1605943207.33.0.904447657295.issue42422@roundup.psfhosted.org>
Message-ID: <1607382671.38.0.537394337949.issue42422@roundup.psfhosted.org>


Sofian Brabez <sbrabez at gmail.com> added the comment:

Any ETA? I would appreciate to see my contribution being merged.

Batuhan, the current code is not doing what it's supposed to do in bogus_code_obj.py (i.e. no crash after 3.8 and above in master and branches). This still make the issue valid I guess.

```
$ ./python -V
Python 3.8.6+
$ ./python -V
Python 3.10.0a2+
$ ./python Lib/test/crashers/bogus_code_obj.py 
Traceback (most recent call last):
  File "/usr/home/sbz/github/cpython/Lib/test/crashers/bogus_code_obj.py", line 17, in <module>
    co = types.CodeType(0, 0, 0, 0, 0, b'\x04\x71\x00\x00',
TypeError: code expected at least 14 arguments, got 13
```

I would be happy to update and fix it instead if you think it's better that way. Please let me know, it will be great to see my first submission being treated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42422>
_______________________________________

From report at bugs.python.org  Mon Dec  7 18:15:28 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 07 Dec 2020 23:15:28 +0000
Subject: [issue42572] Better path handling with argparse
In-Reply-To: <1607121735.85.0.926277593776.issue42572@roundup.psfhosted.org>
Message-ID: <1607382928.84.0.0961102612312.issue42572@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Hi, Austin.

If it's something that can be implemented in a library (which this suggestion qualifies as), then we typically want to see it on PyPI and to gain some traction there. I only suggested argparse-types because it also has some argparse add-ons. But you could certainly make a new package on PyPI.

But even then I'm not sure this would make it into the stdlib. For add-on functionality we're usually happy to leave things on PyPI. On the other hand, paths are somewhat more fundamental than some of the things in argparse-types. You might want to bring it up on the python-ideas mailing list and see how much support you get there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42572>
_______________________________________

From report at bugs.python.org  Mon Dec  7 18:23:01 2020
From: report at bugs.python.org (Blue)
Date: Mon, 07 Dec 2020 23:23:01 +0000
Subject: [issue40406] MagicMock __aenter__ should be
 AsyncMock(return_value=MagicMock())
In-Reply-To: <1587994408.9.0.812209740883.issue40406@roundup.psfhosted.org>
Message-ID: <1607383381.71.0.825469203531.issue40406@roundup.psfhosted.org>


Change by Blue <simon.d.beal at gmail.com>:


----------
nosy: +simon.d.beal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40406>
_______________________________________

From report at bugs.python.org  Mon Dec  7 18:38:11 2020
From: report at bugs.python.org (mattip)
Date: Mon, 07 Dec 2020 23:38:11 +0000
Subject: [issue39825] EXT_SUFFIX inconsistent between sysconfig and
 distutils.sysconfig (Windows)
In-Reply-To: <1583156407.62.0.364374237882.issue39825@roundup.psfhosted.org>
Message-ID: <1607384291.89.0.5129327995.issue39825@roundup.psfhosted.org>


mattip <matti.picus at gmail.com> added the comment:

I moved the new test to a separate test function and added `skipIf` for freebsd and AIX.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39825>
_______________________________________

From report at bugs.python.org  Mon Dec  7 18:45:27 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 07 Dec 2020 23:45:27 +0000
Subject: [issue42574] Travis can't build the 3.8 branch right now
In-Reply-To: <1607149839.2.0.378125476647.issue42574@roundup.psfhosted.org>
Message-ID: <1607384727.5.0.229260542766.issue42574@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset b6d6f5367da1f2e3f749c358ae8563c56a0cc395 by Pablo Galindo in branch '3.8':
bpo-42574: Use format() instead of f-string in Tools/clinic/clinic.py to allow using older Python versions (GH-23685)
https://github.com/python/cpython/commit/b6d6f5367da1f2e3f749c358ae8563c56a0cc395


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42574>
_______________________________________

From report at bugs.python.org  Mon Dec  7 18:45:38 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 07 Dec 2020 23:45:38 +0000
Subject: [issue42574] Travis can't build the 3.8 branch right now
In-Reply-To: <1607149839.2.0.378125476647.issue42574@roundup.psfhosted.org>
Message-ID: <1607384738.62.0.4147203062.issue42574@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/issue42574>
_______________________________________

From report at bugs.python.org  Mon Dec  7 18:50:27 2020
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 07 Dec 2020 23:50:27 +0000
Subject: [issue41889] enum: Mixin and int base class regression in 3.8.6
In-Reply-To: <1601439696.58.0.28102514399.issue41889@roundup.psfhosted.org>
Message-ID: <1607385027.95.0.889826881065.issue41889@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset 699e5e448919283578afe445069ab93b34bf8eae by Miss Islington (bot) in branch '3.8':
bpo-41889: [Enum] fix multiple-inheritance regression (GH-22487) (GH-23672)
https://github.com/python/cpython/commit/699e5e448919283578afe445069ab93b34bf8eae


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41889>
_______________________________________

From report at bugs.python.org  Mon Dec  7 18:51:19 2020
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 07 Dec 2020 23:51:19 +0000
Subject: [issue41889] enum: Mixin and int base class regression in 3.8.6
In-Reply-To: <1601439696.58.0.28102514399.issue41889@roundup.psfhosted.org>
Message-ID: <1607385079.54.0.457346549292.issue41889@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset be52ca45d9eb9c3e8941e46ddc67a210f0f4c6fa by Miss Islington (bot) in branch '3.9':
bpo-41889: [Enum] fix multiple-inheritance regression (GH-22487) (GH-23673)
https://github.com/python/cpython/commit/be52ca45d9eb9c3e8941e46ddc67a210f0f4c6fa


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41889>
_______________________________________

From report at bugs.python.org  Mon Dec  7 19:24:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 00:24:19 +0000
Subject: [issue42587] test_buffer fails on Python built with GCC 11
In-Reply-To: <1607353221.74.0.500162368406.issue42587@roundup.psfhosted.org>
Message-ID: <1607387059.8.0.6145287773.issue42587@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> FAIL: test_memoryview_cast (test.test_buffer.TestBufferProtocol)

On AArch64, GCC 11 miscompiles unpack_cmp() of Objects/memoryview.c for the '?' case:

    /* boolean */
    case '?': CMP_SINGLE(p, q, _Bool); return equal;

I reported the bug to GCC upstream: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98190

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42587>
_______________________________________

From report at bugs.python.org  Mon Dec  7 19:31:53 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 08 Dec 2020 00:31:53 +0000
Subject: [issue42059] TypedDict(...) as function does not respect "total" when
 setting __required_keys__ and __optional_keys__
In-Reply-To: <1602926609.93.0.947551036861.issue42059@roundup.psfhosted.org>
Message-ID: <1607387513.27.0.401604504838.issue42059@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Looking for another reviewer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42059>
_______________________________________

From report at bugs.python.org  Mon Dec  7 19:44:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 00:44:33 +0000
Subject: [issue39689] struct and memoryview tests rely on undefined behavior
 (as revealed by clang 9)
In-Reply-To: <1582124509.96.0.385275594117.issue39689@roundup.psfhosted.org>
Message-ID: <1607388273.93.0.774499915819.issue39689@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Objects/memoryview.c uses memcpy() on _Bool which leads to undefined behavior with GCC 11: see bpo-42587.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39689>
_______________________________________

From report at bugs.python.org  Mon Dec  7 20:05:24 2020
From: report at bugs.python.org (Soumendra Ganguly)
Date: Tue, 08 Dec 2020 01:05:24 +0000
Subject: [issue41818] Lib/pty.py major revision
In-Reply-To: <1600557574.22.0.272934906824.issue41818@roundup.psfhosted.org>
Message-ID: <1607389524.92.0.608770981007.issue41818@roundup.psfhosted.org>


Change by Soumendra Ganguly <soumendra at tamu.edu>:


----------
pull_requests: +22550
pull_request: https://github.com/python/cpython/pull/23686

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41818>
_______________________________________

From report at bugs.python.org  Mon Dec  7 20:31:16 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 08 Dec 2020 01:31:16 +0000
Subject: [issue25573] FrameSummary repr() does not support previously working
 uses of repr in traceback module
In-Reply-To: <1446845666.11.0.0803768990935.issue25573@psf.upfronthosting.co.za>
Message-ID: <1607391076.74.0.293242916937.issue25573@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
keywords: +patch
pull_requests: +22551
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/23687

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25573>
_______________________________________

From report at bugs.python.org  Mon Dec  7 20:32:35 2020
From: report at bugs.python.org (Austin Scola)
Date: Tue, 08 Dec 2020 01:32:35 +0000
Subject: [issue42572] Better path handling with argparse
In-Reply-To: <1607121735.85.0.926277593776.issue42572@roundup.psfhosted.org>
Message-ID: <1607391155.3.0.107848170075.issue42572@roundup.psfhosted.org>


Austin Scola <austinscola at gmail.com> added the comment:

Awesome, thank you for the guidance Eric. I'll start a thread on the python-ideas mailing list, gauge the level of support, and go from there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42572>
_______________________________________

From report at bugs.python.org  Mon Dec  7 20:34:57 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 08 Dec 2020 01:34:57 +0000
Subject: [issue25573] FrameSummary repr() does not support previously working
 uses of repr in traceback module
In-Reply-To: <1446845666.11.0.0803768990935.issue25573@psf.upfronthosting.co.za>
Message-ID: <1607391297.95.0.426866656053.issue25573@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
pull_requests:  -22551

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25573>
_______________________________________

From report at bugs.python.org  Mon Dec  7 20:36:15 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 08 Dec 2020 01:36:15 +0000
Subject: [issue42247] unittest hides traceback frames in chained exceptions
In-Reply-To: <1604341559.53.0.224869314437.issue42247@roundup.psfhosted.org>
Message-ID: <1607391375.26.0.71804483037.issue42247@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
keywords: +patch
nosy: +iritkatriel
nosy_count: 1.0 -> 2.0
pull_requests: +22552
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23687

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42247>
_______________________________________

From report at bugs.python.org  Mon Dec  7 20:36:15 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 08 Dec 2020 01:36:15 +0000
Subject: [issue25573] FrameSummary repr() does not support previously working
 uses of repr in traceback module
In-Reply-To: <1446845666.11.0.0803768990935.issue25573@psf.upfronthosting.co.za>
Message-ID: <1607391375.32.0.947411613281.issue25573@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
pull_requests: +22553
pull_request: https://github.com/python/cpython/pull/23687

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25573>
_______________________________________

From report at bugs.python.org  Mon Dec  7 20:43:14 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 08 Dec 2020 01:43:14 +0000
Subject: [issue25573] FrameSummary repr() does not support previously working
 uses of repr in traceback module
In-Reply-To: <1446845666.11.0.0803768990935.issue25573@psf.upfronthosting.co.za>
Message-ID: <1607391794.25.0.26926177892.issue25573@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
pull_requests: +22554
pull_request: https://github.com/python/cpython/pull/23688

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25573>
_______________________________________

From report at bugs.python.org  Mon Dec  7 20:43:36 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 08 Dec 2020 01:43:36 +0000
Subject: [issue25573] FrameSummary repr() does not support previously working
 uses of repr in traceback module
In-Reply-To: <1446845666.11.0.0803768990935.issue25573@psf.upfronthosting.co.za>
Message-ID: <1607391816.6.0.871365419928.issue25573@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
pull_requests:  -22553

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25573>
_______________________________________

From report at bugs.python.org  Mon Dec  7 20:43:56 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 08 Dec 2020 01:43:56 +0000
Subject: [issue42247] unittest hides traceback frames in chained exceptions
In-Reply-To: <1604341559.53.0.224869314437.issue42247@roundup.psfhosted.org>
Message-ID: <1607391836.3.0.893554627611.issue42247@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
versions: +Python 3.10 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42247>
_______________________________________

From report at bugs.python.org  Mon Dec  7 20:46:10 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 08 Dec 2020 01:46:10 +0000
Subject: [issue42247] unittest hides traceback frames in chained exceptions
In-Reply-To: <1604341559.53.0.224869314437.issue42247@roundup.psfhosted.org>
Message-ID: <1607391970.05.0.62151782246.issue42247@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
pull_requests:  -22552

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42247>
_______________________________________

From report at bugs.python.org  Mon Dec  7 20:46:55 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 08 Dec 2020 01:46:55 +0000
Subject: [issue42247] unittest hides traceback frames in chained exceptions
In-Reply-To: <1604341559.53.0.224869314437.issue42247@roundup.psfhosted.org>
Message-ID: <1607392015.15.0.497299998122.issue42247@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
pull_requests: +22552
pull_request: https://github.com/python/cpython/pull/23687

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42247>
_______________________________________

From report at bugs.python.org  Mon Dec  7 20:47:35 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 08 Dec 2020 01:47:35 +0000
Subject: [issue42247] unittest hides traceback frames in chained exceptions
In-Reply-To: <1604341559.53.0.224869314437.issue42247@roundup.psfhosted.org>
Message-ID: <1607392055.06.0.346666383961.issue42247@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
pull_requests:  -22552

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42247>
_______________________________________

From report at bugs.python.org  Mon Dec  7 20:47:52 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 08 Dec 2020 01:47:52 +0000
Subject: [issue42247] unittest hides traceback frames in chained exceptions
In-Reply-To: <1604341559.53.0.224869314437.issue42247@roundup.psfhosted.org>
Message-ID: <1607392072.52.0.706405369082.issue42247@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
pull_requests: +22555
pull_request: https://github.com/python/cpython/pull/23687

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42247>
_______________________________________

From report at bugs.python.org  Mon Dec  7 20:48:58 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 08 Dec 2020 01:48:58 +0000
Subject: [issue42247] unittest hides traceback frames in chained exceptions
In-Reply-To: <1604341559.53.0.224869314437.issue42247@roundup.psfhosted.org>
Message-ID: <1607392138.16.0.848349527923.issue42247@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
pull_requests: +22556
pull_request: https://github.com/python/cpython/pull/23688

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42247>
_______________________________________

From report at bugs.python.org  Mon Dec  7 20:52:34 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 08 Dec 2020 01:52:34 +0000
Subject: [issue25573] FrameSummary repr() does not support previously working
 uses of repr in traceback module
In-Reply-To: <1446845666.11.0.0803768990935.issue25573@psf.upfronthosting.co.za>
Message-ID: <1607392354.58.0.259138539838.issue25573@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
pull_requests:  -22554

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25573>
_______________________________________

From report at bugs.python.org  Mon Dec  7 20:56:34 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 08 Dec 2020 01:56:34 +0000
Subject: [issue42247] unittest hides traceback frames in chained exceptions
In-Reply-To: <1604341559.53.0.224869314437.issue42247@roundup.psfhosted.org>
Message-ID: <1607392594.91.0.622099665544.issue42247@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

I made a patch that replaces the limit hack by a filter on the traceback. We could stop here an just fix this, or we could create a more generic filter in the traceback module as suggested in issue31299.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42247>
_______________________________________

From report at bugs.python.org  Mon Dec  7 21:12:26 2020
From: report at bugs.python.org (Gregory Szorc)
Date: Tue, 08 Dec 2020 02:12:26 +0000
Subject: [issue42564] "from .__init__ import ..." syntax imports a duplicate
 module
In-Reply-To: <1607047912.32.0.654567376337.issue42564@roundup.psfhosted.org>
Message-ID: <1607393546.95.0.637400062928.issue42564@roundup.psfhosted.org>


Gregory Szorc <gregory.szorc at gmail.com> added the comment:

Who uses this syntax? https://github.com/search?l=Python&q=%22from+.__init__+import%22&type=Code says a lot of random code, surprisingly/sadly.

As for python-ideas, thanks for the suggestion: I may very well craft an email!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42564>
_______________________________________

From report at bugs.python.org  Mon Dec  7 21:31:41 2020
From: report at bugs.python.org (paul j3)
Date: Tue, 08 Dec 2020 02:31:41 +0000
Subject: [issue42572] Better path handling with argparse
In-Reply-To: <1607121735.85.0.926277593776.issue42572@roundup.psfhosted.org>
Message-ID: <1607394701.91.0.0715065627307.issue42572@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

What exactly do you do with a path argument?

Admittedly I'm not expert with os and os.path modules, but isn't a path just a string passed to a function such as cwd(), or joined to another create a filename.

I don't know what a 'path' type or action would do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42572>
_______________________________________

From report at bugs.python.org  Mon Dec  7 21:42:01 2020
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 08 Dec 2020 02:42:01 +0000
Subject: [issue42560] Improve Tkinter Documentation
In-Reply-To: <1607020537.02.0.420924180434.issue42560@roundup.psfhosted.org>
Message-ID: <1607395321.48.0.15561479826.issue42560@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 2.0 -> 3.0
pull_requests: +22557
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23689

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42560>
_______________________________________

From report at bugs.python.org  Mon Dec  7 22:21:43 2020
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 08 Dec 2020 03:21:43 +0000
Subject: [issue41889] enum: Mixin and int base class regression in 3.8.6
In-Reply-To: <1601439696.58.0.28102514399.issue41889@roundup.psfhosted.org>
Message-ID: <1607397703.85.0.798681780515.issue41889@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41889>
_______________________________________

From report at bugs.python.org  Mon Dec  7 22:55:17 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Tue, 08 Dec 2020 03:55:17 +0000
Subject: [issue42422] Py_Decref on value crash the interpreter in
 Python/ceval.c:1104
In-Reply-To: <1605943207.33.0.904447657295.issue42422@roundup.psfhosted.org>
Message-ID: <1607399717.28.0.241583596861.issue42422@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

Why not just fix bogus_code_obj.py?

Something like this (using the replace method) would make it more future-proof to similar changes in the code object constructor signature (and be more readable!):

import dis
POP_TOP = dis.opmap['POP_TOP']
wordcode = bytes([POP_TOP, 0] * 10)
f = lambda: None
f.__code__ = f.__code__.replace(co_code=wordcode)
f()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42422>
_______________________________________

From report at bugs.python.org  Mon Dec  7 23:10:50 2020
From: report at bugs.python.org (NO_DANGER LacalBitcoins)
Date: Tue, 08 Dec 2020 04:10:50 +0000
Subject: [issue42595] 5 * str
Message-ID: <1607400650.61.0.129436529135.issue42595@roundup.psfhosted.org>


New submission from NO_DANGER LacalBitcoins <denisustinovweb at gmail.com>:

5 * 'abc' ??? ??????. ?????????!

----------
files: Screenshot_1.png
messages: 382709
nosy: denisustinovweb
priority: normal
severity: normal
status: open
title: 5 * str
type: crash
Added file: https://bugs.python.org/file49659/Screenshot_1.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42595>
_______________________________________

From report at bugs.python.org  Mon Dec  7 23:35:17 2020
From: report at bugs.python.org (tosunilmathew@yahoo.com)
Date: Tue, 08 Dec 2020 04:35:17 +0000
Subject: [issue42573] Installation of Python 3.9 failing with message "User
 cancelled installation"
In-Reply-To: <1607167348.75.0.906880980974.issue42573@roundup.psfhosted.org>
Message-ID: <1607402117.89.0.192157488023.issue42573@roundup.psfhosted.org>


tosunilmathew at yahoo.com <tosunilmathew at yahoo.com> added the comment:

Thanks everyone. It worked once I ran as admin.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42573>
_______________________________________

From report at bugs.python.org  Mon Dec  7 23:50:30 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 08 Dec 2020 04:50:30 +0000
Subject: [issue42595] 5 * str
In-Reply-To: <1607400650.61.0.129436529135.issue42595@roundup.psfhosted.org>
Message-ID: <1607403030.69.0.793578699015.issue42595@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Sorry, this isn't a bug.  It is tested and guaranteed behavior.

----------
nosy: +rhettinger
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42595>
_______________________________________

From report at bugs.python.org  Tue Dec  8 02:47:29 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 08 Dec 2020 07:47:29 +0000
Subject: [issue42422] Py_Decref on value crash the interpreter in
 Python/ceval.c:1104
In-Reply-To: <1605943207.33.0.904447657295.issue42422@roundup.psfhosted.org>
Message-ID: <1607413649.17.0.583560210084.issue42422@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

> I would be happy to update and fix it instead if you think it's better that way. Please let me know, it will be great to see my first submission being treated.

Yes, please. That seems more appropriate

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42422>
_______________________________________

From report at bugs.python.org  Tue Dec  8 02:51:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 07:51:06 +0000
Subject: [issue42422] Py_Decref on value crash the interpreter in
 Python/ceval.c:1104
In-Reply-To: <1605943207.33.0.904447657295.issue42422@roundup.psfhosted.org>
Message-ID: <1607413866.6.0.0829216612432.issue42422@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

About PR 23448: I don't see the value of adding a script just prove that CPython has no bytecode verifier.

If you consider that it's not well documented, it should be documented in the types.CodeType documentation:
https://docs.python.org/dev/library/types.html#types.CodeType

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42422>
_______________________________________

From report at bugs.python.org  Tue Dec  8 02:53:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 07:53:15 +0000
Subject: [issue42422] types.CodeType() has no bytecode verifier
In-Reply-To: <1605943207.33.0.904447657295.issue42422@roundup.psfhosted.org>
Message-ID: <1607413995.83.0.448961760541.issue42422@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Compiled bytecode is not portable between Python versions. You may use https://bytecode.readthedocs.io/ which might help to write more portable code, but this project does not contain a bytecode verifier and I'm not sure that it's updated when the Python bytecode becomes backward incompatible. (I wrote the first version as a Proof-of-Concept of my PEP 511, but I no longer maintain it.)

----------
title: Py_Decref on value crash the interpreter in Python/ceval.c:1104 -> types.CodeType() has no bytecode verifier

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42422>
_______________________________________

From report at bugs.python.org  Tue Dec  8 02:55:05 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 07:55:05 +0000
Subject: [issue42422] types.CodeType() has no bytecode verifier
In-Reply-To: <1605943207.33.0.904447657295.issue42422@roundup.psfhosted.org>
Message-ID: <1607414105.98.0.106090343815.issue42422@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> You may use https://bytecode.readthedocs.io/ which might help to write more portable code, (...)

Ah, I didn't notice that at the beginning of the documentation, you can see that even a very simple loop has a different bytecode before and after Python 3.8:

"Python 3.8 removed SETUP_LOOP"
https://bytecode.readthedocs.io/en/latest/usage.html#simple-loop

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42422>
_______________________________________

From report at bugs.python.org  Tue Dec  8 03:08:34 2020
From: report at bugs.python.org (Xavier Morel)
Date: Tue, 08 Dec 2020 08:08:34 +0000
Subject: [issue42572] Better path handling with argparse
In-Reply-To: <1607121735.85.0.926277593776.issue42572@roundup.psfhosted.org>
Message-ID: <1607414914.05.0.45020483167.issue42572@roundup.psfhosted.org>


Xavier Morel <xavier.morel at masklinn.net> added the comment:

> What exactly do you do with a path argument?

Because they mention "convert[ing] the string to a path", I would expect an output of `pathlib.Path`, optionally checked for existence / non-existence and / or kind (file, directory, symlink, ...).

Obviously it is rather easy to bring your own, but OP's expectation is that paths input is common enough (especially in smaller standalone scripts I would expect) that having a helper in a standard library would be... helpful.

----------
nosy: +xmorel

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42572>
_______________________________________

From report at bugs.python.org  Tue Dec  8 03:08:52 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 08 Dec 2020 08:08:52 +0000
Subject: [issue42561] better error reporting in ast
In-Reply-To: <1607027058.31.0.3436923935.issue42561@roundup.psfhosted.org>
Message-ID: <1607414932.95.0.311154618129.issue42561@roundup.psfhosted.org>


Change by Batuhan Taskaya <isidentical at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42561>
_______________________________________

From report at bugs.python.org  Tue Dec  8 03:09:22 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 08 Dec 2020 08:09:22 +0000
Subject: [issue42561] better error reporting in ast
In-Reply-To: <1607027058.31.0.3436923935.issue42561@roundup.psfhosted.org>
Message-ID: <1607414962.28.0.731867360808.issue42561@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

This is a duplicate of issue 28964

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42561>
_______________________________________

From report at bugs.python.org  Tue Dec  8 04:22:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 09:22:04 +0000
Subject: [issue42596] aarch64 Fedora Rawhide LTO + PGO 3.8 fails to build
 Python: /usr/bin/ld: error adding symbols: bad value
Message-ID: <1607419324.76.0.598132356337.issue42596@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

aarch64 Fedora Rawhide LTO + PGO 3.8:
https://buildbot.python.org/all/#/builders/528/builds/243

/usr/bin/ld: /lib64/libgcc_s.so.1: .gnu.version_r invalid entry
/usr/bin/ld: /lib64/libgcc_s.so.1: error adding symbols: bad value
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:578: python] Error 1
make[3]: *** Waiting for unfinished jobs....

Is it another GCC 11 bug when using LTO and/or PGO?

----------
components: Build
messages: 382718
nosy: vstinner
priority: normal
severity: normal
status: open
title: aarch64 Fedora Rawhide LTO + PGO 3.8 fails to build Python: /usr/bin/ld: error adding symbols: bad value
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42596>
_______________________________________

From report at bugs.python.org  Tue Dec  8 04:49:30 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 09:49:30 +0000
Subject: [issue42587] test_buffer fails on Python built with GCC 11
In-Reply-To: <1607353221.74.0.500162368406.issue42587@roundup.psfhosted.org>
Message-ID: <1607420970.54.0.0417740658637.issue42587@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also: Behavior of struct ??? format (native _Bool)
https://discuss.python.org/t/behavior-of-struct-format-native-bool/3774

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42587>
_______________________________________

From report at bugs.python.org  Tue Dec  8 04:49:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 09:49:58 +0000
Subject: [issue42587] memoryview rely on _Bool undefined behavior (test_buffer
 fails on Python built with GCC 11)
In-Reply-To: <1607353221.74.0.500162368406.issue42587@roundup.psfhosted.org>
Message-ID: <1607420998.48.0.282937063444.issue42587@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: test_buffer fails on Python built with GCC 11 -> memoryview rely on _Bool undefined behavior (test_buffer fails on Python built with GCC 11)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42587>
_______________________________________

From report at bugs.python.org  Tue Dec  8 05:11:29 2020
From: report at bugs.python.org (Michael Felt)
Date: Tue, 08 Dec 2020 10:11:29 +0000
Subject: [issue39825] EXT_SUFFIX inconsistent between sysconfig and
 distutils.sysconfig (Windows)
In-Reply-To: <1583156407.62.0.364374237882.issue39825@roundup.psfhosted.org>
Message-ID: <1607422289.55.0.239746503145.issue39825@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

On Windows - in distutils (?) did they perhaps make a change only for windows, for whatever reason.

I don't have a python3.7 pr a 3.8 handy atm.

Not sure what 'distutils' pip updates either - but with py36 and pip 20.2.4 and setuptools 40.6.2 I get:

Python 3.6.12 (default, Sep 23 2020, 08:27:01) [C] on aix5
Type "help", "copyright", "credits" or "license" for more information.
>>> import sysconfig
>>> sysconfig.get_config_var('EXT_SUFFIX')
'.so'
>>> from distutils import sysconfig
>>> sysconfig.get_config_var('EXT_SUFFIX')
'.so'

I am guessing that distutils has not updated - whatever - for AIX, FreeBSD, and perhaps others.

@mattip: is the problem perhaps with distutils rather than a particular platform. I also admit, I do not know what 'EXT_SUFFIX' is suppossed to return. From past behavior I took it to mean a file 'tag' for files that are accessed using dlopen().

Is it - perhaps - that different platforms have different needs or abilities - and the error is not the platform - but the adequacy of tests to differentiate platform behavior. I am guessing now - but maybe that is why distutils has not changed AIX and FreeBSD and maybe more.

----------
nosy: +Michael.Felt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39825>
_______________________________________

From report at bugs.python.org  Tue Dec  8 05:19:27 2020
From: report at bugs.python.org (Dominik V.)
Date: Tue, 08 Dec 2020 10:19:27 +0000
Subject: [issue42597] Improve documentation of locals() w.r.t. "free
 variables" vs. global variables
Message-ID: <1607422767.08.0.320752230073.issue42597@roundup.psfhosted.org>


New submission from Dominik V. <dominik.vilsmeier1123 at gmail.com>:

The documentation of locals() mentions that:

> Free variables are returned by locals() when it is called in function blocks [...]

The term "free variable" is defined in the documentation about the execution model (https://docs.python.org/3/reference/executionmodel.html#binding-of-names):

> If a variable is used in a code block but not defined there, it is a free variable.

That definition includes global variables (and builtin ones), but these are not returned by locals(). For example compare the following:

```
x = 1
def foo():
    # global x
    x = 1
    def bar():
        print(locals())
        y = x
    bar()
foo()
```

If the `global x` is commented then it prints {'x': 1}, and if it is uncommented it prints {}. The same holds for names of builtins.

So the documentation of locals() could mention this in the following way (emphasis added):

> Free variables *of enclosing functions* are returned by locals() when it is called in function blocks [...]

-----

There is also a StackOverflow question, that describes this confusion: https://stackoverflow.com/questions/12919278/how-to-define-free-variable-in-python

By the way, would it be helpful to add the term "free variable" to the glossary (https://docs.python.org/3/glossary.html)?

----------
assignee: docs at python
components: Documentation
messages: 382721
nosy: Dominik V., docs at python
priority: normal
severity: normal
status: open
title: Improve documentation of locals() w.r.t. "free variables" vs. global variables
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42597>
_______________________________________

From report at bugs.python.org  Tue Dec  8 05:25:06 2020
From: report at bugs.python.org (Joshua Root)
Date: Tue, 08 Dec 2020 10:25:06 +0000
Subject: [issue31601] Availability of utimensat,
 futimens not checked correctly on macOS
In-Reply-To: <1506493420.2.0.154975027568.issue31601@psf.upfronthosting.co.za>
Message-ID: <1607423106.1.0.23983796368.issue31601@roundup.psfhosted.org>


Joshua Root <josh+python at root.id.au> added the comment:

Looks like this is fixed as of 3.9.1.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31601>
_______________________________________

From report at bugs.python.org  Tue Dec  8 05:25:43 2020
From: report at bugs.python.org (Michael Felt)
Date: Tue, 08 Dec 2020 10:25:43 +0000
Subject: [issue39825] EXT_SUFFIX inconsistent between sysconfig and
 distutils.sysconfig (Windows)
In-Reply-To: <1583156407.62.0.364374237882.issue39825@roundup.psfhosted.org>
Message-ID: <1607423143.05.0.481324991621.issue39825@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Looking at https://github.com/python/cpython/pull/22088/files

imho: the patch forced Windows behavior ("""Initialize the module as appropriate for NT""") to be equivalent to vars['SO'] - which is what the test used to compare.

So, likely the change to the tests would be to have one for NT (per the comment in Lib/sysconfig.py) and the prior test set to be skipped if the platform is `NT` aka non_posix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39825>
_______________________________________

From report at bugs.python.org  Tue Dec  8 05:27:00 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 10:27:00 +0000
Subject: [issue21627] Concurrently closing files and iterating over the open
 files directory is not well specified
In-Reply-To: <1401643353.39.0.53304722389.issue21627@psf.upfronthosting.co.za>
Message-ID: <1607423220.59.0.230288871063.issue21627@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Linux 5.9 added close_range() syscall that we can use.

Linux 5.10 may get a new CLOSE_RANGE_CLOEXEC flag for close_range().
https://lwn.net/Articles/837816/

We may use close_range() rather than iterating on /proc/self/fd/ in user space. It may be faster and safer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21627>
_______________________________________

From report at bugs.python.org  Tue Dec  8 05:53:24 2020
From: report at bugs.python.org (E. Paine)
Date: Tue, 08 Dec 2020 10:53:24 +0000
Subject: [issue42560] Improve Tkinter Documentation
In-Reply-To: <1607020537.02.0.420924180434.issue42560@roundup.psfhosted.org>
Message-ID: <1607424804.54.0.688403131533.issue42560@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

See issue34154. I'm personally against such changes because we don't know what Tk version to write them for. Our documentation could be both outdated and too recent, including kwargs not available to some people (because they are running an older version).

The documentation available on third-party websites is pretty good and the official docs link to those. It is a shame Effbot is currently down, but the content is still available on https://web.archive.org/web/20201111145627/http://effbot.org/

----------
nosy: +epaine, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42560>
_______________________________________

From report at bugs.python.org  Tue Dec  8 06:15:17 2020
From: report at bugs.python.org (Joshua Root)
Date: Tue, 08 Dec 2020 11:15:17 +0000
Subject: [issue42598] Some configure checks rely on implicit function
 declaration
Message-ID: <1607426117.25.0.975744797691.issue42598@roundup.psfhosted.org>


New submission from Joshua Root <josh+python at root.id.au>:

There are several cases in the configure script of exit being used without including stdlib.h, and one case of close being used without including unistd.h. A compiler that does not allow implicit function declaration, such as clang in Xcode 12, will error out due to this, which may cause the affected checks to give incorrect results.

----------
components: Build
messages: 382726
nosy: jmr
priority: normal
severity: normal
status: open
title: Some configure checks rely on implicit function declaration
type: compile error
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42598>
_______________________________________

From report at bugs.python.org  Tue Dec  8 06:17:35 2020
From: report at bugs.python.org (Joshua Root)
Date: Tue, 08 Dec 2020 11:17:35 +0000
Subject: [issue42598] Some configure checks rely on implicit function
 declaration
In-Reply-To: <1607426117.25.0.975744797691.issue42598@roundup.psfhosted.org>
Message-ID: <1607426255.7.0.336571740283.issue42598@roundup.psfhosted.org>


Change by Joshua Root <josh+python at root.id.au>:


----------
keywords: +patch
pull_requests: +22558
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23690

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42598>
_______________________________________

From report at bugs.python.org  Tue Dec  8 06:25:12 2020
From: report at bugs.python.org (hai shi)
Date: Tue, 08 Dec 2020 11:25:12 +0000
Subject: [issue42599] Remove PyModule_GetWarningsModule() in pylifecycle.c
Message-ID: <1607426712.85.0.240458410103.issue42599@roundup.psfhosted.org>


New submission from hai shi <shihai1991 at 126.com>:

PyModule_GetWarningsModule() of pylifecycle.c is useless when _warning module was converted to a builtin module in 2.6. So move it directly now is OK.

----------
components: Interpreter Core
messages: 382727
nosy: petr.viktorin, shihai1991, vstinner
priority: normal
severity: normal
status: open
title: Remove PyModule_GetWarningsModule() in pylifecycle.c
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42599>
_______________________________________

From report at bugs.python.org  Tue Dec  8 06:28:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 11:28:20 +0000
Subject: [issue42599] Remove PyModule_GetWarningsModule() in pylifecycle.c
In-Reply-To: <1607426712.85.0.240458410103.issue42599@roundup.psfhosted.org>
Message-ID: <1607426900.79.0.940138303981.issue42599@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It's not part of the C API and it's no longer exported in libpython since we (the default visibility was changed to "hidden"). IMHO it's safe to remove the function. But it would not harm to document the removal in https://docs.python.org/dev/whatsnew/3.10.html#id4 section.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42599>
_______________________________________

From report at bugs.python.org  Tue Dec  8 06:34:45 2020
From: report at bugs.python.org (hai shi)
Date: Tue, 08 Dec 2020 11:34:45 +0000
Subject: [issue42599] Remove PyModule_GetWarningsModule() in pylifecycle.c
In-Reply-To: <1607426712.85.0.240458410103.issue42599@roundup.psfhosted.org>
Message-ID: <1607427285.17.0.440818741859.issue42599@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
keywords: +patch
pull_requests: +22559
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23691

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42599>
_______________________________________

From report at bugs.python.org  Tue Dec  8 06:36:55 2020
From: report at bugs.python.org (hai shi)
Date: Tue, 08 Dec 2020 11:36:55 +0000
Subject: [issue42599] Remove PyModule_GetWarningsModule() in pylifecycle.c
In-Reply-To: <1607426712.85.0.240458410103.issue42599@roundup.psfhosted.org>
Message-ID: <1607427415.24.0.157647196792.issue42599@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

> But it would not harm to document the removal in https://docs.python.org/dev/whatsnew/3.10.html#id4 section.

Copy that. I will update it soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42599>
_______________________________________

From report at bugs.python.org  Tue Dec  8 07:00:01 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 08 Dec 2020 12:00:01 +0000
Subject: [issue42599] Remove PyModule_GetWarningsModule() in pylifecycle.c
In-Reply-To: <1607426712.85.0.240458410103.issue42599@roundup.psfhosted.org>
Message-ID: <1607428801.61.0.117281375396.issue42599@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

When was the visibility changed to hidden?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42599>
_______________________________________

From report at bugs.python.org  Tue Dec  8 07:28:45 2020
From: report at bugs.python.org (Joshua Root)
Date: Tue, 08 Dec 2020 12:28:45 +0000
Subject: [issue41617] __builtin_bswap16 is used without checking it is
 supported
In-Reply-To: <1598144567.0.0.176317601198.issue41617@roundup.psfhosted.org>
Message-ID: <1607430525.27.0.273832124593.issue41617@roundup.psfhosted.org>


Joshua Root <josh+python at root.id.au> added the comment:

Confirmed fixed in 3.9.1 and 3.10.0a3. Thanks Victor!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41617>
_______________________________________

From report at bugs.python.org  Tue Dec  8 07:35:56 2020
From: report at bugs.python.org (Hynek Schlawack)
Date: Tue, 08 Dec 2020 12:35:56 +0000
Subject: [issue42600] Cancelling tasks waiting for asyncio.Conditions crashes
 w/ RuntimeError: Lock is not acquired.
Message-ID: <1607430956.17.0.934441920245.issue42600@roundup.psfhosted.org>


New submission from Hynek Schlawack <hs at ox.cx>:

This is something I've been procrastinating on for almost a year and working around it using my own version of asyncio.Condition because I wasn't sure how to describe it. So here's my best take:

Consider the following code:

```
import asyncio


async def tf(con):
    async with con:
        await asyncio.wait_for(con.wait(), 60)


async def f(loop):
    con = asyncio.Condition()

    t = loop.create_task(tf(con))

    await asyncio.sleep(1)
    t.cancel()

    async with con:
        con.notify_all()

    await t


loop = asyncio.get_event_loop()
loop.run_until_complete(f(loop))
```

(I'm using old-school APIs because I wanted to verify whether it was a regression. I ran into the bug with new-style APIs: https://gist.github.com/hynek/387f44672722171c901b8422320e8f9b)

`await t` will crash with:


```
Traceback (most recent call last):
  File "/Users/hynek/t.py", line 6, in tf
    await asyncio.wait_for(con.wait(), 60)
  File "/Users/hynek/.asdf/installs/python/3.9.0/lib/python3.9/asyncio/tasks.py", line 466, in wait_for
    await waiter
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/hynek/t.py", line 24, in <module>
    loop.run_until_complete(f(loop))
  File "/Users/hynek/.asdf/installs/python/3.9.0/lib/python3.9/asyncio/base_events.py", line 642, in run_until_complete
    return future.result()
  File "/Users/hynek/t.py", line 20, in f
    await t
  File "/Users/hynek/t.py", line 6, in tf
    await asyncio.wait_for(con.wait(), 60)
  File "/Users/hynek/.asdf/installs/python/3.9.0/lib/python3.9/asyncio/locks.py", line 20, in __aexit__
    self.release()
  File "/Users/hynek/.asdf/installs/python/3.9.0/lib/python3.9/asyncio/locks.py", line 146, in release
    raise RuntimeError('Lock is not acquired.')
RuntimeError: Lock is not acquired.

```

If you replace wait_for with a simple await, it works and raises an asyncio.exceptions.CancelledError:

```
Traceback (most recent call last):
  File "/Users/hynek/t.py", line 6, in tf
    await con.wait()
  File "/Users/hynek/.asdf/installs/python/3.9.0/lib/python3.9/asyncio/locks.py", line 290, in wait
    await fut
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/hynek/t.py", line 20, in f
    await t
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/hynek/t.py", line 24, in <module>
    loop.run_until_complete(f(loop))
  File "/Users/hynek/.asdf/installs/python/3.9.0/lib/python3.9/asyncio/base_events.py", line 642, in run_until_complete
    return future.result()
asyncio.exceptions.CancelledError
```

I have verified, that this has been broken at least since 3.5.10. The current 3.10.0a3 is affected too.

----------
components: asyncio
messages: 382732
nosy: asvetlov, hynek, lukasz.langa, yselivanov
priority: normal
severity: normal
status: open
title: Cancelling tasks waiting for asyncio.Conditions crashes w/ RuntimeError: Lock is not acquired.
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42600>
_______________________________________

From report at bugs.python.org  Tue Dec  8 08:23:48 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 08 Dec 2020 13:23:48 +0000
Subject: [issue31608] crash in methods of a subclass of _collections.deque
 with a bad __new__()
In-Reply-To: <1506509038.4.0.154975027568.issue31608@psf.upfronthosting.co.za>
Message-ID: <1607433828.38.0.219914794437.issue31608@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


----------
pull_requests: +22560
pull_request: https://github.com/python/cpython/pull/9178

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31608>
_______________________________________

From report at bugs.python.org  Tue Dec  8 08:31:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 13:31:40 +0000
Subject: [issue41617] __builtin_bswap16 is used without checking it is
 supported
In-Reply-To: <1598144567.0.0.176317601198.issue41617@roundup.psfhosted.org>
Message-ID: <1607434300.62.0.193675161054.issue41617@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Confirmed fixed in 3.9.1 and 3.10.0a3. Thanks Victor!

Woooot!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41617>
_______________________________________

From report at bugs.python.org  Tue Dec  8 08:36:45 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 08 Dec 2020 13:36:45 +0000
Subject: [issue40652] Test test_locale failed when running cpython test on
 Windows 10 x64 for version 3.9.0a6+
In-Reply-To: <1589682647.75.0.547799731095.issue40652@roundup.psfhosted.org>
Message-ID: <1607434605.01.0.675629353491.issue40652@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> [Windows] locale.getdefaultlocale() issues on Windows: test_locale.test_getsetlocale_issue1813()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40652>
_______________________________________

From report at bugs.python.org  Tue Dec  8 08:38:20 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 08 Dec 2020 13:38:20 +0000
Subject: [issue31636] test_locale failure on OpenBSD
In-Reply-To: <1506677973.45.0.213398074469.issue31636@psf.upfronthosting.co.za>
Message-ID: <1607434700.15.0.137407657578.issue31636@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests:  -8617

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31636>
_______________________________________

From report at bugs.python.org  Tue Dec  8 08:38:42 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 13:38:42 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1607434722.37.0.450874845558.issue32381@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b6d98c10fff6f320f8fdf595c3f9a05d8be4e31d by Victor Stinner in branch 'master':
bpo-32381: Fix PyRun_SimpleFileExFlags() encoding (GH-23642)
https://github.com/python/cpython/commit/b6d98c10fff6f320f8fdf595c3f9a05d8be4e31d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32381>
_______________________________________

From report at bugs.python.org  Tue Dec  8 08:42:43 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 08 Dec 2020 13:42:43 +0000
Subject: [issue31636] test_locale failure on OpenBSD
In-Reply-To: <1506677973.45.0.213398074469.issue31636@psf.upfronthosting.co.za>
Message-ID: <1607434963.09.0.956187027666.issue31636@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

PR-9178 was for #31608.  I corrected the PR and unlinked it from here.

This is a duplicate of #25191, with proposed patch.  #37945 is the same issue for Windows, with extensive discussion.

----------
nosy: +terry.reedy
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> test_getsetlocale_issue1813 failed on OpenBSD

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31636>
_______________________________________

From report at bugs.python.org  Tue Dec  8 08:46:09 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 13:46:09 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1607435169.05.0.982118002893.issue32381@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22561
pull_request: https://github.com/python/cpython/pull/23692

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32381>
_______________________________________

From report at bugs.python.org  Tue Dec  8 08:48:29 2020
From: report at bugs.python.org (Harvastum)
Date: Tue, 08 Dec 2020 13:48:29 +0000
Subject: [issue42601] [doc] add more examples and additional explanation to
 re.sub
Message-ID: <1607435309.34.0.33576150552.issue42601@roundup.psfhosted.org>


New submission from Harvastum <harvastum at gmail.com>:

This entire page:
https://docs.python.org/3.10/library/re.html
does not have a single occurrence of the word "lambda".
In my humble opinion it's a pretty important trick to utilize capture groups in lambdas to e.g. use them to access value in a dictionary.
Examples are available here: https://stackoverflow.com/a/18737927/6380791
and here:
https://www.oreilly.com/library/view/python-cookbook/0596001673/ch03s15.html
but somehow not in the documentation.
There is a mention about referencing groups from different contexts, but the lambda is quite unique and although I think it does fall under "when processing match object m", I think it still is worth its own entry.

Btw. it's my first contribution here, sorry for any faux pas I may have commited, please point it out if I did!

----------
assignee: docs at python
components: Documentation
messages: 382736
nosy: docs at python, harvastum
priority: normal
severity: normal
status: open
title: [doc] add more examples and additional explanation to re.sub
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42601>
_______________________________________

From report at bugs.python.org  Tue Dec  8 08:52:42 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 08 Dec 2020 13:52:42 +0000
Subject: [issue40600] Add option to disallow > 1 instance of an extension
 module
In-Reply-To: <1589235149.46.0.0630975096351.issue40600@roundup.psfhosted.org>
Message-ID: <1607435562.78.0.929716905977.issue40600@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

Is it really necessary to add a slot/flag for this?
It can be done in about 10 lines as below, without complications like a global (or per-interpreter) registry of singleton modules.
Are there many modules that need to be per-interpreter singletons, but may be loaded in multiple interpreters? In my experience, it is really hard to ensure modules behave that way; if (if!) we need to add a dedicated API for this, I'd go for once-per-process.


static int loaded = 0;

static int
exec_module(PyObject* module)
{
    if (loaded) {
        PyErr_SetString(PyExc_ImportError,
                        "cannot load module more than once per process");
        return -1;
    }
    loaded = 1;
    // ... rest of initialization
}

----------
nosy: +petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40600>
_______________________________________

From report at bugs.python.org  Tue Dec  8 09:01:21 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 08 Dec 2020 14:01:21 +0000
Subject: [issue25191] test_getsetlocale_issue1813 failed on OpenBSD
In-Reply-To: <1442737878.41.0.0154038500687.issue25191@psf.upfronthosting.co.za>
Message-ID: <1607436081.97.0.607268406138.issue25191@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The problem with this patch is that the second assert is the point of the test.  Do get/set_locale work in the TR locale?

Although this issue came first, I am closing it as a duplicate of #37945 as the latter has extensive, but to date inconclusive, analysis and discussion.

----------
nosy: +terry.reedy
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> [Windows] locale.getdefaultlocale() issues on Windows: test_locale.test_getsetlocale_issue1813()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25191>
_______________________________________

From report at bugs.python.org  Tue Dec  8 09:06:02 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 08 Dec 2020 14:06:02 +0000
Subject: [issue37945]
 test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails
In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org>
Message-ID: <1607436362.71.0.827254772223.issue37945@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This seemingly useless test is the only test failure for me with installed 3.9.1.  Why keep it, at least on Windows.

The failure with "locale.Error: unsupported locale setting" is not limited to Windows.  #25191 and duplicate #31636 report the same error on user machines (non-buildbot, as here). #25191proposes the following patch to skip this failure.

-        locale.setlocale(locale.LC_CTYPE, loc)
-        self.assertEqual(loc, locale.getlocale(locale.LC_CTYPE))
+        try:
+            locale.setlocale(locale.LC_CTYPE, loc)
+            self.assertEqual(loc, locale.getlocale(locale.LC_CTYPE))
+        except locale.Error:
+            # Unsupported locale setting
+            self.skipTest('unsupported locale setting')

I believe that this is effectively the same as deleting the test.  But if we believe it is being skipped on at least Windows buildbots, then we should do the same at least on user Windows machines.  Or, if we could detect user manchines, skip on them.

----------
nosy: +serhiy.storchaka
title: [Windows] locale.getdefaultlocale() issues on Windows: test_locale.test_getsetlocale_issue1813() -> test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37945>
_______________________________________

From report at bugs.python.org  Tue Dec  8 09:42:45 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 14:42:45 +0000
Subject: [issue42599] Remove PyModule_GetWarningsModule() in pylifecycle.c
In-Reply-To: <1607426712.85.0.240458410103.issue42599@roundup.psfhosted.org>
Message-ID: <1607438565.55.0.513559276171.issue42599@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 0f91f586ae9b76c3bb44559bd8cd473b1b8de5ff by Hai Shi in branch 'master':
bpo-42599: Remove useless PyModule_GetWarningsModule() (GH-23691)
https://github.com/python/cpython/commit/0f91f586ae9b76c3bb44559bd8cd473b1b8de5ff


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42599>
_______________________________________

From report at bugs.python.org  Tue Dec  8 09:46:53 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 14:46:53 +0000
Subject: [issue42599] Remove PyModule_GetWarningsModule() in pylifecycle.c
In-Reply-To: <1607426712.85.0.240458410103.issue42599@roundup.psfhosted.org>
Message-ID: <1607438813.04.0.763324635554.issue42599@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> When was the visibility changed to hidden?

In Python 3.9:

commit 0b60f64e4343913b4931dc27379d9808e5b78fe1
Author: Vinay Sajip <vinay_sajip at yahoo.co.uk>
Date:   Tue Oct 15 08:26:12 2019 +0100

    bpo-11410: Standardize and use symbol visibility attributes across POSIX and Windows. (GH-16347)


Symbols which are not declared with PyAPI_FUNC() are no longer exported when using GCC or clang (any compiler supporting -fvisibility=hidden).


PyModule_GetWarningsModule() was not documented nor exported.

I merged the PR. If it breaks too many packages, we can consider to revert the change. But I expect that there are zero project using it.

Note: PyModule_GetWarningsModule() was not part of PC/python3dll.c neither, hopefully ;-)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42599>
_______________________________________

From report at bugs.python.org  Tue Dec  8 10:10:36 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 08 Dec 2020 15:10:36 +0000
Subject: [issue41910] Document that object.__eq__ implements `a is b`
In-Reply-To: <1601652122.88.0.984647748564.issue41910@roundup.psfhosted.org>
Message-ID: <1607440236.73.0.665350025679.issue41910@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +22562
pull_request: https://github.com/python/cpython/pull/23695

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41910>
_______________________________________

From report at bugs.python.org  Tue Dec  8 10:14:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 15:14:03 +0000
Subject: [issue39825] EXT_SUFFIX inconsistent between sysconfig and
 distutils.sysconfig (Windows)
In-Reply-To: <1583156407.62.0.364374237882.issue39825@roundup.psfhosted.org>
Message-ID: <1607440443.35.0.315976232128.issue39825@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39825>
_______________________________________

From report at bugs.python.org  Tue Dec  8 10:15:55 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 15:15:55 +0000
Subject: [issue40600] Add option to disallow > 1 instance of an extension
 module
In-Reply-To: <1589235149.46.0.0630975096351.issue40600@roundup.psfhosted.org>
Message-ID: <1607440555.79.0.986839867018.issue40600@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> static int loaded = 0;

I would like to limit an extension to once instance *per interpreter*.

See the atexit module for an example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40600>
_______________________________________

From report at bugs.python.org  Tue Dec  8 10:16:12 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 15:16:12 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1607440572.94.0.00818568832891.issue32381@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset f0e42ae03c41ec32fcb3064772f46ff7f2c5ff3b by Victor Stinner in branch '3.9':
bpo-32381: Fix PyRun_SimpleFileExFlags() encoding (GH-23642) (GH-23692)
https://github.com/python/cpython/commit/f0e42ae03c41ec32fcb3064772f46ff7f2c5ff3b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32381>
_______________________________________

From report at bugs.python.org  Tue Dec  8 10:19:43 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 15:19:43 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1607440783.93.0.0212822149501.issue32381@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22563
pull_request: https://github.com/python/cpython/pull/23696

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32381>
_______________________________________

From report at bugs.python.org  Tue Dec  8 10:30:07 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 08 Dec 2020 15:30:07 +0000
Subject: [issue41910] Document that object.__eq__ implements `a is b`
In-Reply-To: <1601652122.88.0.984647748564.issue41910@roundup.psfhosted.org>
Message-ID: <1607441406.99.0.507067003359.issue41910@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 4aa67853cc7d6ed4f9ebb726ceaa2c89f9feabda by Terry Jan Reedy in branch 'master':
 bpo-41910: move news entry  (GH-23695)
https://github.com/python/cpython/commit/4aa67853cc7d6ed4f9ebb726ceaa2c89f9feabda


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41910>
_______________________________________

From report at bugs.python.org  Tue Dec  8 10:45:55 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 08 Dec 2020 15:45:55 +0000
Subject: [issue41910] Document that object.__eq__ implements `a is b`
In-Reply-To: <1601652122.88.0.984647748564.issue41910@roundup.psfhosted.org>
Message-ID: <1607442355.62.0.288096855055.issue41910@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +22564
pull_request: https://github.com/python/cpython/pull/23697

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41910>
_______________________________________

From report at bugs.python.org  Tue Dec  8 10:46:31 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 08 Dec 2020 15:46:31 +0000
Subject: [issue40600] Add option to disallow > 1 instance of an extension
 module
In-Reply-To: <1589235149.46.0.0630975096351.issue40600@roundup.psfhosted.org>
Message-ID: <1607442391.81.0.800958023031.issue40600@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

Are there any other examples?

In my view, atexit is very special, and very closely tied to interpreter. I don't think it's good to design general API for one module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40600>
_______________________________________

From report at bugs.python.org  Tue Dec  8 10:54:25 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 08 Dec 2020 15:54:25 +0000
Subject: [issue41910] Document that object.__eq__ implements `a is b`
In-Reply-To: <1601652122.88.0.984647748564.issue41910@roundup.psfhosted.org>
Message-ID: <1607442865.07.0.807379718658.issue41910@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +22565
pull_request: https://github.com/python/cpython/pull/23698

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41910>
_______________________________________

From report at bugs.python.org  Tue Dec  8 10:55:37 2020
From: report at bugs.python.org (Myungbae Son)
Date: Tue, 08 Dec 2020 15:55:37 +0000
Subject: [issue42602] seekable() returns True on pipe objects in Windows
Message-ID: <1607442937.17.0.755090753747.issue42602@roundup.psfhosted.org>


New submission from Myungbae Son <nedsociety at gmail.com>:

>>> import os
>>> r, w = os.pipe()
>>> os.lseek(w, 10, 0)
10
>>> wf = open(w, 'w')
>>> wf.seekable()
True

This happens on Windows. Consequently seek() works for these objects but they seems to be no-op. This may confuse libraries that depend on seeking.

The named pipe objects (via CreateNamedPipe -> open_osfhandle -> open()) exhibit the same behavior.

----------
components: IO
messages: 382746
nosy: nedsociety
priority: normal
severity: normal
status: open
title: seekable() returns True on pipe objects in Windows
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42602>
_______________________________________

From report at bugs.python.org  Tue Dec  8 11:27:02 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 16:27:02 +0000
Subject: [issue40600] Add option to disallow > 1 instance of an extension
 module
In-Reply-To: <1589235149.46.0.0630975096351.issue40600@roundup.psfhosted.org>
Message-ID: <1607444822.58.0.0882109997597.issue40600@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I'm not 100% sure that preventing to create multiple module instances is needed. For the atexit module, another solution is to move the "module state" into the interpreter, as it has been done for other modules like _warnings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40600>
_______________________________________

From report at bugs.python.org  Tue Dec  8 11:31:31 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 08 Dec 2020 16:31:31 +0000
Subject: [issue40600] Add option to disallow > 1 instance of an extension
 module
In-Reply-To: <1589235149.46.0.0630975096351.issue40600@roundup.psfhosted.org>
Message-ID: <1607445091.81.0.158975739641.issue40600@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:

> another solution is to move the "module state" into the interpreter,

I am +1 on this solution if this module is a very special case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40600>
_______________________________________

From report at bugs.python.org  Tue Dec  8 11:37:01 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 08 Dec 2020 16:37:01 +0000
Subject: [issue42111] Make the xxlimited module an example of best extension
 module practices
In-Reply-To: <1603310336.9.0.27411366123.issue42111@roundup.psfhosted.org>
Message-ID: <1607445421.23.0.579050740765.issue42111@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c168b5078f88874b9acd993ac886f82269c780dd by Petr Viktorin in branch 'master':
bpo-42111: Make the xxlimited module an example of best extension module practices (GH-23226)
https://github.com/python/cpython/commit/c168b5078f88874b9acd993ac886f82269c780dd


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42111>
_______________________________________

From report at bugs.python.org  Tue Dec  8 11:42:39 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 16:42:39 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1607445759.93.0.485347560821.issue32381@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b5cf308de8b19bf8f77053013f7e8a944159e1aa by Victor Stinner in branch '3.8':
bpo-32381: Fix PyRun_SimpleFileExFlags() encoding (GH-23642) (GH-23692) (GH-23696)
https://github.com/python/cpython/commit/b5cf308de8b19bf8f77053013f7e8a944159e1aa


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32381>
_______________________________________

From report at bugs.python.org  Tue Dec  8 11:43:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 16:43:19 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1607445799.95.0.258811475195.issue32381@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

It's now fixed in 3.8, 3.9 and master branches.

Thanks for the bug report tianjg.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32381>
_______________________________________

From report at bugs.python.org  Tue Dec  8 11:51:05 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 08 Dec 2020 16:51:05 +0000
Subject: [issue40600] Add option to disallow > 1 instance of an extension
 module
In-Reply-To: <1589235149.46.0.0630975096351.issue40600@roundup.psfhosted.org>
Message-ID: <1607446265.21.0.715734444176.issue40600@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
pull_requests: +22566
pull_request: https://github.com/python/cpython/pull/23699

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40600>
_______________________________________

From report at bugs.python.org  Tue Dec  8 11:57:31 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 16:57:31 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1607446651.21.0.539731766712.issue32381@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22567
pull_request: https://github.com/python/cpython/pull/23700

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32381>
_______________________________________

From report at bugs.python.org  Tue Dec  8 12:11:57 2020
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 08 Dec 2020 17:11:57 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1607447517.97.0.567778159673.issue32381@roundup.psfhosted.org>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

Thanks for the fix and backports!

----------
resolution: fixed -> 
stage: resolved -> patch review
status: closed -> open
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32381>
_______________________________________

From report at bugs.python.org  Tue Dec  8 12:12:35 2020
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 08 Dec 2020 17:12:35 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1607447555.9.0.213650219926.issue32381@roundup.psfhosted.org>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32381>
_______________________________________

From report at bugs.python.org  Tue Dec  8 12:13:14 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 17:13:14 +0000
Subject: [issue35134] Add a new Include/cpython/ subdirectory for the "CPython
 API" with implementation details
In-Reply-To: <1541076409.33.0.788709270274.issue35134@psf.upfronthosting.co.za>
Message-ID: <1607447594.71.0.21351642112.issue35134@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22568
pull_request: https://github.com/python/cpython/pull/23701

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35134>
_______________________________________

From report at bugs.python.org  Tue Dec  8 12:21:11 2020
From: report at bugs.python.org (Ken Jin)
Date: Tue, 08 Dec 2020 17:21:11 +0000
Subject: [issue41559] Add support for PEP 612 to typing.py
In-Reply-To: <1597516564.62.0.520187732663.issue41559@roundup.psfhosted.org>
Message-ID: <1607448071.45.0.868585099962.issue41559@roundup.psfhosted.org>


Change by Ken Jin <kenjin4096 at gmail.com>:


----------
keywords: +patch
nosy: +kj
nosy_count: 1.0 -> 2.0
pull_requests: +22569
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/23702

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41559>
_______________________________________

From report at bugs.python.org  Tue Dec  8 12:47:01 2020
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 08 Dec 2020 17:47:01 +0000
Subject: [issue42602] seekable() returns True on pipe objects in Windows
In-Reply-To: <1607442937.17.0.755090753747.issue42602@roundup.psfhosted.org>
Message-ID: <1607449621.38.0.254633504211.issue42602@roundup.psfhosted.org>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

Yes, despite that MSVCRT knows the type of the file descriptor because it calls GetFileType() on its creation, it doesn't check it in lseek() implementation and simply calls SetFilePointer(), which spuriously succeeds for pipes. MSDN says the following[1]:

Calling the SetFilePointer function with a handle to a non-seeking device such as a pipe or a communications device is not supported, even though the SetFilePointer function may not return an error. The behavior of the SetFilePointer function in this case is undefined.

[1] https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-setfilepointer

----------
components: +Windows
nosy: +eryksun, izbyshev, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
versions: +Python 3.10, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42602>
_______________________________________

From report at bugs.python.org  Tue Dec  8 13:00:36 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 08 Dec 2020 18:00:36 +0000
Subject: [issue41910] Document that object.__eq__ implements `a is b`
In-Reply-To: <1601652122.88.0.984647748564.issue41910@roundup.psfhosted.org>
Message-ID: <1607450436.42.0.307586043025.issue41910@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset b947b305a6833cc059214d5bdd2065edd65024c4 by Terry Jan Reedy in branch '3.8':
[3.8] bpo-41910: move news entry (GH-23698)
https://github.com/python/cpython/commit/b947b305a6833cc059214d5bdd2065edd65024c4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41910>
_______________________________________

From report at bugs.python.org  Tue Dec  8 13:00:36 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 08 Dec 2020 18:00:36 +0000
Subject: [issue41910] Document that object.__eq__ implements `a is b`
In-Reply-To: <1601652122.88.0.984647748564.issue41910@roundup.psfhosted.org>
Message-ID: <1607450436.42.0.307586043025.issue41910@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset b947b305a6833cc059214d5bdd2065edd65024c4 by Terry Jan Reedy in branch '3.8':
[3.8] bpo-41910: move news entry (GH-23698)
https://github.com/python/cpython/commit/b947b305a6833cc059214d5bdd2065edd65024c4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41910>
_______________________________________

From report at bugs.python.org  Tue Dec  8 13:00:36 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 08 Dec 2020 18:00:36 +0000
Subject: [issue41910] Document that object.__eq__ implements `a is b`
In-Reply-To: <1601652122.88.0.984647748564.issue41910@roundup.psfhosted.org>
Message-ID: <1607450436.54.0.376307542441.issue41910@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset a3a4bf3b8dc79e4ec4f24f59bd1e9e2a75229112 by Terry Jan Reedy in branch '3.9':
[3.9] bpo-41910: move news entry (GH-23697)
https://github.com/python/cpython/commit/a3a4bf3b8dc79e4ec4f24f59bd1e9e2a75229112


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41910>
_______________________________________

From report at bugs.python.org  Tue Dec  8 13:07:44 2020
From: report at bugs.python.org (Manolis Stamatogiannakis)
Date: Tue, 08 Dec 2020 18:07:44 +0000
Subject: [issue42603] Tkinter: pkg-config is not used to get location of tcl
 and tk headers/libraries
Message-ID: <1607450864.79.0.446942772761.issue42603@roundup.psfhosted.org>


New submission from Manolis Stamatogiannakis <mstamat at gmail.com>:

This is indirectly related to 42541: If pkg-config settings are honoured, it is made easier to compile Python against a modern version of TCL/TK.

----------
components: Tkinter
messages: 382756
nosy: m000
priority: normal
severity: normal
status: open
title: Tkinter: pkg-config is not used to get location of tcl and tk headers/libraries
type: compile error
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42603>
_______________________________________

From report at bugs.python.org  Tue Dec  8 13:11:46 2020
From: report at bugs.python.org (hai shi)
Date: Tue, 08 Dec 2020 18:11:46 +0000
Subject: [issue40600] Add option to disallow > 1 instance of an extension
 module
In-Reply-To: <1589235149.46.0.0630975096351.issue40600@roundup.psfhosted.org>
Message-ID: <1607451106.86.0.59275198091.issue40600@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

> another solution is to move the "module state" into the interpreter,

OK, I am agree victor's solution too. It's a more simpler way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40600>
_______________________________________

From report at bugs.python.org  Tue Dec  8 13:12:27 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Tue, 08 Dec 2020 18:12:27 +0000
Subject: [issue42059] TypedDict(...) as function does not respect "total" when
 setting __required_keys__ and __optional_keys__
In-Reply-To: <1602926609.93.0.947551036861.issue42059@roundup.psfhosted.org>
Message-ID: <1607451147.61.0.606745060699.issue42059@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
nosy: +brandtbucher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42059>
_______________________________________

From report at bugs.python.org  Tue Dec  8 13:12:30 2020
From: report at bugs.python.org (paul j3)
Date: Tue, 08 Dec 2020 18:12:30 +0000
Subject: [issue42572] Better path handling with argparse
In-Reply-To: <1607121735.85.0.926277593776.issue42572@roundup.psfhosted.org>
Message-ID: <1607451150.45.0.62206207772.issue42572@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

The pathlib.Path is new since I paid much attention to os matters (I cut my teeth on py2.5).

Off hand it looks like the user could

    import pathlib
    parser.add_argument('-p', type=pathlib.Path)

to convert a string into a Path object.

A custom type function could call this, and apply any desired methods before returning the Path object. But that should be up to the user, not the `argparse` developers.

Importing path specific modules such as pathlib (which in turn has a lot of imports) goes against the attempt to reduce the number of unnecessary imports with modules like argparse.

https://bugs.python.org/issue30152
Reduce the number of imports for argparse

After this diet argparse still imports os, and uses:

    os.path.basename

I might also note that argparse has only one custom 'type' function, the FileType factory.  Other common type functions like 'int' and 'float' are Python builtin's.  Adding a custom 'bool' (to be used instead of the builtin 'bool') has been rejected.

https://bugs.python.org/issue37564

json, yaml, and datetime types have also been rejected
https://bugs.python.org/issue35005

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42572>
_______________________________________

From report at bugs.python.org  Tue Dec  8 14:14:24 2020
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 08 Dec 2020 19:14:24 +0000
Subject: [issue41907] Regression in IntFlag behaviour in f-string
In-Reply-To: <1601606290.92.0.604621625655.issue41907@roundup.psfhosted.org>
Message-ID: <1607454864.95.0.0941562622966.issue41907@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset 37440eef7f9a0c27e13fc9ce0850574bb00688b0 by Ethan Furman in branch 'master':
bpo-41907: [Enum] fix format() behavior for IntFlag (GH-22497)
https://github.com/python/cpython/commit/37440eef7f9a0c27e13fc9ce0850574bb00688b0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41907>
_______________________________________

From report at bugs.python.org  Tue Dec  8 14:14:57 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 08 Dec 2020 19:14:57 +0000
Subject: [issue41907] Regression in IntFlag behaviour in f-string
In-Reply-To: <1601606290.92.0.604621625655.issue41907@roundup.psfhosted.org>
Message-ID: <1607454897.77.0.942840807463.issue41907@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 6.0 -> 7.0
pull_requests: +22570
pull_request: https://github.com/python/cpython/pull/23703

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41907>
_______________________________________

From report at bugs.python.org  Tue Dec  8 14:15:08 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 08 Dec 2020 19:15:08 +0000
Subject: [issue41907] Regression in IntFlag behaviour in f-string
In-Reply-To: <1601606290.92.0.604621625655.issue41907@roundup.psfhosted.org>
Message-ID: <1607454908.11.0.335640732152.issue41907@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22571
pull_request: https://github.com/python/cpython/pull/23704

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41907>
_______________________________________

From report at bugs.python.org  Tue Dec  8 14:35:29 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 08 Dec 2020 19:35:29 +0000
Subject: [issue42572] Better path handling with argparse
In-Reply-To: <1607121735.85.0.926277593776.issue42572@roundup.psfhosted.org>
Message-ID: <1607456129.94.0.617824012481.issue42572@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

The more I think about this, the more I think it shouldn't be in the stdlib. paul.j3 is correct that the simple case is just type=pathlib.Path.

For something more adventurous you could start with:

@dataclass(eq=True, frozen=True)
class ArgumentPath:
    must_exist: bool = False
    # Add other conditions as needed.

    def __call__(self, val):
        result = Path(val)
        if self.must_exist:
            if not result.exists():
                raise ValueError(f"path {result} must exist")
        return result

The reason I think this shouldn't be in the stdlib is that there are race conditions here between when you inspect the filesystem and when you'd actually use the path. What if the file was deleting, or it went from being a directory to a file?

I think the best advice is to use type=pathlib.Path, and handle anything else when you try to cd, or open, or whatever it is you're doing with the path.

It probably wouldn't hurt to document type=pathlib.Path in the argparse docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42572>
_______________________________________

From report at bugs.python.org  Tue Dec  8 14:35:55 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 08 Dec 2020 19:35:55 +0000
Subject: [issue24110] zipfile.ZipFile.write() does not accept bytes arcname
In-Reply-To: <1430515803.94.0.193757537296.issue24110@psf.upfronthosting.co.za>
Message-ID: <1607456155.08.0.944546060893.issue24110@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

That part of the documentation was updated here by Serhiy: https://github.com/python/cpython/pull/10592

----------
nosy: +iritkatriel

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24110>
_______________________________________

From report at bugs.python.org  Tue Dec  8 14:52:36 2020
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 08 Dec 2020 19:52:36 +0000
Subject: [issue41907] Regression in IntFlag behaviour in f-string
In-Reply-To: <1601606290.92.0.604621625655.issue41907@roundup.psfhosted.org>
Message-ID: <1607457156.34.0.446943631059.issue41907@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset 14eaa7d75282d8458455c41e9e871c56db8b9a10 by Miss Islington (bot) in branch '3.9':
bpo-41907: [Enum] fix format() behavior for IntFlag (GH-22497) (GH-23703)
https://github.com/python/cpython/commit/14eaa7d75282d8458455c41e9e871c56db8b9a10


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41907>
_______________________________________

From report at bugs.python.org  Tue Dec  8 14:53:07 2020
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 08 Dec 2020 19:53:07 +0000
Subject: [issue41907] Regression in IntFlag behaviour in f-string
In-Reply-To: <1601606290.92.0.604621625655.issue41907@roundup.psfhosted.org>
Message-ID: <1607457186.99.0.429888261487.issue41907@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset cbfcc67170d459bcf3e9d63d2f44eadec740bf69 by Miss Islington (bot) in branch '3.8':
bpo-41907: [Enum] fix format() behavior for IntFlag (GH-22497) (GH-23704)
https://github.com/python/cpython/commit/cbfcc67170d459bcf3e9d63d2f44eadec740bf69


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41907>
_______________________________________

From report at bugs.python.org  Tue Dec  8 14:54:13 2020
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 08 Dec 2020 19:54:13 +0000
Subject: [issue41907] Regression in IntFlag behaviour in f-string
In-Reply-To: <1601606290.92.0.604621625655.issue41907@roundup.psfhosted.org>
Message-ID: <1607457253.19.0.451994490383.issue41907@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41907>
_______________________________________

From report at bugs.python.org  Tue Dec  8 15:10:43 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 08 Dec 2020 20:10:43 +0000
Subject: [issue41559] Add support for PEP 612 to typing.py
In-Reply-To: <1597516564.62.0.520187732663.issue41559@roundup.psfhosted.org>
Message-ID: <1607458243.25.0.781268189698.issue41559@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Thanks for working on this -- let me know when you have a question for me. Once this is ready we should also add it to the typing_extensions module so people can use it on older Python versions. (https://github.com/python/typing/tree/master/typing_extensions)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41559>
_______________________________________

From report at bugs.python.org  Tue Dec  8 15:13:23 2020
From: report at bugs.python.org (E. Paine)
Date: Tue, 08 Dec 2020 20:13:23 +0000
Subject: [issue42603] Tkinter: pkg-config is not used to get location of tcl
 and tk headers/libraries
In-Reply-To: <1607450864.79.0.446942772761.issue42603@roundup.psfhosted.org>
Message-ID: <1607458403.9.0.844900731971.issue42603@roundup.psfhosted.org>


Change by E. Paine <paineelisha at gmail.com>:


----------
components: +Build
nosy: +epaine, serhiy.storchaka
type: compile error -> enhancement
versions:  -Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42603>
_______________________________________

From report at bugs.python.org  Tue Dec  8 15:40:41 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 08 Dec 2020 20:40:41 +0000
Subject: [issue42572] Better path handling with argparse
In-Reply-To: <1607121735.85.0.926277593776.issue42572@roundup.psfhosted.org>
Message-ID: <1607460041.83.0.395297121972.issue42572@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Agreed that we should not include new functionality here and instead just update the docs to show what can currently be done.

I'll write-up a documentation patch for this.

----------
assignee:  -> rhettinger
components: +Documentation -Library (Lib)
versions: +Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42572>
_______________________________________

From report at bugs.python.org  Tue Dec  8 16:35:56 2020
From: report at bugs.python.org (Austin Scola)
Date: Tue, 08 Dec 2020 21:35:56 +0000
Subject: [issue42572] Better path handling with argparse
In-Reply-To: <1607121735.85.0.926277593776.issue42572@roundup.psfhosted.org>
Message-ID: <1607463356.68.0.389029301872.issue42572@roundup.psfhosted.org>


Austin Scola <austinscola at gmail.com> added the comment:

I think that type=pathlib.Path is probably all that I was looking for here. I was unaware types could be passed easily like that and so updated documentation would definitely be helpful. The predicates such as existence would just have been nice-to-haves, but not necessary (and eric.smith brings up a good point about race conditions).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42572>
_______________________________________

From report at bugs.python.org  Tue Dec  8 16:53:22 2020
From: report at bugs.python.org (mattip)
Date: Tue, 08 Dec 2020 21:53:22 +0000
Subject: [issue42604] EXT_SUFFIX too short on FreeBSD and AIX
Message-ID: <1607464402.35.0.336960410788.issue42604@roundup.psfhosted.org>


New submission from mattip <matti.picus at gmail.com>:

Continuation of bpo 39825, this time for FreeBSD and AIX. As commented there, the test added in the fix to 39825 fails on FreeBSD and AIX:

FAIL: test_EXT_SUFFIX_in_vars (test.test_sysconfig.TestSysConfig)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd-564d/build/Lib/test/test_sysconfig.py", line 368, in test_EXT_SUFFIX_in_vars
    self.assertEqual(vars['EXT_SUFFIX'], _imp.extension_suffixes()[0])
AssertionError: '.so' != '.cpython-310d.so'
- .so
+ .cpython-310d.so

So somehow EXT_SUFFIX is being set to .so rather than .cpython-310d.so.

It seems the difference in EXT_SUFFIX comes from this stanza in configure:

case $ac_sys_system in
    Linux*|GNU*|Darwin|VxWorks)
	EXT_SUFFIX=.${SOABI}${SHLIB_SUFFIX};;
    *)
	EXT_SUFFIX=${SHLIB_SUFFIX};;
esac

where $ac_sys_system is `uname -s`. On FREEBSD, this is "FreeBSD", and I think on AIX it is "AIX". My preference would be to always set EXT_SUFFIX to ${SOABI}${SHLIB_SUFFIX}, with no option for setting it to a different value. Does that seem right?

----------
components: Build
messages: 382767
nosy: mattip, vstinner
priority: normal
severity: normal
status: open
title: EXT_SUFFIX too short on FreeBSD and AIX
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42604>
_______________________________________

From report at bugs.python.org  Tue Dec  8 16:54:24 2020
From: report at bugs.python.org (Michael Felt)
Date: Tue, 08 Dec 2020 21:54:24 +0000
Subject: [issue41625] Add splice() to the os module
In-Reply-To: <1598284638.54.0.211220433787.issue41625@roundup.psfhosted.org>
Message-ID: <1607464464.79.0.481778755029.issue41625@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

Sorry Victor - family matters - so I was not watching for several days.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41625>
_______________________________________

From report at bugs.python.org  Tue Dec  8 17:09:01 2020
From: report at bugs.python.org (mattip)
Date: Tue, 08 Dec 2020 22:09:01 +0000
Subject: [issue42604] EXT_SUFFIX too short on FreeBSD and AIX
In-Reply-To: <1607464402.35.0.336960410788.issue42604@roundup.psfhosted.org>
Message-ID: <1607465341.54.0.770256848848.issue42604@roundup.psfhosted.org>


Change by mattip <matti.picus at gmail.com>:


----------
keywords: +patch
pull_requests: +22572
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23708

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42604>
_______________________________________

From report at bugs.python.org  Tue Dec  8 17:20:53 2020
From: report at bugs.python.org (Manolis Stamatogiannakis)
Date: Tue, 08 Dec 2020 22:20:53 +0000
Subject: [issue42603] Tkinter: pkg-config is not used to get location of tcl
 and tk headers/libraries
In-Reply-To: <1607450864.79.0.446942772761.issue42603@roundup.psfhosted.org>
Message-ID: <1607466053.9.0.219222038806.issue42603@roundup.psfhosted.org>


Manolis Stamatogiannakis <mstamat at gmail.com> added the comment:

I already have a patch to fix this. Waiting for my CLA to be registered before creating a PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42603>
_______________________________________

From report at bugs.python.org  Tue Dec  8 17:51:35 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 22:51:35 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1607467895.09.0.835772738761.issue32381@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 815506d852daabc40e14ff0987c1142c0205fbe7 by Victor Stinner in branch 'master':
bpo-32381: Rewrite PyErr_ProgramText() (GH-23700)
https://github.com/python/cpython/commit/815506d852daabc40e14ff0987c1142c0205fbe7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32381>
_______________________________________

From report at bugs.python.org  Tue Dec  8 17:51:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 22:51:57 +0000
Subject: [issue35134] Add a new Include/cpython/ subdirectory for the "CPython
 API" with implementation details
In-Reply-To: <1541076409.33.0.788709270274.issue35134@psf.upfronthosting.co.za>
Message-ID: <1607467917.78.0.721675900962.issue35134@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset fe6e5e7cfd68eeaa69fd1511f354a1b4d8d90990 by Victor Stinner in branch 'master':
bpo-35134: Add Include/cpython/pythonrun.h file (GH-23701)
https://github.com/python/cpython/commit/fe6e5e7cfd68eeaa69fd1511f354a1b4d8d90990


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35134>
_______________________________________

From report at bugs.python.org  Tue Dec  8 18:00:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 23:00:16 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1607468416.89.0.644738030226.issue32381@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22573
pull_request: https://github.com/python/cpython/pull/23709

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32381>
_______________________________________

From report at bugs.python.org  Tue Dec  8 18:01:42 2020
From: report at bugs.python.org (paul j3)
Date: Tue, 08 Dec 2020 23:01:42 +0000
Subject: [issue42572] Better path handling with argparse
In-Reply-To: <1607121735.85.0.926277593776.issue42572@roundup.psfhosted.org>
Message-ID: <1607468502.97.0.825209787665.issue42572@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

One caution - the type parameter is a callable (function) that takes one string as argument.  I proposed `pathlib.Path` because it does that, returning a Path object.  It's a class instance creator.  I believe the module has other class initiators.

bool() has confused many users.  While it returns a bool class instance, True or False, the only string that returns False is the empty one, with argparse can't supply. It does not convert strings like 'False' or 'no' to boolean False.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42572>
_______________________________________

From report at bugs.python.org  Tue Dec  8 18:18:45 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 23:18:45 +0000
Subject: [issue41443] some test cases in test_posix.py fail if some os
 attributes are not supported
In-Reply-To: <1596106142.56.0.534494527465.issue41443@roundup.psfhosted.org>
Message-ID: <1607469525.47.0.0828509980186.issue41443@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset eb7594f85741ef809b1ee337ee3431df20e6f8bb by pxinwr in branch 'master':
bpo-41443:  Add more attribute checking in test_posix (GH-21688)
https://github.com/python/cpython/commit/eb7594f85741ef809b1ee337ee3431df20e6f8bb


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41443>
_______________________________________

From report at bugs.python.org  Tue Dec  8 18:20:22 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 23:20:22 +0000
Subject: [issue41439] test_uuid.py and test_ssl.py failure on OSes without
 os.fork (VxWorks RTOS)
In-Reply-To: <1596089205.38.0.465991237875.issue41439@roundup.psfhosted.org>
Message-ID: <1607469622.87.0.680937163214.issue41439@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 98a54171932584883cb3973f78dd30f92d7a3a78 by pxinwr in branch 'master':
bpo-41439: Skip test_ssl and test_uuid tests if fork() is not supported (GH-21684)
https://github.com/python/cpython/commit/98a54171932584883cb3973f78dd30f92d7a3a78


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41439>
_______________________________________

From report at bugs.python.org  Tue Dec  8 18:22:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 23:22:46 +0000
Subject: [issue41439] test_uuid.py and test_ssl.py failure on OSes without
 os.fork (VxWorks RTOS)
In-Reply-To: <1596089205.38.0.465991237875.issue41439@roundup.psfhosted.org>
Message-ID: <1607469766.61.0.263959708353.issue41439@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks Peixing Xin, I merged your fix.

Terry:
> I could merge and backport

I don't think that it's worth it to backport to 3.9: Python 3.9 doesn't support VxWorks. I prefer to only merge VxWorks changes in the master branch.

Terry:
> We do not put conditions for unsupported oses in production code, but I don't know about skips for such systems in tests.

The final change is not specific to VxWorks and so reasonable.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41439>
_______________________________________

From report at bugs.python.org  Tue Dec  8 18:23:28 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 23:23:28 +0000
Subject: [issue41443] some test cases in test_posix.py fail if some os
 attributes are not supported
In-Reply-To: <1596106142.56.0.534494527465.issue41443@roundup.psfhosted.org>
Message-ID: <1607469808.2.0.430241765845.issue41443@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41443>
_______________________________________

From report at bugs.python.org  Tue Dec  8 18:24:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 23:24:37 +0000
Subject: [issue41442] test_posix.PosixTester.test_getgroups fail on operating
 systems without supporting unix shell
In-Reply-To: <1596103524.36.0.943373328991.issue41442@roundup.psfhosted.org>
Message-ID: <1607469877.07.0.658715655754.issue41442@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
superseder:  -> Python should support VxWorks RTOS

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41442>
_______________________________________

From report at bugs.python.org  Tue Dec  8 18:33:02 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 23:33:02 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1607470382.28.0.334054622556.issue32381@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 550e4673be538d98b6ddf5550b3922539cf5c4b2 by Victor Stinner in branch 'master':
bpo-32381: Add _PyRun_SimpleFileObject() (GH-23709)
https://github.com/python/cpython/commit/550e4673be538d98b6ddf5550b3922539cf5c4b2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32381>
_______________________________________

From report at bugs.python.org  Tue Dec  8 18:36:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 23:36:58 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1607470618.27.0.632498436619.issue32381@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22574
pull_request: https://github.com/python/cpython/pull/23711

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32381>
_______________________________________

From report at bugs.python.org  Tue Dec  8 18:38:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 08 Dec 2020 23:38:21 +0000
Subject: [issue42569] Callers of _Py_fopen/_Py_wfopen may be broken after
 addition of audit hooks
In-Reply-To: <1607098353.32.0.624763724813.issue42569@roundup.psfhosted.org>
Message-ID: <1607470701.42.0.98540127312.issue42569@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I wrote PR 23711 (for bpo-32381) which removes half of the problem: it removes _Py_fopen() :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42569>
_______________________________________

From report at bugs.python.org  Tue Dec  8 18:44:35 2020
From: report at bugs.python.org (Ken Jin)
Date: Tue, 08 Dec 2020 23:44:35 +0000
Subject: [issue41559] Add support for PEP 612 to typing.py
In-Reply-To: <1607458243.25.0.781268189698.issue41559@roundup.psfhosted.org>
Message-ID: <CAOMZG7h+-8eiu6hty49J9o5s8tgT=sRbAcZquuAZRoA-mc7Daw@mail.gmail.com>


Ken Jin <kenjin4096 at gmail.com> added the comment:

I have a one question:
Should ParamSpec be treated as a type of TypeVar? This mostly pertains to
adding it to __parameters__ of generic aliases. Type substitution/chaining,
seems inappropiate for it right now.

Thanks for your help!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41559>
_______________________________________

From report at bugs.python.org  Tue Dec  8 19:22:36 2020
From: report at bugs.python.org (Alexey Izbyshev)
Date: Wed, 09 Dec 2020 00:22:36 +0000
Subject: [issue42569] Callers of _Py_fopen/_Py_wfopen may be broken after
 addition of audit hooks
In-Reply-To: <1607098353.32.0.624763724813.issue42569@roundup.psfhosted.org>
Message-ID: <1607473356.57.0.192417476909.issue42569@roundup.psfhosted.org>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

Great approach :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42569>
_______________________________________

From report at bugs.python.org  Tue Dec  8 19:30:44 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Dec 2020 00:30:44 +0000
Subject: [issue39573] [C API] Make PyObject an opaque structure in the limited
 C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1607473844.77.0.548239337779.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> pyside2 https://bugzilla.redhat.com/show_bug.cgi?id=1898974

I proposed a fix upstream: https://bugreports.qt.io/browse/PYSIDE-1436 I also wrote a fix in Fedora: https://src.fedoraproject.org/rpms/python-pyside2/pull-request/7 The issue is now tracked in Fedora as: https://bugzilla.redhat.com/show_bug.cgi?id=1902618

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Tue Dec  8 19:45:01 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Dec 2020 00:45:01 +0000
Subject: [issue39573] [C API] Make PyObject an opaque structure in the limited
 C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1607474701.93.0.0469288255244.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> bitarray https://bugzilla.redhat.com/show_bug.cgi?id=1897536

I created https://github.com/ilanschnell/bitarray/pull/109

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Tue Dec  8 20:08:23 2020
From: report at bugs.python.org (Aleksey Vlasenko)
Date: Wed, 09 Dec 2020 01:08:23 +0000
Subject: [issue42605] dir_util.copy_tree crashes if folder it previously
 created is removed
Message-ID: <1607476103.38.0.0125735789387.issue42605@roundup.psfhosted.org>


New submission from Aleksey Vlasenko <vlasenkoalexey at gmail.com>:

Minimal example:

import os
import shutil
from distutils import dir_util

shutil.rmtree('folder1')

os.makedirs('folder1/folder2/folder3/')
with open('folder1/folder2/folder3/data.txt', 'w') as fp:
    fp.write('hello')
    
print(os.path.exists('folder1/new_folder2')) # -> prints false
dir_util.copy_tree('folder1/folder2', 'folder1/new_folder2') # -> works

shutil.rmtree('folder1/new_folder2')
print(os.path.exists('folder1/new_folder2')) # -> prints false
dir_util.copy_tree('folder1/folder2', 'folder1/new_folder2') # -> crashes

---------------------------------------------------------------------------
FileNotFoundError                         Traceback (most recent call last)
/opt/conda/lib/python3.7/distutils/file_util.py in _copy_file_contents(src, dst, buffer_size)
     40         try:
---> 41             fdst = open(dst, 'wb')
     42         except OSError as e:

FileNotFoundError: [Errno 2] No such file or directory: 'folder1/new_folder2/folder3/data.txt'

dir_util caches folders it previously created in a static global variable _path_created which is a bad idea:
https://github.com/python/cpython/blob/master/Lib/distutils/dir_util.py

----------
components: Distutils
messages: 382782
nosy: dstufft, eric.araujo, vlasenkoalexey
priority: normal
severity: normal
status: open
title: dir_util.copy_tree crashes if folder it previously created is removed
type: crash
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42605>
_______________________________________

From report at bugs.python.org  Tue Dec  8 20:13:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Dec 2020 01:13:17 +0000
Subject: [issue39573] [C API] Make PyObject an opaque structure in the limited
 C API
In-Reply-To: <1581030432.16.0.48160379721.issue39573@roundup.psfhosted.org>
Message-ID: <1607476397.46.0.293247492338.issue39573@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> boost https://bugzilla.redhat.com/show_bug.cgi?id=1896382

I proposed https://github.com/boostorg/python/pull/330 fix.

See also https://github.com/boostorg/python/pull/329

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39573>
_______________________________________

From report at bugs.python.org  Tue Dec  8 22:12:46 2020
From: report at bugs.python.org (Alexey Izbyshev)
Date: Wed, 09 Dec 2020 03:12:46 +0000
Subject: [issue42606] Support POSIX atomicity guarantee of O_APPEND on Windows
Message-ID: <1607483566.95.0.1927829703.issue42606@roundup.psfhosted.org>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

On POSIX-conforming systems, O_APPEND flag for open() must ensure that no intervening file modification occurs between changing the file offset and the write operation[1]. In effect, two processes that independently opened the same file with O_APPEND can't overwrite each other's data. On Windows, however, the Microsoft C runtime implements O_APPEND as an lseek(fd, 0, SEEK_END) followed by write(), which obviously doesn't provide the above guarantee. This affects both os.open() and the builtin open() Python functions, which rely on _wopen() from MSVCRT. A demo is attached.

While POSIX O_APPEND doesn't guarantee the absence of partial writes, the guarantee of non-overlapping writes alone is still useful in cases such as debug logging from multiple processes without file locking or other synchronization. Moreover, for local filesystems, partial writes don't really occur in practice (barring conditions such as ENOSPC or EIO).

Windows offers two ways to achieve non-overlapping appends:

1. WriteFile()[2] with OVERLAPPED structure with Offset and OffsetHigh set to -1. This is essentially per-write O_APPEND.

2. Using a file handle with FILE_APPEND_DATA access right but without FILE_WRITE_DATA access right.

While (1) seems easy to add to FileIO, there are some problems:

* os.write(fd) can't use it without caller's help because it has no way to know that the fd was opened with O_APPEND (there is no fcntl() in MSVCRT)

* write() from MSVCRT (currently used by FileIO) performs some additional remapping of error codes and checks after it calls WriteFile(), so we'd have to emulate that behavior or risk breaking compatibility.

I considered to go for (2) by reimplementing _wopen() via CreateFile(), which would also allow us to solve a long-standing issue of missing FILE_SHARE_DELETE on file handles, but hit several problems:

* the most serious one is rather silly: we need to honor the current umask to possibly create a read-only file, but there is no way to query it without changing it, which is not thread-safe. Well, actually, I did discover a way: _umask_s(), when called with an invalid mask, returns both EINVAL error and the current umask. But this behavior directly contradicts MSDN, which claims that _umask_s() doesn't modify its second argument on failure[3]. So I'm not willing to rely on this until Microsoft fixes their docs.

* os module exposes some MSVCRT-specific flags for use with os.open() (like O_TEMPORARY), which a reimplementation would have to support. It seems easy in most cases, but there is O_TEXT, which enables some obscure legacy behavior in MSVCRT such as removal of a trailing byte 26 (Ctrl-Z) when a file is opened with O_RDWR. More generally, it's unclear to me whether os.open() is explicitly intended to be a gateway to MSVCRT and thus support all current and future flags or is just expected to work similarly to MSVCRT in common cases.

So in the end I decided to let _wopen() create the initial fd as usual, but then fix it up via DuplicateHandle() -- see the PR.

[1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/write.html
[2] https://docs.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-writefile
[3] https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/umask-s?view=msvc-160

----------
components: IO, Windows
files: test.py
messages: 382784
nosy: eryksun, izbyshev, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
priority: normal
severity: normal
status: open
title: Support POSIX atomicity guarantee of O_APPEND on Windows
type: enhancement
versions: Python 3.10
Added file: https://bugs.python.org/file49661/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42606>
_______________________________________

From report at bugs.python.org  Tue Dec  8 22:16:13 2020
From: report at bugs.python.org (Alexey Izbyshev)
Date: Wed, 09 Dec 2020 03:16:13 +0000
Subject: [issue42606] Support POSIX atomicity guarantee of O_APPEND on Windows
In-Reply-To: <1607483566.95.0.1927829703.issue42606@roundup.psfhosted.org>
Message-ID: <1607483773.51.0.63083655142.issue42606@roundup.psfhosted.org>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
keywords: +patch
pull_requests: +22575
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23712

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42606>
_______________________________________

From report at bugs.python.org  Tue Dec  8 22:18:11 2020
From: report at bugs.python.org (=?utf-8?b?5a6J6L+3?=)
Date: Wed, 09 Dec 2020 03:18:11 +0000
Subject: [issue42607] raw strings SyntaxError
Message-ID: <1607483891.66.0.214609891347.issue42607@roundup.psfhosted.org>


New submission from ?? <anmikf at qq.com>:

[test at test ~]# python3 -c 'print(r"\n")'
\n
[test at test ~]# python3 -c 'print(r"n\")'
  File "<string>", line 1
    print(r"n\")
               ^
SyntaxError: EOL while scanning string literal

----------
components: Windows
messages: 382785
nosy: anmikf, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: raw strings SyntaxError
type: behavior
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42607>
_______________________________________

From report at bugs.python.org  Tue Dec  8 23:16:03 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 09 Dec 2020 04:16:03 +0000
Subject: [issue42607] raw strings SyntaxError
In-Reply-To: <1607483891.66.0.214609891347.issue42607@roundup.psfhosted.org>
Message-ID: <1607487363.35.0.500741946172.issue42607@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

This is a FAQ: https://docs.python.org/3/faq/design.html#why-can-t-raw-strings-r-strings-end-with-a-backslash

Raw strings can't end with an odd number of backslashes.

----------
components:  -Windows
nosy: +eric.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42607>
_______________________________________

From report at bugs.python.org  Wed Dec  9 01:18:35 2020
From: report at bugs.python.org (Nishant Gautam)
Date: Wed, 09 Dec 2020 06:18:35 +0000
Subject: [issue42456] Logical Error
In-Reply-To: <1606277996.92.0.109667336628.issue42456@roundup.psfhosted.org>
Message-ID: <1607494714.99.0.124078710393.issue42456@roundup.psfhosted.org>


Nishant Gautam <ng29834 at gmail.com> added the comment:

a = 10

b = 10


if (a >= b) & (a & b) & (a == b):

        print("Yes")

else:

        print("No")

Output: No

This is the bug because all then condition in if is true but it print No, This is the vulnerability of this code.

----------
resolution: not a bug -> 
status: closed -> open
versions: +Python 3.6, Python 3.7, Python 3.9
Added file: https://bugs.python.org/file49662/main.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42456>
_______________________________________

From report at bugs.python.org  Wed Dec  9 01:29:09 2020
From: report at bugs.python.org (Tim Peters)
Date: Wed, 09 Dec 2020 06:29:09 +0000
Subject: [issue42456] Logical Error
In-Reply-To: <1606277996.92.0.109667336628.issue42456@roundup.psfhosted.org>
Message-ID: <1607495349.24.0.898498329684.issue42456@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

Please ask for help on StackOverflow or the general Python mailing list. Your understanding of the operations is incorrect.

"&" is NOT a logical operator ("and" is). It's a bitwise operator on integers.

>>> 10 & 10
10
>>> bin(10)
'0b1010'

The last bit is 0, so when you "&" the result with True (which is equivalent to integer 1) the result is 0:

>>> (10 & 10) & True
0

and the integer 0 is treated as False in a Boolean context.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42456>
_______________________________________

From report at bugs.python.org  Wed Dec  9 01:37:32 2020
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 09 Dec 2020 06:37:32 +0000
Subject: [issue42567] Enum: manually call __init_subclass__ after members are
 added
In-Reply-To: <1607093463.71.0.994675423727.issue42567@roundup.psfhosted.org>
Message-ID: <1607495852.13.0.770125096048.issue42567@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
keywords: +patch
pull_requests: +22576
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/23714

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42567>
_______________________________________

From report at bugs.python.org  Wed Dec  9 01:47:59 2020
From: report at bugs.python.org (Shantanu)
Date: Wed, 09 Dec 2020 06:47:59 +0000
Subject: [issue39791] New `files()` api from importlib_resources.
In-Reply-To: <1582949490.73.0.868974160192.issue39791@roundup.psfhosted.org>
Message-ID: <1607496479.63.0.925209345228.issue39791@roundup.psfhosted.org>


Change by Shantanu <hauntsaninja at gmail.com>:


----------
nosy: +hauntsaninja
nosy_count: 8.0 -> 9.0
pull_requests: +22577
pull_request: https://github.com/python/cpython/pull/23715

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39791>
_______________________________________

From report at bugs.python.org  Wed Dec  9 02:02:32 2020
From: report at bugs.python.org (mattip)
Date: Wed, 09 Dec 2020 07:02:32 +0000
Subject: [issue42504] Failure to build with MACOSX_DEPLOYMENT_TARGET=11 on Big
 Sur
In-Reply-To: <1606662964.61.0.531913261121.issue42504@roundup.psfhosted.org>
Message-ID: <1607497352.37.0.418542881409.issue42504@roundup.psfhosted.org>


mattip <matti.picus at gmail.com> added the comment:

It seems the approach that "The code for sysconfig.get_config_var() has a pretty clear intent: it will try to cast its return value to an int." has been accepted as true even though other parts of the code assumed the returned value was a string, and the CPython code was updated appropriately. This is causing problems for downstream libraries like NumPy, see https://github.com/numpy/numpy/pull/17906. If CPython does not wish to reconsider this decision, it should at least be documented clearly via a type hint and/or in the documentation for sysconfig.get_config_var https://docs.python.org/3/library/sysconfig.html#sysconfig.get_config_var

----------
nosy: +mattip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42504>
_______________________________________

From report at bugs.python.org  Wed Dec  9 02:29:08 2020
From: report at bugs.python.org (Peixing Xin)
Date: Wed, 09 Dec 2020 07:29:08 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1607498948.42.0.152391378235.issue31904@roundup.psfhosted.org>


Change by Peixing Xin <peixing.xin at windriver.com>:


----------
pull_requests: +22578
pull_request: https://github.com/python/cpython/pull/23716

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Wed Dec  9 04:14:29 2020
From: report at bugs.python.org (ali)
Date: Wed, 09 Dec 2020 09:14:29 +0000
Subject: [issue42608] Installation failed from source code on Debian
 ([307/416] test_socket)
Message-ID: <1607505269.45.0.398750468222.issue42608@roundup.psfhosted.org>


New submission from ali <ali.azimzadeh70 at gmail.com>:

I'm following guide below to install Python3.7 from source on Debian-64Bit.

https://linuxize.com/post/how-to-install-python-3-7-on-ubuntu-18-04/

I'm installing Python3.7.9-final-64bit.

But `make -j 8` hanged out more than 2 hours  on:
0:22:43 load avg: 1.29 [307/416] test_socket

How to fix it !/?

----------
components: Build
messages: 382790
nosy: alimp5
priority: normal
severity: normal
status: open
title: Installation failed from source code on Debian ([307/416] test_socket)
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42608>
_______________________________________

From report at bugs.python.org  Wed Dec  9 06:05:07 2020
From: report at bugs.python.org (Erik Lamers)
Date: Wed, 09 Dec 2020 11:05:07 +0000
Subject: [issue42609] Eval with two high string multiplication crashes newer
 Python versions
Message-ID: <1607511907.66.0.321451468972.issue42609@roundup.psfhosted.org>


New submission from Erik Lamers <mail at eriklamers.nl>:

For Python version 3.7 and above the following statement will end up in a segfault.

eval("1 + 100"*1000000)

Whereas Python versions 3.6 and below would tread this as a Recursion error.

----------
components: Interpreter Core
messages: 382791
nosy: Erik-Lamers1
priority: normal
severity: normal
status: open
title: Eval with two high string multiplication crashes newer Python versions
type: crash
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42609>
_______________________________________

From report at bugs.python.org  Wed Dec  9 06:05:21 2020
From: report at bugs.python.org (Erik Lamers)
Date: Wed, 09 Dec 2020 11:05:21 +0000
Subject: [issue42609] Eval with two high string multiplication crashes newer
 Python versions
In-Reply-To: <1607511907.66.0.321451468972.issue42609@roundup.psfhosted.org>
Message-ID: <1607511921.19.0.788105081742.issue42609@roundup.psfhosted.org>


Change by Erik Lamers <mail at eriklamers.nl>:


----------
versions: +Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42609>
_______________________________________

From report at bugs.python.org  Wed Dec  9 06:06:31 2020
From: report at bugs.python.org (Erik Lamers)
Date: Wed, 09 Dec 2020 11:06:31 +0000
Subject: [issue42609] Eval with too high string multiplication crashes newer
 Python versions
In-Reply-To: <1607511907.66.0.321451468972.issue42609@roundup.psfhosted.org>
Message-ID: <1607511991.31.0.346296855292.issue42609@roundup.psfhosted.org>


Change by Erik Lamers <mail at eriklamers.nl>:


----------
title: Eval with two high string multiplication crashes newer Python versions -> Eval with too high string multiplication crashes newer Python versions

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42609>
_______________________________________

From report at bugs.python.org  Wed Dec  9 06:25:03 2020
From: report at bugs.python.org (Peixing Xin)
Date: Wed, 09 Dec 2020 11:25:03 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1607513103.11.0.203309012587.issue31904@roundup.psfhosted.org>


Change by Peixing Xin <peixing.xin at windriver.com>:


----------
pull_requests: +22579
pull_request: https://github.com/python/cpython/pull/23718

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Wed Dec  9 07:01:06 2020
From: report at bugs.python.org (pmp-p)
Date: Wed, 09 Dec 2020 12:01:06 +0000
Subject: [issue42609] Eval with too high string multiplication crashes newer
 Python versions
In-Reply-To: <1607511907.66.0.321451468972.issue42609@roundup.psfhosted.org>
Message-ID: <1607515266.67.0.830427508599.issue42609@roundup.psfhosted.org>


Change by pmp-p <pmpp.pub at gmail.com>:


----------
nosy: +pmpp

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42609>
_______________________________________

From report at bugs.python.org  Wed Dec  9 08:39:46 2020
From: report at bugs.python.org (dimitri.wei)
Date: Wed, 09 Dec 2020 13:39:46 +0000
Subject: [issue42610] Get the type of from a var
Message-ID: <1607521186.12.0.817710588965.issue42610@roundup.psfhosted.org>


New submission from dimitri.wei <dimitri.wei.lingfeng at gmail.com>:

**Feature**
A similar feature in typescript
```ts
const foo: number = 1
type Foo = typeof foo  // type Foo = number

function bar(x: string): void {

}

type Bar = typeof bar // type Bar = (x: string) => void
```

**Pitch**
The expected way in future python.
```py
from typing import Type
foo: int = 1
Foo = Type[foo]  # equivalent to Foo = int

def bar(x: string) -> None :
    ...
Bar = Type[bar]  # equivalent to Bar = Callable[[str], None]
```

----------
components: Demos and Tools
messages: 382792
nosy: wlf100220
priority: normal
severity: normal
status: open
title: Get the type of from a var
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42610>
_______________________________________

From report at bugs.python.org  Wed Dec  9 08:41:15 2020
From: report at bugs.python.org (dimitri.wei)
Date: Wed, 09 Dec 2020 13:41:15 +0000
Subject: [issue42610] Get the type of from a var
In-Reply-To: <1607521186.12.0.817710588965.issue42610@roundup.psfhosted.org>
Message-ID: <1607521275.69.0.174101948189.issue42610@roundup.psfhosted.org>


Change by dimitri.wei <dimitri.wei.lingfeng at gmail.com>:


----------
components:  -Demos and Tools

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42610>
_______________________________________

From report at bugs.python.org  Wed Dec  9 08:47:53 2020
From: report at bugs.python.org (dimitri.wei)
Date: Wed, 09 Dec 2020 13:47:53 +0000
Subject: [issue42610] Get the type from a var
In-Reply-To: <1607521186.12.0.817710588965.issue42610@roundup.psfhosted.org>
Message-ID: <1607521673.22.0.906679725521.issue42610@roundup.psfhosted.org>


Change by dimitri.wei <dimitri.wei.lingfeng at gmail.com>:


----------
title: Get the type of from a var -> Get the type from a var

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42610>
_______________________________________

From report at bugs.python.org  Wed Dec  9 08:48:09 2020
From: report at bugs.python.org (dimitri.wei)
Date: Wed, 09 Dec 2020 13:48:09 +0000
Subject: [issue42610] Get the type from a variable
In-Reply-To: <1607521186.12.0.817710588965.issue42610@roundup.psfhosted.org>
Message-ID: <1607521689.34.0.323588195409.issue42610@roundup.psfhosted.org>


Change by dimitri.wei <dimitri.wei.lingfeng at gmail.com>:


----------
title: Get the type from a var -> Get the type from a variable

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42610>
_______________________________________

From report at bugs.python.org  Wed Dec  9 08:51:54 2020
From: report at bugs.python.org (dimitri.wei)
Date: Wed, 09 Dec 2020 13:51:54 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1607521914.58.0.293995406598.issue31904@roundup.psfhosted.org>


dimitri.wei <dimitri.wei.lingfeng at gmail.com> added the comment:

test comment

----------
components: +Build -Cross-Build
nosy: +wlf100220

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Wed Dec  9 10:23:49 2020
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 09 Dec 2020 15:23:49 +0000
Subject: [issue38893] broken container/selinux integration
In-Reply-To: <1574408245.03.0.269959513005.issue38893@roundup.psfhosted.org>
Message-ID: <1607527429.92.0.994847088433.issue38893@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
pull_requests: +22580
pull_request: https://github.com/python/cpython/pull/23720

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38893>
_______________________________________

From report at bugs.python.org  Wed Dec  9 10:30:04 2020
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 09 Dec 2020 15:30:04 +0000
Subject: [issue38893] broken container/selinux integration
In-Reply-To: <1574408245.03.0.269959513005.issue38893@roundup.psfhosted.org>
Message-ID: <1607527804.33.0.0227213253377.issue38893@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

I have created a new PR that introduces preserve_security_context argument and changes the default behavior of copy operations. All copy operations behave now similar to "cp -p --preserve=xattr" by default. copy2(src, dst, preserve_security_context=True) restores the old, problematic behavior that is similar to "cp -p --preserve=xattr,context".

It's not completely equivalent because I decided to omit all attributes in the restricted "security" xattr namespace. coreutils only handles "security.selinux" on an SELinux enabled system differently.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38893>
_______________________________________

From report at bugs.python.org  Wed Dec  9 11:31:40 2020
From: report at bugs.python.org (Manolis Stamatogiannakis)
Date: Wed, 09 Dec 2020 16:31:40 +0000
Subject: [issue42603] Tkinter: pkg-config is not used to get location of tcl
 and tk headers/libraries
In-Reply-To: <1607450864.79.0.446942772761.issue42603@roundup.psfhosted.org>
Message-ID: <1607531500.99.0.185743144375.issue42603@roundup.psfhosted.org>


Change by Manolis Stamatogiannakis <mstamat at gmail.com>:


----------
keywords: +patch
pull_requests: +22581
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23721

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42603>
_______________________________________

From report at bugs.python.org  Wed Dec  9 11:42:51 2020
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 09 Dec 2020 16:42:51 +0000
Subject: [issue42517] Enum: do not convert private names into members
In-Reply-To: <1606774653.87.0.704564487827.issue42517@roundup.psfhosted.org>
Message-ID: <1607532171.31.0.377779937367.issue42517@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Make that deprecate in 3.9, work correctly in 3.10.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42517>
_______________________________________

From report at bugs.python.org  Wed Dec  9 12:04:42 2020
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 09 Dec 2020 17:04:42 +0000
Subject: [issue42517] Enum: do not convert private names into members
In-Reply-To: <1606774653.87.0.704564487827.issue42517@roundup.psfhosted.org>
Message-ID: <1607533482.31.0.847698583054.issue42517@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
keywords: +patch
pull_requests: +22583
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/23722

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42517>
_______________________________________

From report at bugs.python.org  Wed Dec  9 12:19:56 2020
From: report at bugs.python.org (Andrea Giudiceandrea)
Date: Wed, 09 Dec 2020 17:19:56 +0000
Subject: [issue41928] ZipFile does not supports Unicode Path Extra Field
 (0x7075) zip header field
In-Reply-To: <1601810501.41.0.603959888811.issue41928@roundup.psfhosted.org>
Message-ID: <1607534396.48.0.0831584920292.issue41928@roundup.psfhosted.org>


Change by Andrea Giudiceandrea <andreaerdna at libero.it>:


----------
nosy: +andreaerdna

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41928>
_______________________________________

From report at bugs.python.org  Wed Dec  9 13:29:30 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 09 Dec 2020 18:29:30 +0000
Subject: [issue26131] Raise ImportWarning when loader.load_module() is used
In-Reply-To: <1452894244.92.0.478987355259.issue26131@psf.upfronthosting.co.za>
Message-ID: <1607538570.51.0.617533846633.issue26131@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

I'm seeing the following test failure locally on master (doesn't seem to be showing up in CI though). I'm not too familiar with this stuff, but it looks related to this change:

======================================================================
FAIL: test_all (test.test___all__.AllTest) (module='distutils.command')
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/bucher/src/cpython/Lib/test/test___all__.py", line 55, in check_all
    self.assertEqual(keys, all_set, "in module {}".format(modname))
  File "/home/bucher/src/cpython/Lib/contextlib.py", line 140, in __exit__
    next(self.gen)
  File "/home/bucher/src/cpython/Lib/test/support/warnings_helper.py", line 177, in _filterwarnings
    raise AssertionError("unhandled warning %s" % reraise[0])
AssertionError: unhandled warning {message : ImportWarning('VendorImporter.exec_module() not found; falling back to load_module()'), category : 'ImportWarning', filename : '<frozen importlib._bootstrap>', lineno : 681, line : None}

----------------------------------------------------------------------

Should we be ignoring the new warning in this test as well? I'm still not sure why I seem to be the only one seeing it.

----------
nosy: +brandtbucher

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26131>
_______________________________________

From report at bugs.python.org  Wed Dec  9 13:29:43 2020
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 09 Dec 2020 18:29:43 +0000
Subject: [issue40747] sysconfig.get_config_var("py_version_nodot") should
 return 3_10
In-Reply-To: <1590266866.08.0.16909581495.issue40747@roundup.psfhosted.org>
Message-ID: <1607538583.74.0.881180904633.issue40747@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

What's blocking this?
It is a real pain not to be able to install packages for 3.10.

I don't much care what the format is, but since there seems to be some difficulty in changing it, why not leave the output as `310`?

It isn't ambiguous, as long as we specify how to parse the number:
2 digits: XY.  X = major, Y = minor
3 digits: XYY. X = major, YY = minor
4 digits: XXYY. XX = major, YY = minor

So 31.0 will be `3100`.

That should be good for a millenium or so :)

----------
nosy: +Mark.Shannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40747>
_______________________________________

From report at bugs.python.org  Wed Dec  9 13:38:40 2020
From: report at bugs.python.org (Bhushan Shelke)
Date: Wed, 09 Dec 2020 18:38:40 +0000
Subject: [issue42417] Empty body {} in POST requests leads to 405 Method not
 allowed error
In-Reply-To: <1605864023.48.0.825673701965.issue42417@roundup.psfhosted.org>
Message-ID: <1607539120.68.0.551365413607.issue42417@roundup.psfhosted.org>


Bhushan Shelke <bhushan.shelke at gmail.com> added the comment:

Any update on this? Did the files I submitted help in reproducing/identifying the issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42417>
_______________________________________

From report at bugs.python.org  Wed Dec  9 13:40:10 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 09 Dec 2020 18:40:10 +0000
Subject: [issue26131] Raise ImportWarning when loader.load_module() is used
In-Reply-To: <1452894244.92.0.478987355259.issue26131@psf.upfronthosting.co.za>
Message-ID: <1607539210.39.0.278551446286.issue26131@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

What is "VendorImporter" (see the message of the ImportWarning)? That's not in the stdlib, so it looks like your system is injecting something via some `.pth` file or environment variable that doesn't define exec_module().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26131>
_______________________________________

From report at bugs.python.org  Wed Dec  9 14:03:14 2020
From: report at bugs.python.org (Mason Ginter)
Date: Wed, 09 Dec 2020 19:03:14 +0000
Subject: [issue42560] Improve Tkinter Documentation
In-Reply-To: <1607020537.02.0.420924180434.issue42560@roundup.psfhosted.org>
Message-ID: <1607540594.54.0.87469923731.issue42560@roundup.psfhosted.org>


Mason Ginter <mason at dagint.com> added the comment:

Would it then be a good idea to add a link to the archive.org version of effbot? If so how best to add it to the documentation. The only other instances I can find links to archive.org in the documentation reference webpages that are down permanently, unlike effbot.

Docs/library/unittest.rst:55
Docs/library/xmlrpc.client.rst:52
Docs/using/windows.rst:1088

In the documentation, should we clarify that effbot is temporarily down and link to the archive.org, or just change the hyperlink (as in other instances above)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42560>
_______________________________________

From report at bugs.python.org  Wed Dec  9 14:10:01 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Wed, 09 Dec 2020 19:10:01 +0000
Subject: [issue26131] Raise ImportWarning when loader.load_module() is used
In-Reply-To: <1452894244.92.0.478987355259.issue26131@psf.upfronthosting.co.za>
Message-ID: <1607541001.51.0.136760275528.issue26131@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

Yep, looks like that was it. Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26131>
_______________________________________

From report at bugs.python.org  Wed Dec  9 14:18:20 2020
From: report at bugs.python.org (E. Paine)
Date: Wed, 09 Dec 2020 19:18:20 +0000
Subject: [issue42560] Improve Tkinter Documentation
In-Reply-To: <1607020537.02.0.420924180434.issue42560@roundup.psfhosted.org>
Message-ID: <1607541500.74.0.561337223139.issue42560@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

@Fredrik, can you comment on when we might expect effbot.org to become available again? (i.e. is it worth us updating the docs to note that its down / changing the link to the Wayback Machine?)

----------
nosy: +effbot

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42560>
_______________________________________

From report at bugs.python.org  Wed Dec  9 14:25:15 2020
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 09 Dec 2020 19:25:15 +0000
Subject: [issue40084] HTTPStatus has incomplete dir() listing
In-Reply-To: <1585293405.13.0.478935860244.issue40084@roundup.psfhosted.org>
Message-ID: <1607541915.46.0.109483762326.issue40084@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset f6d1520219899874d78e7710934c9b21af880f9a by Miss Islington (bot) in branch '3.8':
bpo-40084: [Enum] dir() includes member attributes (GH-19219) (GH-22853)
https://github.com/python/cpython/commit/f6d1520219899874d78e7710934c9b21af880f9a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40084>
_______________________________________

From report at bugs.python.org  Wed Dec  9 14:54:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Dec 2020 19:54:40 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1607543680.42.0.463977958165.issue32381@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset ca064402079f889226cb107b26b329891431c319 by Victor Stinner in branch 'master':
bpo-32381: Remove unused _Py_fopen() function (GH-23711)
https://github.com/python/cpython/commit/ca064402079f889226cb107b26b329891431c319


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32381>
_______________________________________

From report at bugs.python.org  Wed Dec  9 15:24:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Dec 2020 20:24:27 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1607545467.45.0.383711292238.issue32381@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22584
pull_request: https://github.com/python/cpython/pull/23723

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32381>
_______________________________________

From report at bugs.python.org  Wed Dec  9 16:33:10 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 09 Dec 2020 21:33:10 +0000
Subject: [issue41559] Add support for PEP 612 to typing.py
In-Reply-To: <1597516564.62.0.520187732663.issue41559@roundup.psfhosted.org>
Message-ID: <1607549590.4.0.0123363051622.issue41559@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I wrote

class C(Generic[T, P]): ...

and was surprised that C.__parameters__ was (T,) instead of (T, P).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41559>
_______________________________________

From report at bugs.python.org  Wed Dec  9 16:37:55 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Dec 2020 21:37:55 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1607549875.62.0.0452500003755.issue32381@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset a82f63f5af027a0eab0f0812d750b804368cbd25 by Victor Stinner in branch 'master':
bpo-32381: Add _PyRun_AnyFileObject() (GH-23723)
https://github.com/python/cpython/commit/a82f63f5af027a0eab0f0812d750b804368cbd25


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32381>
_______________________________________

From report at bugs.python.org  Wed Dec  9 16:40:53 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Dec 2020 21:40:53 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1607550053.59.0.530253132451.issue32381@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22585
pull_request: https://github.com/python/cpython/pull/23724

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32381>
_______________________________________

From report at bugs.python.org  Wed Dec  9 16:47:36 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 09 Dec 2020 21:47:36 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1607550456.43.0.823870711793.issue31904@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset d5dcb653176387b72c8630f1a5464571f538a639 by pxinwr in branch 'master':
bpo-31904: Define THREAD_STACK_SIZE for VxWorks (GH-23718)
https://github.com/python/cpython/commit/d5dcb653176387b72c8630f1a5464571f538a639


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Wed Dec  9 17:15:06 2020
From: report at bugs.python.org (Andrei Kulakov)
Date: Wed, 09 Dec 2020 22:15:06 +0000
Subject: [issue42417] Empty body {} in POST requests leads to 405 Method not
 allowed error
In-Reply-To: <1605864023.48.0.825673701965.issue42417@roundup.psfhosted.org>
Message-ID: <1607552106.78.0.619717931967.issue42417@roundup.psfhosted.org>


Andrei Kulakov <andrei.avk at gmail.com> added the comment:

I cannot reproduce with 3.9.0, using attached files -- I do not get either 400 or 405; I get "None received" message:

```python3 flask_client.py                                                                                                                                                                                                                    --INS--
b'"None received"\n'
<http.client.HTTPResponse object at 0x10d288f10>
```

----------
nosy: +andrei.avk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42417>
_______________________________________

From report at bugs.python.org  Wed Dec  9 17:22:57 2020
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 09 Dec 2020 22:22:57 +0000
Subject: [issue34750] locals().update doesn't work in Enum body,
 even though direct assignment to locals() does
In-Reply-To: <1537447163.92.0.956365154283.issue34750@psf.upfronthosting.co.za>
Message-ID: <1607552577.25.0.840744621319.issue34750@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.10 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34750>
_______________________________________

From report at bugs.python.org  Wed Dec  9 17:28:13 2020
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 09 Dec 2020 22:28:13 +0000
Subject: [issue34750] locals().update doesn't work in Enum body,
 even though direct assignment to locals() does
In-Reply-To: <1537447163.92.0.956365154283.issue34750@psf.upfronthosting.co.za>
Message-ID: <1607552893.96.0.797007017591.issue34750@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
keywords: +patch
pull_requests: +22586
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/23725

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34750>
_______________________________________

From report at bugs.python.org  Wed Dec  9 17:31:04 2020
From: report at bugs.python.org (Ethan Furman)
Date: Wed, 09 Dec 2020 22:31:04 +0000
Subject: [issue34750] locals().update doesn't work in Enum body,
 even though direct assignment to locals() does
In-Reply-To: <1537447163.92.0.956365154283.issue34750@psf.upfronthosting.co.za>
Message-ID: <1607553064.1.0.611198361082.issue34750@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Okay, you convinced me.  I would ask two things, though:

- use vars() instead of locals()
- split the one-liner  ;)

    class Foo(Enum):
        vars().update({
                k: v
                for k, v in foo_defines.items()
                if k.startswith('FOO_')
                })
        def some_method(self):
            # do something

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34750>
_______________________________________

From report at bugs.python.org  Wed Dec  9 17:41:44 2020
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 09 Dec 2020 22:41:44 +0000
Subject: [issue39707] Abstract property setter/deleter implementation not
 enforced, but documented as such
In-Reply-To: <1582282750.75.0.718234610951.issue39707@roundup.psfhosted.org>
Message-ID: <1607553704.72.0.339336631888.issue39707@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

If this is going to be closed as rejected, I think it still needs some improvement to the documentation. Right now, the docs for abstractproperty (deprecated in favor of combining property and abstractmethod) state:

"If only some components are abstract, only those components need to be updated to create a concrete property in a subclass:"

This heavily implies that if *all* components of the property are abstract, they must *all* be updated to create a concrete property on the subclass, when that is not the case (it's documenting a special way of overriding just one component by borrowing the base class, not a normal means of defining a property). If nothing else, mentioning this quirk in the docs seems like it would save confusion (e.g. https://stackoverflow.com/questions/65224767/python-abstract-property-cant-instantiate-abstract-class-with-abstract-me ).

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, josh.r
resolution: rejected -> 
status: closed -> open
title: Abstract property setter/deleter implementation not enforced. -> Abstract property setter/deleter implementation not enforced, but documented as such
versions: +Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39707>
_______________________________________

From report at bugs.python.org  Wed Dec  9 17:45:34 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 09 Dec 2020 22:45:34 +0000
Subject: [issue39707] Abstract property setter/deleter implementation not
 enforced, but documented as such
In-Reply-To: <1582282750.75.0.718234610951.issue39707@roundup.psfhosted.org>
Message-ID: <1607553934.75.0.537674573226.issue39707@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Josh, feel free to submit a PR (make sure it mentions this issue).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39707>
_______________________________________

From report at bugs.python.org  Wed Dec  9 18:47:15 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 09 Dec 2020 23:47:15 +0000
Subject: [issue39791] New `files()` api from importlib_resources.
In-Reply-To: <1582949490.73.0.868974160192.issue39791@roundup.psfhosted.org>
Message-ID: <1607557635.57.0.11846636191.issue39791@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

This issue was implemented, just not as fully as I'd have hoped. Still lacking is native support for .files on the built-in package providers and removing the legacy APIs or at least configuring them to rely on the files API, but as far as supplying the files API, this work is done.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9 -Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39791>
_______________________________________

From report at bugs.python.org  Wed Dec  9 19:41:30 2020
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 10 Dec 2020 00:41:30 +0000
Subject: [issue42567] Enum: manually call __init_subclass__ after members are
 added
In-Reply-To: <1607093463.71.0.994675423727.issue42567@roundup.psfhosted.org>
Message-ID: <1607560890.37.0.486835996696.issue42567@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset 6bd94de168b58ac9358277ed6f200490ab26c174 by Ethan Furman in branch 'master':
bpo-42567: [Enum] call __init_subclass__ after members are added (GH-23714)
https://github.com/python/cpython/commit/6bd94de168b58ac9358277ed6f200490ab26c174


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42567>
_______________________________________

From report at bugs.python.org  Wed Dec  9 20:12:42 2020
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 10 Dec 2020 01:12:42 +0000
Subject: [issue42567] Enum: manually call __init_subclass__ after members are
 added
In-Reply-To: <1607093463.71.0.994675423727.issue42567@roundup.psfhosted.org>
Message-ID: <1607562762.35.0.685697183802.issue42567@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
stage: patch review -> backport needed
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42567>
_______________________________________

From report at bugs.python.org  Wed Dec  9 20:12:38 2020
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 10 Dec 2020 01:12:38 +0000
Subject: [issue42517] Enum: do not convert private names into members
In-Reply-To: <1606774653.87.0.704564487827.issue42517@roundup.psfhosted.org>
Message-ID: <1607562758.46.0.0503883744209.issue42517@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset 7cf0aad96d1d20f07d7f0e374885f327c2d5ff27 by Ethan Furman in branch 'master':
bpo-42517: [Enum] do not convert private names into members (GH-23722)
https://github.com/python/cpython/commit/7cf0aad96d1d20f07d7f0e374885f327c2d5ff27


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42517>
_______________________________________

From report at bugs.python.org  Wed Dec  9 22:28:47 2020
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 10 Dec 2020 03:28:47 +0000
Subject: [issue42385] Should enum.auto's behavior be adjusted for StrEnum to
 return the enum name?
In-Reply-To: <1605603671.61.0.469483986721.issue42385@roundup.psfhosted.org>
Message-ID: <1607570927.8.0.756677514274.issue42385@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
keywords: +patch
pull_requests: +22587
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/23727

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42385>
_______________________________________

From report at bugs.python.org  Wed Dec  9 23:51:12 2020
From: report at bugs.python.org (Kyle Stanley)
Date: Thu, 10 Dec 2020 04:51:12 +0000
Subject: [issue42611] PEP 594
Message-ID: <1607575872.07.0.562391698279.issue42611@roundup.psfhosted.org>


New submission from Kyle Stanley <aeros167 at gmail.com>:

This issue was created for the purpose of tracking any changes related to PEP 594 (Removing dead batteries from stdlib), and any relevant discussions about the modules being removed.

----------
components: Library (Lib)
messages: 382815
nosy: aeros, christian.heimes
priority: normal
pull_requests: 22588
severity: normal
status: open
title: PEP 594
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42611>
_______________________________________

From report at bugs.python.org  Thu Dec 10 01:35:07 2020
From: report at bugs.python.org (Jeremy Kloth)
Date: Thu, 10 Dec 2020 06:35:07 +0000
Subject: [issue42611] PEP 594
In-Reply-To: <1607575872.07.0.562391698279.issue42611@roundup.psfhosted.org>
Message-ID: <1607582107.99.0.34361958491.issue42611@roundup.psfhosted.org>


Change by Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>:


----------
nosy: +jkloth

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42611>
_______________________________________

From report at bugs.python.org  Thu Dec 10 02:20:03 2020
From: report at bugs.python.org (Deepanshu Garg)
Date: Thu, 10 Dec 2020 07:20:03 +0000
Subject: [issue42612] Software Designer
Message-ID: <1607584803.23.0.875978893674.issue42612@roundup.psfhosted.org>


New submission from Deepanshu Garg <deepanshugarg09 at gmail.com>:

I am calling and executing python script from C++ code using "PyRun_SimpleFile". This API is being called from windows thread and every thread intializes and finalizes the python interpreter. However, it works fine for single thread but if intiate a request immideatly after first returned the results, it does not work.

I ttried using PyGILState_STATE as well but it caused me access violation issue and application crashed

----------
components: C API
messages: 382816
nosy: deepanshugarg09
priority: normal
severity: normal
status: open
title: Software Designer
type: crash
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42612>
_______________________________________

From report at bugs.python.org  Thu Dec 10 04:21:43 2020
From: report at bugs.python.org (=?utf-8?b?VsOhY2xhdiBCcm/FvmVr?=)
Date: Thu, 10 Dec 2020 09:21:43 +0000
Subject: [issue41877] Check against misspellings of assert etc. in mock
In-Reply-To: <1601317157.88.0.730935461305.issue41877@roundup.psfhosted.org>
Message-ID: <1607592103.1.0.813084567824.issue41877@roundup.psfhosted.org>


Change by V?clav Bro?ek <vabr at google.com>:


----------
pull_requests: +22589
pull_request: https://github.com/python/cpython/pull/23729

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41877>
_______________________________________

From report at bugs.python.org  Thu Dec 10 04:26:58 2020
From: report at bugs.python.org (Christian Bachmaier)
Date: Thu, 10 Dec 2020 09:26:58 +0000
Subject: [issue42591] Method Py_FrozenMain missing in libpython3.9
In-Reply-To: <1607356833.89.0.498069278584.issue42591@roundup.psfhosted.org>
Message-ID: <1607592418.44.0.968406294636.issue42591@roundup.psfhosted.org>


Christian Bachmaier <chris at infosun.fim.uni-passau.de> added the comment:

The same under Python 3.9.1 (Package from Debian bullseye/testing). As the method Py_FrozenMain is contained in the source code, maybe ist has something to do with the build process, a change in makefile? As far as I can see, the builder of the distribution packages call the makefile as provided.

Chris

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42591>
_______________________________________

From report at bugs.python.org  Thu Dec 10 04:35:02 2020
From: report at bugs.python.org (Christian Bachmaier)
Date: Thu, 10 Dec 2020 09:35:02 +0000
Subject: [issue42591] Method Py_FrozenMain missing in libpython3.9
In-Reply-To: <1607356833.89.0.498069278584.issue42591@roundup.psfhosted.org>
Message-ID: <1607592902.02.0.38805833355.issue42591@roundup.psfhosted.org>


Christian Bachmaier <chris at infosun.fim.uni-passau.de> added the comment:

The file containing the source code is Python/frozenmain.c .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42591>
_______________________________________

From report at bugs.python.org  Thu Dec 10 04:44:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Dec 2020 09:44:16 +0000
Subject: [issue42591] Method Py_FrozenMain missing in libpython3.9
In-Reply-To: <1607356833.89.0.498069278584.issue42591@roundup.psfhosted.org>
Message-ID: <1607593456.17.0.914046770475.issue42591@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
nosy: +vstinner
nosy_count: 1.0 -> 2.0
pull_requests: +22590
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23730

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42591>
_______________________________________

From report at bugs.python.org  Thu Dec 10 04:45:00 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Dec 2020 09:45:00 +0000
Subject: [issue42591] Method Py_FrozenMain missing in libpython3.9
In-Reply-To: <1607356833.89.0.498069278584.issue42591@roundup.psfhosted.org>
Message-ID: <1607593500.56.0.670028444422.issue42591@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I wrote PR 23730 to fix the issue. Would it be possible for you to test it?

Since Python 3.9, symbols which are not explicitly exported are no longer exported. Python now uses -fvisibility=hidden.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42591>
_______________________________________

From report at bugs.python.org  Thu Dec 10 04:45:01 2020
From: report at bugs.python.org (=?utf-8?b?VsOhY2xhdiBCcm/FvmVr?=)
Date: Thu, 10 Dec 2020 09:45:01 +0000
Subject: [issue41877] Check against misspellings of assert etc. in mock
In-Reply-To: <1601317157.88.0.730935461305.issue41877@roundup.psfhosted.org>
Message-ID: <1607593501.8.0.883608126177.issue41877@roundup.psfhosted.org>


V?clav Bro?ek <vabr at google.com> added the comment:

https://github.com/python/cpython/pull/23729 is now a follow-up to improve docs and error message about the assert misspellings.

I'm now looking at the misspelled arguments: autospec and spec_set. These are accepted by patch, patch.object and patch.multiple, and spec_set is also accepted by create_autospec.

The three frequent misspellings I saw in our codebase are auto_spec, autospect and set_spec. I could add a check to look for them in kwargs, and also add an "unsafe" argument (default False), which, when True, disables the check. This would mimic what is already done for the misspelled asserts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41877>
_______________________________________

From report at bugs.python.org  Thu Dec 10 05:01:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Dec 2020 10:01:58 +0000
Subject: [issue42613] freeze.py doesn't support sys.platlibdir different than
 lib nor multiarch
Message-ID: <1607594518.8.0.0823964738983.issue42613@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Tools/freeze/freeze.py doesn't support config directory using multiarch nor directory using a sys.platlibdir different than "lib". In short, it doesn't work on Fedora 33 which uses:

/usr/lib64/python3.10/config-3.10-x86_64-linux-gnu/

It might be possible to copy/paste the code creating the config-xxx path from Lib/sysconfig.py to Tools/freeze/freeze.py, but I would prefer to reuse code if possible, to make the code more sustainable.

Maybe we can add a private function to get the path to the "config" directory.

Or even a public function.

----------
components: Unicode
messages: 382821
nosy: ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: freeze.py doesn't support sys.platlibdir different than lib nor multiarch
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42613>
_______________________________________

From report at bugs.python.org  Thu Dec 10 05:26:25 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 10 Dec 2020 10:26:25 +0000
Subject: [issue42611] PEP 594
In-Reply-To: <1607575872.07.0.562391698279.issue42611@roundup.psfhosted.org>
Message-ID: <1607595985.68.0.0194547605194.issue42611@roundup.psfhosted.org>


Change by Batuhan Taskaya <isidentical at gmail.com>:


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42611>
_______________________________________

From report at bugs.python.org  Thu Dec 10 06:12:59 2020
From: report at bugs.python.org (hai shi)
Date: Thu, 10 Dec 2020 11:12:59 +0000
Subject: [issue42612] Software Designer
In-Reply-To: <1607584803.23.0.875978893674.issue42612@roundup.psfhosted.org>
Message-ID: <1607598779.8.0.86241588839.issue42612@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

Hi, Thanks for your report, Deepanshu. Can you upload your code in here?

Adding victor in this bpo, MAYBE he can give some suggestions about it.

----------
nosy: +shihai1991, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42612>
_______________________________________

From report at bugs.python.org  Thu Dec 10 06:32:57 2020
From: report at bugs.python.org (Mihail Kirilov)
Date: Thu, 10 Dec 2020 11:32:57 +0000
Subject: =?utf-8?q?=5Bissue42614=5D_Pathlib_does_not_support_a_Cyrillic_character_?=
 =?utf-8?b?J9C5Jw==?=
Message-ID: <1607599977.07.0.665981519829.issue42614@roundup.psfhosted.org>


New submission from Mihail Kirilov <hidr0.frbg at gmail.com>:

I have a file with a Cirilyc name - "???? ?? ?????????", which when I load with path.Path and call name on it behaves differently

```
(Pdb) pathlib.Path("/tmp/pytest-of-root/pytest-15/test_bulgarian_name0/data/encoding/???? ?? ?????????.ldr").name
'???? ?? ?????????.ldr'
(Pdb) pathlib.Path("/tmp/pytest-of-root/pytest-15/test_bulgarian_name0/data/encoding/???? ?? ?????????.ldr").name[2]
'?'
(Pdb) pathlib.Path("/tmp/pytest-of-root/pytest-15/test_bulgarian_name0/data/encoding/???? ?? ?????????.ldr").name == "???? ?? ?????????"
False
```

----------
components: Unicode
messages: 382823
nosy: ezio.melotti, hidr0.frbg, vstinner
priority: normal
severity: normal
status: open
title: Pathlib does not support a Cyrillic character '?'
type: crash
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42614>
_______________________________________

From report at bugs.python.org  Thu Dec 10 07:01:37 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 10 Dec 2020 12:01:37 +0000
Subject: =?utf-8?q?=5Bissue42614=5D_Pathlib_does_not_support_a_Cyrillic_character_?=
 =?utf-8?b?J9C5Jw==?=
In-Reply-To: <1607599977.07.0.665981519829.issue42614@roundup.psfhosted.org>
Message-ID: <1607601697.31.0.530390918211.issue42614@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

What platform are you using?

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42614>
_______________________________________

From report at bugs.python.org  Thu Dec 10 07:02:14 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 10 Dec 2020 12:02:14 +0000
Subject: [issue30459] PyList_SET_ITEM  could be safer
In-Reply-To: <1495638852.56.0.0790136948712.issue30459@psf.upfronthosting.co.za>
Message-ID: <1607601734.77.0.871577311558.issue30459@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

This change goes directly against PEP 387.

----------
nosy: +petr.viktorin

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30459>
_______________________________________

From report at bugs.python.org  Thu Dec 10 07:07:14 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 10 Dec 2020 12:07:14 +0000
Subject: =?utf-8?q?=5Bissue42614=5D_Pathlib_does_not_support_a_Cyrillic_character_?=
 =?utf-8?b?J9C5Jw==?=
In-Reply-To: <1607599977.07.0.665981519829.issue42614@roundup.psfhosted.org>
Message-ID: <1607602034.84.0.0484288432163.issue42614@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

You are comparing the name with the file extension against the name without the file extension:

>>> "???? ?? ?????????.ldr" == "???? ?? ?????????"
False

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42614>
_______________________________________

From report at bugs.python.org  Thu Dec 10 07:15:13 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 10 Dec 2020 12:15:13 +0000
Subject: =?utf-8?q?=5Bissue42614=5D_Pathlib_does_not_support_a_Cyrillic_character_?=
 =?utf-8?b?J9C5Jw==?=
In-Reply-To: <1607599977.07.0.665981519829.issue42614@roundup.psfhosted.org>
Message-ID: <1607602513.39.0.743587122132.issue42614@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

In addition, you are probably hitting normalization issues. There are two ways to get the Cyrillic character '?' in your string, one of them is a single code point, the other is two code points:

>>> a = '?'
>>> b = '??'
>>> len(a), unicodedata.name(a)
(1, 'CYRILLIC SMALL LETTER SHORT I')
>>> len(b), unicodedata.name(b[0]), unicodedata.name(b[1])
(2, 'CYRILLIC SMALL LETTER I', 'COMBINING BREVE')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42614>
_______________________________________

From report at bugs.python.org  Thu Dec 10 07:18:02 2020
From: report at bugs.python.org (Mihail Kirilov)
Date: Thu, 10 Dec 2020 12:18:02 +0000
Subject: =?utf-8?q?=5Bissue42614=5D_Pathlib_does_not_support_a_Cyrillic_character_?=
 =?utf-8?b?J9C5Jw==?=
In-Reply-To: <1607599977.07.0.665981519829.issue42614@roundup.psfhosted.org>
Message-ID: <1607602682.65.0.854985461963.issue42614@roundup.psfhosted.org>


Mihail Kirilov <hidr0.frbg at gmail.com> added the comment:

I am uploading an Archive with

1 - mac.png
Using a mac I cannot generate the other '?', but I can load the file, it exists, but .name is wrong.

2 - linux.png
Using a linux the exact same thing generates the file not existing.

3 - The file itself.

It is very tricky to generate the problem on the mac I can hop on a call with you to show you exactly what I do.

----------
Added file: https://bugs.python.org/file49663/Archive.zip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42614>
_______________________________________

From report at bugs.python.org  Thu Dec 10 07:45:26 2020
From: report at bugs.python.org (Christian Bachmaier)
Date: Thu, 10 Dec 2020 12:45:26 +0000
Subject: [issue42591] Method Py_FrozenMain missing in libpython3.9
In-Reply-To: <1607356833.89.0.498069278584.issue42591@roundup.psfhosted.org>
Message-ID: <1607604326.24.0.369968790568.issue42591@roundup.psfhosted.org>


Christian Bachmaier <chris at infosun.fim.uni-passau.de> added the comment:

Dear Victor,

a simple test with the tools/freeze/hello.py example was successfull with your patch and the newest cpython from github.

1. git clone https://github.com/python/cpython.git
2. Applied a patch of your pull request
3. configure, make, amke install to xxx
4. freeze.py wants wants this for a very long time:
   ln -s /usr/local/lib/python3.10/config-3.10-x86_64-linux-gnu
     /usr/local/lib/python3.10/config-3.10
5. python3 cpython/Tools/freeze.py -o frozen hello.py
6. cd frozen; make; ./hello
   Helo world...

Thanks again,
Chris

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42591>
_______________________________________

From report at bugs.python.org  Thu Dec 10 08:18:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Dec 2020 13:18:17 +0000
Subject: [issue30459] PyList_SET_ITEM  could be safer
In-Reply-To: <1495638852.56.0.0790136948712.issue30459@psf.upfronthosting.co.za>
Message-ID: <1607606297.33.0.0333816817704.issue30459@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> This change goes directly against PEP 387.

The change respects the documentation which always documented the result type as "void".

3.10: https://docs.python.org/dev/c-api/tuple.html#c.PyTuple_SET_ITEM
3.5: https://docs.python.org/3.5/c-api/tuple.html#c.PyTuple_SET_ITEM
2.7: https://docs.python.org/2.7/c-api/tuple.html#c.PyTuple_SET_ITEM

This change is backward incompatible on purpose: it's to implement the documented behavior, and the macro was misused leading to a bug: "PyList_SET_ITEM (l, i, obj) < 0" in py-qt4.

I would also prefer a deprecation warning, but I don't see how do detect when a macro is abused to write "x = SET();" or "SET() = x;" Maybe a C linter could detect that, but I don't know any tool doing that.

The best we can do is to announce the change. That's why I documented in What's New in Python 3.10, and not only "hidden" in the Changelog:
https://docs.python.org/dev/whatsnew/3.10.html#id2

My expectation is that apart py-qt4, no project abuse these 3 macros.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30459>
_______________________________________

From report at bugs.python.org  Thu Dec 10 08:31:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Dec 2020 13:31:47 +0000
Subject: [issue30459] PyList_SET_ITEM  could be safer
In-Reply-To: <1495638852.56.0.0790136948712.issue30459@psf.upfronthosting.co.za>
Message-ID: <1607607107.14.0.851646860673.issue30459@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I checked: commit 0ef96c2b2a291c9d2d9c0ba42bbc1900a21e65f3 is part of Python 3.10.0a3 (released 3 days ago).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30459>
_______________________________________

From report at bugs.python.org  Thu Dec 10 09:12:11 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 10 Dec 2020 14:12:11 +0000
Subject: [issue30459] PyList_SET_ITEM  could be safer
In-Reply-To: <1495638852.56.0.0790136948712.issue30459@psf.upfronthosting.co.za>
Message-ID: <1607609531.65.0.201950606663.issue30459@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

> The change respects the documentation which always documented the result type as "void".

Then, IMO, the documentation should be fixed.

> My expectation is that apart py-qt4, no project abuse these 3 macros.

That's not true; at least ALSA's python bindings use PyTuple_SET_ITEM as a lvalue as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30459>
_______________________________________

From report at bugs.python.org  Thu Dec 10 11:23:58 2020
From: report at bugs.python.org (Ken Jin)
Date: Thu, 10 Dec 2020 16:23:58 +0000
Subject: [issue41559] Add support for PEP 612 to typing.py
In-Reply-To: <1597516564.62.0.520187732663.issue41559@roundup.psfhosted.org>
Message-ID: <1607617438.2.0.13336922055.issue41559@roundup.psfhosted.org>


Ken Jin <kenjin4096 at gmail.com> added the comment:

> and was surprised that C.__parameters__ was (T,) instead of (T, P).
Alright, I just fixed that :).

I'm now encountering many problems with how typing works which prevent what PEP 612 declare as valid from not throwing an error (these are all examples copied from the PEP)::

class X(Generic[T, P]): ...

1. X[int, [int, bool]] raises TypeError because second arg isn't a type (this is easy to fix).

2. X[int, ...] raises TypeError because for the same reason. One way to fix this is to automatically convert Ellipsis to EllipsisType just like how we already convert None to NoneType. Only problem now is that Callable[[...], int] doesn't raise TypeError. Should we just defer the problem of validating Callable to static type checkers instead?

class Z(Generic[P]): ...

3. Z[[int, str, bool]] raises TypeError, same as 1.

4. Z[int, str, bool] raises TypeError, but for too many parameters (not enough TypeVars). This one troubles me the most, current TypeVar substitution checks for len(__args__) == len(__parameters__).


I have a feeling your wish of greatly loosening type checks will come true ;). Should we proceed with that? That'd fix 1, 2, 3. The only showstopper now is 4. A quick idea is to just disable the check for len(__args__) == len(__parameters__) if there's only a single ParamSpec in __parameters__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41559>
_______________________________________

From report at bugs.python.org  Thu Dec 10 11:47:13 2020
From: report at bugs.python.org (Om G)
Date: Thu, 10 Dec 2020 16:47:13 +0000
Subject: [issue42615] Redundant jump instructions due to deleted unreachable
 bytecode blocks
Message-ID: <1607618833.17.0.897209602583.issue42615@roundup.psfhosted.org>


New submission from Om G <im.omgupta+python at gmail.com>:

During optimization, the compiler deletes blocks that are marked as unreachable. In doing so, it can render jump instructions that used to jump over the now-deleted blocks redundant, since simply falling through to the next non-empty block is now equivalent.

An example of a place where this occurs is around "if condition: statement; else: break" style structures (see attached proof of concept code below), but this is a general case and could occur in other places.

Tested on the latest 3.10 branch including all recent compile.c changes.

----------
files: jmptest.py
messages: 382834
nosy: OmG
priority: normal
severity: normal
status: open
title: Redundant jump instructions due to deleted unreachable bytecode blocks
type: performance
versions: Python 3.10
Added file: https://bugs.python.org/file49664/jmptest.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42615>
_______________________________________

From report at bugs.python.org  Thu Dec 10 11:48:53 2020
From: report at bugs.python.org (Om G)
Date: Thu, 10 Dec 2020 16:48:53 +0000
Subject: [issue42615] Redundant jump instructions due to deleted unreachable
 bytecode blocks
In-Reply-To: <1607618833.17.0.897209602583.issue42615@roundup.psfhosted.org>
Message-ID: <1607618933.97.0.90464001117.issue42615@roundup.psfhosted.org>


Change by Om G <im.omgupta+python at gmail.com>:


----------
keywords: +patch
pull_requests: +22591
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23733

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42615>
_______________________________________

From report at bugs.python.org  Thu Dec 10 12:39:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Dec 2020 17:39:25 +0000
Subject: [issue42591] Method Py_FrozenMain missing in libpython3.9
In-Reply-To: <1607356833.89.0.498069278584.issue42591@roundup.psfhosted.org>
Message-ID: <1607621965.87.0.985939459027.issue42591@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b5c7b38f5ebbc84b5b80192db1743d3e1cdcf4c5 by Victor Stinner in branch 'master':
bpo-42591: Export missing Py_FrozenMain() symbol (GH-23730)
https://github.com/python/cpython/commit/b5c7b38f5ebbc84b5b80192db1743d3e1cdcf4c5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42591>
_______________________________________

From report at bugs.python.org  Thu Dec 10 12:41:23 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Dec 2020 17:41:23 +0000
Subject: [issue42591] Method Py_FrozenMain missing in libpython3.9
In-Reply-To: <1607356833.89.0.498069278584.issue42591@roundup.psfhosted.org>
Message-ID: <1607622083.18.0.857744106524.issue42591@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> a simple test with the tools/freeze/hello.py example was successfull with your patch and the newest cpython from github.

Oh great, thanks for your quick feedback! I applied your PR to master and I will backport it to 3.9.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42591>
_______________________________________

From report at bugs.python.org  Thu Dec 10 12:53:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 10 Dec 2020 17:53:11 +0000
Subject: [issue42591] Method Py_FrozenMain missing in libpython3.9
In-Reply-To: <1607356833.89.0.498069278584.issue42591@roundup.psfhosted.org>
Message-ID: <1607622791.17.0.418284773554.issue42591@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22593
pull_request: https://github.com/python/cpython/pull/23734

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42591>
_______________________________________

From report at bugs.python.org  Thu Dec 10 12:58:30 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 10 Dec 2020 17:58:30 +0000
Subject: [issue41559] Add support for PEP 612 to typing.py
In-Reply-To: <1597516564.62.0.520187732663.issue41559@roundup.psfhosted.org>
Message-ID: <1607623110.0.0.159510879599.issue41559@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

> class X(Generic[T, P]): ...
> 
> 1. X[int, [int, bool]] raises TypeError because second arg isn't a type (this is easy to fix).

How would you fix it? By just allowing it? But then X.__args__ would be unhashable (see the other issue we're working on together).

> 2. X[int, ...] raises TypeError because for the same reason. One way to fix this is to automatically convert Ellipsis to EllipsisType just like how we already convert None to NoneType. Only problem now is that Callable[[...], int] doesn't raise TypeError. Should we just defer the problem of validating Callable to static type checkers instead?

I don't like using EllipsisType here, because this notation doesn't mean that we accept an ellipsis here -- it means (if I understand the PEP correctly) that we don't care about the paramspec.

> class Z(Generic[P]): ...
> 
> 3. Z[[int, str, bool]] raises TypeError, same as 1.

Same comment.

> 4. Z[int, str, bool] raises TypeError, but for too many parameters (not enough TypeVars). This one troubles me the most, current TypeVar substitution checks for len(__args__) == len(__parameters__).

The code should check that __parameters__ is (P,) for some ParamSpec P, and then transform this internally as if it was written Z[[int, str, bool]] and then typecheck that.

**BUT...**

How about an alternative implementation where as soon as we see that there's a ParamSpec in __parameters__ we just don't type-check at all, and accept anything? Leave it to the static type checker. Our goal here should be to support the syntax that PEP 612 describes so static type checkers can implement it, not to implement all the requirements described by the PEP at runtime.

I wonder what Pyre has in its stub files for ParamSpec -- maybe we can borrow that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41559>
_______________________________________

From report at bugs.python.org  Thu Dec 10 13:17:08 2020
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 10 Dec 2020 18:17:08 +0000
Subject: [issue42385] adjust enum.auto's behavior for StrEnum to return the
 enum name
In-Reply-To: <1605603671.61.0.469483986721.issue42385@roundup.psfhosted.org>
Message-ID: <1607624228.69.0.535565089839.issue42385@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
stage: patch review -> needs patch
title: Should enum.auto's behavior be adjusted for StrEnum to return the enum name? -> adjust enum.auto's behavior for StrEnum to return the enum name

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42385>
_______________________________________

From report at bugs.python.org  Thu Dec 10 13:35:40 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 10 Dec 2020 18:35:40 +0000
Subject: [issue41877] Check against misspellings of assert etc. in mock
In-Reply-To: <1601317157.88.0.730935461305.issue41877@roundup.psfhosted.org>
Message-ID: <1607625340.63.0.0141636054252.issue41877@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9fc571359af9320fddbe4aa2710a767f168c1707 by vabr-g in branch 'master':
bpo-41877: Improve docs for assert misspellings check in mock (GH-23729)
https://github.com/python/cpython/commit/9fc571359af9320fddbe4aa2710a767f168c1707


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41877>
_______________________________________

From report at bugs.python.org  Thu Dec 10 13:56:11 2020
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 10 Dec 2020 18:56:11 +0000
Subject: [issue42385] adjust enum.auto's behavior for StrEnum to return the
 enum name
In-Reply-To: <1605603671.61.0.469483986721.issue42385@roundup.psfhosted.org>
Message-ID: <1607626571.58.0.00346709207037.issue42385@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
pull_requests: +22594
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/23735

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42385>
_______________________________________

From report at bugs.python.org  Thu Dec 10 14:45:20 2020
From: report at bugs.python.org (Andrea Giudiceandrea)
Date: Thu, 10 Dec 2020 19:45:20 +0000
Subject: [issue41928] ZipFile does not supports Unicode Path Extra Field
 (0x7075) zip header field
In-Reply-To: <1601810501.41.0.603959888811.issue41928@roundup.psfhosted.org>
Message-ID: <1607629519.99.0.215415866474.issue41928@roundup.psfhosted.org>


Change by Andrea Giudiceandrea <andreaerdna at libero.it>:


----------
keywords: +patch
pull_requests: +22595
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23736

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41928>
_______________________________________

From report at bugs.python.org  Thu Dec 10 14:47:44 2020
From: report at bugs.python.org (=?utf-8?b?VsOhY2xhdiBCcm/FvmVr?=)
Date: Thu, 10 Dec 2020 19:47:44 +0000
Subject: [issue41877] Check against misspellings of assert etc. in mock
In-Reply-To: <1601317157.88.0.730935461305.issue41877@roundup.psfhosted.org>
Message-ID: <1607629664.1.0.859775785071.issue41877@roundup.psfhosted.org>


Change by V?clav Bro?ek <vabr at google.com>:


----------
pull_requests: +22596
pull_request: https://github.com/python/cpython/pull/23737

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41877>
_______________________________________

From report at bugs.python.org  Thu Dec 10 14:50:39 2020
From: report at bugs.python.org (=?utf-8?b?VsOhY2xhdiBCcm/FvmVr?=)
Date: Thu, 10 Dec 2020 19:50:39 +0000
Subject: [issue41877] Check against misspellings of assert etc. in mock
In-Reply-To: <1601317157.88.0.730935461305.issue41877@roundup.psfhosted.org>
Message-ID: <1607629839.03.0.842395940176.issue41877@roundup.psfhosted.org>


V?clav Bro?ek <vabr at google.com> added the comment:

https://github.com/python/cpython/pull/23737 has the initial draft of the check against misspelled arguments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41877>
_______________________________________

From report at bugs.python.org  Thu Dec 10 15:20:16 2020
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 10 Dec 2020 20:20:16 +0000
Subject: [issue42385] adjust enum.auto's behavior for StrEnum to return the
 enum name
In-Reply-To: <1605603671.61.0.469483986721.issue42385@roundup.psfhosted.org>
Message-ID: <1607631616.83.0.732992038694.issue42385@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset efb13be72cbf49edf591936fafb120fe1b7d59f7 by Ethan Furman in branch 'master':
bpo-42385: [Enum] add `_generate_next_value_` to StrEnum (GH-23735)
https://github.com/python/cpython/commit/efb13be72cbf49edf591936fafb120fe1b7d59f7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42385>
_______________________________________

From report at bugs.python.org  Thu Dec 10 15:21:24 2020
From: report at bugs.python.org (Tom Birch)
Date: Thu, 10 Dec 2020 20:21:24 +0000
Subject: [issue42616] C Extensions on Darwin that link against libpython are
 likely to crash
Message-ID: <1607631684.88.0.776282381427.issue42616@roundup.psfhosted.org>


New submission from Tom Birch <froody at gmail.com>:

After https://github.com/python/cpython/pull/12946, there exists an issue on MacOS due to the two-level namespace for symbol resolution. If a C extension links against libpython.dylib, all symbols dependencies from the Python C API will be bound to libpython. When the C extension is loaded into a process launched by running the `python` binary, there will be two active copies of the python runtime. This can lead to crashes if objects from one runtime are used by the other.

https://developer.apple.com/library/archive/documentation/Porting/Conceptual/PortingUnix/compiling/compiling.html#//apple_ref/doc/uid/TP40002850-BCIHJBBF

See issue/test case here: https://github.com/PDAL/python/pull/76

----------
components: C API, macOS
messages: 382841
nosy: froody, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: C Extensions on Darwin that link against libpython are likely to crash
type: crash
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42616>
_______________________________________

From report at bugs.python.org  Thu Dec 10 15:21:34 2020
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 10 Dec 2020 20:21:34 +0000
Subject: [issue42385] adjust enum.auto's behavior for StrEnum to return the
 enum name
In-Reply-To: <1605603671.61.0.469483986721.issue42385@roundup.psfhosted.org>
Message-ID: <1607631694.61.0.588786579434.issue42385@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Thank you for finding that, Antony.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42385>
_______________________________________

From report at bugs.python.org  Thu Dec 10 15:30:05 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 10 Dec 2020 20:30:05 +0000
Subject: [issue41559] Add support for PEP 612 to typing.py
In-Reply-To: <1597516564.62.0.520187732663.issue41559@roundup.psfhosted.org>
Message-ID: <1607632205.83.0.876567659678.issue41559@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

For reference, here's what Pyre has (though it's an older version):

https://github.com/facebook/pyre-check/tree/master/pyre_extensions

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41559>
_______________________________________

From report at bugs.python.org  Thu Dec 10 16:04:19 2020
From: report at bugs.python.org (Steve Stagg)
Date: Thu, 10 Dec 2020 21:04:19 +0000
Subject: [issue42609] Eval with too high string multiplication crashes newer
 Python versions
In-Reply-To: <1607511907.66.0.321451468972.issue42609@roundup.psfhosted.org>
Message-ID: <1607634259.84.0.375180531832.issue42609@roundup.psfhosted.org>


Steve Stagg <stestagg at gmail.com> added the comment:

Looks like it was introduced by https://github.com/python/cpython/commit/7ea143ae795a9fd57eaccf490d316bdc13ee9065:

bpo-29469: Move constant folding to AST optimizer (GH-2858)

----------
nosy: +stestagg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42609>
_______________________________________

From report at bugs.python.org  Thu Dec 10 16:07:13 2020
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 10 Dec 2020 21:07:13 +0000
Subject: [issue34750] locals().update doesn't work in Enum body,
 even though direct assignment to locals() does
In-Reply-To: <1537447163.92.0.956365154283.issue34750@psf.upfronthosting.co.za>
Message-ID: <1607634433.02.0.500523340824.issue34750@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset a65828717982e6a56382d7aff738478f5b5b25d0 by Ethan Furman in branch 'master':
bpo-34750: [Enum] add `_EnumDict.update()` support (GH-23725)
https://github.com/python/cpython/commit/a65828717982e6a56382d7aff738478f5b5b25d0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34750>
_______________________________________

From report at bugs.python.org  Thu Dec 10 16:07:59 2020
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 10 Dec 2020 21:07:59 +0000
Subject: [issue34750] locals().update doesn't work in Enum body,
 even though direct assignment to locals() does
In-Reply-To: <1537447163.92.0.956365154283.issue34750@psf.upfronthosting.co.za>
Message-ID: <1607634479.18.0.683100849507.issue34750@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34750>
_______________________________________

From report at bugs.python.org  Thu Dec 10 16:23:13 2020
From: report at bugs.python.org (Karl Nelson)
Date: Thu, 10 Dec 2020 21:23:13 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1607635393.35.0.189530077543.issue42529@roundup.psfhosted.org>


Karl Nelson <nelson85 at llnl.gov> added the comment:

I managed to get the debugger attached (unfortunately I am not a windows programmer so I don't use these tools). 

It appears when loading from a pyc, it is attempting to open the directory as a Zip file which is throwing an exception resulting in a failure to load the internal _jpype module.   

Unfortunately this is outside my area as nothing in jpype nor _jpype is calling the zipimport module.  So it must be something internal to Python.  It is a major issue as I can't release to anaconda on windows until I can resolve the problem.   Can you direct me how to proceed?

Details:

zipimport.ZipImportError
  Message=not a Zip file
  StackTrace:
<frozen zipimport>:88 in __init__

Replicating the problem is simple.   Download jpype from git, use "python setup.py develop" to create the module, run python -c  "import jpype", and repeat python -c "import jpype"

Screen shot of the visual studio error is shown.

----------
Added file: https://bugs.python.org/file49665/Capture.PNG

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Thu Dec 10 16:27:30 2020
From: report at bugs.python.org (Antony Lee)
Date: Thu, 10 Dec 2020 21:27:30 +0000
Subject: [issue34750] locals().update doesn't work in Enum body,
 even though direct assignment to locals() does
In-Reply-To: <1537447163.92.0.956365154283.issue34750@psf.upfronthosting.co.za>
Message-ID: <1607635650.25.0.57387292806.issue34750@roundup.psfhosted.org>


Antony Lee <anntzer.lee at gmail.com> added the comment:

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34750>
_______________________________________

From report at bugs.python.org  Thu Dec 10 16:27:38 2020
From: report at bugs.python.org (Antony Lee)
Date: Thu, 10 Dec 2020 21:27:38 +0000
Subject: [issue34750] locals().update doesn't work in Enum body,
 even though direct assignment to locals() does
In-Reply-To: <1537447163.92.0.956365154283.issue34750@psf.upfronthosting.co.za>
Message-ID: <1607635658.0.0.653245403876.issue34750@roundup.psfhosted.org>


Change by Antony Lee <anntzer.lee at gmail.com>:


----------
nosy:  -Antony.Lee

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34750>
_______________________________________

From report at bugs.python.org  Thu Dec 10 16:28:33 2020
From: report at bugs.python.org (Antony Lee)
Date: Thu, 10 Dec 2020 21:28:33 +0000
Subject: [issue42385] adjust enum.auto's behavior for StrEnum to return the
 enum name
In-Reply-To: <1605603671.61.0.469483986721.issue42385@roundup.psfhosted.org>
Message-ID: <1607635713.88.0.60952686678.issue42385@roundup.psfhosted.org>


Antony Lee <anntzer.lee at gmail.com> added the comment:

Thanks for implementing!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42385>
_______________________________________

From report at bugs.python.org  Thu Dec 10 16:28:39 2020
From: report at bugs.python.org (Antony Lee)
Date: Thu, 10 Dec 2020 21:28:39 +0000
Subject: [issue42385] adjust enum.auto's behavior for StrEnum to return the
 enum name
In-Reply-To: <1605603671.61.0.469483986721.issue42385@roundup.psfhosted.org>
Message-ID: <1607635719.77.0.703529625173.issue42385@roundup.psfhosted.org>


Change by Antony Lee <anntzer.lee at gmail.com>:


----------
nosy:  -Antony.Lee

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42385>
_______________________________________

From report at bugs.python.org  Thu Dec 10 16:34:01 2020
From: report at bugs.python.org (Steve Stagg)
Date: Thu, 10 Dec 2020 21:34:01 +0000
Subject: [issue42609] Eval with too high string multiplication crashes newer
 Python versions
In-Reply-To: <1607511907.66.0.321451468972.issue42609@roundup.psfhosted.org>
Message-ID: <1607636041.53.0.900192875057.issue42609@roundup.psfhosted.org>


Steve Stagg <stestagg at gmail.com> added the comment:

In python 3.7/8, It's a stack overflow in the constant folding code.

On master, the overflow seems to come out of validate_expr.c.

* thread #1, name = 'python3', stop reason = signal SIGSEGV: invalid address (fault address: 0x7fffff7feff8)
    frame #0: 0x00005555557aadba python3`validate_expr(exp=0x00005555602617c0, ctx=Load) at ast.c:224:16
   221          }
   222          return validate_exprs(exp->v.BoolOp.values, Load, 0);
   223      case BinOp_kind:
-> 224          return validate_expr(exp->v.BinOp.left, Load) &&
   225              validate_expr(exp->v.BinOp.right, Load);
   226      case UnaryOp_kind:
   227          return validate_expr(exp->v.UnaryOp.operand, Load);


300,000 ish stack frames of this:

    frame #70832: 0x00005555557aadbf python3`validate_expr(exp=0x000055556150af40, ctx=Load) at ast.c:224:16
    frame #70833: 0x00005555557aadbf python3`validate_expr(exp=0x000055556150b050, ctx=Load) at ast.c:224:16
    frame #70834: 0x00005555557aadbf python3`validate_expr(exp=0x000055556150b160, ctx=Load) at ast.c:224:16
    frame #70835: 0x00005555557aadbf python3`validate_expr(exp=0x000055556150b270, ctx=Load) at ast.c:224:16
    frame #70836: 0x00005555557aadbf python3`validate_expr(exp=0x000055556150b380, ctx=Load) at ast.c:224:16
    frame #70837: 0x00005555557aadbf python3`validate_expr(exp=0x000055556150b490, ctx=Load) at ast.c:224:16
    frame #70838: 0x00005555557aadbf python3`validate_expr(exp=0x000055556150b5a0, ctx=Load) at ast.c:224:16
    frame #70839: 0x00005555557aadbf python3`validate_expr(exp=0x000055556150b6b0, ctx=Load) at ast.c:224:16


On the one hand, pure python code should never segfault, on the other hand, `eval`ling untrusted input has bigger problems than a segfault on carefully crafted input.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42609>
_______________________________________

From report at bugs.python.org  Thu Dec 10 16:40:40 2020
From: report at bugs.python.org (Karl Nelson)
Date: Thu, 10 Dec 2020 21:40:40 +0000
Subject: [issue42617] Enhancement request for PyType_FromSpecWIthBases add
 option for meta class
Message-ID: <1607636440.03.0.352368649598.issue42617@roundup.psfhosted.org>


New submission from Karl Nelson <nelson85 at llnl.gov>:

PyType_FromSpecWithBases is missing an argument for taking a meta class.  As a result it is necessary to replicate a large portion of Python code when I need to create a new heap type with a specified meta class.  This is a maintenance issue as replicating Python code is likely to get broken in future.

I have replicated to code from JPype so that it is clear how the meta class is coming into place.   PyJPClass_Type is derived from a 
PyHeapType with additional slots for Java to use and overrides allocation slots to that it can add extra slots (needs true multiple inheritance as it needed to add Java slots to types with mismatching memory layouts object, long, float, exception, ...).

This code could be made much safer if there were a PyType_FromSpecWithBasesMeta which used the meta class to allocate the memory (then I could safely override the slots after creation).
 

```
PyObject* PyJPClass_FromSpecWithBases(PyType_Spec *spec, PyObject *bases)
{
        JP_PY_TRY("PyJPClass_FromSpecWithBases");
        // Python lacks a FromSpecWithMeta so we are going to have to fake it here.
        PyTypeObject* type = (PyTypeObject*) PyJPClass_Type->tp_alloc(PyJPClass_Type, 0); // <== we need to use the meta class here
        PyHeapTypeObject* heap = (PyHeapTypeObject*) type;
        type->tp_flags = spec->flags | Py_TPFLAGS_HEAPTYPE | Py_TPFLAGS_HAVE_GC;
        type->tp_name = spec->name;
        const char *s = strrchr(spec->name, '.');
        if (s == NULL)
                s = spec->name;
        else
                s++;
        heap->ht_qualname = PyUnicode_FromString(s);
        heap->ht_name = heap->ht_qualname;
        Py_INCREF(heap->ht_name);
        if (bases == NULL)
                type->tp_bases = PyTuple_Pack(1, (PyObject*) & PyBaseObject_Type);
        else
        {
                type->tp_bases = bases;
                Py_INCREF(bases);
        }
        type->tp_base = (PyTypeObject*) PyTuple_GetItem(type->tp_bases, 0);
        Py_INCREF(type->tp_base);
        type->tp_as_async = &heap->as_async;
        type->tp_as_buffer = &heap->as_buffer;
        type->tp_as_mapping = &heap->as_mapping;
        type->tp_as_number = &heap->as_number;
        type->tp_as_sequence = &heap->as_sequence;
        type->tp_basicsize = spec->basicsize;
        if (spec->basicsize == 0)
                type->tp_basicsize = type->tp_base->tp_basicsize;
        type->tp_itemsize = spec->itemsize;
        if (spec->itemsize == 0)
                type->tp_itemsize = type->tp_base->tp_itemsize;

        // <=== Replicated code from the meta class 
        type->tp_alloc = PyJPValue_alloc;
        type->tp_free = PyJPValue_free;
        type->tp_finalize = (destructor) PyJPValue_finalize;

        // <= Replicated code from Python
        for (PyType_Slot* slot = spec->slots; slot->slot; slot++)
        {
               switch (slot->slot)
                {
                        case Py_tp_free:
                                type->tp_free = (freefunc) slot->pfunc;
                                break;
                        case Py_tp_new:
                                type->tp_new = (newfunc) slot->pfunc;
                                break;
                        case Py_tp_init:
                                type->tp_init = (initproc) slot->pfunc;
                                break;
                        case Py_tp_getattro:
                                type->tp_getattro = (getattrofunc) slot->pfunc;
                                break;
                        case Py_tp_setattro:
                                type->tp_setattro = (setattrofunc) slot->pfunc;
                                break;
                        case Py_tp_dealloc:
                                type->tp_dealloc = (destructor) slot->pfunc;
                                break;
                        case Py_tp_str:
                                type->tp_str = (reprfunc) slot->pfunc;
                                break;
                        case Py_tp_repr:
                                type->tp_repr = (reprfunc) slot->pfunc;
                                break;
                        case Py_tp_methods:
                                type->tp_methods = (PyMethodDef*) slot->pfunc;
                                break;
                        case Py_sq_item:
                                heap->as_sequence.sq_item = (ssizeargfunc) slot->pfunc;
                                break;
                        case Py_sq_length:
                                heap->as_sequence.sq_length = (lenfunc) slot->pfunc;
                                break;
                        case Py_mp_ass_subscript:
                                heap->as_mapping.mp_ass_subscript = (objobjargproc) slot->pfunc;
                                break;
                        case Py_tp_hash:
                                type->tp_hash = (hashfunc) slot->pfunc;
                                break;
                        case Py_nb_int:
                                heap->as_number.nb_int = (unaryfunc) slot->pfunc;
                                break;
                        case Py_nb_float:
                                heap->as_number.nb_float = (unaryfunc) slot->pfunc;
                                break;
                        case Py_tp_richcompare:
                                type->tp_richcompare = (richcmpfunc) slot->pfunc;
                                break;
                        case Py_mp_subscript:
                                heap->as_mapping.mp_subscript = (binaryfunc) slot->pfunc;
                                break;
                        case Py_nb_index:
                                heap->as_number.nb_index = (unaryfunc) slot->pfunc;
                                break;
                        case Py_nb_absolute:
                                heap->as_number.nb_absolute = (unaryfunc) slot->pfunc;
                                break;
                        case Py_nb_and:
                                heap->as_number.nb_and = (binaryfunc) slot->pfunc;
                                break;
                        case Py_nb_or:
                                heap->as_number.nb_or = (binaryfunc) slot->pfunc;
                                break;
                        case Py_nb_xor:
                                heap->as_number.nb_xor = (binaryfunc) slot->pfunc;
                                break;
                        case Py_nb_add:
                                heap->as_number.nb_add = (binaryfunc) slot->pfunc;
                                break;
                        case Py_nb_subtract:
                                heap->as_number.nb_subtract = (binaryfunc) slot->pfunc;
                                break;
                        case Py_nb_multiply:
                                heap->as_number.nb_multiply = (binaryfunc) slot->pfunc;
                                break;
                        case Py_nb_rshift:
                                heap->as_number.nb_rshift = (binaryfunc) slot->pfunc;
                                break;
                        case Py_nb_lshift:
                                heap->as_number.nb_lshift = (binaryfunc) slot->pfunc;
                               break;
                        case Py_nb_negative:
                                heap->as_number.nb_negative = (unaryfunc) slot->pfunc;
                                break;
                        case Py_nb_bool:
                                heap->as_number.nb_bool = (inquiry) slot->pfunc;
                                break;
                        case Py_nb_invert:
                                heap->as_number.nb_invert = (unaryfunc) slot->pfunc;
                                break;
                        case Py_nb_positive:
                                heap->as_number.nb_positive = (unaryfunc) slot->pfunc;
                                break;
                        case Py_nb_floor_divide:
                                heap->as_number.nb_floor_divide = (binaryfunc) slot->pfunc;
                                break;
                        case Py_nb_divmod:
                                heap->as_number.nb_divmod = (binaryfunc) slot->pfunc;
                                break;
                        case Py_tp_getset:
                                type->tp_getset = (PyGetSetDef*) slot->pfunc;
                                break;
                                // GCOVR_EXCL_START
                        default:
                                PyErr_Format(PyExc_TypeError, "slot %d not implemented", slot->slot);
                                JP_RAISE_PYTHON();
                                // GCOVR_EXCL_STOP
                }
        }
        PyType_Ready(type);
        PyDict_SetItemString(type->tp_dict, "__module__", PyUnicode_FromString("_jpype"));
        return (PyObject*) type;
        JP_PY_CATCH(NULL); // GCOVR_EXCL_LINE
}
```

----------
components: C API
messages: 382850
nosy: Thrameos
priority: normal
severity: normal
status: open
title: Enhancement request  for PyType_FromSpecWIthBases add option for meta class
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42617>
_______________________________________

From report at bugs.python.org  Thu Dec 10 16:49:14 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Thu, 10 Dec 2020 21:49:14 +0000
Subject: [issue42059] TypedDict(...) as function does not respect "total" when
 setting __required_keys__ and __optional_keys__
In-Reply-To: <1602926609.93.0.947551036861.issue42059@roundup.psfhosted.org>
Message-ID: <1607636954.75.0.995055313507.issue42059@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:


New changeset 67b769f5157c9dad1c7dd6b24e067b9fdab5b35d by Alex Gr?nholm in branch 'master':
bpo-42059: Fix required/optional keys for TypedDict(..., total=False) (GH-22736)
https://github.com/python/cpython/commit/67b769f5157c9dad1c7dd6b24e067b9fdab5b35d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42059>
_______________________________________

From report at bugs.python.org  Thu Dec 10 16:49:26 2020
From: report at bugs.python.org (Karl Nelson)
Date: Thu, 10 Dec 2020 21:49:26 +0000
Subject: [issue42618] Enhancement request for importing stacktraces from
 foreign sources
Message-ID: <1607636966.94.0.276935236028.issue42618@roundup.psfhosted.org>


New submission from Karl Nelson <nelson85 at llnl.gov>:

In JPype, I am transfer stack information from Java into Python for diagnostics and display purposed.  Unfortunately, as the exception system is directly accessing traceback structure elements this cannot be replicated without creating traceback structures in C.   I have thus been forced to create new methods that create this using internal Python structures.  It would be much better if there were C API method to allow importing a foreign stack trace into Python.

Here is an example of the code used in JPype for reference.


```
// Transfer list of filenames, functions and lines to Python.
PyObject* PyTrace_FromJPStackTrace(JPStackTrace& trace)
{
        PyTracebackObject *last_traceback = NULL;
        PyObject *dict = PyModule_GetDict(PyJPModule);
        for (JPStackTrace::iterator iter = trace.begin(); iter != trace.end(); ++iter)
        {
                last_traceback = tb_create(last_traceback, dict,  iter->getFile(),
                                iter->getFunction(), iter->getLine());
        }
        if (last_traceback == NULL)
                Py_RETURN_NONE;
        return (PyObject*) last_traceback;
}

PyTracebackObject *tb_create(                                                                                                                                                               PyTracebackObject *last_traceback,
                PyObject *dict,                                                                                                                                                             const char* filename,
                const char* funcname,
                int linenum)
{
        // Create a code for this frame.
        PyCodeObject *code = PyCode_NewEmpty(filename, funcname, linenum);
        // Create a frame for the traceback.
        PyFrameObject *frame = (PyFrameObject*) PyFrame_Type.tp_alloc(&PyFrame_Type, 0);
        frame->f_back = NULL;
        if (last_traceback != NULL)
        {
                frame->f_back = last_traceback->tb_frame;
                Py_INCREF(frame->f_back);
        }
        frame->f_builtins = dict;
        Py_INCREF(frame->f_builtins);
        frame->f_code = (PyCodeObject*) code;
        frame->f_executing = 0;
        frame->f_gen = NULL;
        frame->f_globals = dict;
        Py_INCREF(frame->f_globals);
        frame->f_iblock = 0;
        frame->f_lasti = 0;
        frame->f_lineno = 0;
        frame->f_locals = NULL;
        frame->f_localsplus[0] = 0;
        frame->f_stacktop = NULL;
        frame->f_trace = NULL;
        frame->f_valuestack = 0;
#if PY_VERSION_HEX>=0x03070000
        frame->f_trace_lines = 0;
        frame->f_trace_opcodes = 0;
#endif
        // Create a traceback
        PyTracebackObject *traceback = (PyTracebackObject*)
                        PyTraceBack_Type.tp_alloc(&PyTraceBack_Type, 0);
        traceback->tb_frame = frame;
        traceback->tb_lasti = frame->f_lasti;
        traceback->tb_lineno = linenum;
        traceback->tb_next = last_traceback;
        return traceback;
}

```

----------
components: C API
messages: 382852
nosy: Thrameos
priority: normal
severity: normal
status: open
title: Enhancement request for importing stacktraces from foreign sources
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42618>
_______________________________________

From report at bugs.python.org  Thu Dec 10 18:12:47 2020
From: report at bugs.python.org (Steve Stagg)
Date: Thu, 10 Dec 2020 23:12:47 +0000
Subject: [issue42083] PyStructSequence_NewType broken in 3.8
In-Reply-To: <1603132025.42.0.432168177789.issue42083@roundup.psfhosted.org>
Message-ID: <1607641967.17.0.192211314526.issue42083@roundup.psfhosted.org>


Steve Stagg <stestagg at gmail.com> added the comment:

It looks like the segfault was fixed in https://github.com/python/cpython/commit/88c2cfd9ffbcfc43fd1364f2984852a819547d43

as part of https://bugs.python.org/issue41832.

The code in this area of typeobject.c looks a bit different, now, but the backport seems simple?

Simple testcase:

#include <stdio.h>
#include <Python.h>
int main() {
    Py_Initialize();
    PyStructSequence_Field fields[2] = {
        {NULL, NULL}
    };
    PyStructSequence_Desc d = {"test", NULL, &fields[0], 0};
    PyStructSequence_NewType(&d);
    Py_Finalize();
}

Segfault reproducible on 3.8 and 3.9

----------
nosy: +stestagg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42083>
_______________________________________

From report at bugs.python.org  Thu Dec 10 19:02:31 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 11 Dec 2020 00:02:31 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1607644951.7.0.038343079118.issue42529@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Replicating also requires installing Java (I got as far as the build failing), which is going to have to wait until I have time to spin up a throwaway machine :)

That exception is a normal part of the import process and should be being handled. It's not the same one that eventually terminates the program.

I'd continue past that one and keep continuing until you hit one that looks like "DLL initialization routine failed". That *should* come out of the DLL that is actually failing, which Python isn't able to identify, and will give us hints toward the actual root cause.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Thu Dec 10 19:14:28 2020
From: report at bugs.python.org (Karl Nelson)
Date: Fri, 11 Dec 2020 00:14:28 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1607645668.44.0.551934716297.issue42529@roundup.psfhosted.org>


Karl Nelson <nelson85 at llnl.gov> added the comment:

Oddly that was the only exception that I got.  When I hit continue it proceeded without issue and the dll was loaded correctly.   However, when I try without the debugger attached the error reappears.   So this is one of those Schrodinger errors.   I know the error is there because I see it when we run on the CI and on a local machine,  but all attempts to isolate it say that is should not exist.  There can't really be a path that is different when compiling then loading from a pyc unless this is some type of uninitialized variable issues where we just happened to have been unfortunate enough to hit it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Thu Dec 10 19:24:12 2020
From: report at bugs.python.org (Ken Jin)
Date: Fri, 11 Dec 2020 00:24:12 +0000
Subject: [issue41559] Add support for PEP 612 to typing.py
In-Reply-To: <1607632205.83.0.876567659678.issue41559@roundup.psfhosted.org>
Message-ID: <CAOMZG7gy9KV47GoO==xO-1RnkQ-zARrwDObZ36ziPHdDLZrsYw@mail.gmail.com>


Ken Jin <kenjin4096 at gmail.com> added the comment:

The pyre version in their __init__.py looks like they took your advice for
letting the static checker do the work wholeheartedly.

I'm not in favour of type checking either. Just that the pre-existing code
does it for me.

Not type checking when seeing ~P in __parameters__ would work, just that
__args__ will be unhashable (like you mentioned) so things will be slower
due to no type cache. Maybe we can cast the [int, str] to (int, str), that
should work with cache for most cases. And unlike the Callable issue -
since we don't need to ensure runtime correctness - we can ignore any weird
effects to __args__ and __parameters__ in ParamSpec, like TypeVars not
collecting etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41559>
_______________________________________

From report at bugs.python.org  Thu Dec 10 19:42:46 2020
From: report at bugs.python.org (Steve Dower)
Date: Fri, 11 Dec 2020 00:42:46 +0000
Subject: [issue40747] sysconfig.get_config_var("py_version_nodot") should
 return 3_10
In-Reply-To: <1590266866.08.0.16909581495.issue40747@roundup.psfhosted.org>
Message-ID: <1607647366.05.0.0525190448304.issue40747@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

This has been blocking it: https://discuss.python.org/t/pep-641-using-an-underscore-in-the-version-portion-of-python-3-10-compatibility-tags/5513

Pablo (PEP delegate) has just posted his rejection though, so it will be fixed when packaging changes back to "310" from "3_10" and updates percolate out through the ecosystem.

Since moving to "4.x" is a breaking change, we can change to any system we like at that point. Well in advance of 31.0 being ambiguous.

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40747>
_______________________________________

From report at bugs.python.org  Thu Dec 10 19:42:52 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 11 Dec 2020 00:42:52 +0000
Subject: [issue42609] Eval with too high string multiplication crashes newer
 Python versions
In-Reply-To: <1607511907.66.0.321451468972.issue42609@roundup.psfhosted.org>
Message-ID: <1607647372.04.0.788001239652.issue42609@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42609>
_______________________________________

From report at bugs.python.org  Thu Dec 10 19:43:12 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 11 Dec 2020 00:43:12 +0000
Subject: [issue42609] Eval with too high string multiplication crashes newer
 Python versions
In-Reply-To: <1607511907.66.0.321451468972.issue42609@roundup.psfhosted.org>
Message-ID: <1607647392.22.0.342646108652.issue42609@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
nosy: +methane

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42609>
_______________________________________

From report at bugs.python.org  Thu Dec 10 19:54:35 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 11 Dec 2020 00:54:35 +0000
Subject: [issue41559] Add support for PEP 612 to typing.py
In-Reply-To: <CAOMZG7gy9KV47GoO==xO-1RnkQ-zARrwDObZ36ziPHdDLZrsYw@mail.gmail.com>
Message-ID: <CAP7+vJJTf175tZ60ZTYkD2ZL=h5xU7qhSeg0Sxg+UtV+4Jxsxw@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

I started doing this in the original code (long ago when PEP 484 was brand
new) but have since realized that this makes the typing module both slow
and hard to maintain. We should not follow this example. I do think we
should try to keep `__args__` hashable, casting `[int, str]` to `(int,
str)` sounds right.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41559>
_______________________________________

From report at bugs.python.org  Thu Dec 10 21:41:04 2020
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 11 Dec 2020 02:41:04 +0000
Subject: [issue39717] Fix exception causes in tarfile module
In-Reply-To: <1582315232.59.0.621263718222.issue39717@roundup.psfhosted.org>
Message-ID: <1607654464.23.0.0489440324561.issue39717@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
keywords: +patch
pull_requests: +22597
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23739

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39717>
_______________________________________

From report at bugs.python.org  Thu Dec 10 21:42:25 2020
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 11 Dec 2020 02:42:25 +0000
Subject: [issue39717] Fix exception causes in tarfile module
In-Reply-To: <1582315232.59.0.621263718222.issue39717@roundup.psfhosted.org>
Message-ID: <1607654545.88.0.047649696298.issue39717@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
versions: +Python 3.10 -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39717>
_______________________________________

From report at bugs.python.org  Thu Dec 10 23:55:10 2020
From: report at bugs.python.org (Soumendra Ganguly)
Date: Fri, 11 Dec 2020 04:55:10 +0000
Subject: [issue41818] Lib/pty.py major revision
In-Reply-To: <1600557574.22.0.272934906824.issue41818@roundup.psfhosted.org>
Message-ID: <1607662510.57.0.852718537964.issue41818@roundup.psfhosted.org>


Change by Soumendra Ganguly <soumendra at tamu.edu>:


----------
pull_requests: +22598
pull_request: https://github.com/python/cpython/pull/23740

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41818>
_______________________________________

From report at bugs.python.org  Fri Dec 11 03:27:51 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 11 Dec 2020 08:27:51 +0000
Subject: [issue41879] Outdated description of async iterables in documentation
 of async for statement
In-Reply-To: <1601324135.53.0.963696566223.issue41879@roundup.psfhosted.org>
Message-ID: <1607675271.95.0.903422646547.issue41879@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4b8cdfcb22fbeaab9d954cb693a7fb3362a382b6 by Nick Gaya in branch 'master':
bpo-41879: Doc: Fix description of async for statement (GH-23548)
https://github.com/python/cpython/commit/4b8cdfcb22fbeaab9d954cb693a7fb3362a382b6


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41879>
_______________________________________

From report at bugs.python.org  Fri Dec 11 05:12:29 2020
From: report at bugs.python.org (hongweipeng)
Date: Fri, 11 Dec 2020 10:12:29 +0000
Subject: [issue42609] Eval with too high string multiplication crashes newer
 Python versions
In-Reply-To: <1607511907.66.0.321451468972.issue42609@roundup.psfhosted.org>
Message-ID: <1607681549.25.0.48497268177.issue42609@roundup.psfhosted.org>


Change by hongweipeng <hongweichen8888 at sina.com>:


----------
nosy: +hongweipeng

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42609>
_______________________________________

From report at bugs.python.org  Fri Dec 11 05:22:08 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 11 Dec 2020 10:22:08 +0000
Subject: [issue42616] C Extensions on Darwin that link against libpython are
 likely to crash
In-Reply-To: <1607631684.88.0.776282381427.issue42616@roundup.psfhosted.org>
Message-ID: <1607682128.77.0.192087291986.issue42616@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Does this affect unix-style builds with --enable-shared or framework builds?

For the latter the python executable is linked to the framework, and lib python.dylib is an alias for the framework. 


A related known problem is that linking an extension to a different interpreter than it was loaded into. That is, link to /opt/lib/libpython.dylib, and use with a framework build (of v.v.).  That's one reason why linking extensions to libpython is not commonly done.

It might be interesting to experiment with "-bundle_loader ..." in the link flags instead of linking to libpython, this checks symbols not found in one of the linked to libraries against the bundle_loader ("like it was one of the dynamic libraries the bundle was linked with").  I don't know if this is a recursive check that will also look at libraries linked to by the bundle loader.

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42616>
_______________________________________

From report at bugs.python.org  Fri Dec 11 05:34:20 2020
From: report at bugs.python.org (xz_sophos)
Date: Fri, 11 Dec 2020 10:34:20 +0000
Subject: [issue42619] python 3.9.1 failed to create .so files as universal2
 (arm64, x86_64) on Mac
Message-ID: <1607682860.38.0.598588089863.issue42619@roundup.psfhosted.org>


New submission from xz_sophos <xing.zhang at sophos.com>:

With 3.9.1 source code, I am trying to make univerisal2 build of python.framework from the source code. The problem I am seeing is the main python binary is universal, but all the .so files in lib-dynload (Python.framework/Versions/3.9/lib/python3.9/lib-dynload/) are only x86_64.

The Mac is MacOS 10.15, with Xcode 12.2 installed. Xcode12.2 has SDKs to support universal build for both arm64 and x86_64 architecture. I have no problems making other universal applications and frameworks on the machine. 

Following the documentation. I ran the following build command:
./configure --enable-universalsdk --enable-framework=./tmp --with-universal-archs=universal2 --without-ensurepip
make
make install

The resulting python was universal but the .so files are not.

----------
components: macOS
messages: 382861
nosy: ned.deily, ronaldoussoren, xz_sophos
priority: normal
severity: normal
status: open
title: python 3.9.1 failed to create .so files as universal2 (arm64, x86_64) on Mac
type: compile error
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42619>
_______________________________________

From report at bugs.python.org  Fri Dec 11 06:13:00 2020
From: report at bugs.python.org (Peixing Xin)
Date: Fri, 11 Dec 2020 11:13:00 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1607685180.14.0.166991395963.issue31904@roundup.psfhosted.org>


Change by Peixing Xin <peixing.xin at windriver.com>:


----------
pull_requests: +22599
pull_request: https://github.com/python/cpython/pull/23741

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Fri Dec 11 06:38:37 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 11 Dec 2020 11:38:37 +0000
Subject: [issue42619] python 3.9.1 failed to create .so files as universal2
 (arm64, x86_64) on Mac
In-Reply-To: <1607682860.38.0.598588089863.issue42619@roundup.psfhosted.org>
Message-ID: <1607686717.43.0.648554421015.issue42619@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Currently macOS 11 is needed to build a universal2 framework. That because we haven't spent time yet on detecting if the current compiler can compile for arm64.

An easy workaround: Patch _osx_support.py, in particular the function "_supports_arm64_builds". This checks that the macOS version is 11.0 or later.



A PR that detects if Xcode 12 or the corresponding command line tools are used  would be welcome :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42619>
_______________________________________

From report at bugs.python.org  Fri Dec 11 06:49:59 2020
From: report at bugs.python.org (Rick van Rein)
Date: Fri, 11 Dec 2020 11:49:59 +0000
Subject: [issue42620] documentation on `getsockname()` wrong for AF_INET6
Message-ID: <1607687399.41.0.179840129913.issue42620@roundup.psfhosted.org>


New submission from Rick van Rein <rick at openfortress.nl>:

Shown in the session below is unexpected output of a 4-tuple from an AF_INET6 socket along with documentation that *suggests* to expect a 2-tuple.  The phrasing "IP" might have to be toned down to "IPv4" or "AF_INET" to be accurate enough to avoid confusion.

Opinion: I think you should be explicit about the different behaviour for AF_INET6, so it is not reduced to a special/nut case for special interest groups.  IPv6 has a hard enough time getting in; different formats for AF_INET and AF_INET6 should ideally be shown to all programmers, to at least avoid *uninformed* decisions to be incompatible with IPv6 while they develop on an IPv4 system (and the same in the opposite direction).


Python 3.7.3 (default, Jul 25 2020, 13:03:44) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> sox6 = socket.socket (socket.AF_INET6)
>>> sox6.getsockname ()
('::', 0, 0, 0)
>>> sox6.getsockname.__doc__
'getsockname() -> address info\n\nReturn the address of the local endpoint.  For IP sockets, the address\ninfo is a pair (hostaddr, port).'

----------
components: Library (Lib)
messages: 382863
nosy: vanrein
priority: normal
severity: normal
status: open
title: documentation on `getsockname()` wrong for AF_INET6
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42620>
_______________________________________

From report at bugs.python.org  Fri Dec 11 07:30:59 2020
From: report at bugs.python.org (Avinash Gaur)
Date: Fri, 11 Dec 2020 12:30:59 +0000
Subject: [issue42621] Python IDLE no longer opens after clicking on its icon
Message-ID: <1607689859.93.0.151638298109.issue42621@roundup.psfhosted.org>


New submission from Avinash Gaur <8962avi at gmail.com>:

I was able to use python IDLE earlier. But when I tried to open now, I was unable to open Python 3.7 IDLE. I have tried uninstalling and reinstalling Python(different versions) and deleting the .idlerc folder. I am using Windows 10.

----------
assignee: terry.reedy
components: IDLE
messages: 382864
nosy: 8962avi, terry.reedy
priority: normal
severity: normal
status: open
title: Python IDLE no longer opens after clicking on its icon
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42621>
_______________________________________

From report at bugs.python.org  Fri Dec 11 08:12:23 2020
From: report at bugs.python.org (Avinash Gaur)
Date: Fri, 11 Dec 2020 13:12:23 +0000
Subject: [issue42621] Python IDLE no longer opens after clicking on its icon
In-Reply-To: <1607689859.93.0.151638298109.issue42621@roundup.psfhosted.org>
Message-ID: <1607692343.82.0.500377349933.issue42621@roundup.psfhosted.org>


Change by Avinash Gaur <8962avi at gmail.com>:


----------
versions: +Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42621>
_______________________________________

From report at bugs.python.org  Fri Dec 11 08:39:10 2020
From: report at bugs.python.org (Avinash Gaur)
Date: Fri, 11 Dec 2020 13:39:10 +0000
Subject: [issue42621] Python IDLE no longer opens after clicking on its icon
In-Reply-To: <1607689859.93.0.151638298109.issue42621@roundup.psfhosted.org>
Message-ID: <1607693950.55.0.520995301609.issue42621@roundup.psfhosted.org>


Avinash Gaur <8962avi at gmail.com> added the comment:

I downloaded the .exe file from python.org
After trying to open the idle from cmd "py -3.9 -m idlelib", the error shown in picture comes.(python 3.7 was also showing same error)

----------
Added file: https://bugs.python.org/file49666/error.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42621>
_______________________________________

From report at bugs.python.org  Fri Dec 11 08:57:42 2020
From: report at bugs.python.org (=?utf-8?b?6ZuF6Zuv?=)
Date: Fri, 11 Dec 2020 13:57:42 +0000
Subject: [issue42621] Python IDLE no longer opens after clicking on its icon
In-Reply-To: <1607689859.93.0.151638298109.issue42621@roundup.psfhosted.org>
Message-ID: <1607695062.05.0.795205128466.issue42621@roundup.psfhosted.org>


?? <zhtw1234 at gmail.com> added the comment:

???

----------
nosy: +zhtw1234

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42621>
_______________________________________

From report at bugs.python.org  Fri Dec 11 09:03:07 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 11 Dec 2020 14:03:07 +0000
Subject: [issue42621] Python IDLE no longer opens after clicking on its icon
In-Reply-To: <1607689859.93.0.151638298109.issue42621@roundup.psfhosted.org>
Message-ID: <1607695387.95.0.740180474554.issue42621@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
Removed message: https://bugs.python.org/msg382866

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42621>
_______________________________________

From report at bugs.python.org  Fri Dec 11 09:06:00 2020
From: report at bugs.python.org (Bohdan Borkivskyi)
Date: Fri, 11 Dec 2020 14:06:00 +0000
Subject: [issue42622] Add support to add existing parser to
 ArgumentParser.subparsers
Message-ID: <1607695560.13.0.222854382376.issue42622@roundup.psfhosted.org>


New submission from Bohdan Borkivskyi <bohdan.borkivskyi at gmail.com>:

Currently, there is only a possibility to create empty parser as subparser - argparse.py, line 1122

The purpose of issue is to add support for existing parser to be added as subparser

----------
components: Library (Lib)
messages: 382867
nosy: borkivskyi
priority: normal
severity: normal
status: open
title: Add support to add existing parser to ArgumentParser.subparsers
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42622>
_______________________________________

From report at bugs.python.org  Fri Dec 11 09:12:48 2020
From: report at bugs.python.org (Bohdan Borkivskyi)
Date: Fri, 11 Dec 2020 14:12:48 +0000
Subject: [issue42622] Add support to add existing parser to
 ArgumentParser.subparsers
In-Reply-To: <1607695560.13.0.222854382376.issue42622@roundup.psfhosted.org>
Message-ID: <1607695968.59.0.714248924353.issue42622@roundup.psfhosted.org>


Change by Bohdan Borkivskyi <bohdan.borkivskyi at gmail.com>:


----------
versions: +Python 3.10 -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42622>
_______________________________________

From report at bugs.python.org  Fri Dec 11 09:17:39 2020
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 11 Dec 2020 14:17:39 +0000
Subject: [issue42620] documentation on `getsockname()` wrong for AF_INET6
In-Reply-To: <1607687399.41.0.179840129913.issue42620@roundup.psfhosted.org>
Message-ID: <1607696259.07.0.959017581684.issue42620@roundup.psfhosted.org>


Change by Christian Heimes <lists at cheimes.de>:


----------
keywords: +patch
nosy: +christian.heimes
nosy_count: 1.0 -> 2.0
pull_requests: +22600
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23742

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42620>
_______________________________________

From report at bugs.python.org  Fri Dec 11 09:21:11 2020
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 11 Dec 2020 14:21:11 +0000
Subject: [issue42620] documentation on `getsockname()` wrong for AF_INET6
In-Reply-To: <1607687399.41.0.179840129913.issue42620@roundup.psfhosted.org>
Message-ID: <1607696471.39.0.76271196857.issue42620@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

Good point. The address info depends on the address family, https://docs.python.org/3/library/socket.html#socket-families . I have updated the doc string:

>>> import socket
>>> print(socket.socket.getsockname.__doc__)
getsockname() -> address info

Return the address of the local endpoint. The format depends on the
address family. For IPv4 sockets, the address info is a pair
(hostaddr, port).

----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42620>
_______________________________________

From report at bugs.python.org  Fri Dec 11 09:41:40 2020
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 11 Dec 2020 14:41:40 +0000
Subject: [issue42246] Implement PEP 626
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1607697700.11.0.435719463404.issue42246@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +22601
pull_request: https://github.com/python/cpython/pull/23743

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42246>
_______________________________________

From report at bugs.python.org  Fri Dec 11 09:51:49 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 11 Dec 2020 14:51:49 +0000
Subject: [issue15898] OSX TTY bug
In-Reply-To: <1347238694.31.0.649838162085.issue15898@psf.upfronthosting.co.za>
Message-ID: <1607698309.14.0.721703837445.issue15898@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Closing this issue, because this is a platform bug.


The reproducer in msg170147 works reliably for me on macOS 10.15 with Python 3.9, the system bug may have been fixed in the meantime.

----------
components: +macOS
resolution: not a bug -> third party
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15898>
_______________________________________

From report at bugs.python.org  Fri Dec 11 10:09:15 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 11 Dec 2020 15:09:15 +0000
Subject: [issue42622] Add support to add existing parser to
 ArgumentParser.subparsers
In-Reply-To: <1607695560.13.0.222854382376.issue42622@roundup.psfhosted.org>
Message-ID: <1607699355.84.0.855490391215.issue42622@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +paul.j3, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42622>
_______________________________________

From report at bugs.python.org  Fri Dec 11 10:15:11 2020
From: report at bugs.python.org (conchylicultor)
Date: Fri, 11 Dec 2020 15:15:11 +0000
Subject: [issue39106] Add suggestions to argparse error message output for
 unrecognized arguments
In-Reply-To: <1576832169.43.0.680374670537.issue39106@roundup.psfhosted.org>
Message-ID: <1607699711.47.0.0970169287781.issue39106@roundup.psfhosted.org>


conchylicultor <etiennefg.pot at gmail.com> added the comment:

I don't think this should have been closed.

[1]  If the user is using sub_parser, the options are not even displayed. For example in our https://github.com/tensorflow/datasets project:

```
$ tfds build mnist --overwritte
usage: tfds [-h] [--helpfull] [--version] {build,new} ...
tfds: error: unrecognized arguments: --overwritte
```

[2] For some programs, there can be 20+ options and having to scroll through the list is not user friendly at all.

[3] Other CLI, like Google absl.flags has this option too and it is very convenient.

----------
nosy: +conchylicultor

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39106>
_______________________________________

From report at bugs.python.org  Fri Dec 11 10:26:07 2020
From: report at bugs.python.org (Ned Batchelder)
Date: Fri, 11 Dec 2020 15:26:07 +0000
Subject: [issue42246] Implement PEP 626
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1607700367.43.0.403265528571.issue42246@roundup.psfhosted.org>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

Mark, BTW: I have run the coverage.py test suite on 3.10.0a3, and as expected there are failures.  I haven't dug into it yet to see what looks expected and what does not.  I also see there are still changes happening on master, so I'm not sure when to commit the time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42246>
_______________________________________

From report at bugs.python.org  Fri Dec 11 10:50:18 2020
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 11 Dec 2020 15:50:18 +0000
Subject: [issue42246] Implement PEP 626
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1607701818.19.0.137742694701.issue42246@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Ned,
What are the failures?

I'd like to take a look, to see if things are as expected, and if there are any tests we can add to CPython.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42246>
_______________________________________

From report at bugs.python.org  Fri Dec 11 10:52:21 2020
From: report at bugs.python.org (Avinash Gaur)
Date: Fri, 11 Dec 2020 15:52:21 +0000
Subject: [issue42621] Python IDLE no longer opens after clicking on its icon
In-Reply-To: <1607689859.93.0.151638298109.issue42621@roundup.psfhosted.org>
Message-ID: <1607701941.95.0.895980420686.issue42621@roundup.psfhosted.org>


Avinash Gaur <8962avi at gmail.com> added the comment:

I tried deleting Environment Variables which has python. and now it is working.

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42621>
_______________________________________

From report at bugs.python.org  Fri Dec 11 12:07:17 2020
From: report at bugs.python.org (Sviatoslav Sydorenko)
Date: Fri, 11 Dec 2020 17:07:17 +0000
Subject: [issue26131] Raise ImportWarning when loader.load_module() is used
In-Reply-To: <1452894244.92.0.478987355259.issue26131@psf.upfronthosting.co.za>
Message-ID: <1607706437.07.0.677262622942.issue26131@roundup.psfhosted.org>


Sviatoslav Sydorenko <svyatoslav at sydorenko.org.ua> added the comment:

> What is "VendorImporter"

@brett.cannon `VendorImporter` is something comping from `pkg_resources`. Because of an entangled traceback and the fact that it dynamically injects a vendored copy of `six`, it's hard to spot. Here's an upstream issue I filed about this warning: https://github.com/pypa/setuptools/issues/2481.

----------
nosy: +webknjaz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26131>
_______________________________________

From report at bugs.python.org  Fri Dec 11 12:12:26 2020
From: report at bugs.python.org (Rick van Rein)
Date: Fri, 11 Dec 2020 17:12:26 +0000
Subject: [issue42620] documentation on `getsockname()` wrong for AF_INET6
In-Reply-To: <1607696471.39.0.76271196857.issue42620@roundup.psfhosted.org>
Message-ID: <5FD3A86D.3090008@openfortress.nl>


Rick van Rein <rick at openfortress.nl> added the comment:

Excellent, thanks.  I personally would appreciate if a remark about IPv6 would also be made.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42620>
_______________________________________

From report at bugs.python.org  Fri Dec 11 13:28:37 2020
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Dec 2020 18:28:37 +0000
Subject: [issue42456] Logical Error
In-Reply-To: <1606277996.92.0.109667336628.issue42456@roundup.psfhosted.org>
Message-ID: <1607711317.83.0.506356098582.issue42456@roundup.psfhosted.org>


Change by ?ric Araujo <merwok at netwok.org>:


----------
hgrepos:  -394

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42456>
_______________________________________

From report at bugs.python.org  Fri Dec 11 13:30:55 2020
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 11 Dec 2020 18:30:55 +0000
Subject: [issue42571] [docs] add links to Glossary#parameter in libraries
In-Reply-To: <1607116268.54.0.585771365964.issue42571@roundup.psfhosted.org>
Message-ID: <1607711455.84.0.155264238029.issue42571@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t think every function signature should have links when using `*`, `*args` or `**kwargs`.

Is there another page that we could improve?
What did you search for when you wanted to understand what it means?

Possible candidates: tutorial page about functions; language reference about functions; others?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42571>
_______________________________________

From report at bugs.python.org  Fri Dec 11 13:42:51 2020
From: report at bugs.python.org (Neil Schemenauer)
Date: Fri, 11 Dec 2020 18:42:51 +0000
Subject: [issue42608] Installation failed from source code on Debian
 ([307/416] test_socket)
In-Reply-To: <1607505269.45.0.398750468222.issue42608@roundup.psfhosted.org>
Message-ID: <1607712171.3.0.631079519233.issue42608@roundup.psfhosted.org>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

Maybe something to do the configuration of the machine, so that TCP/UDP socket networking if failing?  Two things to try:

- give the "python" process a SIGINT signal and you should get a traceback showing where it is hanging.  Or you could use "gdb" and attach to the process (assuming you know how to use gdb).

- configure without PGO (i.e. don't specify "--enable-optimizations" to conifgure).  That will result in a slightly slower build but the build will not require running of the tests.

----------
nosy: +nascheme

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42608>
_______________________________________

From report at bugs.python.org  Fri Dec 11 14:37:12 2020
From: report at bugs.python.org (Tom Birch)
Date: Fri, 11 Dec 2020 19:37:12 +0000
Subject: [issue42616] C Extensions on Darwin that link against libpython are
 likely to crash
In-Reply-To: <1607631684.88.0.776282381427.issue42616@roundup.psfhosted.org>
Message-ID: <1607715432.33.0.851671781275.issue42616@roundup.psfhosted.org>


Tom Birch <froody at gmail.com> added the comment:

> Does this affect unix-style builds with --enable-shared or framework builds?

I believe the answer is no, since in both those cases the `python` executable doesn't contain definitions for any of the libpython symbols. In my testing I was using a python binary from anaconda, where the `python` executable defines all the symbols found in libpython.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42616>
_______________________________________

From report at bugs.python.org  Fri Dec 11 14:54:24 2020
From: report at bugs.python.org (=?utf-8?b?6ZuF6Zuv?=)
Date: Fri, 11 Dec 2020 19:54:24 +0000
Subject: [issue42616] C Extensions on Darwin that link against libpython are
 likely to crash
In-Reply-To: <1607631684.88.0.776282381427.issue42616@roundup.psfhosted.org>
Message-ID: <1607716464.69.0.950751150749.issue42616@roundup.psfhosted.org>


?? <zhtw1234 at gmail.com> added the comment:

???

----------
components: +2to3 (2.x to 3.x conversion tool), Argument Clinic, Build, Cross-Build, asyncio, ctypes
nosy: +Alex.Willmer, asvetlov, larry, yselivanov, zhtw1234
versions: +Python 3.10, Python 3.6, Python 3.7
Added file: https://bugs.python.org/file49667/IMAG0629_1.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42616>
_______________________________________

From report at bugs.python.org  Fri Dec 11 14:56:37 2020
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 11 Dec 2020 19:56:37 +0000
Subject: [issue42616] C Extensions on Darwin that link against libpython are
 likely to crash
In-Reply-To: <1607631684.88.0.776282381427.issue42616@roundup.psfhosted.org>
Message-ID: <1607716597.59.0.665769445043.issue42616@roundup.psfhosted.org>


Change by Larry Hastings <larry at hastings.org>:


----------
nosy:  -larry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42616>
_______________________________________

From report at bugs.python.org  Fri Dec 11 14:58:11 2020
From: report at bugs.python.org (=?utf-8?b?6ZuF6Zuv?=)
Date: Fri, 11 Dec 2020 19:58:11 +0000
Subject: [issue42616] C Extensions on Darwin that link against libpython are
 likely to crash
In-Reply-To: <1607631684.88.0.776282381427.issue42616@roundup.psfhosted.org>
Message-ID: <1607716691.05.0.238660459666.issue42616@roundup.psfhosted.org>


?? <zhtw1234 at gmail.com> added the comment:

????????????????????????????????????????????????

----------
nosy: +larry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42616>
_______________________________________

From report at bugs.python.org  Fri Dec 11 14:59:09 2020
From: report at bugs.python.org (=?utf-8?b?6ZuF6Zuv?=)
Date: Fri, 11 Dec 2020 19:59:09 +0000
Subject: [issue42616] C Extensions on Darwin that link against libpython are
 likely to crash
In-Reply-To: <1607631684.88.0.776282381427.issue42616@roundup.psfhosted.org>
Message-ID: <1607716749.92.0.604367808509.issue42616@roundup.psfhosted.org>


Change by ?? <zhtw1234 at gmail.com>:


Removed file: https://bugs.python.org/file49667/IMAG0629_1.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42616>
_______________________________________

From report at bugs.python.org  Fri Dec 11 14:59:07 2020
From: report at bugs.python.org (paul j3)
Date: Fri, 11 Dec 2020 19:59:07 +0000
Subject: [issue39106] Add suggestions to argparse error message output for
 unrecognized arguments
In-Reply-To: <1576832169.43.0.680374670537.issue39106@roundup.psfhosted.org>
Message-ID: <1607716747.24.0.647868367716.issue39106@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

In the subparser example, it's the `build` subparser that puts '--overwritte' in the unrecognized list.  That is then passed back to the main parser, which then issues the 'unrecognized' error, along with its own usage.

The subparser is called with `parse_known_args` while the proposed patch is run in the `parse_args` method of the main parser.  It doesn't have access to the subparser's arguments.  So implementing the proposed matching will be much harder.

For some types of error, such as type or choices, the subparser itself raises the error, with the appropriate usage.  

===

https://bugs.python.org/issue42297
[argparse] Bad error message formatting when using custom usage text

is another case where error messages produced by the subparser differ from messages produced by the main. In this case the unrecognized error usage message is clearer since it is produced by the main parser.

===

I didn't close this issue, but it does feel like an enhancement that's too big for the bug/issues forum.  The proposed patch could be developed as a separate 'parser.parse_args_with_hints' method, and distributed as a pypi addition.  During development and testing, the regular 'parser.parse_args()' does not need to be touched.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39106>
_______________________________________

From report at bugs.python.org  Fri Dec 11 15:00:09 2020
From: report at bugs.python.org (=?utf-8?b?6ZuF6Zuv?=)
Date: Fri, 11 Dec 2020 20:00:09 +0000
Subject: [issue21536] extension built with a shared python cannot be loaded
 with a static python
In-Reply-To: <1400525402.57.0.75792320709.issue21536@psf.upfronthosting.co.za>
Message-ID: <1607716809.9.0.770603673071.issue21536@roundup.psfhosted.org>


?? <zhtw1234 at gmail.com> added the comment:

???

----------
nosy: +zhtw1234

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21536>
_______________________________________

From report at bugs.python.org  Fri Dec 11 15:00:31 2020
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 11 Dec 2020 20:00:31 +0000
Subject: [issue42616] C Extensions on Darwin that link against libpython are
 likely to crash
In-Reply-To: <1607631684.88.0.776282381427.issue42616@roundup.psfhosted.org>
Message-ID: <1607716831.7.0.469601975171.issue42616@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

Stop adding me to this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42616>
_______________________________________

From report at bugs.python.org  Fri Dec 11 15:02:09 2020
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 11 Dec 2020 20:02:09 +0000
Subject: [issue42616] C Extensions on Darwin that link against libpython are
 likely to crash
In-Reply-To: <1607631684.88.0.776282381427.issue42616@roundup.psfhosted.org>
Message-ID: <1607716929.68.0.493728475862.issue42616@roundup.psfhosted.org>


Change by Larry Hastings <larry at hastings.org>:


----------
nosy:  -larry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42616>
_______________________________________

From report at bugs.python.org  Fri Dec 11 15:03:10 2020
From: report at bugs.python.org (=?utf-8?b?6ZuF6Zuv?=)
Date: Fri, 11 Dec 2020 20:03:10 +0000
Subject: [issue42246] Implement PEP 626
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1607716990.19.0.514713839138.issue42246@roundup.psfhosted.org>


?? <zhtw1234 at gmail.com> added the comment:

???

----------
nosy: +zhtw1234
Added file: https://bugs.python.org/file49668/IMAG0629_1.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42246>
_______________________________________

From report at bugs.python.org  Fri Dec 11 15:03:44 2020
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 11 Dec 2020 20:03:44 +0000
Subject: [issue42616] C Extensions on Darwin that link against libpython are
 likely to crash
In-Reply-To: <1607631684.88.0.776282381427.issue42616@roundup.psfhosted.org>
Message-ID: <1607717024.34.0.747659998152.issue42616@roundup.psfhosted.org>


Larry Hastings <larry at hastings.org> added the comment:

Sorry, somehow bpo decided I added two people to this issue?  Weird.  Anyway I have removed them (Ned and "froody").

----------
nosy: +larry -froody, ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42616>
_______________________________________

From report at bugs.python.org  Fri Dec 11 15:03:52 2020
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 11 Dec 2020 20:03:52 +0000
Subject: [issue42616] C Extensions on Darwin that link against libpython are
 likely to crash
In-Reply-To: <1607631684.88.0.776282381427.issue42616@roundup.psfhosted.org>
Message-ID: <1607717032.85.0.148577890247.issue42616@roundup.psfhosted.org>


Change by Larry Hastings <larry at hastings.org>:


----------
nosy:  -larry

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42616>
_______________________________________

From report at bugs.python.org  Fri Dec 11 15:04:23 2020
From: report at bugs.python.org (=?utf-8?b?6ZuF6Zuv?=)
Date: Fri, 11 Dec 2020 20:04:23 +0000
Subject: [issue42246] Implement PEP 626
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1607717063.88.0.821607321317.issue42246@roundup.psfhosted.org>


?? <zhtw1234 at gmail.com> added the comment:

????

----------
Added file: https://bugs.python.org/file49669/IMAG0629_1(1).jpg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42246>
_______________________________________

From report at bugs.python.org  Fri Dec 11 15:04:38 2020
From: report at bugs.python.org (=?utf-8?b?6ZuF6Zuv?=)
Date: Fri, 11 Dec 2020 20:04:38 +0000
Subject: [issue42246] Implement PEP 626
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1607717078.6.0.327007908169.issue42246@roundup.psfhosted.org>


Change by ?? <zhtw1234 at gmail.com>:


Removed file: https://bugs.python.org/file49668/IMAG0629_1.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42246>
_______________________________________

From report at bugs.python.org  Fri Dec 11 15:05:09 2020
From: report at bugs.python.org (paul j3)
Date: Fri, 11 Dec 2020 20:05:09 +0000
Subject: [issue42622] Add support to add existing parser to
 ArgumentParser.subparsers
In-Reply-To: <1607695560.13.0.222854382376.issue42622@roundup.psfhosted.org>
Message-ID: <1607717109.63.0.576734493243.issue42622@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

An existing parser can be included in a new subparser via the 'parents' mechanism.  With that the _actions and groups of the parent are copied (by reference) to the new subparser.

There are some rough edges to the parents mechanism, but people have used it to add a common subset of arguments to all subparsers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42622>
_______________________________________

From report at bugs.python.org  Fri Dec 11 15:06:23 2020
From: report at bugs.python.org (=?utf-8?b?6ZuF6Zuv?=)
Date: Fri, 11 Dec 2020 20:06:23 +0000
Subject: [issue42246] Implement PEP 626
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1607717183.95.0.337904253838.issue42246@roundup.psfhosted.org>


?? <zhtw1234 at gmail.com> added the comment:

???
????????????

----------
Added file: https://bugs.python.org/file49670/IMAG0629_1.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42246>
_______________________________________

From report at bugs.python.org  Fri Dec 11 15:08:02 2020
From: report at bugs.python.org (=?utf-8?b?6ZuF6Zuv?=)
Date: Fri, 11 Dec 2020 20:08:02 +0000
Subject: [issue42246] Implement PEP 626
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1607717282.68.0.575042756755.issue42246@roundup.psfhosted.org>


?? <zhtw1234 at gmail.com> added the comment:

?????

----------
Added file: https://bugs.python.org/file49671/IMAG0629_1.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42246>
_______________________________________

From report at bugs.python.org  Fri Dec 11 15:09:40 2020
From: report at bugs.python.org (=?utf-8?b?6ZuF6Zuv?=)
Date: Fri, 11 Dec 2020 20:09:40 +0000
Subject: [issue42246] Implement PEP 626
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1607717380.13.0.110463973884.issue42246@roundup.psfhosted.org>


?? <zhtw1234 at gmail.com> added the comment:

???

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42246>
_______________________________________

From report at bugs.python.org  Fri Dec 11 16:14:14 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 11 Dec 2020 21:14:14 +0000
Subject: [issue42246] Implement PEP 626 -- Precise line numbers for debugging
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1607721254.99.0.43801822454.issue42246@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
title: Implement PEP 626 -> Implement PEP 626 -- Precise line numbers for debugging

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42246>
_______________________________________

From report at bugs.python.org  Fri Dec 11 16:14:55 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 11 Dec 2020 21:14:55 +0000
Subject: [issue41559] Add support for PEP 612  to typing.py
In-Reply-To: <1597516564.62.0.520187732663.issue41559@roundup.psfhosted.org>
Message-ID: <1607721295.96.0.369994412571.issue41559@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
title: Add support for PEP 612 to typing.py -> Add support for PEP 612  to typing.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41559>
_______________________________________

From report at bugs.python.org  Fri Dec 11 16:15:25 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 11 Dec 2020 21:15:25 +0000
Subject: [issue41559] Add support for PEP 612 (Parameter Specification
 Variables) to typing.py
In-Reply-To: <1597516564.62.0.520187732663.issue41559@roundup.psfhosted.org>
Message-ID: <1607721325.29.0.290927540397.issue41559@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
title: Add support for PEP 612  to typing.py -> Add support for PEP 612 (Parameter Specification Variables) to typing.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41559>
_______________________________________

From report at bugs.python.org  Fri Dec 11 16:48:17 2020
From: report at bugs.python.org (=?utf-8?q?Filipe_La=C3=ADns?=)
Date: Fri, 11 Dec 2020 21:48:17 +0000
Subject: [issue42610] Get the type from a variable
In-Reply-To: <1607521186.12.0.817710588965.issue42610@roundup.psfhosted.org>
Message-ID: <1607723297.4.0.40140264274.issue42610@roundup.psfhosted.org>


Filipe La?ns <lains at riseup.net> added the comment:

There is type() to get the runtime type.

https://docs.python.org/3/library/functions.html#type

```python
>>> foo = 1
>>> type(foo)
<class 'int'>
```

Keep in mind that in Python using type hints does not enforce anything at runtime. You can say `foo: int = 1` but `int` there is just some extra information for type checkers, like mypy, to use.

If you want the type hints, you can use typing.get_type_hints() but this is only available for modules, classes or functions, not variables.

----------
nosy: +FFY00

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42610>
_______________________________________

From report at bugs.python.org  Fri Dec 11 17:14:54 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 11 Dec 2020 22:14:54 +0000
Subject: [issue42621] Python IDLE no longer opens after clicking on its icon
In-Reply-To: <1607689859.93.0.151638298109.issue42621@roundup.psfhosted.org>
Message-ID: <1607724894.68.0.0361905707459.issue42621@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

https://docs.python.org/3/library/idle.html#startup-failure says
"A common cause of failure is a user-written file with the same name as a standard library module, such as random.py and tkinter.py. When such a file is located in the same directory as a file that is about to be run, IDLE cannot import the stdlib file. The current fix is to rename the user file."

In this case, the offending file and name is your Desktop/code.py.  Rename it.

----------
resolution:  -> not a bug

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42621>
_______________________________________

From report at bugs.python.org  Fri Dec 11 17:25:18 2020
From: report at bugs.python.org (Andre Roberge)
Date: Fri, 11 Dec 2020 22:25:18 +0000
Subject: [issue42577] Unhelpful syntax error when expression spans multiple
 lines
In-Reply-To: <1607181038.72.0.910363231446.issue42577@roundup.psfhosted.org>
Message-ID: <1607725518.81.0.237363692587.issue42577@roundup.psfhosted.org>


Andre Roberge <andre.roberge at gmail.com> added the comment:

I suspect that the Python parser cannot easily be changed to given any other message. Replace the colon by "else" and add one more closing parenthesis and you have a valid Python program.  So, is it a matter of an unclosed parenthesis, or not using "else" ? ....



If you want possible additional help in such situations, you can try to use the third-party package friendly-traceback which gives the following information for this case (I put your code in a file named "ignore.py")

====
Traceback (most recent call last):
  File "ignore.py", line 5
    if 2:
        ^
SyntaxError: invalid syntax

    A `SyntaxError` occurs when Python cannot understand your code.

    Python could not understand the code in the file
    'ignore.py'
    beyond the location indicated by --> and ^.

       2:     if 1:
       3:         print(((123))
       4:
    -->5: if 2:
              ^
       6:     print(123)

        I make an effort below to guess what caused the problem
        but I might guess incorrectly.

        The opening parenthesis `(` on line 3 is not closed.

            3:         print(((123))
                            ^

----------
nosy: +aroberge

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42577>
_______________________________________

From report at bugs.python.org  Fri Dec 11 18:50:15 2020
From: report at bugs.python.org (Christoph Reiter)
Date: Fri, 11 Dec 2020 23:50:15 +0000
Subject: [issue42577] Unhelpful syntax error when expression spans multiple
 lines
In-Reply-To: <1607181038.72.0.910363231446.issue42577@roundup.psfhosted.org>
Message-ID: <1607730615.3.0.309435779267.issue42577@roundup.psfhosted.org>


Christoph Reiter <reiter.christoph at gmail.com> added the comment:

I would expect Python to print the current statement up to the error instead of just the last line:

```
File "error.py", line 3-5
          print(((123))

  if 2:
      ^
```

This would solve this case nicely while in the common case still show one line as before.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42577>
_______________________________________

From report at bugs.python.org  Fri Dec 11 20:00:01 2020
From: report at bugs.python.org (Irit Katriel)
Date: Sat, 12 Dec 2020 01:00:01 +0000
Subject: [issue24959] unittest swallows part of stack trace when raising
 AssertionError in a TestCase
In-Reply-To: <1440864914.24.0.799928607113.issue24959@psf.upfronthosting.co.za>
Message-ID: <1607734801.33.0.423620948146.issue24959@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

I think this is the same as issue42247, where I've recently attached a patch that removes __unittest frames from the traceback rather than count them and then set a limit for printing. 

I could add to that patch what Robert suggests here - to filter the __cause__ traceback as well.

----------
nosy: +iritkatriel
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24959>
_______________________________________

From report at bugs.python.org  Fri Dec 11 20:39:53 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 12 Dec 2020 01:39:53 +0000
Subject: [issue42575] Suggest to add an LinkedList data structure to python
In-Reply-To: <1607150139.15.0.868707735034.issue42575@roundup.psfhosted.org>
Message-ID: <1607737193.57.0.0655446447369.issue42575@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The opening claim (no linked list structures in Python) is flawed. Abstractly, a linked list is a binary tree with right items of nodes restricted to being a linked list or None.  If the left items are restricted to being non-lists values, then the linked list implements, in somewhat peculiar way, a sequence of non-list values.

Python's tuples and lists can make general trees with unrestricted numbers and types of items.  Add the linked-list restriction as to number and types and one has, in Python already, a frozen or mutable linked list.  Alternatively, one can make linked lists in Python with a class with two named attributes with whichever linked-list restrictions.  Finally, one can view a deque as a doubly-linked list, mutable at each end.  Internally, it is a doubly-linked list of blocks of values.  The block size is tuned to the cache size of modern processors.

Lisp's linked lists are a solution to incrementally building immutable structures that can be processed by function-call recursion.  The key idea is that a sequence can be inductively defined as the first item followed by the rest.  Python is not restricted to either immutable structures or recursion, but its iteration protocol implements that key idea.  it = iter(iterable) represents a non-iterator iterable by an iterator (and an iterator by itself).  next(it) splits the sequence represented by 'it' into first and rest, mutates 'it' to represent the rest, and returns the first.  (The proposed class is missing a ListIterator class and a .__iter__ method to return one.)
---

I am sure that adding linked lists has been proposed and rejected before.  I know that b-trees have been, and likely others specialized structures.  Guido decided long ago that such things should generally be left to what is now https://pypi.org. The major exceptional addition was deque, which filled the hole of being efficiently mutated at each end.  So I think that this issue should be closed.

Adding a new structure is too 'big' a change for a bpo issue.  Discussion on python-ideas list and a PEP would be needed.  But I think the chance of success is nil.

----------
components: +Interpreter Core -C API
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42575>
_______________________________________

From report at bugs.python.org  Fri Dec 11 20:45:32 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 12 Dec 2020 01:45:32 +0000
Subject: [issue42603] Tkinter: pkg-config is not used to get location of tcl
 and tk headers/libraries
In-Reply-To: <1607450864.79.0.446942772761.issue42603@roundup.psfhosted.org>
Message-ID: <1607737532.71.0.297939903002.issue42603@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Correctly prefixed, issue 42541 and #42541 are links.  And thanks for doing CLA first.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42603>
_______________________________________

From report at bugs.python.org  Fri Dec 11 20:54:23 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 12 Dec 2020 01:54:23 +0000
Subject: [issue42611] PEP 594 Removing dead batteries from stdlib
In-Reply-To: <1607575872.07.0.562391698279.issue42611@roundup.psfhosted.org>
Message-ID: <1607738063.49.0.949886328262.issue42611@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Until a pep is approved, discussion of its ideas belong elsewhere; an issue is only needed for a proposed implementation  Is PR 23728 purely for discussion leading to possible approval of the PEP, or for merging regardless of the PEP fate?

----------
nosy: +terry.reedy
title: PEP 594 -> PEP 594 Removing dead batteries from stdlib

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42611>
_______________________________________

From report at bugs.python.org  Fri Dec 11 21:04:16 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 12 Dec 2020 02:04:16 +0000
Subject: [issue42575] Suggest to add an LinkedList data structure to python
In-Reply-To: <1607150139.15.0.868707735034.issue42575@roundup.psfhosted.org>
Message-ID: <1607738656.8.0.199254287785.issue42575@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> So I think that this issue should be closed.

I agree with the respondents.  Marking this one as closed.

----------
nosy: +rhettinger
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42575>
_______________________________________

From report at bugs.python.org  Fri Dec 11 21:31:43 2020
From: report at bugs.python.org (Pratik Palwai)
Date: Sat, 12 Dec 2020 02:31:43 +0000
Subject: [issue42623] Syntax Error showing pointer in wrong location
Message-ID: <1607740303.61.0.556483220394.issue42623@roundup.psfhosted.org>


New submission from Pratik Palwai <1051371 at student.auhsd.us>:

When I get a syntax error, it shows the line with the error, and then a little '^' on the next line, showing where the error is. However, the location of the '^' is a little misleading, since it isn't in the right spot. For example (not sure if it will format correctly though):
elif self.left == None and self.right =! None:
                          ^
The symbol should be under the +! instead of under the 'and.' Also, this problem doesn't occur with the font Courier.

----------
assignee: terry.reedy
components: IDLE
messages: 382900
nosy: 1051371, terry.reedy
priority: normal
severity: normal
status: open
title: Syntax Error showing pointer in wrong location
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42623>
_______________________________________

From report at bugs.python.org  Fri Dec 11 22:23:57 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 12 Dec 2020 03:23:57 +0000
Subject: [issue42623] Syntax Error showing pointer in wrong location
In-Reply-To: <1607740303.61.0.556483220394.issue42623@roundup.psfhosted.org>
Message-ID: <1607743437.49.0.436417934565.issue42623@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

The position of the caret assumes that every character in the string takes up the same width, measured in pixels. That is only true for monospaced fonts like Courier.

The only way to position the caret precisely with a proportional-width font is to compute the number of pixels for each character and then line up the caret at a position based on pixels rather than character columns. Unless Tkinter has functions to do both, it will probably be complicated and expensive, and I doubt anyone would care enough to do it.

----------
nosy: +steven.daprano -1051371

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42623>
_______________________________________

From report at bugs.python.org  Sat Dec 12 01:46:00 2020
From: report at bugs.python.org (ali)
Date: Sat, 12 Dec 2020 06:46:00 +0000
Subject: [issue42608] Installation failed from source code on Debian
 ([307/416] test_socket)
In-Reply-To: <1607505269.45.0.398750468222.issue42608@roundup.psfhosted.org>
Message-ID: <1607755560.0.0.6218526997.issue42608@roundup.psfhosted.org>


ali <ali.azimzadeh70 at gmail.com> added the comment:

I used build_all  instead of --enable-optimizations option.

Thanks you.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42608>
_______________________________________

From report at bugs.python.org  Sat Dec 12 03:47:49 2020
From: report at bugs.python.org (LIU Qingyuan)
Date: Sat, 12 Dec 2020 08:47:49 +0000
Subject: [issue42624] sqlite3 package document mistake
Message-ID: <1607762869.89.0.42414804314.issue42624@roundup.psfhosted.org>


New submission from LIU Qingyuan <possnioo2 at gmail.com>:

In the document about sqlite3 package, it was suggested that when users are trying to create a table already exists, sqlite3.ProgrammingError is going to be thrown. However, the actual exception thrown is sqlite3.OperationalError, which is inconsistent with the document.

Doc: https://docs.python.org/3/library/sqlite3.html#exceptions

----------
assignee: docs at python
components: Documentation
messages: 382904
nosy: docs at python, seeker-Liu
priority: normal
severity: normal
status: open
title: sqlite3 package document mistake
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42624>
_______________________________________

From report at bugs.python.org  Sat Dec 12 04:35:51 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Sat, 12 Dec 2020 09:35:51 +0000
Subject: [issue42624] sqlite3 package document mistake
In-Reply-To: <1607762869.89.0.42414804314.issue42624@roundup.psfhosted.org>
Message-ID: <1607765751.47.0.875697260733.issue42624@roundup.psfhosted.org>


Change by Karthikeyan Singaravelan <tir.karthi at gmail.com>:


----------
nosy: +berker.peksag, ghaering

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42624>
_______________________________________

From report at bugs.python.org  Sat Dec 12 04:41:34 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Sat, 12 Dec 2020 09:41:34 +0000
Subject: [issue41972] bytes.find consistently hangs in a particular scenario
In-Reply-To: <1602113519.53.0.297229304628.issue41972@roundup.psfhosted.org>
Message-ID: <1607766094.56.0.820360947045.issue41972@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

For convenience, attached is a quick and dirty Tkinter GUI that lets you step through the Crochemore/Perrin Algorithm on your choice of inputs, just for play/discovery.

A good illustration of the memory for periodic needles can be found by testing:
    haystack="456,123,123,456,123,123,456"
    needle="123,123,123,"

The GUI program does not implement the Boyer-Moore/Horspool/Sunday-style shift-table. In the current PR 22904, this table is used in exactly those situations where the GUI says "Matched 0, so jump ahead by 1".

----------
Added file: https://bugs.python.org/file49672/twoway_demo.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41972>
_______________________________________

From report at bugs.python.org  Sat Dec 12 05:14:46 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 12 Dec 2020 10:14:46 +0000
Subject: =?utf-8?q?=5Bissue42614=5D_Pathlib_does_not_support_a_Cyrillic_character_?=
 =?utf-8?b?J9C5Jw==?=
In-Reply-To: <1607599977.07.0.665981519829.issue42614@roundup.psfhosted.org>
Message-ID: <1607768086.74.0.255603615607.issue42614@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

What filesystem is used on macOS? If it is HFS+ you're likely running into unicode normalisation in the filesystem.

That is, '?' can be represented as a single unicode codepoint (and likely is in your script), but in the NFD normalisation used by HFS+ the same character is represented using two codepoints (one of which is a combining character). Python string comparison compares code points and is not normalisation aware.

For APFS (used by default in recent macOS versions) the situation is more complicated according to what I've found on Google. However, APFS doesn't seen to normalise names (I've created a file name '?' and os.listdir() returns a name with a single codepoint).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42614>
_______________________________________

From report at bugs.python.org  Sat Dec 12 05:15:03 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 12 Dec 2020 10:15:03 +0000
Subject: =?utf-8?q?=5Bissue42614=5D_Pathlib_does_not_support_a_Cyrillic_character_?=
 =?utf-8?b?J9C5Jw==?=
In-Reply-To: <1607599977.07.0.665981519829.issue42614@roundup.psfhosted.org>
Message-ID: <1607768103.79.0.660713185776.issue42614@roundup.psfhosted.org>


Change by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
components: +macOS
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42614>
_______________________________________

From report at bugs.python.org  Sat Dec 12 05:16:24 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 12 Dec 2020 10:16:24 +0000
Subject: [issue42616] C Extensions on Darwin that link against libpython are
 likely to crash
In-Reply-To: <1607631684.88.0.776282381427.issue42616@roundup.psfhosted.org>
Message-ID: <1607768184.18.0.227451454326.issue42616@roundup.psfhosted.org>


Change by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
Removed message: https://bugs.python.org/msg382880

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42616>
_______________________________________

From report at bugs.python.org  Sat Dec 12 05:16:45 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 12 Dec 2020 10:16:45 +0000
Subject: [issue42616] C Extensions on Darwin that link against libpython are
 likely to crash
In-Reply-To: <1607631684.88.0.776282381427.issue42616@roundup.psfhosted.org>
Message-ID: <1607768205.58.0.0468468666394.issue42616@roundup.psfhosted.org>


Change by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
Removed message: https://bugs.python.org/msg382879

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42616>
_______________________________________

From report at bugs.python.org  Sat Dec 12 05:17:37 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 12 Dec 2020 10:17:37 +0000
Subject: [issue42616] C Extensions on Darwin that link against libpython are
 likely to crash
In-Reply-To: <1607631684.88.0.776282381427.issue42616@roundup.psfhosted.org>
Message-ID: <1607768257.45.0.719270993563.issue42616@roundup.psfhosted.org>


Change by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
components: +Distutils -2to3 (2.x to 3.x conversion tool), Argument Clinic, C API, Cross-Build, asyncio, ctypes
nosy: +dstufft, eric.araujo, froody, ned.deily -Alex.Willmer, asvetlov, yselivanov, zhtw1234
versions:  -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42616>
_______________________________________

From report at bugs.python.org  Sat Dec 12 05:18:51 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 12 Dec 2020 10:18:51 +0000
Subject: [issue42616] C Extensions on Darwin that link against libpython are
 likely to crash
In-Reply-To: <1607631684.88.0.776282381427.issue42616@roundup.psfhosted.org>
Message-ID: <1607768331.77.0.35851214044.issue42616@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've removed two spammy comments and adjusted the categories (the latter explains Larry's annoyance, someone selected all categories which automatically added him to the nosy list).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42616>
_______________________________________

From report at bugs.python.org  Sat Dec 12 05:26:03 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 12 Dec 2020 10:26:03 +0000
Subject: [issue42616] C Extensions on Darwin that link against libpython are
 likely to crash
In-Reply-To: <1607631684.88.0.776282381427.issue42616@roundup.psfhosted.org>
Message-ID: <1607768763.06.0.0752473896468.issue42616@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Linking extensions to libpython with a static build of python will cause problems (as you described in your initial message).

The not very satisfactory response is "don't do that then".  Note that distutils won't link against libpython by default.

Longer term I want to look into "-bundle_loader ..." because that might allow us to drop "-undefined dynamic_lookup" from the linker flags and hence give a nicer development experience (build-time error instead of runtime error when symbols cannot be found).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42616>
_______________________________________

From report at bugs.python.org  Sat Dec 12 07:31:35 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 12 Dec 2020 12:31:35 +0000
Subject: [issue42609] Eval with too high string multiplication crashes newer
 Python versions
In-Reply-To: <1607511907.66.0.321451468972.issue42609@roundup.psfhosted.org>
Message-ID: <1607776295.09.0.196953304415.issue42609@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
nosy: +serhiy.storchaka
nosy_count: 6.0 -> 7.0
pull_requests: +22602
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23744

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42609>
_______________________________________

From report at bugs.python.org  Sat Dec 12 07:43:09 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 12 Dec 2020 12:43:09 +0000
Subject: [issue38137] hashopenssl fails to compile on MacOS
In-Reply-To: <1568295369.63.0.535075391802.issue38137@roundup.psfhosted.org>
Message-ID: <1607776989.47.0.02174571798.issue38137@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

can this issue be closed?

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38137>
_______________________________________

From report at bugs.python.org  Sat Dec 12 07:43:20 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 12 Dec 2020 12:43:20 +0000
Subject: [issue38137] hashopenssl fails to compile on MacOS
In-Reply-To: <1568295369.63.0.535075391802.issue38137@roundup.psfhosted.org>
Message-ID: <1607777000.63.0.162400861053.issue38137@roundup.psfhosted.org>


Change by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
components: +macOS
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38137>
_______________________________________

From report at bugs.python.org  Sat Dec 12 07:44:04 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 12 Dec 2020 12:44:04 +0000
Subject: [issue42609] Eval with too high string multiplication crashes newer
 Python versions
In-Reply-To: <1607511907.66.0.321451468972.issue42609@roundup.psfhosted.org>
Message-ID: <1607777044.34.0.701800980875.issue42609@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This is known issue, but interesting that the cause of the crash is different in 3.7-3.8 and 3.9+.

PR 23744 adds recursion checks in the AST validator and optimizer similar to the checks in the symtable. It should not break any existing code because too deep AST tree did not pass checks in the symtable in any case.

But it does not solve all problems. A compound statement with too many "elif"s is still crashed because the new parser uses recursion in C to parse it (elif_stmt_rule). I think it should be a separate issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42609>
_______________________________________

From report at bugs.python.org  Sat Dec 12 08:41:20 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 12 Dec 2020 13:41:20 +0000
Subject: [issue42617] Enhancement request for PyType_FromSpecWIthBases add
 option for meta class
In-Reply-To: <1607636440.03.0.352368649598.issue42617@roundup.psfhosted.org>
Message-ID: <1607780480.68.0.592758092794.issue42617@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

>This code could be made much safer if there were a PyType_FromSpecWithBasesMeta which used the meta class to allocate the memory

IMHO, `PyType_FromSpecWithBases` is a atomic API of `TypeObject`.
Adding a class as a param will result in `PyType_FromSpecWithBases` will be complicated(the logic of this function depends on the children's tp_alloc sometimes).

I add pter in this bpo, maybe he have some better ideas :)

----------
nosy: +petr.viktorin, shihai1991
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42617>
_______________________________________

From report at bugs.python.org  Sat Dec 12 08:52:09 2020
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 12 Dec 2020 13:52:09 +0000
Subject: [issue38137] hashopenssl fails to compile on MacOS
In-Reply-To: <1568295369.63.0.535075391802.issue38137@roundup.psfhosted.org>
Message-ID: <1607781129.82.0.64783874921.issue38137@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

I don't have access to macOS. Did the PR fix the issue?

----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38137>
_______________________________________

From report at bugs.python.org  Sat Dec 12 09:19:08 2020
From: report at bugs.python.org (E. Paine)
Date: Sat, 12 Dec 2020 14:19:08 +0000
Subject: [issue42623] Syntax Error showing pointer in wrong location
In-Reply-To: <1607740303.61.0.556483220394.issue42623@roundup.psfhosted.org>
Message-ID: <1607782748.07.0.398453009444.issue42623@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

While Tkinter could do it, I see no point in doing so. One thing that may be worth looking into is only allowing IDLE to use fixed-width fonts, but maybe this is just another of my crazy ideas... I think this can be safely closed unless someone wants to make a strong point for such changes.

@ Steven, did you mean to un-nosy Pratik?

----------
nosy: +epaine

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42623>
_______________________________________

From report at bugs.python.org  Sat Dec 12 09:39:22 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 12 Dec 2020 14:39:22 +0000
Subject: [issue42623] Syntax Error showing pointer in wrong location
In-Reply-To: <1607782748.07.0.398453009444.issue42623@roundup.psfhosted.org>
Message-ID: <20201212143850.GJ4576@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> @ Steven, did you mean to un-nosy Pratik?

No. I have tried to re-add him, but I think that because his user name 
is all digits, the bug tracker won't accept it.

When I try, I get this error:

Edit Error: user has no node 1051371

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42623>
_______________________________________

From report at bugs.python.org  Sat Dec 12 10:09:41 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 12 Dec 2020 15:09:41 +0000
Subject: [issue42625] Segmentation fault of PyState_AddModule()
Message-ID: <1607785781.22.0.676457210715.issue42625@roundup.psfhosted.org>


New submission from hai shi <shihai1991 at 126.com>:

PyState_AddModule(NULL, &_testcapimodule) in _testcapi module will get a segmentation fault. And it's a C API, so a little improvement will be better.

----------
assignee: shihai1991
components: C API
messages: 382915
nosy: petr.viktorin, shihai1991, vstinner
priority: normal
severity: normal
status: open
title: Segmentation fault of PyState_AddModule()
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42625>
_______________________________________

From report at bugs.python.org  Sat Dec 12 10:23:48 2020
From: report at bugs.python.org (hai shi)
Date: Sat, 12 Dec 2020 15:23:48 +0000
Subject: [issue42625] Segmentation fault of PyState_AddModule()
In-Reply-To: <1607785781.22.0.676457210715.issue42625@roundup.psfhosted.org>
Message-ID: <1607786628.15.0.113877430771.issue42625@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
keywords: +patch
pull_requests: +22603
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23745

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42625>
_______________________________________

From report at bugs.python.org  Sat Dec 12 11:20:38 2020
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Sat, 12 Dec 2020 16:20:38 +0000
Subject: [issue41429] Let fnmatch.filter accept a tuple of patterns
In-Reply-To: <1595979718.87.0.129861821474.issue41429@roundup.psfhosted.org>
Message-ID: <1607790038.74.0.0387448822324.issue41429@roundup.psfhosted.org>


Andr?s Delfino <adelfino at gmail.com> added the comment:

Serhiy, could you take a look at this when you have some spare time? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41429>
_______________________________________

From report at bugs.python.org  Sat Dec 12 12:51:50 2020
From: report at bugs.python.org (Joakim Nilsson)
Date: Sat, 12 Dec 2020 17:51:50 +0000
Subject: [issue42626] readline history, vi-editingmode and ANSI color codes bug
Message-ID: <1607795510.65.0.341487246406.issue42626@roundup.psfhosted.org>


New submission from Joakim Nilsson <nijoakim at gmail.com>:

Tested on Debian Bullseye with Python 3.9.

If 'set editing-mode vi' is used in .inputrc and the attached program is run, a bug occurs when navigating the readline history. It seems only to occur when ANSI color escape characters are input to the 'input()' function.

To reproduce the bug:
  Run 'readline-example.py'
  Enter '0123456789' in the prompt without quotes.
  Press enter.
  Press escape and then 'k' to go back in history in vi normal mode.
  The cursor is now placed between '2' and '3' and it is impossible to erase anything after the '2'. (To enter vi insert mode, press i and start editing the text normally.)

This bug does not occur for shorter strings. If for example '012345678' is input, the program behaves normally. If the escape characters are not used in the 'input()' function, program behaves normally.

----------
components: Library (Lib)
files: readline-example.py
messages: 382917
nosy: nijoakim
priority: normal
severity: normal
status: open
title: readline history, vi-editingmode and ANSI color codes bug
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49673/readline-example.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42626>
_______________________________________

From report at bugs.python.org  Sat Dec 12 13:10:07 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Sat, 12 Dec 2020 18:10:07 +0000
Subject: [issue30858] Keyword can't be an expression?
In-Reply-To: <1499275280.43.0.372385518137.issue30858@psf.upfronthosting.co.za>
Message-ID: <1607796607.18.0.454692767538.issue30858@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

I like the current error message. What bugs me a little is the position of the caret, which I think is a bit misleading.

Guido, Pablo, should we move the caret to point at the `=` sign or whatever comes after it? I think I prefer the former.

----------
nosy: +gvanrossum, lys.nikolaou, pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30858>
_______________________________________

From report at bugs.python.org  Sat Dec 12 13:50:21 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Sat, 12 Dec 2020 18:50:21 +0000
Subject: [issue42625] Segmentation fault of PyState_AddModule()
In-Reply-To: <1607785781.22.0.676457210715.issue42625@roundup.psfhosted.org>
Message-ID: <1607799021.29.0.845071430595.issue42625@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

When does this actually happen? Is there a common situation where you'd mistakenly pass NULL to PyState_AddModule?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42625>
_______________________________________

From report at bugs.python.org  Sat Dec 12 14:47:26 2020
From: report at bugs.python.org (Karl Nelson)
Date: Sat, 12 Dec 2020 19:47:26 +0000
Subject: [issue42617] Enhancement request for PyType_FromSpecWIthBases add
 option for meta class
In-Reply-To: <1607780480.68.0.592758092794.issue42617@roundup.psfhosted.org>
Message-ID: <SJ0PR09MB7406D03FEEE81F0A95F41014B0C90@SJ0PR09MB7406.namprd09.prod.outlook.com>


Karl Nelson <nelson85 at llnl.gov> added the comment:

Perhaps just having PyType_InitHeapFromSpec which have just heap type linkage and slot copy section would help with the issue.   The major problem I have is maintaining the slot code which may change at some point in the future.   There would still be some risk of missing a portion of the init procedure but it would be a bit safer some of the process was in Python.

----------
title: Enhancement request  for PyType_FromSpecWIthBases add option for meta class -> Enhancement request for PyType_FromSpecWIthBases add option for meta class

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42617>
_______________________________________

From report at bugs.python.org  Sat Dec 12 15:27:52 2020
From: report at bugs.python.org (benrg)
Date: Sat, 12 Dec 2020 20:27:52 +0000
Subject: [issue42627] urllib.request.getproxies() misparses Windows registry
 proxy settings
Message-ID: <1607804872.9.0.5170746987.issue42627@roundup.psfhosted.org>


New submission from benrg <benrudiak at gmail.com>:

If `HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer` contains the string `http=host:123;https=host:456;ftp=host:789`, then getproxies_registry() should return

    {'http': 'http://host:123', 'https': 'http://host:456', 'ftp': 'http://host:789'}

for consistency with WinInet and Chromium, but it actually returns

    {'http': 'http://host:123', 'https': 'https://host:456', 'ftp': 'ftp://host:789'}

This bug has existed for a very long time (since Python 2.0.1 if not earlier), but it was exposed recently when urllib3 added support for HTTPS-in-HTTPS proxies in version 1.26. Before that, an `https` prefix on the HTTPS proxy url was silently treated as `http`, accidentally resulting in the correct behavior.

There are additional bugs in the treatment of single-proxy strings (the case when the string contains no `=` character).

The Chromium code for parsing the ProxyServer string can be found here: https://source.chromium.org/chromium/chromium/src/+/refs/tags/89.0.4353.1:net/proxy_resolution/proxy_config.cc;l=86

Below is my attempt at modifying the code from `getproxies_registry` to approximately match Chromium's behavior. I could turn this into a patch, but I'd like feedback on the corner cases first.

    if '=' not in proxyServer and ';' not in proxyServer:
        # Use one setting for all protocols.
        # Chromium treats this as a separate category, and some software
        # uses the ALL_PROXY environment variable for a similar purpose,
        # so arguably this should be 'all={}'.format(proxyServer),
        # but this is more backward compatible.
        proxyServer = 'http={0};https={0};ftp={0}'.format(proxyServer)

    for p in proxyServer.split(';'):
        # Chromium and WinInet are inconsistent in their treatment of
        # invalid strings with the wrong number of = characters. It
        # probably doesn't matter.
        protocol, addresses = p.split('=', 1)
        protocol = protocol.strip()

        # Chromium supports more than one proxy per protocol. I don't
        # know how many clients support the same, but handling it is at
        # least no worse than leaving the commas uninterpreted.
        for address in addresses.split(','):
            if protocol in {'http', 'https', 'ftp', 'socks'}:
                # See if address has a type:// prefix
                if not re.match('(?:[^/:]+)://', address):
                    if protocol == 'socks':
                        # Chromium notes that the correct protocol here
                        # is SOCKS4, but "socks://" is interpreted
                        # as SOCKS5 elsewhere. I don't know whether
                        # prepending socks4:// here would break code.
                        address = 'socks://' + address
                    else:
                        address = 'http://' + address

            # A string like 'http=foo;http=bar' will produce a
            # comma-separated list, while previously 'bar' would
            # override 'foo'. That could potentially break something.
            if protocol not in proxies:
                proxies[protocol] = address
            else:
                proxies[protocol] += ',' + address

----------
components: Library (Lib), Windows
messages: 382921
nosy: benrg, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: urllib.request.getproxies() misparses Windows registry proxy settings
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42627>
_______________________________________

From report at bugs.python.org  Sat Dec 12 16:23:18 2020
From: report at bugs.python.org (Kent Watsen)
Date: Sat, 12 Dec 2020 21:23:18 +0000
Subject: [issue42628] binascii doesn't work on some base64
Message-ID: <1607808198.75.0.933631782561.issue42628@roundup.psfhosted.org>


New submission from Kent Watsen <kent+python2 at watsen.net>:

[Tested on 3.8.2 and 3.9.0, bug may manifest in other versions too]

The IETF sometimes uses the dummy base64 value "base64encodedvalue==" in specifications in lieu of a block of otherwise meaningless b64.  

Even though it is a dummy value, the value should be convertible to binary and back again.  This works using the built-in command `base64` as well as OpenSSL command line, but binascii is unable to do it.  See below:

$ echo "base64encodedvalue==" | base64 | base64 -d
base64encodedvalue==

$ echo "base64encodedvalue==" | openssl enc -base64 -A | openssl enc -d base64 -A
base64encodedvalue==                                                                                                         

$ printf "import binascii\nprint(binascii.b2a_base64(binascii.a2b_base64('base64encodedvalue=='), newline=False).decode('ascii'))" |  python -
base64encodedvaluQ==

After some investigation, it appears that almost any valid base64 matching the pattern "??==" fails.  For instance:

$ printf "import binascii\nprint(binascii.b2a_base64(binascii.a2b_base64('ue=='), newline=False).decode('ascii'))" |  python -                                                           
uQ==

$ printf "import binascii\nprint(binascii.b2a_base64(binascii.a2b_base64('aa=='), newline=False).decode('ascii'))" |  python -                                                           
aQ==

$ printf "import binascii\nprint(binascii.b2a_base64(binascii.a2b_base64('a0=='), newline=False).decode('ascii'))" |  python -                                                           
aw==


Is this a bug?

----------
messages: 382922
nosy: kwatsen2
priority: normal
severity: normal
status: open
title: binascii doesn't work on some base64
type: behavior
versions: Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42628>
_______________________________________

From report at bugs.python.org  Sat Dec 12 16:26:52 2020
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 12 Dec 2020 21:26:52 +0000
Subject: [issue39717] Fix exception causes in tarfile module
In-Reply-To: <1582315232.59.0.621263718222.issue39717@roundup.psfhosted.org>
Message-ID: <1607808412.01.0.507908141486.issue39717@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset b5a6db9111562454617b6771b61f2734ea0420c9 by Ethan Furman in branch 'master':
bpo-39717: [tarfile] update nested exception raising (GH-23739)
https://github.com/python/cpython/commit/b5a6db9111562454617b6771b61f2734ea0420c9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39717>
_______________________________________

From report at bugs.python.org  Sat Dec 12 16:30:10 2020
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 12 Dec 2020 21:30:10 +0000
Subject: [issue39717] Fix exception causes in tarfile module
In-Reply-To: <1582315232.59.0.621263718222.issue39717@roundup.psfhosted.org>
Message-ID: <1607808610.15.0.299766206811.issue39717@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39717>
_______________________________________

From report at bugs.python.org  Sat Dec 12 18:36:35 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 12 Dec 2020 23:36:35 +0000
Subject: [issue42623] IDLE: Syntax Error showing pointer in wrong location
In-Reply-To: <1607740303.61.0.556483220394.issue42623@roundup.psfhosted.org>
Message-ID: <1607816195.51.0.680375920632.issue42623@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Current IDLE indicates the SyntaxError position given by Python by highlighting the character, as in the editor.  No more caret.  End of problem.

There is no fixed-width Unicode font.  I revised the font sample in part to let people see which alphabets fixed in a particular font face.  Courier likely is best for this: Ascii, Latin1, IPA, Greek, Cyrillic, Hebrow, and Arabic all have the same fixed pitch, but this makes for some badly scruntched characters.

I emailed Pratik about the userid issue and the solution (upgrade).

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
title: Syntax Error showing pointer in wrong location -> IDLE: Syntax Error showing pointer in wrong location

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42623>
_______________________________________

From report at bugs.python.org  Sat Dec 12 18:42:06 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 12 Dec 2020 23:42:06 +0000
Subject: [issue42623] IDLE: Syntax Error showing pointer in wrong location
In-Reply-To: <1607740303.61.0.556483220394.issue42623@roundup.psfhosted.org>
Message-ID: <1607816526.56.0.254644599467.issue42623@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

"Your message to 1051371 at student.auhsd.us has been blocked. ...
This email has been rejected because it is directed outside the AUHSD domain."

Makes no sense unless the link back here was an issue.  Oh well, I tried.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42623>
_______________________________________

From report at bugs.python.org  Sat Dec 12 18:44:40 2020
From: report at bugs.python.org (Ned Deily)
Date: Sat, 12 Dec 2020 23:44:40 +0000
Subject: [issue42603] Tkinter: pkg-config is not used to get location of tcl
 and tk headers/libraries
In-Reply-To: <1607450864.79.0.446942772761.issue42603@roundup.psfhosted.org>
Message-ID: <1607816680.28.0.765390274293.issue42603@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42603>
_______________________________________

From report at bugs.python.org  Sat Dec 12 19:21:25 2020
From: report at bugs.python.org (Max Bachmann)
Date: Sun, 13 Dec 2020 00:21:25 +0000
Subject: [issue42629] PyObject_Call not behaving as documented
Message-ID: <1607818885.74.0.707505524552.issue42629@roundup.psfhosted.org>


New submission from Max Bachmann <kontakt at maxbachmann.de>:

The documentation of PyObject_Call here: https://docs.python.org/3/c-api/call.html#c.PyObject_Call
states, that it is the equivalent of the Python expression: callable(*args, **kwargs).

so I would expect:
PyObject* args = PyTuple_New(0);
PyObject* kwargs = PyDict_New();
PyObject_Call(funcObj, args, kwargs)

to behave similar to
args = []
kwargs = {}
func(*args, **kwargs)

however this is not the case since in this case when I edit kwargs inside
PyObject* func(PyObject* /*self*/, PyObject* /*args*/, PyObject* keywds)
{
  PyObject* str = PyUnicode_FromString("test_str");
  PyDict_SetItemString(keywds, "test", str);
}

it changes the original dictionary passed into PyObject_Call. I was wondering, whether this means, that:
a) it is not allowed to modify the keywds argument passed to a PyCFunctionWithKeywords
b) when calling PyObject_Call it is required to copy the kwargs for the call using PyDict_Copy

Neither the documentation of PyObject_Call nor the documentation of PyCFunctionWithKeywords (https://docs.python.org/3/c-api/structures.html#c.PyCFunctionWithKeywords) made this clear to me.

----------
components: C API
messages: 382927
nosy: maxbachmann
priority: normal
severity: normal
status: open
title: PyObject_Call not behaving as documented
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42629>
_______________________________________

From report at bugs.python.org  Sat Dec 12 19:27:24 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 13 Dec 2020 00:27:24 +0000
Subject: [issue40084] HTTPStatus has incomplete dir() listing
In-Reply-To: <1585293405.13.0.478935860244.issue40084@roundup.psfhosted.org>
Message-ID: <1607819244.09.0.727535185529.issue40084@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22604
pull_request: https://github.com/python/cpython/pull/23746

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40084>
_______________________________________

From report at bugs.python.org  Sat Dec 12 19:44:57 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 13 Dec 2020 00:44:57 +0000
Subject: [issue42059] TypedDict(...) as function does not respect "total" when
 setting __required_keys__ and __optional_keys__
In-Reply-To: <1602926609.93.0.947551036861.issue42059@roundup.psfhosted.org>
Message-ID: <1607820297.09.0.675633648139.issue42059@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +22605
pull_request: https://github.com/python/cpython/pull/23747

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42059>
_______________________________________

From report at bugs.python.org  Sat Dec 12 19:46:33 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 13 Dec 2020 00:46:33 +0000
Subject: [issue42517] Enum: do not convert private names into members
In-Reply-To: <1606774653.87.0.704564487827.issue42517@roundup.psfhosted.org>
Message-ID: <1607820393.78.0.271130830499.issue42517@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +22606
pull_request: https://github.com/python/cpython/pull/23748

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42517>
_______________________________________

From report at bugs.python.org  Sat Dec 12 19:54:48 2020
From: report at bugs.python.org (Irit Katriel)
Date: Sun, 13 Dec 2020 00:54:48 +0000
Subject: [issue22442] Deprecate PIPE with subprocess.check_call() and call()
In-Reply-To: <1411134999.3.0.739689982343.issue22442@psf.upfronthosting.co.za>
Message-ID: <1607820888.17.0.669964425348.issue22442@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
resolution:  -> out of date
stage: patch review -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22442>
_______________________________________

From report at bugs.python.org  Sat Dec 12 19:55:09 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 13 Dec 2020 00:55:09 +0000
Subject: [issue41879] Outdated description of async iterables in documentation
 of async for statement
In-Reply-To: <1601324135.53.0.963696566223.issue41879@roundup.psfhosted.org>
Message-ID: <1607820909.72.0.272391683435.issue41879@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
keywords: +patch
pull_requests: +22607
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/23749

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41879>
_______________________________________

From report at bugs.python.org  Sat Dec 12 19:58:53 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 13 Dec 2020 00:58:53 +0000
Subject: [issue33660] pathlib.Path.resolve() returns path with double slash
 when resolving a relative path in root directory
In-Reply-To: <1527418713.03.0.682650639539.issue33660@psf.upfronthosting.co.za>
Message-ID: <1607821133.73.0.729477940494.issue33660@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22608
pull_request: https://github.com/python/cpython/pull/23750

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33660>
_______________________________________

From report at bugs.python.org  Sat Dec 12 19:59:01 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 13 Dec 2020 00:59:01 +0000
Subject: [issue33660] pathlib.Path.resolve() returns path with double slash
 when resolving a relative path in root directory
In-Reply-To: <1527418713.03.0.682650639539.issue33660@psf.upfronthosting.co.za>
Message-ID: <1607821141.49.0.722723205662.issue33660@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22609
pull_request: https://github.com/python/cpython/pull/23751

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33660>
_______________________________________

From report at bugs.python.org  Sat Dec 12 20:11:29 2020
From: report at bugs.python.org (Irit Katriel)
Date: Sun, 13 Dec 2020 01:11:29 +0000
Subject: [issue26451] CSV documentation doesn't open with an example
In-Reply-To: <1456629484.08.0.443868302354.issue26451@psf.upfronthosting.co.za>
Message-ID: <1607821889.31.0.658414321972.issue26451@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
resolution:  -> out of date
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26451>
_______________________________________

From report at bugs.python.org  Sat Dec 12 20:34:47 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Sun, 13 Dec 2020 01:34:47 +0000
Subject: [issue41972] bytes.find consistently hangs in a particular scenario
In-Reply-To: <1602113519.53.0.297229304628.issue41972@roundup.psfhosted.org>
Message-ID: <1607823287.67.0.663121351544.issue41972@roundup.psfhosted.org>


Change by Dennis Sweeney <sweeney.dennis650 at gmail.com>:


Removed file: https://bugs.python.org/file49672/twoway_demo.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41972>
_______________________________________

From report at bugs.python.org  Sat Dec 12 20:35:39 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Sun, 13 Dec 2020 01:35:39 +0000
Subject: [issue41972] bytes.find consistently hangs in a particular scenario
In-Reply-To: <1602113519.53.0.297229304628.issue41972@roundup.psfhosted.org>
Message-ID: <1607823339.25.0.824298202808.issue41972@roundup.psfhosted.org>


Change by Dennis Sweeney <sweeney.dennis650 at gmail.com>:


Added file: https://bugs.python.org/file49674/twoway_demo.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41972>
_______________________________________

From report at bugs.python.org  Sat Dec 12 22:04:12 2020
From: report at bugs.python.org (Daniel Pflager)
Date: Sun, 13 Dec 2020 03:04:12 +0000
Subject: [issue40505] getpath.c doesn't know about lib64
In-Reply-To: <1588629067.84.0.887023365467.issue40505@roundup.psfhosted.org>
Message-ID: <1607828652.34.0.490116162116.issue40505@roundup.psfhosted.org>


Daniel Pflager <daniel.pflager at gmail.com> added the comment:

Python-3.9.1 OpenSUSE 15.1

While ./configure --with-platlibdir=lib64 does work-around the problem on OpenSUSE by putting everything into lib64/, this is not the default behavior. In other words, should Python-3.9.1 be built on OpenSUSE 15.1 without --with-platlibdir=lib64, the behavior described in this bug report occurs.

Not everyone building Python-3.9.1 on OpenSUSE will take the time to research this and end up finding https://bugs.python.org/issue1294959 (as I did after considerable effort).

Intuitively, doesn't one expect configure to work this kind of thing out (and if it can't, warn the user)?

----------
nosy: +pflagerd

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40505>
_______________________________________

From report at bugs.python.org  Sat Dec 12 22:13:30 2020
From: report at bugs.python.org (Josh Rosenberg)
Date: Sun, 13 Dec 2020 03:13:30 +0000
Subject: [issue42612] Software Designer
In-Reply-To: <1607584803.23.0.875978893674.issue42612@roundup.psfhosted.org>
Message-ID: <1607829210.22.0.144555178869.issue42612@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

A rough description is not sufficient. If you have code that reproduces the problem, post the reproducer so we can check, but odds are you've got a bug in your code.

----------
nosy: +josh.r
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42612>
_______________________________________

From report at bugs.python.org  Sat Dec 12 23:24:55 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 13 Dec 2020 04:24:55 +0000
Subject: [issue41879] Outdated description of async iterables in documentation
 of async for statement
In-Reply-To: <1601324135.53.0.963696566223.issue41879@roundup.psfhosted.org>
Message-ID: <1607833495.4.0.106320898318.issue41879@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset be9e4402db64564f7bf0fedb3769cead46c0d4c4 by Miss Islington (bot) in branch '3.9':
[3.9] bpo-41879: Doc: Fix description of async for statement (GH-23548) (GH-23749)
https://github.com/python/cpython/commit/be9e4402db64564f7bf0fedb3769cead46c0d4c4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41879>
_______________________________________

From report at bugs.python.org  Sun Dec 13 00:17:59 2020
From: report at bugs.python.org (Carol Willing)
Date: Sun, 13 Dec 2020 05:17:59 +0000
Subject: [issue42612] Software Designer
In-Reply-To: <1607584803.23.0.875978893674.issue42612@roundup.psfhosted.org>
Message-ID: <1607836679.69.0.54799893575.issue42612@roundup.psfhosted.org>


Carol Willing <willingc at gmail.com> added the comment:

Hi @Deepanshu. I'm sorry that you are having difficulty with your script.

While we wish to be helpful, it's difficult to troubleshoot whether this is a program issue or a CPython bug. I recommend asking on Stack Overflow or the Python Discourse Users channel (discuss.python.org).

If after consulting those resources and you still believe this is a bug, please open a new issue with a more complete report which includes:
- a clear, specific title
- a concise sentence of what the bug seems to be
- what is the expected behavior
- what is the actual result
- steps to reproduce the error (or a runnable code snippet to demonstrate the behavior)

Mozilla's documentation has a good section on submitting effective bug reports (https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines)

I'm going to close this particular issue. Please do open another issue if needed. Thanks! - Carol

P.S. Josh, a gentle reminder that it's difficult to convey tone in writing. Perhaps adding a "hi" or "hello" at the start of your message would make it friendlier. Thanks for triaging too :D

----------
nosy: +willingc
resolution:  -> not a bug
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42612>
_______________________________________

From report at bugs.python.org  Sun Dec 13 08:34:20 2020
From: report at bugs.python.org (Joshua Root)
Date: Sun, 13 Dec 2020 13:34:20 +0000
Subject: [issue41100] Support macOS 11 and Apple Silicon Macs
In-Reply-To: <1592999467.1.0.372512113251.issue41100@roundup.psfhosted.org>
Message-ID: <1607866460.63.0.990349583635.issue41100@roundup.psfhosted.org>


Joshua Root <josh+python at root.id.au> added the comment:

Are there plans to backport PR 22855 to any branches older than 3.9?

----------
nosy: +jmr

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41100>
_______________________________________

From report at bugs.python.org  Sun Dec 13 10:20:08 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 13 Dec 2020 15:20:08 +0000
Subject: [issue30858] Keyword can't be an expression?
In-Reply-To: <1499275280.43.0.372385518137.issue30858@psf.upfronthosting.co.za>
Message-ID: <1607872808.37.0.580861912142.issue30858@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

+1 for the `=` sign

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30858>
_______________________________________

From report at bugs.python.org  Sun Dec 13 10:22:27 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 13 Dec 2020 15:22:27 +0000
Subject: [issue30858] Keyword can't be an expression?
In-Reply-To: <1499275280.43.0.372385518137.issue30858@psf.upfronthosting.co.za>
Message-ID: <1607872947.3.0.309869011566.issue30858@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +22610
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23753

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30858>
_______________________________________

From report at bugs.python.org  Sun Dec 13 11:00:48 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 13 Dec 2020 16:00:48 +0000
Subject: [issue42625] Segmentation fault of PyState_AddModule()
In-Reply-To: <1607785781.22.0.676457210715.issue42625@roundup.psfhosted.org>
Message-ID: <1607875248.45.0.827335084085.issue42625@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

> When does this actually happen? Is there a common situation where you'd mistakenly pass NULL to PyState_AddModule?

If created mod haven't been checked will have this risk. PyState_AddModule
is a exposing C API, we should make sure that calling API is in a safe way(not raising a segmentation fault). :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42625>
_______________________________________

From report at bugs.python.org  Sun Dec 13 11:47:00 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 13 Dec 2020 16:47:00 +0000
Subject: [issue30858] Keyword can't be an expression?
In-Reply-To: <1499275280.43.0.372385518137.issue30858@psf.upfronthosting.co.za>
Message-ID: <1607878020.87.0.348659039259.issue30858@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 43c4fb6c90c013a00cb820cb61e4990cd8ec7f5e by Pablo Galindo in branch 'master':
bpo-30858: Improve error location for expressions with assignments (GH-23753)
https://github.com/python/cpython/commit/43c4fb6c90c013a00cb820cb61e4990cd8ec7f5e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30858>
_______________________________________

From report at bugs.python.org  Sun Dec 13 11:47:04 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 13 Dec 2020 16:47:04 +0000
Subject: [issue30858] Keyword can't be an expression?
In-Reply-To: <1499275280.43.0.372385518137.issue30858@psf.upfronthosting.co.za>
Message-ID: <1607878024.08.0.332644584158.issue30858@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/issue30858>
_______________________________________

From report at bugs.python.org  Sun Dec 13 13:38:32 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 13 Dec 2020 18:38:32 +0000
Subject: [issue42195] Inconsistent __args__ between typing.Callable and
 collections.abc.Callable
In-Reply-To: <1603974319.88.0.166786801787.issue42195@roundup.psfhosted.org>
Message-ID: <1607884712.32.0.229198370995.issue42195@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 463c7d3d149283814d879a9bb8411af64e656c8e by kj in branch 'master':
bpo-42195: Ensure consistency of Callable's __args__ in collections.abc and typing (GH-23060)
https://github.com/python/cpython/commit/463c7d3d149283814d879a9bb8411af64e656c8e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42195>
_______________________________________

From report at bugs.python.org  Sun Dec 13 13:43:36 2020
From: report at bugs.python.org (Hugo van Kemenade)
Date: Sun, 13 Dec 2020 18:43:36 +0000
Subject: [issue37324] collections: remove deprecated aliases to ABC classes
In-Reply-To: <1560803912.16.0.0813723259969.issue37324@roundup.psfhosted.org>
Message-ID: <1607885016.54.0.316342269667.issue37324@roundup.psfhosted.org>


Change by Hugo van Kemenade <hugovk+python at gmail.com>:


----------
nosy: +hugovk
nosy_count: 4.0 -> 5.0
pull_requests: +22611
pull_request: https://github.com/python/cpython/pull/23754

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37324>
_______________________________________

From report at bugs.python.org  Sun Dec 13 14:09:33 2020
From: report at bugs.python.org (Ned Deily)
Date: Sun, 13 Dec 2020 19:09:33 +0000
Subject: [issue42608] Installation failed from source code on Debian
 ([307/416] test_socket)
In-Reply-To: <1607505269.45.0.398750468222.issue42608@roundup.psfhosted.org>
Message-ID: <1607886573.7.0.681155130194.issue42608@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Also, I have seen test_socket hang like this in the past on Debian when building with older versions of openssl 1.1.0. If possible, try upgrading to a later or current version of openssl 1.1.0.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42608>
_______________________________________

From report at bugs.python.org  Sun Dec 13 14:11:05 2020
From: report at bugs.python.org (Doug Richardson)
Date: Sun, 13 Dec 2020 19:11:05 +0000
Subject: [issue37945]
 test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails
In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org>
Message-ID: <1607886665.11.0.421268126067.issue37945@roundup.psfhosted.org>


Change by Doug Richardson <git at rekt.email>:


----------
nosy: +drichardson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37945>
_______________________________________

From report at bugs.python.org  Sun Dec 13 14:42:06 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 13 Dec 2020 19:42:06 +0000
Subject: [issue41559] Add support for PEP 612 (Parameter Specification
 Variables) to typing.py
In-Reply-To: <1597516564.62.0.520187732663.issue41559@roundup.psfhosted.org>
Message-ID: <1607888526.01.0.684399178636.issue41559@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

This is now unblocked now that GH-23060 has landed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41559>
_______________________________________

From report at bugs.python.org  Sun Dec 13 14:52:54 2020
From: report at bugs.python.org (Ned Deily)
Date: Sun, 13 Dec 2020 19:52:54 +0000
Subject: [issue41100] Support macOS 11 and Apple Silicon Macs
In-Reply-To: <1592999467.1.0.372512113251.issue41100@roundup.psfhosted.org>
Message-ID: <1607889174.79.0.767294016101.issue41100@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

> Are there plans to backport PR 22855 to any branches older than 3.9?

The plan is to also support 3.8 on Big Sur and Apple Silicon as 3.8 is still in bugfix mode.  There are no plans to backport support to 3.7 and 3.6 which are in the security-fix-only phase of their release cycles.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41100>
_______________________________________

From report at bugs.python.org  Sun Dec 13 15:56:38 2020
From: report at bugs.python.org (Ned Deily)
Date: Sun, 13 Dec 2020 20:56:38 +0000
Subject: [issue42598] Some configure checks rely on implicit function
 declaration
In-Reply-To: <1607426117.25.0.975744797691.issue42598@roundup.psfhosted.org>
Message-ID: <1607892998.69.0.315127687524.issue42598@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 674fa0a740151e0416c9383f127b16014e805990 by Joshua Root in branch 'master':
bpo-42598: Fix implicit function declarations in configure (GH-23690)
https://github.com/python/cpython/commit/674fa0a740151e0416c9383f127b16014e805990


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42598>
_______________________________________

From report at bugs.python.org  Sun Dec 13 16:09:48 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 13 Dec 2020 21:09:48 +0000
Subject: [issue42598] Some configure checks rely on implicit function
 declaration
In-Reply-To: <1607426117.25.0.975744797691.issue42598@roundup.psfhosted.org>
Message-ID: <1607893788.05.0.577096774226.issue42598@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +22612
pull_request: https://github.com/python/cpython/pull/23756

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42598>
_______________________________________

From report at bugs.python.org  Sun Dec 13 16:42:16 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 13 Dec 2020 21:42:16 +0000
Subject: [issue42598] Some configure checks rely on implicit function
 declaration
In-Reply-To: <1607426117.25.0.975744797691.issue42598@roundup.psfhosted.org>
Message-ID: <1607895736.15.0.223517541738.issue42598@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22613
pull_request: https://github.com/python/cpython/pull/23757

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42598>
_______________________________________

From report at bugs.python.org  Sun Dec 13 17:01:08 2020
From: report at bugs.python.org (Ned Deily)
Date: Sun, 13 Dec 2020 22:01:08 +0000
Subject: [issue42598] Some configure checks rely on implicit function
 declaration
In-Reply-To: <1607426117.25.0.975744797691.issue42598@roundup.psfhosted.org>
Message-ID: <1607896868.96.0.0811551785816.issue42598@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 3dcdbdeb4833e45430ccc9cb3432f779a6fd8c94 by Miss Islington (bot) in branch '3.9':
bpo-42598: Fix implicit function declarations in configure (GH-23690) (GH-23756)
https://github.com/python/cpython/commit/3dcdbdeb4833e45430ccc9cb3432f779a6fd8c94


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42598>
_______________________________________

From report at bugs.python.org  Sun Dec 13 17:02:02 2020
From: report at bugs.python.org (Ned Deily)
Date: Sun, 13 Dec 2020 22:02:02 +0000
Subject: [issue42598] Some configure checks rely on implicit function
 declaration
In-Reply-To: <1607426117.25.0.975744797691.issue42598@roundup.psfhosted.org>
Message-ID: <1607896922.81.0.994700300035.issue42598@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 9feda9f871498463fe502d63204cf9cd6c1f4706 by Miss Islington (bot) in branch '3.8':
bpo-42598: Fix implicit function declarations in configure (GH-23690) (GH-23757)
https://github.com/python/cpython/commit/9feda9f871498463fe502d63204cf9cd6c1f4706


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42598>
_______________________________________

From report at bugs.python.org  Sun Dec 13 17:04:42 2020
From: report at bugs.python.org (Ned Deily)
Date: Sun, 13 Dec 2020 22:04:42 +0000
Subject: [issue42598] Some configure checks rely on implicit function
 declaration
In-Reply-To: <1607426117.25.0.975744797691.issue42598@roundup.psfhosted.org>
Message-ID: <1607897082.01.0.70749357675.issue42598@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks for noticing the failures and for the PR!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42598>
_______________________________________

From report at bugs.python.org  Sun Dec 13 18:24:00 2020
From: report at bugs.python.org (Ivo Shipkaliev)
Date: Sun, 13 Dec 2020 23:24:00 +0000
Subject: [issue42630] Variable.__init__ raise a RuntimeError instead of
 obscure AttributeError
Message-ID: <1607901840.62.0.626631020476.issue42630@roundup.psfhosted.org>


New submission from Ivo Shipkaliev <ivo.shipkaliev at gmail.com>:

Hello.

I think it would be nice to add:

335 >             if not master:
336 >                 raise RuntimeError('a valid Tk instance is required.')

to lib/tkinter/__init__.py, and not rely on this unclear AttributeError.

Could it be assigned to me, please?

Best Regards
Ivo Shipkaliev

----------
components: Tkinter
messages: 382944
nosy: shippo_
priority: normal
severity: normal
status: open
title: Variable.__init__ raise a RuntimeError instead of obscure AttributeError
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42630>
_______________________________________

From report at bugs.python.org  Sun Dec 13 18:37:58 2020
From: report at bugs.python.org (to7m)
Date: Sun, 13 Dec 2020 23:37:58 +0000
Subject: [issue42631] Multiprocessing module hangs on os.read() on Linux
Message-ID: <1607902678.82.0.104927232585.issue42631@roundup.psfhosted.org>


New submission from to7m <thomashowemain at gmail.com>:

As best I can tell, sometimes when a Listener or Connection is not properly initialised, the Client fails to communicate properly with it. Instead of raising an exception, the Client hangs.


receiver.py:


from multiprocessing.connection import Listener

while True:
    with Listener(("localhost", 10000), authkey=b"test") as listener:
        with listener.accept() as connection:
            print(connection.recv())


client.py (intended as a stress test):


from multiprocessing.connection import Client

for i in range(1000):
    successfully_sent = False
    while not successfully_sent:
        try:
            with Client(("localhost", 10000), authkey=b"test") as client:
                client.send(i)
        except (ConnectionRefusedError, ConnectionResetError):
            continue
        successfully_sent = True


Also noteworthy: I posted on StackExchange (https://stackoverflow.com/questions/65276145/multiprocessing-receive-all-messages-from-multiple-runtimes) and it seems that the code there (only 1000 messages) took around an hour to run for a Windows user, whereas it would take less than a second to successfully run on Linux.

----------
components: IO
files: receive.py
messages: 382945
nosy: to7m
priority: normal
severity: normal
status: open
title: Multiprocessing module hangs on os.read() on Linux
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49675/receive.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42631>
_______________________________________

From report at bugs.python.org  Sun Dec 13 18:49:35 2020
From: report at bugs.python.org (Ivo Shipkaliev)
Date: Sun, 13 Dec 2020 23:49:35 +0000
Subject: [issue42630] Variable.__init__ raise a RuntimeError instead of
 obscure AttributeError
In-Reply-To: <1607901840.62.0.626631020476.issue42630@roundup.psfhosted.org>
Message-ID: <1607903375.17.0.992858955094.issue42630@roundup.psfhosted.org>


Ivo Shipkaliev <ivo.shipkaliev at gmail.com> added the comment:

https://mail.python.org/archives/list/python-ideas at python.org/thread/FSQUFJJQDNSRN4HI7VFXWCNO46YLXQDS/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42630>
_______________________________________

From report at bugs.python.org  Sun Dec 13 19:00:35 2020
From: report at bugs.python.org (Roland Hieber)
Date: Mon, 14 Dec 2020 00:00:35 +0000
Subject: [issue13501] Make libedit support more generic;
 port readline / libedit to FreeBSD
In-Reply-To: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za>
Message-ID: <1607904035.72.0.952457270625.issue13501@roundup.psfhosted.org>


Roland Hieber <rhi at pengutronix.de> added the comment:

What's the status of this patch? Is it still needed after 68669ef7883e, which went into v3.8.1?

----------
nosy: +rhi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13501>
_______________________________________

From report at bugs.python.org  Sun Dec 13 19:02:10 2020
From: report at bugs.python.org (Roland Hieber)
Date: Mon, 14 Dec 2020 00:02:10 +0000
Subject: [issue13501] Make libedit support more generic;
 port readline / libedit to FreeBSD
In-Reply-To: <1322579942.3.0.601983912656.issue13501@psf.upfronthosting.co.za>
Message-ID: <1607904130.29.0.323484127204.issue13501@roundup.psfhosted.org>


Roland Hieber <rhi at pengutronix.de> added the comment:

(That was meant to be 68669ef7883 for the autolinking feature)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue13501>
_______________________________________

From report at bugs.python.org  Sun Dec 13 19:09:57 2020
From: report at bugs.python.org (Ivo Shipkaliev)
Date: Mon, 14 Dec 2020 00:09:57 +0000
Subject: [issue42630] Variable.__init__ to raise a RuntimeError instead of
 obscure AttributeError
In-Reply-To: <1607901840.62.0.626631020476.issue42630@roundup.psfhosted.org>
Message-ID: <1607904597.85.0.670403203264.issue42630@roundup.psfhosted.org>


Ivo Shipkaliev <ivo.shipkaliev at gmail.com> added the comment:

Or maybe:

333 >         if not master:
334 >             if not _default_root:
335 >                 _default_root = Tk()
336 >             master = _default_root
337 >         self._root = master._root()

----------
title: Variable.__init__ raise a RuntimeError instead of obscure AttributeError -> Variable.__init__ to raise a RuntimeError instead of obscure AttributeError

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42630>
_______________________________________

From report at bugs.python.org  Sun Dec 13 19:27:45 2020
From: report at bugs.python.org (Ned Batchelder)
Date: Mon, 14 Dec 2020 00:27:45 +0000
Subject: [issue42246] Implement PEP 626 -- Precise line numbers for debugging
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1607905665.28.0.0119303444149.issue42246@roundup.psfhosted.org>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

Mark, I'm categorizing and characterizing the test failures.  Here's the start of it: https://gist.github.com/nedbat/6c5dedde9df8d2de13de8a6a39a5f112  Let me know what other information would be useful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42246>
_______________________________________

From report at bugs.python.org  Sun Dec 13 21:07:43 2020
From: report at bugs.python.org (Ivo Shipkaliev)
Date: Mon, 14 Dec 2020 02:07:43 +0000
Subject: [issue42630] Variable.__init__ to raise a RuntimeError instead of
 obscure AttributeError
In-Reply-To: <1607901840.62.0.626631020476.issue42630@roundup.psfhosted.org>
Message-ID: <1607911663.38.0.667109304822.issue42630@roundup.psfhosted.org>


Ivo Shipkaliev <ivo.shipkaliev at gmail.com> added the comment:

Sorry, we need "global" too:

333 >         if not master:
334 >             global _default_root
335 >             if not _default_root:
336 >                 _default_root = Tk()
337 >             master = _default_root
338 >         self._root = master._root()

----------
resolution:  -> works for me

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42630>
_______________________________________

From report at bugs.python.org  Sun Dec 13 21:48:08 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 14 Dec 2020 02:48:08 +0000
Subject: [issue42382] No easy way to get the distribution which provided a
 importlib.metadata.EntryPoint
In-Reply-To: <1605596181.46.0.7808505308.issue42382@roundup.psfhosted.org>
Message-ID: <1607914088.73.0.0278122229772.issue42382@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
pull_requests: +22614
pull_request: https://github.com/python/cpython/pull/23758

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42382>
_______________________________________

From report at bugs.python.org  Mon Dec 14 00:49:25 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 14 Dec 2020 05:49:25 +0000
Subject: [issue42532] spec_arg's __bool__ is called while initializing
 NonCallableMock
In-Reply-To: <1606998026.09.0.31549028921.issue42532@roundup.psfhosted.org>
Message-ID: <1607924965.25.0.978169144243.issue42532@roundup.psfhosted.org>


Karthikeyan Singaravelan <tir.karthi at gmail.com> added the comment:


New changeset 14f2a124e20081b8981c8d6165dbd78d11b6808c by Karthikeyan Singaravelan in branch '3.9':
[3.9] bpo-42532: Check if NonCallableMock's spec_arg is not None instead of call its __bool__ function (GH-23613) (GH-23676)
https://github.com/python/cpython/commit/14f2a124e20081b8981c8d6165dbd78d11b6808c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42532>
_______________________________________

From report at bugs.python.org  Mon Dec 14 01:02:52 2020
From: report at bugs.python.org (Xinmeng Xia)
Date: Mon, 14 Dec 2020 06:02:52 +0000
Subject: [issue42632] Reassgining ZeroDivisionError will lead to bug in Except
 clause
Message-ID: <1607925772.13.0.935744871681.issue42632@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

Running the following program:
==============================
def foo():
    try:
        1/0
    except ZeroDivisionError as e:
       	ZeroDivisionError = 1
foo()
==============================
The expected output should be nothing. ZeroDivisionError is caught and then reassignment is executed. However, running this program in Python3.10 will lead to the following error: 

Traceback (most recent call last):
  File "/home/xxm/Desktop/nameChanging/error/1.py", line 5, in foo
    1/0
ZeroDivisionError: division by zero

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/xxm/Desktop/nameChanging/error/1.py", line 8, in <module>
    foo()
  File "/home/xxm/Desktop/nameChanging/error/1.py", line 6, in foo
    except Exception as e:
UnboundLocalError: local variable 'Exception' referenced before assignment

----------
components: Interpreter Core
messages: 382953
nosy: xxm
priority: normal
severity: normal
status: open
title: Reassgining ZeroDivisionError will lead to bug in Except clause
type: compile error
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42632>
_______________________________________

From report at bugs.python.org  Mon Dec 14 01:17:25 2020
From: report at bugs.python.org (Xinmeng Xia)
Date: Mon, 14 Dec 2020 06:17:25 +0000
Subject: [issue42632] Reassgining ZeroDivisionError will lead to bug in Except
 clause
In-Reply-To: <1607925772.13.0.935744871681.issue42632@roundup.psfhosted.org>
Message-ID: <1607926645.31.0.583376147779.issue42632@roundup.psfhosted.org>


Xinmeng Xia <xiaxm at smail.nju.edu.cn> added the comment:

Similar bugs exist in other exceptions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42632>
_______________________________________

From report at bugs.python.org  Mon Dec 14 01:48:15 2020
From: report at bugs.python.org (Pandu E POLUAN)
Date: Mon, 14 Dec 2020 06:48:15 +0000
Subject: [issue27820] Possible bug in smtplib when initial_response_ok=False
In-Reply-To: <1471739698.94.0.271523306415.issue27820@psf.upfronthosting.co.za>
Message-ID: <1607928495.24.0.711952359935.issue27820@roundup.psfhosted.org>


Pandu E POLUAN <pepoluan at gmail.com> added the comment:

Hi, I'm one of the maintainers of aio-libs/aiosmtpd.

This issue also bit me when trying to write unit tests for aio-libs/aiosmtpd AUTH implementation

But I partially disagree with Dario D'Amico's changes, specifically the suggested change in the auth_login() method.

According to draft-murchison-sasl-login-00.txt [1], the two challenges sent by the server SHOULD be ignored. The example in that document uses b"VXNlciBOYW1lAA==" and b"UGFzc3dvcmQA" (b64 of b"User Name\x00" and b"Password\x00", respectively), and this is what we have implemented in aio-libs/aiosmtpd.

Furthermore, the same document never indicated that username may be sent along with "AUTH LOGIN", so we haven't implemented that in aio-libs/aiosmtpd.

So rather than hardcoding the challenges to b"Username:" and b"Password:", a compliant SMTP client must instead _count_ the number of challenges it received.

I propose the following changes instead:

    def auth(self, mechanism, authobject, *, initial_response_ok=True):
        ... snip ...
        if initial_response is not None:
            response = encode_base64(initial_response.encode('ascii'), eol='')
            (code, resp) = self.docmd("AUTH", mechanism + " " + response)
            self._challenge_count = 1
        else:
            (code, resp) = self.docmd("AUTH", mechanism)
            self._challenge_count = 0
        # If server responds with a challenge, send the response.
        while code == 334:
            self._challenge_count += 1
            challenge = base64.decodebytes(resp)
        ... snip ...

    ... snip ...

    def auth_login(self, challenge=None):
        """ Authobject to use with LOGIN authentication. Requires self.user and
        self.password to be set."""
        if challenge is None or self._challenge_count < 2:
            return self.user
        else:
            return self.password


[1] https://www.ietf.org/archive/id/draft-murchison-sasl-login-00.txt

----------
nosy: +pepoluan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27820>
_______________________________________

From report at bugs.python.org  Mon Dec 14 01:50:33 2020
From: report at bugs.python.org (Pandu E POLUAN)
Date: Mon, 14 Dec 2020 06:50:33 +0000
Subject: [issue27820] Possible bug in smtplib when initial_response_ok=False
In-Reply-To: <1471739698.94.0.271523306415.issue27820@psf.upfronthosting.co.za>
Message-ID: <1607928633.1.0.69525947828.issue27820@roundup.psfhosted.org>


Pandu E POLUAN <pepoluan at gmail.com> added the comment:

This issue is still a bug for Python 3.6 and Python 3.8

I haven't checked on Python 3.7 and Python 3.9

----------
versions: +Python 3.6, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27820>
_______________________________________

From report at bugs.python.org  Mon Dec 14 02:03:20 2020
From: report at bugs.python.org (Matthew Walker)
Date: Mon, 14 Dec 2020 07:03:20 +0000
Subject: [issue42633] Wave documentation doesn't mention signed/unsigned
 requirements
Message-ID: <1607929400.79.0.578872374659.issue42633@roundup.psfhosted.org>


New submission from Matthew Walker <mattgwwalker at gmail.com>:

It would be very useful if the documentation for Python's Wave module mentioned that 8-bit samples must be unsigned while 16-bit samples must be signed.

See the Wikipedia article on the WAV format: "There are some inconsistencies in the WAV format: for example, 8-bit data is unsigned while 16-bit data is signed" https://en.wikipedia.org/wiki/WAV

Although I haven't contributed previously, I would be pleased to make such a contribution if it would be appreciated.

----------
assignee: docs at python
components: Documentation
messages: 382957
nosy: docs at python, mattgwwalker
priority: normal
severity: normal
status: open
title: Wave documentation doesn't mention signed/unsigned requirements
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42633>
_______________________________________

From report at bugs.python.org  Mon Dec 14 02:24:56 2020
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 14 Dec 2020 07:24:56 +0000
Subject: [issue42634] Incorrect line number in bytecode for try-except-finally
Message-ID: <1607930696.05.0.974303425196.issue42634@roundup.psfhosted.org>


New submission from Mark Shannon <mark at hotpy.org>:

The following code, when traced, produces a spurious line event for line 5:

a, b, c = 1, 1, 1
try:
    a = 3
except:
    b = 5
finally:
    c = 7
assert a == 3 and b == 1 and c == 7

Bug reported by Ned Batchelder https://gist.github.com/nedbat/6c5dedde9df8d2de13de8a6a39a5f112

----------
assignee: Mark.Shannon
messages: 382958
nosy: Mark.Shannon, nedbat
priority: release blocker
severity: normal
stage: needs patch
status: open
title: Incorrect line number in bytecode for try-except-finally
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42634>
_______________________________________

From report at bugs.python.org  Mon Dec 14 02:50:07 2020
From: report at bugs.python.org (Bhushan Shelke)
Date: Mon, 14 Dec 2020 07:50:07 +0000
Subject: [issue42417] Empty body {} in POST requests leads to 405 Method not
 allowed error
In-Reply-To: <1605864023.48.0.825673701965.issue42417@roundup.psfhosted.org>
Message-ID: <1607932207.18.0.645274736396.issue42417@roundup.psfhosted.org>


Bhushan Shelke <bhushan.shelke at gmail.com> added the comment:

Hmm... intriguing... I just downloaded the files, an executed again, following is response

Server
```127.0.0.1 - - [14/Dec/2020 13:07:34] "{}POST http://localhost:6000/getResponse HTTP/1.1" 405 -```

Client
```py flask_client.py
b'<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">\n<title>405 Method Not Allowed</title>\n<h1>Method Not Allowed</h1>\n<p>The method is not allowed for the requested URL.</p>\n'
<http.client.HTTPResponse object at 0x0000020BE4532CD0>
```

Since my theory is based on - body being appended sent fist before header in TCP packet. I just uploaded a file(flask_client_long_headers.py) having long header values. Could you please use this and check if you can reproduce it now. Also please suggest me any other alternative through which I could send more relevant information.

----------
Added file: https://bugs.python.org/file49676/flask_client_long_headers.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42417>
_______________________________________

From report at bugs.python.org  Mon Dec 14 03:01:46 2020
From: report at bugs.python.org (Bhushan Shelke)
Date: Mon, 14 Dec 2020 08:01:46 +0000
Subject: [issue42417] Empty body {} in POST requests leads to 405 Method not
 allowed error
In-Reply-To: <1605864023.48.0.825673701965.issue42417@roundup.psfhosted.org>
Message-ID: <1607932906.05.0.861325057462.issue42417@roundup.psfhosted.org>


Bhushan Shelke <bhushan.shelke at gmail.com> added the comment:

Also attaching screenshot of TCP dump captured via wireshark
Packet-1

----------
Added file: https://bugs.python.org/file49677/packet-1.PNG

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42417>
_______________________________________

From report at bugs.python.org  Mon Dec 14 03:02:43 2020
From: report at bugs.python.org (Bhushan Shelke)
Date: Mon, 14 Dec 2020 08:02:43 +0000
Subject: [issue42417] Empty body {} in POST requests leads to 405 Method not
 allowed error
In-Reply-To: <1605864023.48.0.825673701965.issue42417@roundup.psfhosted.org>
Message-ID: <1607932963.8.0.654009200833.issue42417@roundup.psfhosted.org>


Bhushan Shelke <bhushan.shelke at gmail.com> added the comment:

Attaching screenshot of TCP dump captured via wireshark
Packet-2

----------
Added file: https://bugs.python.org/file49678/packet-2.PNG

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42417>
_______________________________________

From report at bugs.python.org  Mon Dec 14 03:20:46 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 14 Dec 2020 08:20:46 +0000
Subject: [issue36541] Make lib2to3 grammar better match Python,
 support the := walrus
In-Reply-To: <1554514880.92.0.277848417721.issue36541@roundup.psfhosted.org>
Message-ID: <1607934046.21.0.0807017462238.issue36541@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
pull_requests: +22615
pull_request: https://github.com/python/cpython/pull/23759

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36541>
_______________________________________

From report at bugs.python.org  Mon Dec 14 03:30:08 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 14 Dec 2020 08:30:08 +0000
Subject: [issue36541] Make lib2to3 grammar better match Python,
 support the := walrus
In-Reply-To: <1554514880.92.0.277848417721.issue36541@roundup.psfhosted.org>
Message-ID: <1607934608.2.0.924816021223.issue36541@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

While I said i didn't care... and don't really want to... I found a reason to at least not omit pep-570 positional only arg parsing support give things like yapf still use it rather than forking their own copy.  PR testing.

----------
assignee:  -> gregory.p.smith
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36541>
_______________________________________

From report at bugs.python.org  Mon Dec 14 03:51:39 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Dec 2020 08:51:39 +0000
Subject: [issue40505] getpath.c doesn't know about lib64
In-Reply-To: <1588629067.84.0.887023365467.issue40505@roundup.psfhosted.org>
Message-ID: <1607935899.06.0.446710245392.issue40505@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

This issue is a duplicate of bpo-1294959.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
superseder:  -> Add sys.platlibdir and configure --with-platlibdir to use /usr/lib64 on Fedora and SuSE

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40505>
_______________________________________

From report at bugs.python.org  Mon Dec 14 03:51:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Dec 2020 08:51:51 +0000
Subject: [issue1294959] Add sys.platlibdir and configure --with-platlibdir to
 use /usr/lib64 on Fedora and SuSE
Message-ID: <1607935911.72.0.93309986726.issue1294959@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I marked bpo-40505 as a duplicate of this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1294959>
_______________________________________

From report at bugs.python.org  Mon Dec 14 04:08:31 2020
From: report at bugs.python.org (Frederic Gagnon)
Date: Mon, 14 Dec 2020 09:08:31 +0000
Subject: [issue42571] [docs] add links to Glossary#parameter in libraries
In-Reply-To: <1607116268.54.0.585771365964.issue42571@roundup.psfhosted.org>
Message-ID: <1607936911.06.0.941220628477.issue42571@roundup.psfhosted.org>


Frederic Gagnon <gagnonfrederic9 at gmail.com> added the comment:

I didn't know if that "*" was part of python, or just specific to the documentation.

I started by just looking around the page (header, section on the left and footer) for some kind of link pointing to how to interpret the documentation.

Not finding anything, I went up the tree (first to https://docs.python.org/3/library/index.html , then to https://docs.python.org/3/index.html ). I then went to the FAQ ( https://docs.python.org/3/faq/index.html ).
(Little did I know, the answer was in Glossary...)

Not finding any answer there, I tried googling it (simply starting with "python *"), but since * is interpreted as a wildcard, my searches only gave broad results about "python".

I then asked a friend who pointed me to https://stackoverflow.com/questions/51362773/what-does-mean-as-a-parameter-in-python

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42571>
_______________________________________

From report at bugs.python.org  Mon Dec 14 04:11:10 2020
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 14 Dec 2020 09:11:10 +0000
Subject: [issue42634] Incorrect line number in bytecode for try-except-finally
In-Reply-To: <1607930696.05.0.974303425196.issue42634@roundup.psfhosted.org>
Message-ID: <1607937070.35.0.223445851962.issue42634@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
keywords: +patch
pull_requests: +22616
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/23760

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42634>
_______________________________________

From report at bugs.python.org  Mon Dec 14 04:12:53 2020
From: report at bugs.python.org (Frederic Gagnon)
Date: Mon, 14 Dec 2020 09:12:53 +0000
Subject: [issue42571] [docs] add links to Glossary#parameter in libraries
In-Reply-To: <1607116268.54.0.585771365964.issue42571@roundup.psfhosted.org>
Message-ID: <1607937173.74.0.543800228219.issue42571@roundup.psfhosted.org>


Frederic Gagnon <gagnonfrederic9 at gmail.com> added the comment:

The information could be added to https://docs.python.org/3/faq/library.html#general-library-questions , leading to links to where to find information about the library's syntax

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42571>
_______________________________________

From report at bugs.python.org  Mon Dec 14 04:15:12 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Dec 2020 09:15:12 +0000
Subject: [issue37945] [Windows]
 test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails
In-Reply-To: <1566754401.97.0.888593384986.issue37945@roundup.psfhosted.org>
Message-ID: <1607937312.66.0.336648142201.issue37945@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner
title: test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails -> [Windows] test_locale.TestMiscellaneous.test_getsetlocale_issue1813() fails

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37945>
_______________________________________

From report at bugs.python.org  Mon Dec 14 04:16:55 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Dec 2020 09:16:55 +0000
Subject: =?utf-8?q?=5Bissue42614=5D_Pathlib_does_not_support_a_Cyrillic_character_?=
 =?utf-8?b?J9C5Jw==?=
In-Reply-To: <1607599977.07.0.665981519829.issue42614@roundup.psfhosted.org>
Message-ID: <1607937415.15.0.147823774668.issue42614@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy:  -vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42614>
_______________________________________

From report at bugs.python.org  Mon Dec 14 04:17:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Dec 2020 09:17:25 +0000
Subject: [issue21536] extension built with a shared python cannot be loaded
 with a static python
In-Reply-To: <1400525402.57.0.75792320709.issue21536@psf.upfronthosting.co.za>
Message-ID: <1607937445.19.0.863994735219.issue21536@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
Removed message: https://bugs.python.org/msg382882

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21536>
_______________________________________

From report at bugs.python.org  Mon Dec 14 04:23:10 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Mon, 14 Dec 2020 09:23:10 +0000
Subject: [issue42632] Reassgining ZeroDivisionError will lead to bug in Except
 clause
In-Reply-To: <1607925772.13.0.935744871681.issue42632@roundup.psfhosted.org>
Message-ID: <1607937790.42.0.717826521331.issue42632@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

This is just how local/nonlocal/global/builtin variables work in Python.

When you assign to a name anywhere inside of a function, all occurrences of that name refer by default to a local variable. So the line "ZeroDivisionError = 1" tells the foo() function that it has some local variable called "ZeroDivisionError". In order to make sure that the ZeroDivisionError always refers to the builtin exception, you need to add a global statement:

>>> def foo():
...     global ZeroDivisionError
...     try:
...         1/0
...     except ZeroDivisionError as e:
...         ZeroDivisionError = 1

>>> foo()
>>> ZeroDivisionError
1


See also: https://docs.python.org/3/faq/programming.html?highlight=global#why-am-i-getting-an-unboundlocalerror-when-the-variable-has-a-value

----------
nosy: +Dennis Sweeney

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42632>
_______________________________________

From report at bugs.python.org  Mon Dec 14 04:24:33 2020
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 14 Dec 2020 09:24:33 +0000
Subject: [issue42635] Incorrect line number in bytecode for nested loops
Message-ID: <1607937873.82.0.254975508091.issue42635@roundup.psfhosted.org>


New submission from Mark Shannon <mark at hotpy.org>:

The following code, when traced, produces a spurious line events at the end of the inner loop.


def dloop():
    for i in range(3):
        for j in range(3):
            a = i + j
    assert a == 4



Bug reported by Ned Batchelder https://gist.github.com/nedbat/6c5dedde9df8d2de13de8a6a39a5f112

----------
assignee: Mark.Shannon
messages: 382968
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
stage: needs patch
status: open
title: Incorrect line number in bytecode for nested loops
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42635>
_______________________________________

From report at bugs.python.org  Mon Dec 14 04:29:40 2020
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 14 Dec 2020 09:29:40 +0000
Subject: [issue42635] Incorrect line number in bytecode for nested loops
In-Reply-To: <1607937873.82.0.254975508091.issue42635@roundup.psfhosted.org>
Message-ID: <1607938180.38.0.415412604704.issue42635@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
keywords: +patch
pull_requests: +22617
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/23761

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42635>
_______________________________________

From report at bugs.python.org  Mon Dec 14 04:32:31 2020
From: report at bugs.python.org (Martin Natano)
Date: Mon, 14 Dec 2020 09:32:31 +0000
Subject: [issue42306] wrong exception handling in case asyncio.shiled usage
In-Reply-To: <1604995209.89.0.967807993148.issue42306@roundup.psfhosted.org>
Message-ID: <1607938351.13.0.0297969005958.issue42306@roundup.psfhosted.org>


Martin Natano <natano+pythonbugs at natano.net> added the comment:

I just verified that this is not an issue in python 3.8.6 and python 3.9.0. In those versions a normal stacktrace is generated, as expected.

----------
nosy: +natano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42306>
_______________________________________

From report at bugs.python.org  Mon Dec 14 04:43:08 2020
From: report at bugs.python.org (Evgeny)
Date: Mon, 14 Dec 2020 09:43:08 +0000
Subject: [issue14243] tempfile.NamedTemporaryFile not particularly useful
 on	Windows
In-Reply-To: <1331345648.86.0.0206250913108.issue14243@psf.upfronthosting.co.za>
Message-ID: <1607938988.43.0.729063604851.issue14243@roundup.psfhosted.org>


Change by Evgeny <ev2geny at gmail.com>:


----------
keywords: +patch
pull_requests: +22618
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/22431

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14243>
_______________________________________

From report at bugs.python.org  Mon Dec 14 04:54:48 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 14 Dec 2020 09:54:48 +0000
Subject: [issue42306] wrong exception handling in case asyncio.shiled usage
In-Reply-To: <1604995209.89.0.967807993148.issue42306@roundup.psfhosted.org>
Message-ID: <1607939688.63.0.83132840075.issue42306@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Sorry, this issue is not reproduced on 3.8-3.9, 3.7 is in security mode.
The issue doesn't belong to the security set.
Closing.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42306>
_______________________________________

From report at bugs.python.org  Mon Dec 14 04:56:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Dec 2020 09:56:04 +0000
Subject: [issue30459] PyList_SET_ITEM  could be safer
In-Reply-To: <1495638852.56.0.0790136948712.issue30459@psf.upfronthosting.co.za>
Message-ID: <1607939764.62.0.669809168599.issue30459@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> That's not true; at least ALSA's python bindings use PyTuple_SET_ITEM as a lvalue as well.

alsa-python used PyTuple_SET_ITEM(..., obj) to decide if it should call Py_INCREF(obj). This code looks suspicious. PyTuple_SET_ITEM() should not be used to set an item to NULL.

It's already fixed:
https://github.com/alsa-project/alsa-python/commit/5ea2f8709b4d091700750661231f8a3ddce0fc7c

IMO it's a good thing that such suspicious code is discovered. The surprising part is that it worked previously :-)

Downstream Fedora issue: https://bugzilla.redhat.com/show_bug.cgi?id=1906380 (CLOSED)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30459>
_______________________________________

From report at bugs.python.org  Mon Dec 14 05:12:35 2020
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Mon, 14 Dec 2020 10:12:35 +0000
Subject: [issue40791] hmac.compare_digest could try harder to be constant-time.
In-Reply-To: <1590565267.04.0.961881522519.issue40791@roundup.psfhosted.org>
Message-ID: <1607940755.43.0.0651795827052.issue40791@roundup.psfhosted.org>


Micha? G?rny <mgorny at gentoo.org> added the comment:

Any reason this wasn't backported to 3.6?  FWICS it's supposed to be security supported still.

----------
nosy: +mgorny

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40791>
_______________________________________

From report at bugs.python.org  Mon Dec 14 05:18:49 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Dec 2020 10:18:49 +0000
Subject: [issue42587] memoryview rely on _Bool undefined behavior (test_buffer
 fails on Python built with GCC 11)
In-Reply-To: <1607353221.74.0.500162368406.issue42587@roundup.psfhosted.org>
Message-ID: <1607941129.37.0.153283088809.issue42587@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I reported the bug to GCC upstream: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98190

GCC got a fix:
https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=3e60ddeb8220ed388819bb3f14e8caa9309fd3c2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42587>
_______________________________________

From report at bugs.python.org  Mon Dec 14 05:20:57 2020
From: report at bugs.python.org (E. Paine)
Date: Mon, 14 Dec 2020 10:20:57 +0000
Subject: [issue42630] Variable.__init__ raises obscure AttributeError
In-Reply-To: <1607901840.62.0.626631020476.issue42630@roundup.psfhosted.org>
Message-ID: <1607941257.81.0.0620935953494.issue42630@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

+1 I agree the current AttributeError is not suitable.

I would just copy the code from Lib/tkinter/__init__.py:2524 (or even better: refactor it into its own method to avoid duplication). The code there, though, would raise a similar AttributeError if the default root is disabled, so I suggest that needs a changing to possibly a TypeError (i.e. missing 'master' argument). I assume you are alright to create a PR for this?

Please revert the "resolution" field as this is intended to be the reason for issue closure.

----------
nosy: +epaine, serhiy.storchaka
title: Variable.__init__ to raise a RuntimeError instead of obscure AttributeError -> Variable.__init__ raises obscure AttributeError
versions: +Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42630>
_______________________________________

From report at bugs.python.org  Mon Dec 14 05:36:21 2020
From: report at bugs.python.org (Martin Natano)
Date: Mon, 14 Dec 2020 10:36:21 +0000
Subject: [issue42636] shielded task exception never retrieved when outer task
 cancelled
Message-ID: <1607942181.31.0.646688674125.issue42636@roundup.psfhosted.org>


New submission from Martin Natano <natano+pythonbugs at natano.net>:

A task created with asyncio.shield() never retrieves the task exception, which results in a log message being generated. See the attached script for a minimal example. Output looks something like this:

<snip>
Task exception was never retrieved
future: <Task finished name='Task-2' coro=<some_coroutine() done, defined at /Users/natano/python-bug/trigger-warning.py:4> exception=Exception('foo')>
Traceback (most recent call last):
  File "/Users/natano/python-bug/trigger-warning.py", line 6, in some_coroutine
    raise Exception('foo')
Exception: foo
</snip>

I believe this behaviour is not intended and is an unintended side-effect of commit b35acc5b3a0148c5fd4462968b310fb436726d5a (https://github.com/python/cpython/commit/b35acc5b3a0148c5fd4462968b310fb436726d5a). The _inner_done_callback has has code to retrieve the exception when the outer task was cancelled, but since that commit the _inner_done_callback is not called anymore when the outer task was cancelled.


(Tested with 3.8, 3.9 and 3.10. I don't have a python 3.7 version available for testing, but I think this issue also affects 3.7.)

----------
components: asyncio
files: trigger-warning.py
messages: 382975
nosy: asvetlov, natano, yselivanov
priority: normal
severity: normal
status: open
title: shielded task exception never retrieved when outer task cancelled
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49679/trigger-warning.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42636>
_______________________________________

From report at bugs.python.org  Mon Dec 14 05:38:10 2020
From: report at bugs.python.org (Martin Natano)
Date: Mon, 14 Dec 2020 10:38:10 +0000
Subject: [issue42636] shielded task exception never retrieved when outer task
 cancelled
In-Reply-To: <1607942181.31.0.646688674125.issue42636@roundup.psfhosted.org>
Message-ID: <1607942290.93.0.827788189381.issue42636@roundup.psfhosted.org>


Martin Natano <natano+pythonbugs at natano.net> added the comment:

I'm not sure how to fix this, but here is a regression test for the issue. (failing on the current master branch)

----------
keywords: +patch
Added file: https://bugs.python.org/file49680/regression-test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42636>
_______________________________________

From report at bugs.python.org  Mon Dec 14 05:38:59 2020
From: report at bugs.python.org (E. Paine)
Date: Mon, 14 Dec 2020 10:38:59 +0000
Subject: [issue42637] Python release note tkinter problems
Message-ID: <1607942339.24.0.547653054528.issue42637@roundup.psfhosted.org>


New submission from E. Paine <paineelisha at gmail.com>:

Under the "Installer news" for the Python 3.9.1 release, it notes:
"As we are waiting for an updated version of pip, please consider the macos11.0 installer experimental."

Is it worth also noting that tkinter has serious known problems that are being resolved (issue42541)?

----------
messages: 382977
nosy: epaine, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Python release note tkinter problems

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42637>
_______________________________________

From report at bugs.python.org  Mon Dec 14 05:39:53 2020
From: report at bugs.python.org (E. Paine)
Date: Mon, 14 Dec 2020 10:39:53 +0000
Subject: [issue42637] Python macos11.0 release note tkinter problems in news
In-Reply-To: <1607942339.24.0.547653054528.issue42637@roundup.psfhosted.org>
Message-ID: <1607942393.67.0.519807997022.issue42637@roundup.psfhosted.org>


Change by E. Paine <paineelisha at gmail.com>:


----------
title: Python release note tkinter problems -> Python macos11.0 release note tkinter problems in news

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42637>
_______________________________________

From report at bugs.python.org  Mon Dec 14 05:41:38 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 14 Dec 2020 10:41:38 +0000
Subject: [issue42630] Variable.__init__ raises obscure AttributeError
In-Reply-To: <1607901840.62.0.626631020476.issue42630@roundup.psfhosted.org>
Message-ID: <1607942498.0.0.156833879919.issue42630@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Actually it may be worth to reuse setup_master() from tkinter.ttk.

But I am not sure what is better: raise error (RuntimeError) if the global function uses _default_root which is not initialized, or create the root widget implicitly. Currently AttributeError or NameError is raised.

----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42630>
_______________________________________

From report at bugs.python.org  Mon Dec 14 05:49:10 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 14 Dec 2020 10:49:10 +0000
Subject: [issue42636] shielded task exception never retrieved when outer task
 cancelled
In-Reply-To: <1607942181.31.0.646688674125.issue42636@roundup.psfhosted.org>
Message-ID: <1607942950.31.0.564700627178.issue42636@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Thanks for the report.

I didn't test but looks like `outer.exception()` call can suppress the message about not retrieved exception.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42636>
_______________________________________

From report at bugs.python.org  Mon Dec 14 06:28:54 2020
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 14 Dec 2020 11:28:54 +0000
Subject: [issue42635] Incorrect line number in bytecode for nested loops
In-Reply-To: <1607937873.82.0.254975508091.issue42635@roundup.psfhosted.org>
Message-ID: <1607945334.14.0.119136760482.issue42635@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset f5e97b72fecff9b9ced35704ec5e6cad29e2825d by Mark Shannon in branch 'master':
bpo-42635: Mark JUMP_ABSOLUTE at end of 'for' loop as artificial to avoid spurious line events. (GH-23761)
https://github.com/python/cpython/commit/f5e97b72fecff9b9ced35704ec5e6cad29e2825d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42635>
_______________________________________

From report at bugs.python.org  Mon Dec 14 06:29:54 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 14 Dec 2020 11:29:54 +0000
Subject: [issue42638] IDLE: Context lines not working correctly
Message-ID: <1607945394.59.0.0452931693477.issue42638@roundup.psfhosted.org>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Test: open editor.py in editor.  Turn on Code context with large max lines.  Scroll down to body of _sphinx_version (after line 37).  Nothing appears.  Scroll down to line 82 in EditorWindow.__init__.  'def _sphinx_version' appears.  Scroll up (again with arrow key) to the 'def _sphinx_version' line and it diappears from the context.  Usually repeats.

Is it coincidence that 82 - 37 = 45, the lines in the window?  No.  Shrink window to 26 lines and context line appears when at line 37 + 26 = 63.

----------
assignee: terry.reedy
components: IDLE
messages: 382981
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: Context lines not working correctly
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42638>
_______________________________________

From report at bugs.python.org  Mon Dec 14 06:59:09 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Dec 2020 11:59:09 +0000
Subject: [issue40600] Add option to disallow > 1 instance of an extension
 module
In-Reply-To: <1589235149.46.0.0630975096351.issue40600@roundup.psfhosted.org>
Message-ID: <1607947149.67.0.609108313046.issue40600@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22619
pull_request: https://github.com/python/cpython/pull/23763

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40600>
_______________________________________

From report at bugs.python.org  Mon Dec 14 07:00:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Dec 2020 12:00:33 +0000
Subject: [issue42639] Make atexit state per interpreter
Message-ID: <1607947233.16.0.810683660249.issue42639@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

In Python 2.7, atexit was implemented in Python and registered itself using sys.exitfunc public attribute:
https://docs.python.org/2.7/library/sys.html#sys.exitfunc
https://docs.python.org/2.7/library/atexit.html#module-atexit

In Python 3.0, the atexit module was rewritten in C. A new private _Py_PyAtExit() function was added to set a new private global "pyexitfunc" variable: variable used by call_py_exitfuncs() called by Py_Finalize().

In Python 3.7, the global "pyexitfunc" variable was moved int _PyRuntimeState (commit 2ebc5ce42a8a9e047e790aefbf9a94811569b2b6), and then into PyInterpreterState (commit 776407fe893fd42972c7e3f71423d9d86741d07c).

In Python 3.7, the atexit module was upgrade to the multiphase initialization API (PEP 489): PyInit_atexit() uses PyModuleDef_Init().

Since Python 2.7, the atexit module has a limitation: if a second instance is created, the new instance overrides the old one, and old registered callbacks are newer called.

One option is to disallow creating a second instance: see bpo-40600 and PR 23699 for that.

Another option is to move the atexit state (callbacks) into PyInterpreterState. Two atexit module instances would modify the same list of callbacks. In this issue, I propose to investigate this option.

----------
components: Library (Lib)
messages: 382982
nosy: vstinner
priority: normal
severity: normal
status: open
title: Make atexit state per interpreter
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42639>
_______________________________________

From report at bugs.python.org  Mon Dec 14 07:02:08 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Dec 2020 12:02:08 +0000
Subject: [issue42639] Make atexit state per interpreter
In-Reply-To: <1607947233.16.0.810683660249.issue42639@roundup.psfhosted.org>
Message-ID: <1607947328.76.0.512132785486.issue42639@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +22620
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23763

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42639>
_______________________________________

From report at bugs.python.org  Mon Dec 14 07:03:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Dec 2020 12:03:34 +0000
Subject: [issue40600] Add option to disallow > 1 instance of an extension
 module
In-Reply-To: <1589235149.46.0.0630975096351.issue40600@roundup.psfhosted.org>
Message-ID: <1607947414.61.0.369039299206.issue40600@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I created bpo-42639 and PR 23763 to move the atexit module to PyInterpreterState and so allow to have more than one atexit instance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40600>
_______________________________________

From report at bugs.python.org  Mon Dec 14 07:55:48 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 14 Dec 2020 12:55:48 +0000
Subject: =?utf-8?q?=5Bissue42614=5D_Pathlib_does_not_support_a_Cyrillic_character_?=
 =?utf-8?b?J9C5Jw==?=
In-Reply-To: <1607599977.07.0.665981519829.issue42614@roundup.psfhosted.org>
Message-ID: <1607950548.69.0.777772170012.issue42614@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'm closing this as "not a bug" because this is likely caused by different unicode normalisations for strings.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42614>
_______________________________________

From report at bugs.python.org  Mon Dec 14 08:02:14 2020
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 14 Dec 2020 13:02:14 +0000
Subject: [issue42246] Implement PEP 626 -- Precise line numbers for debugging
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1607950934.71.0.135313701528.issue42246@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Thanks Ned, that's really helpful. I'll go through those points:

Code after break/continue is no longer compiled.
    Expected

First line number of modules
    Expected

Except clause when no exception
    https://bugs.python.org/issue42634

Double loops (this also covers End-of-loop jumps, I think)
    https://bugs.python.org/issue42635

I want to merge https://github.com/python/cpython/pull/23743 before I fix any of the others, but here is a summary of what I think are the root causes.

if-break
    Exit block duplication does not preserve line number of jump to final block

Finally handling
    Combination of two things. Not preserving line numbers when performing jump-to-jump elimination and not marking try cleanup code as artificial.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42246>
_______________________________________

From report at bugs.python.org  Mon Dec 14 08:04:44 2020
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 14 Dec 2020 13:04:44 +0000
Subject: [issue42634] Incorrect line number in bytecode for try-except-finally
In-Reply-To: <1607930696.05.0.974303425196.issue42634@roundup.psfhosted.org>
Message-ID: <1607951084.4.0.463635809859.issue42634@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42634>
_______________________________________

From report at bugs.python.org  Mon Dec 14 08:06:12 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Dec 2020 13:06:12 +0000
Subject: [issue26131] Raise ImportWarning when loader.load_module() is used
In-Reply-To: <1452894244.92.0.478987355259.issue26131@psf.upfronthosting.co.za>
Message-ID: <1607951172.68.0.581139796023.issue26131@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I wrote https://github.com/benjaminp/six/pull/343 to fix the six module. I would appreciate a review.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26131>
_______________________________________

From report at bugs.python.org  Mon Dec 14 08:06:10 2020
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 14 Dec 2020 13:06:10 +0000
Subject: [issue42635] Incorrect line number in bytecode for nested loops
In-Reply-To: <1607937873.82.0.254975508091.issue42635@roundup.psfhosted.org>
Message-ID: <1607951170.21.0.53375845602.issue42635@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
resolution:  -> fixed
stage: patch review -> needs patch
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42635>
_______________________________________

From report at bugs.python.org  Mon Dec 14 08:34:11 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 14 Dec 2020 13:34:11 +0000
Subject: [issue42632] Reassgining ZeroDivisionError will lead to bug in Except
 clause
In-Reply-To: <1607925772.13.0.935744871681.issue42632@roundup.psfhosted.org>
Message-ID: <1607952851.52.0.386860277061.issue42632@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

This code is working as expected, so I'm closing this.

----------
nosy: +eric.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42632>
_______________________________________

From report at bugs.python.org  Mon Dec 14 08:35:22 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 14 Dec 2020 13:35:22 +0000
Subject: [issue42632] Reassgining ZeroDivisionError will lead to bug in Except
 clause
In-Reply-To: <1607925772.13.0.935744871681.issue42632@roundup.psfhosted.org>
Message-ID: <1607952922.43.0.421834935161.issue42632@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

And thanks, Dennis, for the explanation as to why it's the expected behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42632>
_______________________________________

From report at bugs.python.org  Mon Dec 14 09:34:02 2020
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 14 Dec 2020 14:34:02 +0000
Subject: [issue42571] Make documentation of * in function signatures easier to
 find
In-Reply-To: <1607116268.54.0.585771365964.issue42571@roundup.psfhosted.org>
Message-ID: <1607956442.48.0.139713714806.issue42571@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:

Thank you for the details!  This helps finding a good place to document this.
A link to function parameters from the top of the section may be good.
But maybe we need a sidebar link on all pages that goes to a description of doc conventions! (and includes link to basic syntax doc, function parameter glossary, tutorial).

(As you thought, there are notations in the docs (and even in some docstrings) that are documentation conventions but not valid Python, such as "range(start, stop[, step]) -> range object")

Even the enty for '* (asterisk)' in the general index https://docs.python.org/3/genindex-Symbols.html links to places explaining *args, not * alone.

I agree that the glossary entry for parameter is the best place to link to: it?s short and complete and can link to language reference for more.

----------
title: [docs] add links to Glossary#parameter in libraries -> Make documentation of * in function signatures easier to find
versions: +Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42571>
_______________________________________

From report at bugs.python.org  Mon Dec 14 09:44:09 2020
From: report at bugs.python.org (Ken Jin)
Date: Mon, 14 Dec 2020 14:44:09 +0000
Subject: [issue42195] Inconsistent __args__ between typing.Callable and
 collections.abc.Callable
In-Reply-To: <1603974319.88.0.166786801787.issue42195@roundup.psfhosted.org>
Message-ID: <1607957048.99.0.549265987209.issue42195@roundup.psfhosted.org>


Change by Ken Jin <kenjin4096 at gmail.com>:


----------
pull_requests: +22621
pull_request: https://github.com/python/cpython/pull/23765

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42195>
_______________________________________

From report at bugs.python.org  Mon Dec 14 10:14:46 2020
From: report at bugs.python.org (Ivo Shipkaliev)
Date: Mon, 14 Dec 2020 15:14:46 +0000
Subject: [issue42630] Variable.__init__ raises obscure AttributeError
In-Reply-To: <1607901840.62.0.626631020476.issue42630@roundup.psfhosted.org>
Message-ID: <1607958886.19.0.364445143279.issue42630@roundup.psfhosted.org>


Change by Ivo Shipkaliev <ivo.shipkaliev at gmail.com>:


----------
resolution: works for me -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42630>
_______________________________________

From report at bugs.python.org  Mon Dec 14 10:22:33 2020
From: report at bugs.python.org (Michael Woodham)
Date: Mon, 14 Dec 2020 15:22:33 +0000
Subject: [issue38655] ipaddress.ip_network('0.0.0.0/0').is_private == True
In-Reply-To: <1572530691.84.0.462430681921.issue38655@roundup.psfhosted.org>
Message-ID: <1607959353.84.0.778433982016.issue38655@roundup.psfhosted.org>


Michael Woodham <maw1395 at gmail.com> added the comment:

As far as I can tell this is still broken. A hard check for '0.0.0.0/0' should fix this issue.

----------
nosy: +maw1395

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38655>
_______________________________________

From report at bugs.python.org  Mon Dec 14 11:31:00 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 14 Dec 2020 16:31:00 +0000
Subject: [issue42195] Inconsistent __args__ between typing.Callable and
 collections.abc.Callable
In-Reply-To: <1603974319.88.0.166786801787.issue42195@roundup.psfhosted.org>
Message-ID: <1607963460.96.0.681610024186.issue42195@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 33b3fedd43e10e5a227ec8b7d251496e7cad4717 by kj in branch '3.9':
[3.9] bpo-42195: Ensure consistency of Callable's __args__ in collections.abc and typing (GH-23765)
https://github.com/python/cpython/commit/33b3fedd43e10e5a227ec8b7d251496e7cad4717


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42195>
_______________________________________

From report at bugs.python.org  Mon Dec 14 11:33:44 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 14 Dec 2020 16:33:44 +0000
Subject: [issue35332] shutil.rmtree(...,
 ignore_errors=True) doesn't ignore errors from os.close()
In-Reply-To: <1543348313.91.0.788709270274.issue35332@psf.upfronthosting.co.za>
Message-ID: <1607963624.79.0.851622414823.issue35332@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 2.0 -> 3.0
pull_requests: +22622
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23766

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35332>
_______________________________________

From report at bugs.python.org  Mon Dec 14 11:34:44 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 14 Dec 2020 16:34:44 +0000
Subject: [issue42195] Inconsistent __args__ between typing.Callable and
 collections.abc.Callable
In-Reply-To: <1603974319.88.0.166786801787.issue42195@roundup.psfhosted.org>
Message-ID: <1607963684.13.0.116535335479.issue42195@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Looks like we can close this. Thanks for the report Zac (hopefully you can live with the resolution), and thanks a bundle Ken Jin for all your work on this! I hope it was fun and educational for you. I know it was for me.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42195>
_______________________________________

From report at bugs.python.org  Mon Dec 14 11:41:09 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 14 Dec 2020 16:41:09 +0000
Subject: [issue40791] hmac.compare_digest could try harder to be constant-time.
In-Reply-To: <1590565267.04.0.961881522519.issue40791@roundup.psfhosted.org>
Message-ID: <1607964069.77.0.220524621528.issue40791@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22623
pull_request: https://github.com/python/cpython/pull/23767

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40791>
_______________________________________

From report at bugs.python.org  Mon Dec 14 12:05:09 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 14 Dec 2020 17:05:09 +0000
Subject: [issue40791] hmac.compare_digest could try harder to be constant-time.
In-Reply-To: <1590565267.04.0.961881522519.issue40791@roundup.psfhosted.org>
Message-ID: <1607965509.22.0.924538843032.issue40791@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 8bef9ebb1b88cfa4b2a38b93fe4ea22015d8254a by Miss Islington (bot) in branch '3.6':
bpo-40791: Make compare_digest more constant-time. (GH-23438) (GH-23767)
https://github.com/python/cpython/commit/8bef9ebb1b88cfa4b2a38b93fe4ea22015d8254a


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40791>
_______________________________________

From report at bugs.python.org  Mon Dec 14 12:10:21 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 14 Dec 2020 17:10:21 +0000
Subject: [issue36541] Make lib2to3 grammar better match Python,
 support the := walrus
In-Reply-To: <1554514880.92.0.277848417721.issue36541@roundup.psfhosted.org>
Message-ID: <1607965821.63.0.809906345674.issue36541@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset 42c9f0fd0a5e67d4ae0022bfd7370cb9725a5b01 by Gregory P. Smith in branch 'master':
bpo-36541: Add lib2to3 grammar PEP-570 pos-only arg parsing (GH-23759)
https://github.com/python/cpython/commit/42c9f0fd0a5e67d4ae0022bfd7370cb9725a5b01


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36541>
_______________________________________

From report at bugs.python.org  Mon Dec 14 12:10:27 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 14 Dec 2020 17:10:27 +0000
Subject: [issue36541] Make lib2to3 grammar better match Python,
 support the := walrus
In-Reply-To: <1554514880.92.0.277848417721.issue36541@roundup.psfhosted.org>
Message-ID: <1607965827.3.0.843547011412.issue36541@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22624
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/23768

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36541>
_______________________________________

From report at bugs.python.org  Mon Dec 14 12:10:37 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 14 Dec 2020 17:10:37 +0000
Subject: [issue36541] Make lib2to3 grammar better match Python,
 support the := walrus
In-Reply-To: <1554514880.92.0.277848417721.issue36541@roundup.psfhosted.org>
Message-ID: <1607965837.66.0.655061026086.issue36541@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22625
pull_request: https://github.com/python/cpython/pull/23769

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36541>
_______________________________________

From report at bugs.python.org  Mon Dec 14 12:11:27 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 14 Dec 2020 17:11:27 +0000
Subject: [issue40791] hmac.compare_digest could try harder to be constant-time.
In-Reply-To: <1590565267.04.0.961881522519.issue40791@roundup.psfhosted.org>
Message-ID: <1607965887.04.0.985471342748.issue40791@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

> Any reason this wasn't backported to 3.6?

Just an oversight. Thanks for pointing it out.

----------
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40791>
_______________________________________

From report at bugs.python.org  Mon Dec 14 12:30:14 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 14 Dec 2020 17:30:14 +0000
Subject: [issue36541] Make lib2to3 grammar better match Python,
 support the := walrus
In-Reply-To: <1554514880.92.0.277848417721.issue36541@roundup.psfhosted.org>
Message-ID: <1607967014.07.0.939765613289.issue36541@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 06bfd033e847bedb6e123d131dcf46393a4555df by Miss Islington (bot) in branch '3.8':
bpo-36541: Add lib2to3 grammar PEP-570 pos-only arg parsing (GH-23759)
https://github.com/python/cpython/commit/06bfd033e847bedb6e123d131dcf46393a4555df


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36541>
_______________________________________

From report at bugs.python.org  Mon Dec 14 12:38:25 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 14 Dec 2020 17:38:25 +0000
Subject: [issue36541] Make lib2to3 grammar better match Python,
 support the := walrus
In-Reply-To: <1554514880.92.0.277848417721.issue36541@roundup.psfhosted.org>
Message-ID: <1607967505.78.0.330061268675.issue36541@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 20bc40ef44b820733848d5838e803b5fe4350b93 by Miss Islington (bot) in branch '3.9':
bpo-36541: Add lib2to3 grammar PEP-570 pos-only arg parsing (GH-23759)
https://github.com/python/cpython/commit/20bc40ef44b820733848d5838e803b5fe4350b93


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36541>
_______________________________________

From report at bugs.python.org  Mon Dec 14 13:13:48 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 14 Dec 2020 18:13:48 +0000
Subject: [issue36541] Make lib2to3 grammar better match Python,
 support the := walrus
In-Reply-To: <1554514880.92.0.277848417721.issue36541@roundup.psfhosted.org>
Message-ID: <1607969628.45.0.501898094553.issue36541@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
resolution: out of date -> fixed
stage: patch review -> commit review
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36541>
_______________________________________

From report at bugs.python.org  Mon Dec 14 13:22:37 2020
From: report at bugs.python.org (Justin)
Date: Mon, 14 Dec 2020 18:22:37 +0000
Subject: [issue42640] tkinter throws exception when key is pressed
Message-ID: <1607970157.48.0.157059469848.issue42640@roundup.psfhosted.org>


New submission from Justin <justin.a.black at gmail.com>:

On macOs 10.14.6 laptop with a qwerty layout, when I switch my keyboard layout to `French - PC` and use a tkinter keyboard listener
and press the '[' button which should be the '^' button on the azerty keyboard, this Error is thrown:
```
2020-12-14 10:13:26.533 Python[14880:1492926] *** Terminating app due to uncaught exception 'NSRangeException', reason: '-[__NSCFConstantString characterAtIndex:]: Range or index out of bounds'
*** First throw call stack:
(
	0   CoreFoundation                      0x00007fff41ce49ad __exceptionPreprocess + 256
	1   libobjc.A.dylib                     0x00007fff6c3dfa17 objc_exception_throw + 48
	2   CoreFoundation                      0x00007fff41ce47df +[NSException raise:format:] + 201
	3   CoreFoundation                      0x00007fff41c5a159 -[__NSCFString characterAtIndex:] + 102
	4   Tk                                  0x00007fff4da8a806 TkpInitKeymapInfo + 719
	5   Tk                                  0x00007fff4da905e9 Tk_MacOSXSetupTkNotifier + 793
	6   Tcl                                 0x00007fff4d98c48e Tcl_DoOneEvent + 301
	7   _tkinter.cpython-38-darwin.so       0x00000001090802de _tkinter_tkapp_mainloop + 342
	8   Python                              0x0000000108ac1b0a method_vectorcall_FASTCALL + 250
	9   Python                              0x0000000108b5a299 call_function + 346
	10  Python                              0x0000000108b51457 _PyEval_EvalFrameDefault + 3895
	11  Python                              0x0000000108b5ae5d _PyEval_EvalCodeWithName + 2107
	12  Python                              0x0000000108abad39 _PyFunction_Vectorcall + 217
	13  Python                              0x0000000108abcc7d method_vectorcall + 135
	14  Python                              0x0000000108b5a299 call_function + 346
	15  Python                              0x0000000108b51477 _PyEval_EvalFrameDefault + 3927
	16  Python                              0x0000000108b5ae5d _PyEval_EvalCodeWithName + 2107
	17  Python                              0x0000000108b5047d PyEval_EvalCode + 51
	18  Python                              0x0000000108b89025 run_eval_code_obj + 102
	19  Python                              0x0000000108b88473 run_mod + 82
	20  Python                              0x0000000108b87345 PyRun_FileExFlags + 160
	21  Python                              0x0000000108b86a29 PyRun_SimpleFileExFlags + 271
	22  Python                              0x0000000108b9e449 Py_RunMain + 1870
	23  Python                              0x0000000108b9e790 pymain_main + 306
	24  Python                              0x0000000108b9e7de Py_BytesMain + 42
	25  libdyld.dylib                       0x00007fff6dbae3d5 start + 1
	26  ???                                 0x0000000000000002 0x0 + 2
)
libc++abi.dylib: terminating with uncaught exception of type NSException
Abort trap: 6
```
One can verify this by running this program on a macOs laptop with a qwerty keyboard, switching the layout to French - PC and pressing the '[' key.
```
import pygame
pygame.init()
pygame.display.set_mode((100, 100))
while True:
    for event in pygame.event.get():
        if event.type == pygame.QUIT:
            pygame.quit(); #sys.exit() if sys is imported
        if event.type == pygame.KEYDOWN:
            key_name = pygame.key.name(event.key)
            print(event, event.key.__class__, event.key, key_name)
        elif event.type == pygame.KEYUP:
            key_name = pygame.key.name(event.key)
            print(event, event.key.__class__, event.key, key_name)
```
```

----------
messages: 382998
nosy: spacether
priority: normal
severity: normal
status: open
title: tkinter throws exception when key is pressed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42640>
_______________________________________

From report at bugs.python.org  Mon Dec 14 13:24:18 2020
From: report at bugs.python.org (Justin)
Date: Mon, 14 Dec 2020 18:24:18 +0000
Subject: [issue42640] tkinter throws exception when key is pressed
In-Reply-To: <1607970157.48.0.157059469848.issue42640@roundup.psfhosted.org>
Message-ID: <1607970258.08.0.646497710743.issue42640@roundup.psfhosted.org>


Justin <justin.a.black at gmail.com> added the comment:

Sorry my verification keyboard listener program is not the pygame one. It is this one:
```
from tkinter import *
def keyup(e):
    print('up', e.__dict__)
def keydown(e):
    print('down', e.__dict__)

root = Tk()
frame = Frame(root, width=100, height=100)
frame.bind("<KeyPress>", keydown)
frame.bind("<KeyRelease>", keyup)
frame.pack()
frame.focus_set()
root.mainloop()
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42640>
_______________________________________

From report at bugs.python.org  Mon Dec 14 13:26:27 2020
From: report at bugs.python.org (to7m)
Date: Mon, 14 Dec 2020 18:26:27 +0000
Subject: [issue42631] Multiprocessing module hangs on os.read() on Linux
In-Reply-To: <1607902678.82.0.104927232585.issue42631@roundup.psfhosted.org>
Message-ID: <1607970387.35.0.59530865038.issue42631@roundup.psfhosted.org>


Change by to7m <thomashowemain at gmail.com>:


Removed file: https://bugs.python.org/file49675/receive.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42631>
_______________________________________

From report at bugs.python.org  Mon Dec 14 13:30:16 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 14 Dec 2020 18:30:16 +0000
Subject: [issue41877] Check against misspellings of assert etc. in mock
In-Reply-To: <1601317157.88.0.730935461305.issue41877@roundup.psfhosted.org>
Message-ID: <1607970616.64.0.947407622949.issue41877@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset fdb9efce6ac211f973088eef508740c3fa2bd182 by vabr-g in branch 'master':
bpo-41877: Check for misspelled speccing arguments (GH-23737)
https://github.com/python/cpython/commit/fdb9efce6ac211f973088eef508740c3fa2bd182


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41877>
_______________________________________

From report at bugs.python.org  Mon Dec 14 14:22:54 2020
From: report at bugs.python.org (=?utf-8?b?VsOhY2xhdiBCcm/FvmVr?=)
Date: Mon, 14 Dec 2020 19:22:54 +0000
Subject: [issue41877] Check against misspellings of assert etc. in mock
In-Reply-To: <1601317157.88.0.730935461305.issue41877@roundup.psfhosted.org>
Message-ID: <1607973774.23.0.370977877478.issue41877@roundup.psfhosted.org>


V?clav Bro?ek <vabr at google.com> added the comment:

The three PRs which landed for this bug implement what I planned in the original comment, so I'm closing this bug.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41877>
_______________________________________

From report at bugs.python.org  Mon Dec 14 14:22:58 2020
From: report at bugs.python.org (Ivo Shipkaliev)
Date: Mon, 14 Dec 2020 19:22:58 +0000
Subject: [issue42630] Variable.__init__ raises obscure AttributeError
In-Reply-To: <1607901840.62.0.626631020476.issue42630@roundup.psfhosted.org>
Message-ID: <1607973778.27.0.830601287914.issue42630@roundup.psfhosted.org>


Ivo Shipkaliev <ivo.shipkaliev at gmail.com> added the comment:

The current implementation is already relying on _some_ master anyway:

335 >         self._root = master._root()

So, initializing a default root, if one isn't present, shouldn't break anything. And reusing setup_master() is a good idea. Maybe:

333 > master = setup_master(master)
334 > self._root = master._root()

But:

> from tkinter.ttk import setup_master

leads to a circular import error. I'll look into this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42630>
_______________________________________

From report at bugs.python.org  Mon Dec 14 15:42:08 2020
From: report at bugs.python.org (E. Paine)
Date: Mon, 14 Dec 2020 20:42:08 +0000
Subject: [issue42630] Variable.__init__ raises obscure AttributeError
In-Reply-To: <1607901840.62.0.626631020476.issue42630@roundup.psfhosted.org>
Message-ID: <1607978528.67.0.331175433118.issue42630@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

Attached is a diff which moves the logic for `setup_master` to the tkinter module while allowing it to still be imported from the tkinter.ttk module (in case someone uses it...) The diff also replaces the logic in a few other places to:
A. make behaviour more consistent
B. give nicer errors in other methods (i.e. avoiding what this issue is about but in other places)

I guess my question is whether we are limiting most changes to just __init__.py or whether we want to do more of a cleanup throughout the tkinter module (e.g. tkinter.dialog.Dialog can be neatened and no longer needs to inherit the Widget class).

----------
keywords: +patch
Added file: https://bugs.python.org/file49681/setup_master.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42630>
_______________________________________

From report at bugs.python.org  Mon Dec 14 16:06:21 2020
From: report at bugs.python.org (E. Paine)
Date: Mon, 14 Dec 2020 21:06:21 +0000
Subject: [issue42640] tkinter throws exception when key is pressed
In-Reply-To: <1607970157.48.0.157059469848.issue42640@roundup.psfhosted.org>
Message-ID: <1607979981.17.0.721270680159.issue42640@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

Thank you for reporting this. I just have a few questions:
1. Which Python version are you using?
2. If Python 3.9.1, which installer did you use?
3. What does `tkinter.test.support.get_tk_patchlevel()` output?
4. Does your pygame example suffer the same issue (I assume not)?

I am unable to reproduce on macOS 11 with Python 3.8.6, but am almost certain this is a Tk issue due to the nature of it.

----------
components: +Tkinter, macOS
nosy: +epaine, ned.deily, ronaldoussoren, serhiy.storchaka
type:  -> behavior
versions: +Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42640>
_______________________________________

From report at bugs.python.org  Mon Dec 14 16:18:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Dec 2020 21:18:56 +0000
Subject: [issue42639] Make atexit state per interpreter
In-Reply-To: <1607947233.16.0.810683660249.issue42639@roundup.psfhosted.org>
Message-ID: <1607980736.86.0.376795231227.issue42639@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22626
pull_request: https://github.com/python/cpython/pull/23770

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42639>
_______________________________________

From report at bugs.python.org  Mon Dec 14 16:40:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Dec 2020 21:40:47 +0000
Subject: [issue42639] Make atexit state per interpreter
In-Reply-To: <1607947233.16.0.810683660249.issue42639@roundup.psfhosted.org>
Message-ID: <1607982047.89.0.637303426168.issue42639@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 83d52044ae4def1e8611a4b1b9263b850ca5c458 by Victor Stinner in branch 'master':
bpo-42639: Cleanup atexitmodule.c (GH-23770)
https://github.com/python/cpython/commit/83d52044ae4def1e8611a4b1b9263b850ca5c458


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42639>
_______________________________________

From report at bugs.python.org  Mon Dec 14 16:41:03 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 14 Dec 2020 21:41:03 +0000
Subject: [issue42640] tkinter throws exception when key is pressed
In-Reply-To: <1607970157.48.0.157059469848.issue42640@roundup.psfhosted.org>
Message-ID: <1607982063.89.0.603431438513.issue42640@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

The problem here undoubtedly is that the Python you are using is linked with the Apple-provided system version of Tk 8.5.9 which exhibits this nasty behavior of crashing when pressing a composing key. The system version of Tk is woefully out of date with other serious bugs and hasn?t been updated by Apple for many macOS releases despite many bug reports. Their response has been to deprecate the system Tk and they will eventually remove it. That?s why Python binary installers from Python.org now provide their own copy of Tk 8.6. You should update to a macOS build of Python 3.8 or 3.9 that also uses a newer version of Tk. Issue22566 has more details.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> International keyboard makes IDLE crash on OSX

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42640>
_______________________________________

From report at bugs.python.org  Mon Dec 14 16:43:33 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Dec 2020 21:43:33 +0000
Subject: [issue42639] Make atexit state per interpreter
In-Reply-To: <1607947233.16.0.810683660249.issue42639@roundup.psfhosted.org>
Message-ID: <1607982213.89.0.486056927128.issue42639@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22627
pull_request: https://github.com/python/cpython/pull/23771

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42639>
_______________________________________

From report at bugs.python.org  Mon Dec 14 16:52:21 2020
From: report at bugs.python.org (Matthew Suozzo)
Date: Mon, 14 Dec 2020 21:52:21 +0000
Subject: [issue42551] Generator `yield`s counted as primitive calls by cProfile
In-Reply-To: <1606969779.69.0.0674581941893.issue42551@roundup.psfhosted.org>
Message-ID: <1607982741.59.0.377965211704.issue42551@roundup.psfhosted.org>


Matthew Suozzo <matthew.suozzo at gmail.com> added the comment:

One of the problems with my proposed solution that I glossed over was how and where to count the primitive call. If the primitive call is only registered on RETURN (i.e. after all yields), a generator that is incompletely exhausted would have 0 primitive calls. However if the primitive call is registered immediately when the call context is entered, the recorded call would be instantaneous (i.e. 0s duration) which could throw off the percall statistics.

Even with the incomplete generator case, I think registering the primitive call on RETURN is the best of the two options. Although seeing 2/0 for the call count when RETURN wasn't reached might seem odd, it lines up with a conceptual model of a coroutine: An iterator represents a function returning a sequence; Exhausting that iterator corresponds to the function call completing; Incompletely exhausting corresponds to an abbreviated/incomplete function call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42551>
_______________________________________

From report at bugs.python.org  Mon Dec 14 17:08:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Dec 2020 22:08:19 +0000
Subject: [issue42639] Make atexit state per interpreter
In-Reply-To: <1607947233.16.0.810683660249.issue42639@roundup.psfhosted.org>
Message-ID: <1607983699.98.0.0583750688921.issue42639@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 357704c9f2375f29ed5b3a93adac086fa714538d by Victor Stinner in branch 'master':
bpo-42639: atexit now logs callbacks exceptions (GH-23771)
https://github.com/python/cpython/commit/357704c9f2375f29ed5b3a93adac086fa714538d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42639>
_______________________________________

From report at bugs.python.org  Mon Dec 14 17:14:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Dec 2020 22:14:51 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1607984091.61.0.647701698055.issue31904@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset c117426bf8e7dd7a25e7d15bfbc88253b6ed42de by pxinwr in branch 'master':
bpo-31904: Enable libpython3.so shared library for VxWorks (GH-23741)
https://github.com/python/cpython/commit/c117426bf8e7dd7a25e7d15bfbc88253b6ed42de


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Mon Dec 14 17:30:14 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Mon, 14 Dec 2020 22:30:14 +0000
Subject: [issue42609] Eval with too high string multiplication crashes newer
 Python versions
In-Reply-To: <1607511907.66.0.321451468972.issue42609@roundup.psfhosted.org>
Message-ID: <1607985014.34.0.0801164307658.issue42609@roundup.psfhosted.org>


Change by Batuhan Taskaya <isidentical at gmail.com>:


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42609>
_______________________________________

From report at bugs.python.org  Mon Dec 14 17:33:37 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Mon, 14 Dec 2020 22:33:37 +0000
Subject: [issue42059] TypedDict(...) as function does not respect "total" when
 setting __required_keys__ and __optional_keys__
In-Reply-To: <1602926609.93.0.947551036861.issue42059@roundup.psfhosted.org>
Message-ID: <1607985217.36.0.426912161989.issue42059@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:


New changeset dbb00062dc3afb12c41c87564e6faefe60766b01 by Miss Islington (bot) in branch '3.9':
bpo-42059: Fix required/optional keys for TypedDict(..., total=False) (GH-22736) (GH-23747)
https://github.com/python/cpython/commit/dbb00062dc3afb12c41c87564e6faefe60766b01


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42059>
_______________________________________

From report at bugs.python.org  Mon Dec 14 17:43:57 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 14 Dec 2020 22:43:57 +0000
Subject: [issue40084] HTTPStatus has incomplete dir() listing
In-Reply-To: <1585293405.13.0.478935860244.issue40084@roundup.psfhosted.org>
Message-ID: <1607985837.43.0.389407767331.issue40084@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 33cbb04986d0dabb9c542edc52bb4ea6106d3a81 by Miss Islington (bot) in branch '3.9':
bpo-40084: Enum - dir() includes member attributes (GH-19219)
https://github.com/python/cpython/commit/33cbb04986d0dabb9c542edc52bb4ea6106d3a81


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40084>
_______________________________________

From report at bugs.python.org  Mon Dec 14 17:52:43 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Dec 2020 22:52:43 +0000
Subject: [issue42641] Deprecate os.popen() function
Message-ID: <1607986363.29.0.33477455927.issue42641@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

The os.popen() function uses a shell by default which usually leads to shell injection vulnerability.

It also has a weird API:

* closing the file waits until the process completes.
* close() returns a "wait status" (*) not a "returncode"

(*) see https://docs.python.org/dev/library/os.html#os.waitstatus_to_exitcode for the meaning of a "wait status".

IMO the subprocess module provides better and safer alternatives with a clean API. The subprocess module already explains how to replace os.popen() with subprocess:
https://docs.python.org/dev/library/subprocess.html#replacing-os-popen-os-popen2-os-popen3

In Python 2, os.popen() was deprecated since Python 2.6, but Python 3.0 removed the deprecation (commit dcf97b98ec5cad972b3a8b4989001c45da87d0ea, then commit f5a429295d855267c33c5ef110fbf05ee7a3013e extended os.popen() documentation again: bpo-6490).

platform.popen() existed until Python 3.8 (bpo-35345). It was deprecated since Python 3.3 (bpo-11377).

--

There is also the os.system() function which exposes the libc system() function. Should we deprecate this one as well?

----------
components: Library (Lib)
messages: 383012
nosy: vstinner
priority: normal
severity: normal
status: open
title: Deprecate os.popen() function
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42641>
_______________________________________

From report at bugs.python.org  Mon Dec 14 18:01:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Dec 2020 23:01:17 +0000
Subject: [issue42641] Deprecate os.popen() function
In-Reply-To: <1607986363.29.0.33477455927.issue42641@roundup.psfhosted.org>
Message-ID: <1607986877.75.0.896553210814.issue42641@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

In the past, multiple os.popen() usage have been replaced with subprocess in the stdlib to prevent the risk of shell injection:

* bpo-22636: ctypes modules
* bpo-22637: uuid module

By the way, there is an open issue bpo-21557 "os.popen & os.system lack shell-related security warnings".

See also bpo-6490 "os.popen documentation is probably wrong" (fixed).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42641>
_______________________________________

From report at bugs.python.org  Mon Dec 14 18:07:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Dec 2020 23:07:06 +0000
Subject: [issue42641] Deprecate os.popen() function
In-Reply-To: <1607986363.29.0.33477455927.issue42641@roundup.psfhosted.org>
Message-ID: <1607987226.07.0.201474894759.issue42641@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

os.popen() doesn't emit a ResourceWarning when close() is not called, leading to weird issues like bpo-15408.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42641>
_______________________________________

From report at bugs.python.org  Mon Dec 14 18:13:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Dec 2020 23:13:51 +0000
Subject: [issue42641] Deprecate os.popen() function
In-Reply-To: <1607986363.29.0.33477455927.issue42641@roundup.psfhosted.org>
Message-ID: <1607987631.45.0.114158791829.issue42641@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The pipes module uses os.popen(): The open_r() and open_w() methods of pipes.Template are implemented with os.popen().

Multiple tests still use os.popen():

* test_select: SelectTestCase.test_select()
* test_posix: PosixTester.test_getgroups()
* test_os: EnvironTests._test_underlying_process_env()
* test_os: EnvironTests.test_update2()

And os.popen() tests:

* test_os: EnvironTests.test_os_popen_iter()
* test_popen

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42641>
_______________________________________

From report at bugs.python.org  Mon Dec 14 18:19:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Dec 2020 23:19:17 +0000
Subject: [issue42641] Deprecate os.popen() function
In-Reply-To: <1607986363.29.0.33477455927.issue42641@roundup.psfhosted.org>
Message-ID: <1607987957.4.0.151548859981.issue42641@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

About the pipes module, see bpo-41150: "... unapplicable for processing binary data and text data non-encodable with the locale encoding".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42641>
_______________________________________

From report at bugs.python.org  Mon Dec 14 18:20:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Dec 2020 23:20:51 +0000
Subject: [issue42641] Deprecate os.popen() function
In-Reply-To: <1607986363.29.0.33477455927.issue42641@roundup.psfhosted.org>
Message-ID: <1607988051.31.0.325348392381.issue42641@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See also bpo-26124: "shlex.quote and pipes.quote do not quote shell keywords".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42641>
_______________________________________

From report at bugs.python.org  Mon Dec 14 18:29:03 2020
From: report at bugs.python.org (Justin)
Date: Mon, 14 Dec 2020 23:29:03 +0000
Subject: [issue42640] tkinter throws exception when key is pressed
In-Reply-To: <1607970157.48.0.157059469848.issue42640@roundup.psfhosted.org>
Message-ID: <1607988543.07.0.127252275735.issue42640@roundup.psfhosted.org>


Justin <justin.a.black at gmail.com> added the comment:

Thanks for responding so quickly.
1. My python version is:
Python 3.8.6 (default, Oct  8 2020, 14:07:53) 
[Clang 11.0.0 (clang-1100.0.33.17)] on darwin
2. N/A
3. >>> from tkinter.test.support import *
>>> get_tk_patchlevel()
(8, 5, 9, 'final', 0)
4. No; the pygame sample does not crash with this key input

Which version of TK 8.5.X fixes this, 8.5.18.0? That's what it looks like here: https://www.python.org/download/mac/tcltk/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42640>
_______________________________________

From report at bugs.python.org  Mon Dec 14 18:28:56 2020
From: report at bugs.python.org (Ivo Shipkaliev)
Date: Mon, 14 Dec 2020 23:28:56 +0000
Subject: [issue42630] Variable.__init__ raises obscure AttributeError
In-Reply-To: <1607901840.62.0.626631020476.issue42630@roundup.psfhosted.org>
Message-ID: <1607988536.62.0.406347849418.issue42630@roundup.psfhosted.org>


Ivo Shipkaliev <ivo.shipkaliev at gmail.com> added the comment:

"Attached is a diff which ..." -- Much nicer!

Are you gonna submit a PR so I can eventually use _setup_master() in my PR?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42630>
_______________________________________

From report at bugs.python.org  Mon Dec 14 18:29:29 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Dec 2020 23:29:29 +0000
Subject: [issue42641] Deprecate os.popen() function
In-Reply-To: <1607986363.29.0.33477455927.issue42641@roundup.psfhosted.org>
Message-ID: <1607988569.42.0.994371709457.issue42641@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

About shell injection, subprocess.getstatusoutput() uses subprocess.Popen(shell=True).
https://docs.python.org/dev/library/subprocess.html#subprocess.getstatusoutput

It's done on purpose: "Execute the string cmd in a shell with Popen.check_output()".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42641>
_______________________________________

From report at bugs.python.org  Mon Dec 14 18:32:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Dec 2020 23:32:06 +0000
Subject: [issue42591] Method Py_FrozenMain missing in libpython3.9
In-Reply-To: <1607356833.89.0.498069278584.issue42591@roundup.psfhosted.org>
Message-ID: <1607988726.85.0.623361381177.issue42591@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 6b2ed385094839c1920b934f07d946bf049a3770 by Victor Stinner in branch '3.9':
bpo-42591: Export missing Py_FrozenMain() symbol (GH-23730) (GH-23734)
https://github.com/python/cpython/commit/6b2ed385094839c1920b934f07d946bf049a3770


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42591>
_______________________________________

From report at bugs.python.org  Mon Dec 14 18:32:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Dec 2020 23:32:18 +0000
Subject: [issue42591] Method Py_FrozenMain missing in libpython3.9
In-Reply-To: <1607356833.89.0.498069278584.issue42591@roundup.psfhosted.org>
Message-ID: <1607988738.98.0.494803960937.issue42591@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks Christian Bachmaier for the bug report, it's now fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42591>
_______________________________________

From report at bugs.python.org  Mon Dec 14 18:33:30 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 14 Dec 2020 23:33:30 +0000
Subject: [issue42591] Method Py_FrozenMain missing in libpython3.9
In-Reply-To: <1607356833.89.0.498069278584.issue42591@roundup.psfhosted.org>
Message-ID: <1607988810.18.0.463171140466.issue42591@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42591>
_______________________________________

From report at bugs.python.org  Mon Dec 14 18:35:53 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Mon, 14 Dec 2020 23:35:53 +0000
Subject: [issue42577] Unhelpful syntax error when expression spans multiple
 lines
In-Reply-To: <1607181038.72.0.910363231446.issue42577@roundup.psfhosted.org>
Message-ID: <1607988953.45.0.371726057207.issue42577@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

Thanks for opening an issue here, Christoph. This is the right place to discuss this.

Indeed the parser is pretty dumb when reporting errors. In the technical sense the colon is the right thing to point to, since it's the first token that's not grammatically correct. Of course, it's somewhat misleading that it points to a line that *seems* correct, but that probably as good as we can do with the parser's current error reporting mechanisms.

Showing more that one lines would indeed solve this specific case, but implementing this is also difficult and I don't think it's worth it for such an edge case.

Guido, Pablo, your views on this?

----------
nosy: +gvanrossum, lys.nikolaou, pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42577>
_______________________________________

From report at bugs.python.org  Mon Dec 14 18:57:11 2020
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 14 Dec 2020 23:57:11 +0000
Subject: [issue42517] Enum: do not convert private names into members
In-Reply-To: <1606774653.87.0.704564487827.issue42517@roundup.psfhosted.org>
Message-ID: <1607990231.69.0.416829256049.issue42517@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset aba12b67c18b17bb727a0d50dd0653e38cb64dc8 by Miss Islington (bot) in branch '3.9':
[3.9] bpo-42517: [Enum] deprecate private name members (GH-23722) (GH-23748)
https://github.com/python/cpython/commit/aba12b67c18b17bb727a0d50dd0653e38cb64dc8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42517>
_______________________________________

From report at bugs.python.org  Mon Dec 14 18:58:05 2020
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 14 Dec 2020 23:58:05 +0000
Subject: [issue42517] Enum: do not convert private names into members
In-Reply-To: <1606774653.87.0.704564487827.issue42517@roundup.psfhosted.org>
Message-ID: <1607990285.92.0.967008218179.issue42517@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42517>
_______________________________________

From report at bugs.python.org  Mon Dec 14 18:58:57 2020
From: report at bugs.python.org (Karl Nelson)
Date: Mon, 14 Dec 2020 23:58:57 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1607990337.97.0.337444343465.issue42529@roundup.psfhosted.org>


Karl Nelson <nelson85 at llnl.gov> added the comment:

Any progress on this item?  I am seeing additional reports of this error in the conda stream tracker and elsewhere.  As it only occurs when the debugger is not hooked up I don't have much traction to make progress myself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Mon Dec 14 18:59:07 2020
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 14 Dec 2020 23:59:07 +0000
Subject: [issue40084] HTTPStatus has incomplete dir() listing
In-Reply-To: <1585293405.13.0.478935860244.issue40084@roundup.psfhosted.org>
Message-ID: <1607990347.57.0.0978331835476.issue40084@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40084>
_______________________________________

From report at bugs.python.org  Mon Dec 14 19:08:30 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Tue, 15 Dec 2020 00:08:30 +0000
Subject: [issue42059] TypedDict(...) as function does not respect "total" when
 setting __required_keys__ and __optional_keys__
In-Reply-To: <1602926609.93.0.947551036861.issue42059@roundup.psfhosted.org>
Message-ID: <1607990910.52.0.529838951604.issue42059@roundup.psfhosted.org>


Change by Brandt Bucher <brandtbucher at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42059>
_______________________________________

From report at bugs.python.org  Mon Dec 14 19:13:09 2020
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 15 Dec 2020 00:13:09 +0000
Subject: [issue42567] Enum: manually call __init_subclass__ after members are
 added
In-Reply-To: <1607093463.71.0.994675423727.issue42567@roundup.psfhosted.org>
Message-ID: <1607991189.45.0.180290584127.issue42567@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
pull_requests: +22628
stage: backport needed -> patch review
pull_request: https://github.com/python/cpython/pull/23772

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42567>
_______________________________________

From report at bugs.python.org  Mon Dec 14 20:16:10 2020
From: report at bugs.python.org (Ned Deily)
Date: Tue, 15 Dec 2020 01:16:10 +0000
Subject: [issue42640] tkinter throws exception when key is pressed
In-Reply-To: <1607970157.48.0.157059469848.issue42640@roundup.psfhosted.org>
Message-ID: <1607994970.27.0.258286862785.issue42640@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

> Which version of TK 8.5.X fixes this, 8.5.18.0?

Yes, that version of Tk 8.5 does not have this problem. But Tk 8.5 is no longer supported by the Tcl project; we recommend the use of Tk 8.6. In general, you usually cannot just swap Tk versions; the Python instance you are using needs to be built with the right versions of Tcl and Tk. You should check with the provider of the Python you are using and get a more current Python that uses a current version of Tcl and Tk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42640>
_______________________________________

From report at bugs.python.org  Mon Dec 14 21:20:21 2020
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 15 Dec 2020 02:20:21 +0000
Subject: [issue42642] logging: add high priority log level for warnings being
 cleared
Message-ID: <1607998821.36.0.619520119815.issue42642@roundup.psfhosted.org>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

When using the logging module for long running services, there's one limitation of the predefined logging levels that I semi-regularly run into: the only entirely reliable log level for reporting that a WARNING state has been cleared is itself WARNING.

Using INFO instead means that it is common to get error logs that show warning states being entered without any matching "error cleared" notification.

My idea for resolving this would be to define a new ESSENTIAL log level between WARNING and ERROR. The idea of the new log level would be to have a logged-by-default level for non-fault-but-essential messages like:

* service startup (including version info)
* service shutdown
* warnings being cleared

(NOTICE would be another possible name for such a level)

----------
messages: 383027
nosy: ncoghlan, vinay.sajip
priority: low
severity: normal
stage: needs patch
status: open
title: logging: add high priority log level for warnings being cleared
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42642>
_______________________________________

From report at bugs.python.org  Mon Dec 14 21:24:06 2020
From: report at bugs.python.org (Decorater)
Date: Tue, 15 Dec 2020 02:24:06 +0000
Subject: [issue42643] http.server does not support HTTP range requests
Message-ID: <1607999046.16.0.658504644018.issue42643@roundup.psfhosted.org>


New submission from Decorater <seandhunt_7 at yahoo.com>:

I have issues with range requests on http.server module (ran from python -m http.server command)

When requesting files to download from an program written in C (which uses range requests to update an progress bar) it ignores this and simply forces download of the entire thing at once) which in turn on my program makes the progress bar never update to display the progress of the download to the user.

https://tools.ietf.org/id/draft-ietf-httpbis-p5-range-09.html#range.units

It is a part from HTTP/1.1, I think this would be something good to actually have to support partial requests (if they request an range in the header of their request), for directory listings (which can be used to download files from), it could be considered helpful it be able to request specific byte ranges inside of the files to download at a time to split up bandwidth to not overwhelm an file server.

----------
components: Library (Lib)
messages: 383028
nosy: Decorater
priority: normal
severity: normal
status: open
title: http.server does not support HTTP range requests
type: enhancement
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42643>
_______________________________________

From report at bugs.python.org  Mon Dec 14 21:28:47 2020
From: report at bugs.python.org (Decorater)
Date: Tue, 15 Dec 2020 02:28:47 +0000
Subject: [issue42643] http.server does not support HTTP range requests
In-Reply-To: <1607999046.16.0.658504644018.issue42643@roundup.psfhosted.org>
Message-ID: <1607999327.59.0.272820016951.issue42643@roundup.psfhosted.org>


Decorater <seandhunt_7 at yahoo.com> added the comment:

It seems there are some packages that supports the range requests too:

https://github.com/danvk/RangeHTTPServer

Not sure if that supports python 3 or not. It could be used to make a patch for http.server though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42643>
_______________________________________

From report at bugs.python.org  Mon Dec 14 21:41:45 2020
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 15 Dec 2020 02:41:45 +0000
Subject: [issue42567] Enum: manually call __init_subclass__ after members are
 added
In-Reply-To: <1607093463.71.0.994675423727.issue42567@roundup.psfhosted.org>
Message-ID: <1608000105.56.0.603396842877.issue42567@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset 9d1fff1fcd5332f0ba7f72d0e0f9f66b47ec4e8d by Ethan Furman in branch '3.9':
[3.9] bpo-42567: [Enum] call __init_subclass__ after members are added (GH-23714) (GH-23772)
https://github.com/python/cpython/commit/9d1fff1fcd5332f0ba7f72d0e0f9f66b47ec4e8d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42567>
_______________________________________

From report at bugs.python.org  Mon Dec 14 23:03:27 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 15 Dec 2020 04:03:27 +0000
Subject: [issue33610] IDLE: Make multiple improvements to CodeContext
In-Reply-To: <1527052692.02.0.682650639539.issue33610@psf.upfronthosting.co.za>
Message-ID: <1608005007.11.0.776798892044.issue33610@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

E4. Max context lines = 0 is treated as infinity.  For depth 0, "self.info[-self.context_depth:]" is whole slice.  I don't remember if this is intended (if one does not want context, don't toggle it on), but it is not documented in settings help or doc section.  In any case,
  offset = max(1, lines - self.context_depth) - 1
fails with depth 0.

E5. test_codecontext is affected by user customization, but should not be.

E6. Bad bug make CC useless.  See #42638.

----------
dependencies: +IDLE: Context lines not working correctly
versions: +Python 3.10 -Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33610>
_______________________________________

From report at bugs.python.org  Mon Dec 14 23:15:45 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 15 Dec 2020 04:15:45 +0000
Subject: [issue42638] IDLE: Context lines not working correctly
In-Reply-To: <1607945394.59.0.0452931693477.issue42638@roundup.psfhosted.org>
Message-ID: <1608005745.67.0.532577636531.issue42638@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This is a false report due to a brain glitch.

----------
resolution:  -> not a bug
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42638>
_______________________________________

From report at bugs.python.org  Mon Dec 14 23:17:35 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 15 Dec 2020 04:17:35 +0000
Subject: [issue33610] IDLE: Make multiple improvements to CodeContext
In-Reply-To: <1527052692.02.0.682650639539.issue33610@psf.upfronthosting.co.za>
Message-ID: <1608005855.38.0.455763047238.issue33610@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Delete E6.  No bug.  I do have a couple of internal edits.

----------
dependencies:  -IDLE: Context lines not working correctly

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33610>
_______________________________________

From report at bugs.python.org  Mon Dec 14 23:21:01 2020
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 15 Dec 2020 04:21:01 +0000
Subject: [issue42115] Caching infrastructure for the evaluation loop:
 specialised opcodes
In-Reply-To: <1603336898.74.0.366564812208.issue42115@roundup.psfhosted.org>
Message-ID: <1608006061.69.0.93712235293.issue42115@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

pidigits and regex_v8 are LOAD_ATTR heavy benchmarks?
I will run benchmarks in my machine to confirm the results.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42115>
_______________________________________

From report at bugs.python.org  Mon Dec 14 23:29:51 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 15 Dec 2020 04:29:51 +0000
Subject: [issue33610] IDLE: Make multiple improvements to CodeContext
In-Reply-To: <1527052692.02.0.682650639539.issue33610@psf.upfronthosting.co.za>
Message-ID: <1608006591.03.0.355065423512.issue33610@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
pull_requests: +22629
pull_request: https://github.com/python/cpython/pull/23773

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33610>
_______________________________________

From report at bugs.python.org  Mon Dec 14 23:43:44 2020
From: report at bugs.python.org (hai shi)
Date: Tue, 15 Dec 2020 04:43:44 +0000
Subject: [issue42639] Make atexit state per interpreter
In-Reply-To: <1607947233.16.0.810683660249.issue42639@roundup.psfhosted.org>
Message-ID: <1608007424.44.0.0842781267737.issue42639@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
nosy: +shihai1991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42639>
_______________________________________

From report at bugs.python.org  Tue Dec 15 00:03:53 2020
From: report at bugs.python.org (dimitri.wei)
Date: Tue, 15 Dec 2020 05:03:53 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1608008633.73.0.78663787537.issue31904@roundup.psfhosted.org>


Change by dimitri.wei <dimitri.wei.lingfeng at gmail.com>:


----------
nosy:  -wlf100220

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Tue Dec 15 00:07:19 2020
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 15 Dec 2020 05:07:19 +0000
Subject: [issue42567] Enum: manually call __init_subclass__ after members are
 added
In-Reply-To: <1607093463.71.0.994675423727.issue42567@roundup.psfhosted.org>
Message-ID: <1608008839.74.0.889331119616.issue42567@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42567>
_______________________________________

From report at bugs.python.org  Tue Dec 15 00:24:10 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 15 Dec 2020 05:24:10 +0000
Subject: [issue33610] IDLE: Make multiple improvements to CodeContext
In-Reply-To: <1527052692.02.0.682650639539.issue33610@psf.upfronthosting.co.za>
Message-ID: <1608009850.27.0.343937227788.issue33610@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 6f79e60b66dacefca147bdaa80eb37f936a72991 by Terry Jan Reedy in branch 'master':
bpo-33610: Edit idlelib.codecontext (GH-23773)
https://github.com/python/cpython/commit/6f79e60b66dacefca147bdaa80eb37f936a72991


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33610>
_______________________________________

From report at bugs.python.org  Tue Dec 15 00:24:24 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Dec 2020 05:24:24 +0000
Subject: [issue33610] IDLE: Make multiple improvements to CodeContext
In-Reply-To: <1527052692.02.0.682650639539.issue33610@psf.upfronthosting.co.za>
Message-ID: <1608009864.32.0.489429783056.issue33610@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22630
pull_request: https://github.com/python/cpython/pull/23774

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33610>
_______________________________________

From report at bugs.python.org  Tue Dec 15 00:25:37 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Dec 2020 05:25:37 +0000
Subject: [issue33610] IDLE: Make multiple improvements to CodeContext
In-Reply-To: <1527052692.02.0.682650639539.issue33610@psf.upfronthosting.co.za>
Message-ID: <1608009937.76.0.664707904844.issue33610@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22631
pull_request: https://github.com/python/cpython/pull/23775

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33610>
_______________________________________

From report at bugs.python.org  Tue Dec 15 00:45:52 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Dec 2020 05:45:52 +0000
Subject: [issue33610] IDLE: Make multiple improvements to CodeContext
In-Reply-To: <1527052692.02.0.682650639539.issue33610@psf.upfronthosting.co.za>
Message-ID: <1608011152.14.0.146901155949.issue33610@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 925f9987866703b0e7cfde341d23f19b832603cb by Miss Islington (bot) in branch '3.8':
bpo-33610: Edit idlelib.codecontext (GH-23773)
https://github.com/python/cpython/commit/925f9987866703b0e7cfde341d23f19b832603cb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33610>
_______________________________________

From report at bugs.python.org  Tue Dec 15 02:45:48 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Dec 2020 07:45:48 +0000
Subject: [issue42641] Deprecate os.popen() function
In-Reply-To: <1607986363.29.0.33477455927.issue42641@roundup.psfhosted.org>
Message-ID: <1608018348.49.0.658177511896.issue42641@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Searching os.popen in code on GitHub gives around 4.5 millions of results. Seems that most of them are with literal strings which are very specific to the program, like

    check2 = os.popen('grep "net\.ipv4\.ip_forward" /etc/sysctl.conf /etc/sysctl.d/*').read()

They are not vulnerable to shell injection and other drawbacks of os.popen do not matter in that cases. Most of that code looks like specialized scripts rather than parts of general libraries.

Yes, some examples can be vulnerable to shell injection (although in they use cases, with restricted data and environment, they can be pretty safe). But deprecating os.popen can break millions of scripts and cause more harm than prevent bugs.

It may be better strategy to document drawbacks and limitations of os.popen and advertise alternatives.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42641>
_______________________________________

From report at bugs.python.org  Tue Dec 15 02:55:31 2020
From: report at bugs.python.org (Peixing Xin)
Date: Tue, 15 Dec 2020 07:55:31 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1608018931.89.0.30862015646.issue31904@roundup.psfhosted.org>


Change by Peixing Xin <peixing.xin at windriver.com>:


----------
pull_requests: +22632
pull_request: https://github.com/python/cpython/pull/23776

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Tue Dec 15 03:09:48 2020
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 15 Dec 2020 08:09:48 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1608019788.15.0.557696512169.issue31904@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
nosy:  -methane

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Tue Dec 15 03:20:47 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Dec 2020 08:20:47 +0000
Subject: [issue35332] shutil.rmtree(...,
 ignore_errors=True) doesn't ignore errors from os.close()
In-Reply-To: <1543348313.91.0.788709270274.issue35332@psf.upfronthosting.co.za>
Message-ID: <1608020447.22.0.855479038181.issue35332@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I am wondering whether we should silence that error in os.close() unconditionally.

In what circumstances the error is raised? Can it be reproduced on Linux (by monkey-patching os.rmdir)? What can happen in worst case when the error is ignored?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35332>
_______________________________________

From report at bugs.python.org  Tue Dec 15 04:44:41 2020
From: report at bugs.python.org (Martin Natano)
Date: Tue, 15 Dec 2020 09:44:41 +0000
Subject: [issue42636] shielded task exception never retrieved when outer task
 cancelled
In-Reply-To: <1607942181.31.0.646688674125.issue42636@roundup.psfhosted.org>
Message-ID: <1608025481.57.0.40271837711.issue42636@roundup.psfhosted.org>


Martin Natano <natano+pythonbugs at natano.net> added the comment:

How would calling `outer.exception()` suppress the message? This happens when the outer task is cancelled while the inner task is still running. In that case the exception is never set on outer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42636>
_______________________________________

From report at bugs.python.org  Tue Dec 15 05:00:46 2020
From: report at bugs.python.org (OverLordGoldDragon)
Date: Tue, 15 Dec 2020 10:00:46 +0000
Subject: [issue42644] logging.disable('WARN') breaks AsyncIO
Message-ID: <1608026446.25.0.329181114873.issue42644@roundup.psfhosted.org>


New submission from OverLordGoldDragon <OverLordGoldDragon at yahoo.com>:

import logging
with logging.disable('WARN'): pass

See: https://github.com/ipython/ipython/issues/12713
I'm not actually sure what's happening here, just reporting.

----------
components: asyncio
messages: 383040
nosy: OverLordGoldDragon, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: logging.disable('WARN') breaks AsyncIO
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42644>
_______________________________________

From report at bugs.python.org  Tue Dec 15 05:08:02 2020
From: report at bugs.python.org (E. Paine)
Date: Tue, 15 Dec 2020 10:08:02 +0000
Subject: [issue42630] Variable.__init__ raises obscure AttributeError
In-Reply-To: <1607901840.62.0.626631020476.issue42630@roundup.psfhosted.org>
Message-ID: <1608026882.5.0.817512309228.issue42630@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

> Are you gonna submit a PR

I think I assumed you would incorporate it into your PR unless you would prefer it to be separate?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42630>
_______________________________________

From report at bugs.python.org  Tue Dec 15 06:07:59 2020
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 15 Dec 2020 11:07:59 +0000
Subject: [issue42246] Implement PEP 626 -- Precise line numbers for debugging
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1608030479.67.0.883669315937.issue42246@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset 8473cf89bdbf2cb292b39c972db540504669b9cd by Mark Shannon in branch 'master':
bpo-42246: Remove DO_NOT_EMIT_BYTECODE macros, so that while loops and if statements conform to PEP 626. (GH-23743)
https://github.com/python/cpython/commit/8473cf89bdbf2cb292b39c972db540504669b9cd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42246>
_______________________________________

From report at bugs.python.org  Tue Dec 15 06:10:48 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Dec 2020 11:10:48 +0000
Subject: [issue42630] Variable.__init__ raises obscure AttributeError
In-Reply-To: <1607901840.62.0.626631020476.issue42630@roundup.psfhosted.org>
Message-ID: <1608030648.22.0.756787307596.issue42630@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Don't haste. I am currently working on a large PR with many tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42630>
_______________________________________

From report at bugs.python.org  Tue Dec 15 07:06:48 2020
From: report at bugs.python.org (M. Eric Irrgang)
Date: Tue, 15 Dec 2020 12:06:48 +0000
Subject: [issue35083] Fix documentation for __instancecheck__
In-Reply-To: <1540671281.62.0.788709270274.issue35083@psf.upfronthosting.co.za>
Message-ID: <1608034008.85.0.216552194537.issue35083@roundup.psfhosted.org>


Change by M. Eric Irrgang <ericirrgang at gmail.com>:


----------
nosy: +eirrgang

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35083>
_______________________________________

From report at bugs.python.org  Tue Dec 15 07:21:32 2020
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 15 Dec 2020 12:21:32 +0000
Subject: [issue42645] break/continue or return in finally block occurs twice
 in trace.
Message-ID: <1608034892.59.0.529132946554.issue42645@roundup.psfhosted.org>


New submission from Mark Shannon <mark at hotpy.org>:

This function

def f():
     try:
         return 2
     finally:
         4

would generate a try of [1, 2, 4, 2].  It should generate [1, 2, 4]
and not trace the return twice.

----------
assignee: Mark.Shannon
messages: 383044
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
stage: needs patch
status: open
title: break/continue or return in finally block occurs twice in trace.
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42645>
_______________________________________

From report at bugs.python.org  Tue Dec 15 07:27:44 2020
From: report at bugs.python.org (Baptiste Mispelon)
Date: Tue, 15 Dec 2020 12:27:44 +0000
Subject: [issue24416] Have date.isocalendar() return a structseq instance
In-Reply-To: <1433853440.83.0.506944331138.issue24416@psf.upfronthosting.co.za>
Message-ID: <1608035264.91.0.979170496134.issue24416@roundup.psfhosted.org>


Baptiste Mispelon <bmispelon at gmail.com> added the comment:

(Apologies if this isn't the right place and/or time for this kind of negative feedback. I'm open to suggestions for a more appropriate venue)

I found it disheartening that my work on this ticket has been erased.

While I understand that other contributors have worked a lot more on this than I have, I did put in a non-negligible amount of work into this ticket.
>From creating the original issue to taking a first stab at writing a patch (including several rounds of back and forth with core developers).

It would have been nice to have been credited in the commit message for example.

As-is, it gives me the impression that the only things this project values are pure code contributions.

I couldn't find documentation about how this projects credits contributors.
If it's standard practice not to credit non-code contributions or non-merged code contributions then I humbly suggest you reconsider this practice.
>From my perspective it really discourages me from making further contributions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24416>
_______________________________________

From report at bugs.python.org  Tue Dec 15 07:42:41 2020
From: report at bugs.python.org (M. Eric Irrgang)
Date: Tue, 15 Dec 2020 12:42:41 +0000
Subject: [issue35083] Fix documentation for __instancecheck__
In-Reply-To: <1540671281.62.0.788709270274.issue35083@psf.upfronthosting.co.za>
Message-ID: <1608036161.34.0.2599287278.issue35083@roundup.psfhosted.org>


M. Eric Irrgang <ericirrgang at gmail.com> added the comment:

The optimization appears to have been made without this level of discussion. The change to PEP 3119 was likely overlooked. The intended PEP 3119 behavior seems clear and reasonable.

r61575 was a small part of the SVN merge that became git commit d5e2b6f3bcef9fea744bef331ad7278052223f11

Suggest reverting the `/* Quick test for an exact match */`.

If either the optimization is important, or the documented PEP 3119 behavior should be revised, suggest re-raising the issue as a proposed revision to PEP 3119.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35083>
_______________________________________

From report at bugs.python.org  Tue Dec 15 07:51:27 2020
From: report at bugs.python.org (nhamid)
Date: Tue, 15 Dec 2020 12:51:27 +0000
Subject: [issue42116] Inspect library ignore comments at the end of a function
 (inspect.getsource)
In-Reply-To: <1603363723.99.0.873580527867.issue42116@roundup.psfhosted.org>
Message-ID: <1608036687.91.0.534084596238.issue42116@roundup.psfhosted.org>


nhamid <noureddine.hamid at usmba.ac.ma> added the comment:

thank you for the fix, I forgot to mention that python 3.6 and python 3.7 have this issue too.

----------
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42116>
_______________________________________

From report at bugs.python.org  Tue Dec 15 07:52:04 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 15 Dec 2020 12:52:04 +0000
Subject: [issue33610] IDLE: Make multiple improvements to CodeContext
In-Reply-To: <1527052692.02.0.682650639539.issue33610@psf.upfronthosting.co.za>
Message-ID: <1608036724.36.0.980813657987.issue33610@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:


New changeset 99d37a0ee82c16f30a874c9b583d59a3844dc9c9 by Miss Islington (bot) in branch '3.9':
bpo-33610: Edit idlelib.codecontext (GH-23773) (GH-23775)
https://github.com/python/cpython/commit/99d37a0ee82c16f30a874c9b583d59a3844dc9c9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33610>
_______________________________________

From report at bugs.python.org  Tue Dec 15 08:05:06 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 15 Dec 2020 13:05:06 +0000
Subject: [issue42577] Unhelpful syntax error when expression spans multiple
 lines
In-Reply-To: <1607181038.72.0.910363231446.issue42577@roundup.psfhosted.org>
Message-ID: <1608037506.44.0.443713247309.issue42577@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I concur, handling also multi-line constructs is tricky and I would prefer not to implement some hack for specific situations because my experience is that balancing that with other things Is tricky. As Lysandros mentioned, the parser reports correctly the location of the error as indentation is non important inside parentheses and the code there could be an expression or the begging of a generator.

On the other hand we could think if we have a way of detecting of a syntax error occurs in the context of an unclosed parentheses and maybe do something about it, but I have no idea still how many false negatives could appear.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42577>
_______________________________________

From report at bugs.python.org  Tue Dec 15 08:05:41 2020
From: report at bugs.python.org (Wendy Reynolds)
Date: Tue, 15 Dec 2020 13:05:41 +0000
Subject: [issue42042] sphinx3 renders diffrently docs.python.org for 3.10
In-Reply-To: <1602763041.43.0.432643801896.issue42042@roundup.psfhosted.org>
Message-ID: <1608037541.04.0.149494937989.issue42042@roundup.psfhosted.org>


Change by Wendy Reynolds <reynoldsw347 at gmail.com>:


----------
type:  -> performance
Added file: https://bugs.python.org/file49682/python-391.html

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42042>
_______________________________________

From report at bugs.python.org  Tue Dec 15 08:07:08 2020
From: report at bugs.python.org (wyz23x2)
Date: Tue, 15 Dec 2020 13:07:08 +0000
Subject: [issue42646] Add function that supports "applying" methods
Message-ID: <1608037628.46.0.38282222902.issue42646@roundup.psfhosted.org>


New submission from wyz23x2 <wyz23x2 at 163.com>:

Doing this is generally very annoying:
y = x.copy()
y.some_method()
Sometimes x doesn't have copy(), so:
from copy import deepcopy
y = deepcopy(x)
y.some_method()

So maybe a function could be added to help.
For example:

def apply(obj, function, /, args=(), kwargs={}):
    try:
        new = obj.copy()
    except AttributeError:
        from copy import copy
        new = copy(obj)
    function(new, *args, **kwargs)
    return new
# implement reversed() for list
lis = [1, 2, 3, 4, 5]
arr = apply(lis, list.reverse)
print(arr)  # [5, 4, 3, 2, 1]

apply() maybe isn't the best name because of the builtin apply() in Python 2, but that's EOL. It could be added in the standard library.

----------
components: Library (Lib)
messages: 383050
nosy: wyz23x2
priority: normal
severity: normal
status: open
title: Add function that supports "applying" methods
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42646>
_______________________________________

From report at bugs.python.org  Tue Dec 15 08:08:54 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 15 Dec 2020 13:08:54 +0000
Subject: [issue42115] Caching infrastructure for the evaluation loop:
 specialised opcodes
In-Reply-To: <1603336898.74.0.366564812208.issue42115@roundup.psfhosted.org>
Message-ID: <1608037734.35.0.914216195252.issue42115@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> pidigits and regex_v8 are LOAD_ATTR heavy benchmarks?

The PR is for LOAD_METHOD infrastructure, not for LOAD_ATTR (There was an incorrect title in the PR that I corrected but the contents are correct).

> I will run benchmarks in my machine to confirm the results.

Thanks a lot, Inada-san

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42115>
_______________________________________

From report at bugs.python.org  Tue Dec 15 08:09:21 2020
From: report at bugs.python.org (wyz23x2)
Date: Tue, 15 Dec 2020 13:09:21 +0000
Subject: [issue42646] Add function that supports "applying" methods
In-Reply-To: <1608037628.46.0.38282222902.issue42646@roundup.psfhosted.org>
Message-ID: <1608037761.44.0.957568305909.issue42646@roundup.psfhosted.org>


wyz23x2 <wyz23x2 at 163.com> added the comment:

Edit: applied should be the better name because of reversed(), sorted() etc. and doesn't conflict with Py 2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42646>
_______________________________________

From report at bugs.python.org  Tue Dec 15 08:19:31 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 15 Dec 2020 13:19:31 +0000
Subject: [issue42644] logging.disable('WARN') breaks AsyncIO
In-Reply-To: <1608026446.25.0.329181114873.issue42644@roundup.psfhosted.org>
Message-ID: <1608038371.73.0.465482540874.issue42644@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

Reporting what? Please elaborate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42644>
_______________________________________

From report at bugs.python.org  Tue Dec 15 08:21:15 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 15 Dec 2020 13:21:15 +0000
Subject: [issue42116] Inspect library ignore comments at the end of a function
 (inspect.getsource)
In-Reply-To: <1603363723.99.0.873580527867.issue42116@roundup.psfhosted.org>
Message-ID: <1608038475.95.0.46615052749.issue42116@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

Thanks for the report. 3.6 is no longer maintained and 3.7 is getting security fixes only. So this won't be backported to those versions.

----------
versions:  -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42116>
_______________________________________

From report at bugs.python.org  Tue Dec 15 08:34:50 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Dec 2020 13:34:50 +0000
Subject: [issue42639] Make atexit state per interpreter
In-Reply-To: <1607947233.16.0.810683660249.issue42639@roundup.psfhosted.org>
Message-ID: <1608039290.23.0.903064342686.issue42639@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b8fa135908d294b350cdad04e2f512327a538dee by Victor Stinner in branch 'master':
bpo-42639: Move atexit state to PyInterpreterState (GH-23763)
https://github.com/python/cpython/commit/b8fa135908d294b350cdad04e2f512327a538dee


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42639>
_______________________________________

From report at bugs.python.org  Tue Dec 15 08:37:52 2020
From: report at bugs.python.org (OverLordGoldDragon)
Date: Tue, 15 Dec 2020 13:37:52 +0000
Subject: [issue42644] logging.disable('WARN') breaks AsyncIO
In-Reply-To: <1608026446.25.0.329181114873.issue42644@roundup.psfhosted.org>
Message-ID: <1608039472.79.0.150968655416.issue42644@roundup.psfhosted.org>


OverLordGoldDragon <OverLordGoldDragon at yahoo.com> added the comment:

Everything's in the linked issue; in summary, the command kills IPython, and an IPython maintainer showed code suggesting the problem's rooted in CPython's improper handling of 'WARN' as alias for logging.WARN.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42644>
_______________________________________

From report at bugs.python.org  Tue Dec 15 08:52:24 2020
From: report at bugs.python.org (M. Eric Irrgang)
Date: Tue, 15 Dec 2020 13:52:24 +0000
Subject: [issue35083] Fix documentation for __instancecheck__
In-Reply-To: <1540671281.62.0.788709270274.issue35083@psf.upfronthosting.co.za>
Message-ID: <1608040344.48.0.435063132353.issue35083@roundup.psfhosted.org>


M. Eric Irrgang <ericirrgang at gmail.com> added the comment:

Actually, it looks like performance concerns were raised as issues [2303](https://bugs.python.org/issue2303) and [2534](https://bugs.python.org/issue2534). For #2534, the issue was different.

For issue #2303, behavior-changing optimization was proposed. The first comment describes the cost of requiring a check to whether `__instancecheck__` is present (though I don't see what the comment refers to in 1b7f891f416830d0c46ca1c9e1bfe62f05cda655, which is the commit containing the cited r58099, as best I can tell). However, the discussion may have ended prematurely when the optimization https://bugs.python.org/file9742/isinst.diff slipped in through a different change.

See https://bugs.python.org/issue2303 for discussion.

For what it's worth, Guido (author of PEP 3119) did not seem to object to https://codereview.appspot.com/504/diff/1/Objects/abstract.c and no one seems to have discussed the apparent inconsistency with PEP 3119.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35083>
_______________________________________

From report at bugs.python.org  Tue Dec 15 08:59:10 2020
From: report at bugs.python.org (Julien Danjou)
Date: Tue, 15 Dec 2020 13:59:10 +0000
Subject: [issue42647] Unable to use concurrent.futures in atexit hook
Message-ID: <1608040750.56.0.960217977665.issue42647@roundup.psfhosted.org>


New submission from Julien Danjou <julien at danjou.info>:

Python 3.9 introduced a regression with concurrent.futures. The following program works fine on Python < 3.8 but raises an error on 3.9:

```
import atexit
import concurrent.futures

def spawn():
    with concurrent.futures.ThreadPoolExecutor() as t:
        pass

atexit.register(spawn)
```

```
$ python3.9 rep.py
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 790, in exec_module
  File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
  File "/usr/local/Cellar/python at 3.9/3.9.0_3/Frameworks/Python.framework/Versions/3.9/lib/python3.9/concurrent/futures/thread.py", line 37, in <module>
    threading._register_atexit(_python_exit)
  File "/usr/local/Cellar/python at 3.9/3.9.0_3/Frameworks/Python.framework/Versions/3.9/lib/python3.9/threading.py", line 1370, in _register_atexit
    raise RuntimeError("can't register atexit after shutdown")
RuntimeError: can't register atexit after shutdown
```

----------
messages: 383058
nosy: jd
priority: normal
severity: normal
status: open
title: Unable to use concurrent.futures in atexit hook
type: crash
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42647>
_______________________________________

From report at bugs.python.org  Tue Dec 15 09:07:33 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 15 Dec 2020 14:07:33 +0000
Subject: [issue40600] Add option to disallow > 1 instance of an extension
 module
In-Reply-To: <1589235149.46.0.0630975096351.issue40600@roundup.psfhosted.org>
Message-ID: <1608041253.03.0.298973396429.issue40600@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

Thanks! Indeed, that's an even better solution than I had in mind.
It follows PEP 630 quite nicely: https://www.python.org/dev/peps/pep-0630/#managing-global-state

I will close this issue and PRs.
I don't agree with adding a general API for disallowing multiple modules, but do let me know if you see a need for it again.

----------
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40600>
_______________________________________

From report at bugs.python.org  Tue Dec 15 09:09:22 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Tue, 15 Dec 2020 14:09:22 +0000
Subject: [issue42639] Make atexit state per interpreter
In-Reply-To: <1607947233.16.0.810683660249.issue42639@roundup.psfhosted.org>
Message-ID: <1608041362.64.0.403889929181.issue42639@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
nosy: +corona10
nosy_count: 2.0 -> 3.0
pull_requests: +22633
pull_request: https://github.com/python/cpython/pull/23699

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42639>
_______________________________________

From report at bugs.python.org  Tue Dec 15 09:09:30 2020
From: report at bugs.python.org (hai shi)
Date: Tue, 15 Dec 2020 14:09:30 +0000
Subject: [issue42639] Make atexit state per interpreter
In-Reply-To: <1607947233.16.0.810683660249.issue42639@roundup.psfhosted.org>
Message-ID: <1608041370.97.0.056883335402.issue42639@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
pull_requests: +22634
pull_request: https://github.com/python/cpython/pull/23683

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42639>
_______________________________________

From report at bugs.python.org  Tue Dec 15 09:11:31 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Dec 2020 14:11:31 +0000
Subject: [issue42639] Make atexit state per interpreter
In-Reply-To: <1607947233.16.0.810683660249.issue42639@roundup.psfhosted.org>
Message-ID: <1608041491.23.0.41579334941.issue42639@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22635
pull_request: https://github.com/python/cpython/pull/23777

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42639>
_______________________________________

From report at bugs.python.org  Tue Dec 15 09:14:49 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 15 Dec 2020 14:14:49 +0000
Subject: [issue14935] PEP 384 Refactoring applied to _csv module
In-Reply-To: <1338222171.68.0.797250497291.issue14935@psf.upfronthosting.co.za>
Message-ID: <1608041689.8.0.0188551082643.issue14935@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:


New changeset 6a02b384751dbc13979efc1185f0a7c1670dc349 by Petr Viktorin in branch 'master':
bpo-14935: Remove static state from the _csv module (GH-23224)
https://github.com/python/cpython/commit/6a02b384751dbc13979efc1185f0a7c1670dc349


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14935>
_______________________________________

From report at bugs.python.org  Tue Dec 15 09:24:28 2020
From: report at bugs.python.org (Xavier Morel)
Date: Tue, 15 Dec 2020 14:24:28 +0000
Subject: [issue42644] logging.disable('WARN') breaks AsyncIO
In-Reply-To: <1608026446.25.0.329181114873.issue42644@roundup.psfhosted.org>
Message-ID: <1608042268.25.0.979468240569.issue42644@roundup.psfhosted.org>


Xavier Morel <xavier.morel at masklinn.net> added the comment:

The problem seems to be in the user code? As you were told by "Carreau", loggin.disable takes a logging level (an integer), since you're giving it a string which it dutifully stores, it blows up at the next logging call which happens to be in asyncio.

This is not an asyncio bug, nor is it a crash anymore than passing a broken key function to `sorted` is a *Python* crash.

At most it's an enancement request: `logging.disable` could raise a TypeError immediately or convert the value to a loglevel the way `setLevel` does instead of storing the broken value as-is (all it does currently is store the value it receives on the root logger without any check).

----------
nosy: +xmorel

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42644>
_______________________________________

From report at bugs.python.org  Tue Dec 15 09:35:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Dec 2020 14:35:34 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1608042934.04.0.877157990083.issue32381@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22636
pull_request: https://github.com/python/cpython/pull/23778

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32381>
_______________________________________

From report at bugs.python.org  Tue Dec 15 09:43:35 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Dec 2020 14:43:35 +0000
Subject: [issue40600] Add option to disallow > 1 instance of an extension
 module
In-Reply-To: <1589235149.46.0.0630975096351.issue40600@roundup.psfhosted.org>
Message-ID: <1608043415.11.0.595322720534.issue40600@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Thanks! Indeed, that's an even better solution than I had in mind.
> It follows PEP 630 quite nicely: https://www.python.org/dev/peps/pep-0630/#managing-global-state

The atexit module was my main motivation for this issue. So I'm fine with closing it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40600>
_______________________________________

From report at bugs.python.org  Tue Dec 15 09:51:28 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 15 Dec 2020 14:51:28 +0000
Subject: [issue42111] Make the xxlimited module an example of best extension
 module practices
In-Reply-To: <1603310336.9.0.27411366123.issue42111@roundup.psfhosted.org>
Message-ID: <1608043888.5.0.89674331393.issue42111@roundup.psfhosted.org>


Change by Petr Viktorin <encukou at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42111>
_______________________________________

From report at bugs.python.org  Tue Dec 15 10:03:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Dec 2020 15:03:37 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1608044617.88.0.60118563008.issue32381@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

My PR 23778 fix the encoding/error handler when writing the filename into stderr, when the file does not exist:

$ LANG= PYTHONCOERCECLOCALE=0 ./python -X utf8=0 h?llo.py
./python: can't open file '/home/vstinner/python/master/h\udcc3\udca9llo.py': [Errno 2] No such file or directory

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32381>
_______________________________________

From report at bugs.python.org  Tue Dec 15 10:08:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Dec 2020 15:08:24 +0000
Subject: [issue42639] Make atexit state per interpreter
In-Reply-To: <1607947233.16.0.810683660249.issue42639@roundup.psfhosted.org>
Message-ID: <1608044904.54.0.326666527604.issue42639@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset f7049b5fb680c774e4950d10be62859a749f4e79 by Victor Stinner in branch 'master':
bpo-42639: Add script_helper.run_test_script() (GH-23777)
https://github.com/python/cpython/commit/f7049b5fb680c774e4950d10be62859a749f4e79


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42639>
_______________________________________

From report at bugs.python.org  Tue Dec 15 10:11:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Dec 2020 15:11:37 +0000
Subject: [issue42639] Make atexit state per interpreter
In-Reply-To: <1607947233.16.0.810683660249.issue42639@roundup.psfhosted.org>
Message-ID: <1608045097.75.0.433547391752.issue42639@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22637
pull_request: https://github.com/python/cpython/pull/23779

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42639>
_______________________________________

From report at bugs.python.org  Tue Dec 15 10:17:34 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 15 Dec 2020 15:17:34 +0000
Subject: [issue18710] Add PyState_GetModuleAttr
In-Reply-To: <1376311241.36.0.528101018546.issue18710@psf.upfronthosting.co.za>
Message-ID: <1608045454.1.0.192509082844.issue18710@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

Let me summarize the original issue with the following quote from the python-dev thead:

> doing some sys.modules acrobatics and re-importing suddenly
changes the internal state of a previously imported [_csv] module.

The issue is now solved; both reproducers from that thread pass.

If you're interested, please read PEP 630 for a general overview of where we're at w.r.t. C-API changes that started with PEP 3121.
For the API used to fix this issue, see PEP 573; for the specific fix in _csv, see GH-23224.

Thanks to everyone involved, and especially to Nick Coghlan for helping me start this journey way back in 2013 :)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18710>
_______________________________________

From report at bugs.python.org  Tue Dec 15 10:23:26 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 15 Dec 2020 15:23:26 +0000
Subject: [issue42646] Add function that supports "applying" methods
In-Reply-To: <1608037628.46.0.38282222902.issue42646@roundup.psfhosted.org>
Message-ID: <1608045806.75.0.368069857877.issue42646@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

This seems way too special case for the stdlib, and especially not as a builtin. I've never seen this pattern before. Why is copy so special?

I suggest raising this on the python-ideas mailing list if you'd like to get some traction for it.

----------
nosy: +eric.smith
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42646>
_______________________________________

From report at bugs.python.org  Tue Dec 15 10:25:36 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Dec 2020 15:25:36 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1608045936.03.0.67215729739.issue32381@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset ceb420251c1d635520049fbb7b5269a73d63fb58 by Victor Stinner in branch 'master':
bpo-32381: pymain_run_file() uses PySys_FormatStderr() (GH-23778)
https://github.com/python/cpython/commit/ceb420251c1d635520049fbb7b5269a73d63fb58


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32381>
_______________________________________

From report at bugs.python.org  Tue Dec 15 10:29:01 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 15 Dec 2020 15:29:01 +0000
Subject: [issue14935] PEP 384 Refactoring applied to _csv module
In-Reply-To: <1338222171.68.0.797250497291.issue14935@psf.upfronthosting.co.za>
Message-ID: <1608046141.71.0.187834416818.issue14935@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

Thank you for working on this!
It took several years and some new C-API to get it right (see PEP 630), but I believe this and the related issues bpo-18710 and bpo-34533 can now be closed.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14935>
_______________________________________

From report at bugs.python.org  Tue Dec 15 10:36:08 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 15 Dec 2020 15:36:08 +0000
Subject: [issue26515] Update extending/embedding docs to new way to build
 modules in C
In-Reply-To: <1457491421.2.0.684118231911.issue26515@psf.upfronthosting.co.za>
Message-ID: <1608046568.57.0.764433409912.issue26515@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

PEP 630 is now Active. I believe the vast majority of modules can now be ported, and it should be helpful for early adopters (including CPython stdlib). But there are still Open Issues and the API not battle-tested on all the edge cases.

The PEP is written to be easily integrated into official docs when the time comes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26515>
_______________________________________

From report at bugs.python.org  Tue Dec 15 10:40:49 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 15 Dec 2020 15:40:49 +0000
Subject: [issue42035] [C API] PyType_GetSlot cannot get tp_name
In-Reply-To: <1602683525.08.0.938781399322.issue42035@roundup.psfhosted.org>
Message-ID: <1608046849.34.0.938024500808.issue42035@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

I'll be happy to review adding a PyType_GetName function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42035>
_______________________________________

From report at bugs.python.org  Tue Dec 15 10:42:24 2020
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 15 Dec 2020 15:42:24 +0000
Subject: [issue42645] break/continue or return in finally block occurs twice
 in trace.
In-Reply-To: <1608034892.59.0.529132946554.issue42645@roundup.psfhosted.org>
Message-ID: <1608046944.87.0.326524815593.issue42645@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
keywords: +patch
pull_requests: +22638
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/23780

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42645>
_______________________________________

From report at bugs.python.org  Tue Dec 15 10:56:12 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Dec 2020 15:56:12 +0000
Subject: [issue42630] Variable.__init__ raises obscure AttributeError
In-Reply-To: <1607901840.62.0.626631020476.issue42630@roundup.psfhosted.org>
Message-ID: <1608047772.79.0.438766186787.issue42630@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +22639
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23781

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42630>
_______________________________________

From report at bugs.python.org  Tue Dec 15 11:07:46 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Dec 2020 16:07:46 +0000
Subject: [issue42328] ttk style.map function incorrectly handles the default
 state for element options.
In-Reply-To: <1605140874.05.0.0614253934034.issue42328@roundup.psfhosted.org>
Message-ID: <1608048466.06.0.518128551681.issue42328@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42328>
_______________________________________

From report at bugs.python.org  Tue Dec 15 11:12:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Dec 2020 16:12:10 +0000
Subject: [issue42639] Make atexit state per interpreter
In-Reply-To: <1607947233.16.0.810683660249.issue42639@roundup.psfhosted.org>
Message-ID: <1608048730.12.0.724795200405.issue42639@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 3ca2b8fd75043927f0bb03b8dac72d32beae255d by Victor Stinner in branch 'master':
bpo-42639: atexit._run_exitfuncs() uses sys.unraisablehook (GH-23779)
https://github.com/python/cpython/commit/3ca2b8fd75043927f0bb03b8dac72d32beae255d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42639>
_______________________________________

From report at bugs.python.org  Tue Dec 15 11:16:11 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Dec 2020 16:16:11 +0000
Subject: [issue42142] test_ttk timeout: FAIL tkinter ttk LabeledScale
 test_resize, and more
In-Reply-To: <1603582160.73.0.386671878138.issue42142@roundup.psfhosted.org>
Message-ID: <1608048971.14.0.0870486159306.issue42142@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

There should be no timeouts (because wait_visibility no longer is used in tests). The fix can introduce new failures (like in issue42507), but it is a separate issue and may be related to bugs in the implementation of Tk on macOS.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42142>
_______________________________________

From report at bugs.python.org  Tue Dec 15 11:17:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Dec 2020 16:17:11 +0000
Subject: [issue42639] Make atexit state per interpreter
In-Reply-To: <1607947233.16.0.810683660249.issue42639@roundup.psfhosted.org>
Message-ID: <1608049031.65.0.712972541181.issue42639@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Ok, the initial issue is now fixed. It's possible to have more than one atexit module instance, registered callbacks in one or the other module are all called as expected. I also wrote an unit test for that.

I also took the opportunity of this issue to modernize the C code base, fix a bug in test_atexit (no longer clear atexit callbacks, run tests in subprocesses), and enhance atexit._run_exitfuncs(): log all callback exceptions using sys.unraisablehook so it's possible to catch them using the hook.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42639>
_______________________________________

From report at bugs.python.org  Tue Dec 15 11:17:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Dec 2020 16:17:51 +0000
Subject: [issue42641] Deprecate os.popen() function
In-Reply-To: <1607986363.29.0.33477455927.issue42641@roundup.psfhosted.org>
Message-ID: <1608049071.61.0.586485970494.issue42641@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> check2 = os.popen('grep "net\.ipv4\.ip_forward" /etc/sysctl.conf /etc/sysctl.d/*').read()

Such code leaks a zombi process when the child process completes, because the parent never reads its exit status :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42641>
_______________________________________

From report at bugs.python.org  Tue Dec 15 11:22:25 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Dec 2020 16:22:25 +0000
Subject: [issue24893] Tk occasionally mispositions Text() insert cursor on
 mouse click.
In-Reply-To: <1439946374.86.0.179742145584.issue24893@psf.upfronthosting.co.za>
Message-ID: <1608049345.24.0.407574755587.issue24893@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/issue24893>
_______________________________________

From report at bugs.python.org  Tue Dec 15 11:23:10 2020
From: report at bugs.python.org (Julien Palard)
Date: Tue, 15 Dec 2020 16:23:10 +0000
Subject: [issue36675] Doctest directives and comments missing from code samples
In-Reply-To: <1555757030.56.0.8094269644.issue36675@roundup.psfhosted.org>
Message-ID: <1608049390.65.0.0391876290771.issue36675@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:


New changeset c8a10d2fabff492ab352501c316baf5f2fc6510e by Julien Palard in branch 'master':
bpo-36675: Doc: Reveal doctest directives (GH-23620)
https://github.com/python/cpython/commit/c8a10d2fabff492ab352501c316baf5f2fc6510e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36675>
_______________________________________

From report at bugs.python.org  Tue Dec 15 11:38:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Dec 2020 16:38:46 +0000
Subject: [issue42641] Deprecate os.popen() function
In-Reply-To: <1607986363.29.0.33477455927.issue42641@roundup.psfhosted.org>
Message-ID: <1608050326.34.0.581070285128.issue42641@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +22640
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23782

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42641>
_______________________________________

From report at bugs.python.org  Tue Dec 15 11:40:28 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Dec 2020 16:40:28 +0000
Subject: [issue21521] Tkinter + OSX + Spaces : Multiple file dialogues created
In-Reply-To: <1400403340.1.0.400733156313.issue21521@psf.upfronthosting.co.za>
Message-ID: <1608050428.02.0.138414558923.issue21521@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

asksaveasfilename is just a wrapper around the tk_getSaveFile Tk command which is implemented differently on Windows, macOS and X Window. The used widgets have very different appearance and behavior on different platforms, so there is no chance to test macOS issues on Windows or Linux. On Linux at least it honoures initialdir='.'.

In any case Tkinter just converts arguments and results of the Tk command. It does not affect the appearance and behavior. We cannot do anything to fix bugs in Tk.

----------
nosy: +serhiy.storchaka
resolution:  -> third party
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue21521>
_______________________________________

From report at bugs.python.org  Tue Dec 15 11:45:41 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Dec 2020 16:45:41 +0000
Subject: [issue42318] [tkinter] surrogate pairs in Tcl/Tk string when pasting
 an emoji in a text widget
In-Reply-To: <1605043338.18.0.398355808071.issue42318@roundup.psfhosted.org>
Message-ID: <1608050741.91.0.337924693194.issue42318@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Oh, the fix is not backported yet.

Automatically backporting does not work because of renames in the supporting test library.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42318>
_______________________________________

From report at bugs.python.org  Tue Dec 15 11:55:27 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Dec 2020 16:55:27 +0000
Subject: [issue42318] [tkinter] surrogate pairs in Tcl/Tk string when pasting
 an emoji in a text widget
In-Reply-To: <1605043338.18.0.398355808071.issue42318@roundup.psfhosted.org>
Message-ID: <1608051327.27.0.461915131082.issue42318@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +22641
pull_request: https://github.com/python/cpython/pull/23784

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42318>
_______________________________________

From report at bugs.python.org  Tue Dec 15 12:01:14 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Dec 2020 17:01:14 +0000
Subject: [issue19733] Setting image parameter of a button crashes with Cocoa Tk
In-Reply-To: <1385212186.78.0.599244063108.issue19733@psf.upfronthosting.co.za>
Message-ID: <1608051674.79.0.882566690485.issue19733@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +22642
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23785

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19733>
_______________________________________

From report at bugs.python.org  Tue Dec 15 12:05:08 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Dec 2020 17:05:08 +0000
Subject: =?utf-8?q?=5Bissue41349=5D_Tk_window_not_going_full_screen_on_90=C2=B0_ro?=
 =?utf-8?q?tated__screen_on_mac?=
In-Reply-To: <1595259495.1.0.547279913373.issue41349@roundup.psfhosted.org>
Message-ID: <1608051908.75.0.674745897059.issue41349@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> third party
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41349>
_______________________________________

From report at bugs.python.org  Tue Dec 15 12:05:33 2020
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Tue, 15 Dec 2020 17:05:33 +0000
Subject: [issue38820] Make Python compatible with OpenSSL 3.0.0
In-Reply-To: <1573916819.64.0.690362352385.issue38820@roundup.psfhosted.org>
Message-ID: <1608051933.89.0.947717868359.issue38820@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/issue38820>
_______________________________________

From report at bugs.python.org  Tue Dec 15 12:05:42 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Dec 2020 17:05:42 +0000
Subject: [issue42648] subprocess: add a helper/parameter to catch exec()
 OSError exception
Message-ID: <1608051942.35.0.527198192461.issue42648@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

While working on on bpo-42641 "Deprecate os.popen() function", I tried to replace os.popen() with a subprocess function, to avoid relying on an external shell. Example from test_posix:

        with os.popen('id -G 2>/dev/null') as idg:
            groups = idg.read().strip()
            ret = idg.close()

os.popen() uses a shell, and so returns an non-zero exit status if the "id" program is not available:

>>> import os; os.popen('nonexistent').close()
/bin/sh: nonexistent : commande introuvable
32512

whereas the subprocess module raises an OSError:

>>> import subprocess; proc=subprocess.run('nonexistent')
FileNotFoundError: [Errno 2] No such file or directory: 'nonexistent'

It's not convenient to have to write try/except OSError when replacing os.popen() with subprocess.run().

It would be convenient to have a subprocess API which avoid the need for try/except, if possible with keeping the ability to distinguish when exec() fails and when exec() completed but waitpid() returns a non-zero exit status (child process exit code is non-zero).

This issue becomes more interesting when subprocess uses os.posix_spawn(). The subprocess module only uses os.posix_spawn() if the libc implementation is known to report exec() failure: if os.posix_spawn() raises an OSError exception if exec() fails. See subprocess._use_posix_spawn() which uses os.confstr('CS_GNU_LIBC_VERSION') to check if the glibc 2.24+ is used.

Or maybe I simply missed a very obvious API in subprocess for this problem?

----------
components: Library (Lib)
messages: 383078
nosy: gregory.p.smith, vstinner
priority: normal
severity: normal
status: open
title: subprocess: add a helper/parameter to catch exec() OSError exception
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42648>
_______________________________________

From report at bugs.python.org  Tue Dec 15 12:05:47 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Dec 2020 17:05:47 +0000
Subject: [issue41969] ttk.RadioButtons mis-sized under Windows 10 UI Scaling, 
 with dpiAware set true
In-Reply-To: <1602090157.47.0.836989772149.issue41969@roundup.psfhosted.org>
Message-ID: <1608051947.45.0.560990737873.issue41969@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> third party
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41969>
_______________________________________

From report at bugs.python.org  Tue Dec 15 12:06:45 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Dec 2020 17:06:45 +0000
Subject: [issue42641] Deprecate os.popen() function
In-Reply-To: <1607986363.29.0.33477455927.issue42641@roundup.psfhosted.org>
Message-ID: <1608052005.72.0.0324404453366.issue42641@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 7f14a3756b61272cc15f24302589874b125c2f04 by Victor Stinner in branch 'master':
bpo-42641: Enhance test_select.test_select() (GH-23782)
https://github.com/python/cpython/commit/7f14a3756b61272cc15f24302589874b125c2f04


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42641>
_______________________________________

From report at bugs.python.org  Tue Dec 15 12:06:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Dec 2020 17:06:57 +0000
Subject: [issue42641] Deprecate os.popen() function
In-Reply-To: <1607986363.29.0.33477455927.issue42641@roundup.psfhosted.org>
Message-ID: <1608052017.1.0.125832061243.issue42641@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I created bpo-42648: "subprocess: add a helper/parameter to catch exec() OSError exception".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42641>
_______________________________________

From report at bugs.python.org  Tue Dec 15 12:24:18 2020
From: report at bugs.python.org (Ivo Shipkaliev)
Date: Tue, 15 Dec 2020 17:24:18 +0000
Subject: [issue42630] Variable.__init__ raises obscure AttributeError
In-Reply-To: <1607901840.62.0.626631020476.issue42630@roundup.psfhosted.org>
Message-ID: <1608053058.82.0.479133565158.issue42630@roundup.psfhosted.org>


Ivo Shipkaliev <ivo.shipkaliev at gmail.com> added the comment:

Thank you very much, fellows!

Serhiy, I'm lloking at Lib/tkinter/__init__.py changes. I'd like to share my thoughts on this:

I understand your concern: "But I am not sure what is better: raise error (RuntimeError) if the global function uses _default_root which is not initialized, or create the root widget implicitly."

In the new _get_default_root() function, first we check if Support Default Root in on:

290 >     if not _support_default_root:

If we get passed this block, we know that Support Default Root is on, meaning that all entities that require a master, but didn't receive one passed-in, must receive a default one. That's how I perceive the whole idea behind Support Default Root.

But later on we do:

293 >     if not _default_root:
294 >         if what:
295 >             raise RuntimeError(f"Too early to {what}: no default root window")

At this point, if "what" evaluates to True, we raise a RuntimeError. But at this same time Support Default Root is on, and there is no default root. And clearly: ".. no default root window" error contradicts the "_support_default_root" idea.

So further on, assuming Support Default Root is on, if we instantiate a Variable with master=None, we would get: "Too early to create variable: no default root window", which makes no sense.

In my view, we should always create a default root if it's needed, provided that _support_default_root is True. Simply: Support Default Root must lead to a default root.

Best Regards

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42630>
_______________________________________

From report at bugs.python.org  Tue Dec 15 12:34:14 2020
From: report at bugs.python.org (E. Paine)
Date: Tue, 15 Dec 2020 17:34:14 +0000
Subject: [issue42630] Variable.__init__ raises obscure AttributeError
In-Reply-To: <1607901840.62.0.626631020476.issue42630@roundup.psfhosted.org>
Message-ID: <1608053654.02.0.840558596926.issue42630@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

> In my view, we should always create a default root if it's needed

I somewhat disagree. I think Serhiy has done a very good job (in what I've reviewed so far) of balancing when a new root should or shouldn't be created (e.g. does it make sense to create a new root when calling `getboolean` as this should only be called once there is a Tcl object to be processed?).

We also have the consideration of backwards compatibility as some weird script may rely upon such errors to, for example, detect when a root has not already been created.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42630>
_______________________________________

From report at bugs.python.org  Tue Dec 15 12:36:33 2020
From: report at bugs.python.org (Matthias Bussonnier)
Date: Tue, 15 Dec 2020 17:36:33 +0000
Subject: [issue42644] logging.disable('WARN') breaks AsyncIO
In-Reply-To: <1608026446.25.0.329181114873.issue42644@roundup.psfhosted.org>
Message-ID: <1608053793.46.0.348785129365.issue42644@roundup.psfhosted.org>


Matthias Bussonnier <bussonniermatthias at gmail.com> added the comment:

I should have been more careful in my explanation in the upstream issue to have a complete report in here. 

I think that patching logging.disable to raise a type error immediately would be welcome; as the effect of storing a wrong type make any asyncio application fails in place that can be relatively remote from the location of the erroneous value, and could be quite hard to debug in other circumstances.

----------
nosy: +mbussonn

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42644>
_______________________________________

From report at bugs.python.org  Tue Dec 15 12:55:57 2020
From: report at bugs.python.org (Michael Orlitzky)
Date: Tue, 15 Dec 2020 17:55:57 +0000
Subject: [issue42649] RecursionError when parsing unwieldy expression
 (regression from 2.7 -> 3.x)
Message-ID: <1608054957.39.0.0382114401229.issue42649@roundup.psfhosted.org>


New submission from Michael Orlitzky <michael at orlitzky.com>:

The attached file contains a huge, ugly expression that can be parsed in python-2.7 but not python-3.x (I've tested 3.7, 3.8, and 3.9). With the 3.x versions, I get

  $ python3 DPT_defn 
  RecursionError: maximum recursion depth exceeded during compilation

Python-2.7, on the other hand, is able to parse & compile much larger expressions -- this example was whittled down until it was roughly minimal.

----------
components: Interpreter Core
files: DPT_defn
messages: 383084
nosy: mjo
priority: normal
severity: normal
status: open
title: RecursionError when parsing unwieldy expression (regression from 2.7 -> 3.x)
versions: Python 3.9
Added file: https://bugs.python.org/file49683/DPT_defn

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42649>
_______________________________________

From report at bugs.python.org  Tue Dec 15 12:56:14 2020
From: report at bugs.python.org (Michael Orlitzky)
Date: Tue, 15 Dec 2020 17:56:14 +0000
Subject: [issue42649] RecursionError when parsing unwieldy expression
 (regression from 2.7 -> 3.x)
In-Reply-To: <1608054957.39.0.0382114401229.issue42649@roundup.psfhosted.org>
Message-ID: <1608054974.46.0.73748763114.issue42649@roundup.psfhosted.org>


Change by Michael Orlitzky <michael at orlitzky.com>:


----------
type:  -> compile error

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42649>
_______________________________________

From report at bugs.python.org  Tue Dec 15 13:08:46 2020
From: report at bugs.python.org (Matthias Bussonnier)
Date: Tue, 15 Dec 2020 18:08:46 +0000
Subject: [issue42644] logging.disable('WARN') breaks AsyncIO
In-Reply-To: <1608026446.25.0.329181114873.issue42644@roundup.psfhosted.org>
Message-ID: <1608055726.8.0.165309978306.issue42644@roundup.psfhosted.org>


Change by Matthias Bussonnier <bussonniermatthias at gmail.com>:


----------
keywords: +patch
pull_requests: +22643
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23786

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42644>
_______________________________________

From report at bugs.python.org  Tue Dec 15 13:19:47 2020
From: report at bugs.python.org (Xavier Morel)
Date: Tue, 15 Dec 2020 18:19:47 +0000
Subject: [issue42644] logging.disable('WARN') breaks AsyncIO
In-Reply-To: <1608026446.25.0.329181114873.issue42644@roundup.psfhosted.org>
Message-ID: <1608056387.56.0.811206723341.issue42644@roundup.psfhosted.org>


Xavier Morel <xavier.morel at masklinn.net> added the comment:

> I think that patching logging.disable to raise a type error immediately would be welcome

FWIW `logging` has a built-in checker / converter[0] which is already used in a bunch of places (e.g. the aforementioned setLevel), it could just be added inside `disable` in the same way it's used in setLevel[1] and would uniformly convert "level names" to proper levels or raise an error. That seems like a really easy patch / contribution.

[0] https://github.com/python/cpython/blob/3.9/Lib/logging/__init__.py#L189

[1] https://github.com/python/cpython/blob/3.9/Lib/logging/__init__.py#L906

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42644>
_______________________________________

From report at bugs.python.org  Tue Dec 15 13:21:14 2020
From: report at bugs.python.org (Xavier Morel)
Date: Tue, 15 Dec 2020 18:21:14 +0000
Subject: [issue42644] logging.disable('WARN') breaks AsyncIO
In-Reply-To: <1608026446.25.0.329181114873.issue42644@roundup.psfhosted.org>
Message-ID: <1608056474.06.0.978159874296.issue42644@roundup.psfhosted.org>


Xavier Morel <xavier.morel at masklinn.net> added the comment:

Oh I now see you've created a PR to do essentially that, nm.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42644>
_______________________________________

From report at bugs.python.org  Tue Dec 15 13:42:15 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Dec 2020 18:42:15 +0000
Subject: [issue42630] Variable.__init__ raises obscure AttributeError
In-Reply-To: <1607901840.62.0.626631020476.issue42630@roundup.psfhosted.org>
Message-ID: <1608057735.6.0.544672540014.issue42630@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Currently, a root window is created implicitly only when you create a Tkinter or Ttk widget. i.e. things which should be visible to user. When you create image, variable, or use global utility function like getbool() or mainloop() or image_types() it raises an error: AttributeError or NamedError, or sometimes RuntimeError with error message like "Too early to create image: no default root window". With PR 23781 it will always raise RuntimeError instead of AttributeError or NamedError with corresponding error message.

"no default root window" is correct. There is no yet default root window required by the function. After you create it, explicitly or implicitly, you could use that function.

It could be odd if image_type() will successfully return a result with a side effect of popping up a window.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42630>
_______________________________________

From report at bugs.python.org  Tue Dec 15 13:45:09 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Dec 2020 18:45:09 +0000
Subject: [issue42318] [tkinter] surrogate pairs in Tcl/Tk string when pasting
 an emoji in a text widget
In-Reply-To: <1605043338.18.0.398355808071.issue42318@roundup.psfhosted.org>
Message-ID: <1608057909.52.0.983676293902.issue42318@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 28bf6ab61f77c69b732a211c398ac882bf3f65f4 by Serhiy Storchaka in branch '3.9':
[3.9] bpo-42318: Fix support of non-BMP characters in Tkinter on macOS (GH-23281). (GH-23784)
https://github.com/python/cpython/commit/28bf6ab61f77c69b732a211c398ac882bf3f65f4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42318>
_______________________________________

From report at bugs.python.org  Tue Dec 15 13:45:10 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Dec 2020 18:45:10 +0000
Subject: [issue42318] [tkinter] surrogate pairs in Tcl/Tk string when pasting
 an emoji in a text widget
In-Reply-To: <1605043338.18.0.398355808071.issue42318@roundup.psfhosted.org>
Message-ID: <1608057910.62.0.364269220047.issue42318@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +22644
pull_request: https://github.com/python/cpython/pull/23787

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42318>
_______________________________________

From report at bugs.python.org  Tue Dec 15 13:49:25 2020
From: report at bugs.python.org (Brad Warren)
Date: Tue, 15 Dec 2020 18:49:25 +0000
Subject: [issue42650] Can people use dest=argparse.SUPPRESS in custom Action
 classes?
Message-ID: <1608058165.01.0.505230302489.issue42650@roundup.psfhosted.org>


New submission from Brad Warren <bradmwarren at gmail.com>:

argparse internally sets dest=SUPPRESS in action classes like _HelpAction and _VersionAction to prevent an attribute from being created for that option on the resulting namespace.

Can users creating custom Action classes also use this functionality without worrying about it suddenly breaking in a new version of Python? If so, can we document this functionality? I'd be happy to submit a PR.

----------
assignee: docs at python
components: Documentation
messages: 383089
nosy: bmw, docs at python
priority: normal
severity: normal
status: open
title: Can people use dest=argparse.SUPPRESS in custom Action classes?
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42650>
_______________________________________

From report at bugs.python.org  Tue Dec 15 13:50:56 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 15 Dec 2020 18:50:56 +0000
Subject: [issue42577] Unhelpful syntax error when expression spans multiple
 lines
In-Reply-To: <1607181038.72.0.910363231446.issue42577@roundup.psfhosted.org>
Message-ID: <1608058256.5.0.613620475673.issue42577@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I think something should probably be done about this, but opening another tracker issue is not the way to make progress here. So I am closing the issue. It will happen in due time. No need to have more open issues.

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42577>
_______________________________________

From report at bugs.python.org  Tue Dec 15 14:38:46 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Dec 2020 19:38:46 +0000
Subject: [issue38661] Changes to tkinter result in (unexpected) widget map
 call return changes wrt. 3.7
In-Reply-To: <1572618747.95.0.320564330748.issue38661@roundup.psfhosted.org>
Message-ID: <1608061126.8.0.643741067437.issue38661@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

This was likely caused by different versions of Tk.

It should be fixed now in issue42328. Style.map() should convert result to uniform representation on all versions and platforms, and accept input in different forms. Please check.

----------
resolution:  -> duplicate
status: open -> pending
superseder:  -> ttk style.map function incorrectly handles the default state for element options.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38661>
_______________________________________

From report at bugs.python.org  Tue Dec 15 14:43:19 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 15 Dec 2020 19:43:19 +0000
Subject: [issue40219] ttk LabeledScale: label covered by hidden element
In-Reply-To: <1586292175.49.0.452846630354.issue40219@roundup.psfhosted.org>
Message-ID: <1608061399.52.0.620169460884.issue40219@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset b9ced83cf427ec86802ba4c9a562c6d9cafc72f5 by E-Paine in branch 'master':
bpo-40219: Lowered ttk LabeledScale dummy (GH-21467)
https://github.com/python/cpython/commit/b9ced83cf427ec86802ba4c9a562c6d9cafc72f5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40219>
_______________________________________

From report at bugs.python.org  Tue Dec 15 14:43:30 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Dec 2020 19:43:30 +0000
Subject: [issue40219] ttk LabeledScale: label covered by hidden element
In-Reply-To: <1586292175.49.0.452846630354.issue40219@roundup.psfhosted.org>
Message-ID: <1608061410.03.0.380474556217.issue40219@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +22645
pull_request: https://github.com/python/cpython/pull/23788

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40219>
_______________________________________

From report at bugs.python.org  Tue Dec 15 14:43:37 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Dec 2020 19:43:37 +0000
Subject: [issue40219] ttk LabeledScale: label covered by hidden element
In-Reply-To: <1586292175.49.0.452846630354.issue40219@roundup.psfhosted.org>
Message-ID: <1608061417.75.0.650434190333.issue40219@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22646
pull_request: https://github.com/python/cpython/pull/23789

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40219>
_______________________________________

From report at bugs.python.org  Tue Dec 15 15:00:17 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 15 Dec 2020 20:00:17 +0000
Subject: [issue14935] PEP 384 Refactoring applied to _csv module
In-Reply-To: <1338222171.68.0.797250497291.issue14935@psf.upfronthosting.co.za>
Message-ID: <1608062417.37.0.0967971698772.issue14935@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.10 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14935>
_______________________________________

From report at bugs.python.org  Tue Dec 15 15:02:06 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 15 Dec 2020 20:02:06 +0000
Subject: [issue40219] ttk LabeledScale: label covered by hidden element
In-Reply-To: <1586292175.49.0.452846630354.issue40219@roundup.psfhosted.org>
Message-ID: <1608062526.79.0.181856793987.issue40219@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 13d40c2a418116797eccd77bd65e4dbd689008db by Miss Islington (bot) in branch '3.8':
bpo-40219: Lowered ttk LabeledScale dummy (GH-21467)
https://github.com/python/cpython/commit/13d40c2a418116797eccd77bd65e4dbd689008db


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40219>
_______________________________________

From report at bugs.python.org  Tue Dec 15 15:03:26 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 15 Dec 2020 20:03:26 +0000
Subject: [issue1514420] Traceback display code can attempt to open a file
 named "<stdin>"
Message-ID: <1608062606.38.0.652115122588.issue1514420@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

Ok, I'm unconfused now - this is the C version of the traceback, in _Py_DisplaySourceLine, not the traceback.py one that uses linecache.

It wouldn't be hard to add the check for "<>" in the filename there. Is there a reason not to do it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1514420>
_______________________________________

From report at bugs.python.org  Tue Dec 15 15:19:44 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 15 Dec 2020 20:19:44 +0000
Subject: [issue24743] Make _PyTraceback_Add public
In-Reply-To: <1438084954.97.0.508949242804.issue24743@psf.upfronthosting.co.za>
Message-ID: <1608063584.86.0.822507900386.issue24743@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

This seems like something that needs to be discussed on python-ideas before it can be brought to implementation.

----------
resolution:  -> rejected
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24743>
_______________________________________

From report at bugs.python.org  Tue Dec 15 16:20:26 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Dec 2020 21:20:26 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1608067226.83.0.89971739002.issue31904@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset e1e3c2dac3da8a179f57bd3e3309ab65385bcc8a by pxinwr in branch 'master':
bpo-31904: Disable os.popen and popen test cases on VxWorks (GH-21687)
https://github.com/python/cpython/commit/e1e3c2dac3da8a179f57bd3e3309ab65385bcc8a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Tue Dec 15 16:22:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Dec 2020 21:22:06 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1608067326.16.0.769734740311.issue31904@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 9a0dea6137a9fe295c8b03aaa08a74c8572ecc4e by pxinwr in branch 'master':
bpo-31904: Skip some tests of changing owner in _test_all_chown_common() on VxWorks (GH-23716)
https://github.com/python/cpython/commit/9a0dea6137a9fe295c8b03aaa08a74c8572ecc4e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Tue Dec 15 16:24:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Dec 2020 21:24:11 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1608067451.35.0.522120434065.issue31904@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset b230409f21f5e5b42de6ec10147cd95ae3bdd095 by pxinwr in branch 'master':
bpo-31904: Skip os.path.expanduser() tests on VxWorks (GH-23776)
https://github.com/python/cpython/commit/b230409f21f5e5b42de6ec10147cd95ae3bdd095


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Tue Dec 15 16:37:40 2020
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 15 Dec 2020 21:37:40 +0000
Subject: [issue35930] Raising an exception raised in a "future" instance will
 create reference cycles
In-Reply-To: <1549549530.21.0.398741964575.issue35930@roundup.psfhosted.org>
Message-ID: <1608068260.11.0.253653340315.issue35930@roundup.psfhosted.org>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

The corrected test case in the terminal: (a "del" was missing)

"""
import gc
import concurrent.futures
executor = concurrent.futures.ThreadPoolExecutor(999)

def a():
  1/0

future=executor.submit(a)
future.result()
# An exception is raised here. That is normal
del future  # Variable vanish, but data is still there because the cycle
gc.set_debug(gc.DEBUG_SAVEALL)
gc.collect()
gc.garbage
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35930>
_______________________________________

From report at bugs.python.org  Tue Dec 15 17:12:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Dec 2020 22:12:52 +0000
Subject: [issue42641] Deprecate os.popen() function
In-Reply-To: <1607986363.29.0.33477455927.issue42641@roundup.psfhosted.org>
Message-ID: <1608070372.27.0.472852488874.issue42641@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> document drawbacks and limitations of os.popen and advertise alternatives.

This sounds like a good idea in any case ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42641>
_______________________________________

From report at bugs.python.org  Tue Dec 15 17:52:58 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 15 Dec 2020 22:52:58 +0000
Subject: [issue19206] Support disabling file I/O when doing traceback
 formatting
In-Reply-To: <1381324623.16.0.375897659555.issue19206@psf.upfronthosting.co.za>
Message-ID: <1608072778.21.0.68503833876.issue19206@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

Since this issue was created, the traceback module changed considerably, and now we have the TracebackException/StackSummary classes which capture information about an exception for later rendering. The lookup_lines arg controls the timing of the file access: if it is false, this is delayed until render-time.

I believe this solves the use case of the logger - the file access can be delayed till the logger thread renders the exception. I'm not sure I understand the event loop use case, but presumably there, too, the exceptions are not being rendered (because we don't want IO during that loop).

----------
nosy: +iritkatriel
resolution:  -> out of date
status: open -> pending
versions:  -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19206>
_______________________________________

From report at bugs.python.org  Tue Dec 15 18:20:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Dec 2020 23:20:46 +0000
Subject: [issue42648] subprocess: add a helper/parameter to catch exec()
 OSError exception
In-Reply-To: <1608051942.35.0.527198192461.issue42648@roundup.psfhosted.org>
Message-ID: <1608074446.79.0.306711029351.issue42648@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +22647
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23790

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42648>
_______________________________________

From report at bugs.python.org  Tue Dec 15 18:22:12 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 15 Dec 2020 23:22:12 +0000
Subject: [issue2824] zipfile to handle duplicate files in archive
In-Reply-To: <1210537070.35.0.0613996133193.issue2824@psf.upfronthosting.co.za>
Message-ID: <1608074532.25.0.916004492074.issue2824@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

This was changed to a warning in issue20262. Is that enough or should it be an exception?

----------
nosy: +iritkatriel

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2824>
_______________________________________

From report at bugs.python.org  Tue Dec 15 18:25:01 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Dec 2020 23:25:01 +0000
Subject: [issue42648] subprocess: add a helper/parameter to catch exec()
 OSError exception
In-Reply-To: <1608051942.35.0.527198192461.issue42648@roundup.psfhosted.org>
Message-ID: <1608074701.89.0.405005331817.issue42648@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I wrote PR 23790 which adds exec_raise=True parameter to subprocess.Popen. exec_raise=False avoids try/except OSError.

I dislike the "exec_raise" parameter name. The function is not related to exec, but more specific to OSError. A better name may include "oserror", like "catch_oserror"?

The shutil.rmtree() has a "onerror" parameter. I don't know if it's a good inspiration for this feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42648>
_______________________________________

From report at bugs.python.org  Tue Dec 15 18:28:09 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 15 Dec 2020 23:28:09 +0000
Subject: [issue42648] subprocess: add a helper/parameter to catch exec()
 OSError exception
In-Reply-To: <1608051942.35.0.527198192461.issue42648@roundup.psfhosted.org>
Message-ID: <1608074889.75.0.982948417877.issue42648@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

The shell was isolating the user from the exec error by always existing and turning the exec error into a status return.

>>> subprocess.run('foo', shell=True)
/bin/sh: line 1: foo: command not found
CompletedProcess(args='foo', returncode=127)
>>> subprocess.getstatusoutput('foo')
(127, '/bin/sh: line 1: foo: command not found')

For things that don't actually _need_ the output as a pipe file (such as your .read() example), I recommend using .run() like that today and accessing the .stdout and .returncode attributes of the CompletedProcess.  Or use the old getstatusoutput() API if you don't mind stderr being included.

As far as new APIs go, yet another keyword only argument to subprocess.POpen's existing huge list that tells it to turn exec failures into a particular returncode value could be added as a feature.  Is this use case compelling enough to do that?

...

As far as distinguishing failures go, I suggest making such an API be to allow the user to specify a non-negative int to use as returncode - a unique int or one that is out of range such as a negative number or large number could be used to distinguish things if the user were so inclined or even an int subclass like True or an IntEnum value.  But lets keep it a non-negative int, not an arbitrary object.  Negative ints map to signals; using those would be confusing for CalledProcessError when a check constructs one.

```
>>> subprocess.run('foo', exec_fails_via_returncode=256)
CompletedProcess(args='foo', returncode=256)
```

With a default of exec_fails_via_returncode=None being the existing exception raising behavior.

That isn't joyful to use as an API.  So I don't expect most people would use it directly.  They'd have a wrapper function.  Ie: just another variation on getstatusoutput() that allows for use of a shell or stderr inclusion to be controlled.

The shell is fast.  I'd just use the shell when replacing os.popen uses in tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42648>
_______________________________________

From report at bugs.python.org  Tue Dec 15 18:28:33 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 15 Dec 2020 23:28:33 +0000
Subject: [issue14586] TypeError: truncate() takes no keyword arguments
In-Reply-To: <1334455473.06.0.710562653974.issue14586@psf.upfronthosting.co.za>
Message-ID: <1608074913.15.0.524448466156.issue14586@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
versions: +Python 3.10 -Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue14586>
_______________________________________

From report at bugs.python.org  Tue Dec 15 18:31:13 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 15 Dec 2020 23:31:13 +0000
Subject: [issue42648] subprocess: add a helper/parameter to catch exec()
 OSError exception
In-Reply-To: <1608051942.35.0.527198192461.issue42648@roundup.psfhosted.org>
Message-ID: <1608075073.78.0.784255301709.issue42648@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

I suggest just adding a couple options to getstatusoutput instead of wrangling new to-catch-or-not-to-catch APIs if code like your test_posix example is what you want to replace.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42648>
_______________________________________

From report at bugs.python.org  Tue Dec 15 18:34:21 2020
From: report at bugs.python.org (Ivo Shipkaliev)
Date: Tue, 15 Dec 2020 23:34:21 +0000
Subject: [issue42630] Variable.__init__ raises obscure AttributeError
In-Reply-To: <1607901840.62.0.626631020476.issue42630@roundup.psfhosted.org>
Message-ID: <1608075261.17.0.627268769628.issue42630@roundup.psfhosted.org>


Ivo Shipkaliev <ivo.shipkaliev at gmail.com> added the comment:

First: thank you!

> I think Serhiy has done a very good job ...

I'm not saying he ain't! More so, I greatly appreciate everyone's time and effort. But I'm discussing the implementation here, not somebody's work.

Apparently I haven't been precise enough in conveying my message. Let me try to clarify what I mean. Consider the following:

An object gets initialized. The object's constructor accepts a "master" optional parameter (e.g. Variable.__init__). So, every time:
   -- "master" is None
      and
   -- _support_default_root is True
a default root must be instantiated. A master is optional, and when it's not given and _support_default_root switch is on, a default root should be supplied. That's the whole point of _support_default_root after all.

My understanding of the module is not as deep as yours', but getboolean(), mainloop() and image_types() shouldn't be affected.

"Too early to create image: no default root window": Why isn't there? When _support_default_root is on.

Again, I can see that:

> "no default root window" is correct

:But why is there no default window? Support default root is on, right?

> There is no yet default root window required by the function.

:A default root is required when you instantiate an Image without a "master". It's not required as an argument, but it is required for the operation of Image.
I'm suggesting something like:

> class Variable:
> ...
>     def __init__(self, master=None, value=None, name=None):
>         ...
>         master = master or _get_default_root()
>         self._root = master._root()
>         ...

> class Image:
> ...
>     def __init__(self, imgtype, name=None, cnf={}, master=None, **kw):
>         ...
>         master = master or _get_default_root()
>         self.tk = getattr(master, 'tk', master)
>         ...

Best Wishes
Ivo Shipkaliev

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42630>
_______________________________________

From report at bugs.python.org  Tue Dec 15 18:54:44 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 15 Dec 2020 23:54:44 +0000
Subject: [issue42648] subprocess: add a helper/parameter to catch exec()
 OSError exception
In-Reply-To: <1608051942.35.0.527198192461.issue42648@roundup.psfhosted.org>
Message-ID: <1608076484.95.0.775862724689.issue42648@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

https://docs.python.org/dev/library/subprocess.html#subprocess-replacements documentation suggests to replace os.popen(cmd, "w") with Popen(cmd, stdin=PIPE): without shell=True. My problem is that the replacement does change the behavior if the command does not exist.

--

I would like to avoid a shell (shell=True) to avoid any risk of shell injection vulnerability, but also to avoid bugs caused by the usage of a shell.

For example, "*" is a joker character. "*.py" is expanded to the list of filenames ending with ".py", or left unchanged if there is no file with a name ending with ".py". It's surprising if you are not used to a shell, and you expect "*" to be passed to the final command.

There are other weird cases with a shell, like bpo-26124 "shlex.quote and pipes.quote do not quote shell keywords".

See bpo-42641 "Deprecate os.popen() function" for other examples.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42648>
_______________________________________

From report at bugs.python.org  Tue Dec 15 19:42:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 00:42:52 +0000
Subject: [issue42648] subprocess: add a helper/parameter to catch exec()
 OSError exception
In-Reply-To: <1608051942.35.0.527198192461.issue42648@roundup.psfhosted.org>
Message-ID: <1608079372.03.0.00523670287104.issue42648@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I updated my PR 23790 to add many usage of the new parameter, to see which kind of code would benefit of it.

--

Use case: Get the output of a command, don't fail if the command doesn't exist. Example: get "gcc --version" output.

It's common to redirect stderr to /dev/null.

The advantage of having a parameter is the ability to continue using regular subprocess methods without having to bother with the "command not found" case:

   proc.communicate()
   proc.stdout.read()
   if proc.returncode: ...
   ...

--

Tools/scripts/patchcheck.py calls subprocess.check_output() and uses "except subprocess.CalledProcessError:" to ignore any command error. But it doesn't catch "OSError" if the command doesn't exist (ex: "git" in this case).

*Maybe* exec_raise=False should even be the default behavior for functions like check_output()? But changing the default behavior is always a challenge for the backward compatibility :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42648>
_______________________________________

From report at bugs.python.org  Tue Dec 15 20:01:15 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 16 Dec 2020 01:01:15 +0000
Subject: [issue42648] subprocess: add a helper/parameter to catch exec()
 OSError exception
In-Reply-To: <1608051942.35.0.527198192461.issue42648@roundup.psfhosted.org>
Message-ID: <1608080475.81.0.714965710626.issue42648@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

We could also be thinking too low level here.  We don't have to re-use returncode for this or do it on POpen itself.  This could be done at the `run()` API level and CompletedProcess could be given state indicating success or failure of the exec itself.

ex: Add a `capture_oserror=` arg to `run()`.

```
>>> proc = subprocess.run(['foo'], capture_oserror=True)
>>> proc
CompletedProcess(args='foo', oserror=FileNotFoundError(2, 'No such file or directory'))
>>> if proc.failure:
...   
```

Add two properties to CompletedProcess:

```
@property
def success(self):
    return bool(self.oserror is None and not self.returncode)

@property
def failure(self):
    return bool(self.oserror or self.returncode)
```

to make using that an easy one liner.

Another thing that came up recently was someone wishing CompletedProcess had a `__bool__()` method.  I rejected that as it could break existing code already testing None vs CompletedProcess via truthiness.  But such a desire should be satisfied with the above .success and .failure properties.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42648>
_______________________________________

From report at bugs.python.org  Tue Dec 15 20:11:29 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 16 Dec 2020 01:11:29 +0000
Subject: [issue42648] subprocess: add a helper/parameter to catch exec()
 OSError exception
In-Reply-To: <1608051942.35.0.527198192461.issue42648@roundup.psfhosted.org>
Message-ID: <1608081089.67.0.893580869846.issue42648@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

arguably run() with check=True could've turned the OSError into a CalledProcessError [can't do that now, someone surely depends on it].  So if both are supplied, perhaps it does that instead of returning a CompletedProcess with .oserror set?

the API surface we've accumulated in subprocess over the decades is huge. :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42648>
_______________________________________

From report at bugs.python.org  Tue Dec 15 20:14:30 2020
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 16 Dec 2020 01:14:30 +0000
Subject: [issue42648] subprocess: add a helper/parameter to catch exec()
 OSError exception
In-Reply-To: <1608051942.35.0.527198192461.issue42648@roundup.psfhosted.org>
Message-ID: <1608081270.77.0.214401794972.issue42648@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

I suggesting changing the name to indicate that only OSError exceptions are suppressed, not SubprocessError exceptions. Maybe call it no_oserror.

As to the status code to use, if you want a a common code that can't interfere, it has to be either a negative value that can't be confused with a POSIX signal value or, if non-negative, it has to be at least 2**32, since a status code in Windows can be any non-negative 32-bit value.

> The shell is fast.  I'd just use the shell when replacing os.popen 
> uses in tests.

POSIX functions os.system() and os.popen() should be avoided if there's a chance of shell injection, but if you'll be using shell=True anyway, then what's the value in rewriting the code? os.popen() already uses subprocess.Popen() with shell=True.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42648>
_______________________________________

From report at bugs.python.org  Tue Dec 15 20:21:48 2020
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 16 Dec 2020 01:21:48 +0000
Subject: [issue35930] Raising an exception raised in a "future" instance will
 create reference cycles
In-Reply-To: <1549549530.21.0.398741964575.issue35930@roundup.psfhosted.org>
Message-ID: <1608081708.71.0.818003814793.issue35930@roundup.psfhosted.org>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Even more reproductible case, now 100%:

"""
import gc
import concurrent.futures
executor = concurrent.futures.ThreadPoolExecutor(999)

def a():
  1/0

future=executor.submit(a)
future.result()
# An exception is raised here. That is normal
del future  # Variable vanish, but data is still there because the cycle
1/0  # Raises another exception drop references to the future one
gc.set_debug(gc.DEBUG_SAVEALL)
gc.collect()
gc.garbage
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35930>
_______________________________________

From report at bugs.python.org  Tue Dec 15 20:22:01 2020
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 16 Dec 2020 01:22:01 +0000
Subject: [issue35930] Raising an exception raised in a "future" instance will
 create reference cycles
In-Reply-To: <1549549530.21.0.398741964575.issue35930@roundup.psfhosted.org>
Message-ID: <1608081721.76.0.266604798502.issue35930@roundup.psfhosted.org>


Change by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35930>
_______________________________________

From report at bugs.python.org  Tue Dec 15 21:13:04 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 16 Dec 2020 02:13:04 +0000
Subject: [issue42090] zipfile.Path.joinpath API inconsistent with
 pathlib.Path.joinpath
In-Reply-To: <1603141108.13.0.969027124293.issue42090@roundup.psfhosted.org>
Message-ID: <1608084784.59.0.511513043974.issue42090@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 928dbfc16c9c4715459c80fe551c74702480db8b by Jason R. Coombs in branch 'master':
bpo-42090: zipfile.Path.joinpath now accepts multiple arguments (GH-22976)
https://github.com/python/cpython/commit/928dbfc16c9c4715459c80fe551c74702480db8b


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42090>
_______________________________________

From report at bugs.python.org  Tue Dec 15 21:47:35 2020
From: report at bugs.python.org (Carol Willing)
Date: Wed, 16 Dec 2020 02:47:35 +0000
Subject: [issue42179] Clarify chaining exceptions in tutorial/errors.rst
In-Reply-To: <1603873891.9.0.500762071742.issue42179@roundup.psfhosted.org>
Message-ID: <1608086855.63.0.656067181155.issue42179@roundup.psfhosted.org>


Carol Willing <willingc at gmail.com> added the comment:


New changeset 3f9fe23c05280dc5736c07bb0e968cdaf8c503d0 by Vladimir in branch 'master':
bpo-42179: Clarify exception chaining (GH-23160)
https://github.com/python/cpython/commit/3f9fe23c05280dc5736c07bb0e968cdaf8c503d0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42179>
_______________________________________

From report at bugs.python.org  Tue Dec 15 22:07:02 2020
From: report at bugs.python.org (Eugene Toder)
Date: Wed, 16 Dec 2020 03:07:02 +0000
Subject: [issue42125] linecache cannot get source for the __main__ module with
 a custom loader
In-Reply-To: <1603430813.16.0.973913314648.issue42125@roundup.psfhosted.org>
Message-ID: <1608088022.44.0.900046370512.issue42125@roundup.psfhosted.org>


Change by Eugene Toder <eltoder at gmail.com>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42125>
_______________________________________

From report at bugs.python.org  Tue Dec 15 22:18:24 2020
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 16 Dec 2020 03:18:24 +0000
Subject: [issue39416] Document default numeric string formats
In-Reply-To: <1579660529.58.0.0341841917197.issue39416@roundup.psfhosted.org>
Message-ID: <1608088704.95.0.505762133114.issue39416@roundup.psfhosted.org>


?ric Araujo <merwok at netwok.org> added the comment:


New changeset aedc94b8e9d0f7700c665d8d1ba9c93df33e63a8 by Miss Islington (bot) in branch '3.8':
[3.8] bpo-39416: change word case to not imply ABC (GH-22867) (GH-22869)
https://github.com/python/cpython/commit/aedc94b8e9d0f7700c665d8d1ba9c93df33e63a8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39416>
_______________________________________

From report at bugs.python.org  Wed Dec 16 00:18:39 2020
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 16 Dec 2020 05:18:39 +0000
Subject: [issue42115] Caching infrastructure for the evaluation loop:
 specialised opcodes
In-Reply-To: <1603336898.74.0.366564812208.issue42115@roundup.psfhosted.org>
Message-ID: <1608095919.33.0.719012802701.issue42115@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

$ ./python -m pyperf compare_to master.json load_method.json -G --min-speed=1
Slower (15):
- unpack_sequence: 63.2 ns +- 0.8 ns -> 68.5 ns +- 14.8 ns: 1.08x slower (+8%)
- pathlib: 23.1 ms +- 0.3 ms -> 24.4 ms +- 0.4 ms: 1.05x slower (+5%)
- scimark_fft: 418 ms +- 2 ms -> 433 ms +- 3 ms: 1.04x slower (+4%)
- scimark_monte_carlo: 113 ms +- 2 ms -> 116 ms +- 3 ms: 1.03x slower (+3%)
- unpickle_list: 5.30 us +- 0.03 us -> 5.44 us +- 0.28 us: 1.03x slower (+3%)
- nqueens: 107 ms +- 1 ms -> 109 ms +- 3 ms: 1.02x slower (+2%)
- spectral_norm: 154 ms +- 1 ms -> 157 ms +- 1 ms: 1.02x slower (+2%)
- float: 136 ms +- 1 ms -> 138 ms +- 1 ms: 1.02x slower (+2%)
- unpickle_pure_python: 324 us +- 3 us -> 329 us +- 4 us: 1.02x slower (+2%)
- genshi_xml: 71.9 ms +- 1.9 ms -> 73.1 ms +- 1.0 ms: 1.02x slower (+2%)
- scimark_sparse_mat_mult: 5.54 ms +- 0.03 ms -> 5.63 ms +- 0.03 ms: 1.02x slower (+2%)
- regex_effbot: 3.45 ms +- 0.14 ms -> 3.49 ms +- 0.04 ms: 1.01x slower (+1%)
- sqlite_synth: 3.37 us +- 0.06 us -> 3.41 us +- 0.07 us: 1.01x slower (+1%)
- regex_v8: 27.0 ms +- 0.2 ms -> 27.3 ms +- 0.1 ms: 1.01x slower (+1%)
- pickle_dict: 29.7 us +- 0.1 us -> 30.1 us +- 0.2 us: 1.01x slower (+1%)

Faster (10):
- go: 256 ms +- 3 ms -> 246 ms +- 2 ms: 1.04x faster (-4%)
- pickle_pure_python: 497 us +- 5 us -> 478 us +- 5 us: 1.04x faster (-4%)
- logging_simple: 9.84 us +- 0.17 us -> 9.48 us +- 0.22 us: 1.04x faster (-4%)
- mako: 17.1 ms +- 0.2 ms -> 16.5 ms +- 0.2 ms: 1.03x faster (-3%)
- logging_format: 10.9 us +- 0.2 us -> 10.6 us +- 0.2 us: 1.03x faster (-3%)
- logging_silent: 201 ns +- 6 ns -> 198 ns +- 5 ns: 1.02x faster (-2%)
- meteor_contest: 125 ms +- 1 ms -> 123 ms +- 0 ms: 1.02x faster (-2%)
- json_loads: 32.0 us +- 0.3 us -> 31.6 us +- 0.2 us: 1.01x faster (-1%)
- sqlalchemy_imperative: 37.8 ms +- 0.9 ms -> 37.4 ms +- 1.0 ms: 1.01x faster (-1%)
- unpickle: 14.5 us +- 0.3 us -> 14.3 us +- 0.1 us: 1.01x faster (-1%)

Benchmark hidden because not significant (35): 2to3, chameleon, chaos, crypto_pyaes, deltablue, django_template, dulwich_log, fannkuch, genshi_text, hexiom, json_dumps, nbody, pickle, pickle_list, pidigits, pyflate, python_startup, python_startup_no_site, raytrace, regex_compile, regex_dna, richards, scimark_lu, scimark_sor, sqlalchemy_declarative, sympy_expand, sympy_integrate, sympy_sum, sympy_str, telco, tornado_http, xml_etree_parse, xml_etree_iterparse, xml_etree_generate, xml_etree_process

Geometric mean: 1.00 (slower)

----------
Added file: https://bugs.python.org/file49684/results.zip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42115>
_______________________________________

From report at bugs.python.org  Wed Dec 16 01:27:23 2020
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 16 Dec 2020 06:27:23 +0000
Subject: [issue42646] Add function that supports "applying" methods
In-Reply-To: <1608037628.46.0.38282222902.issue42646@roundup.psfhosted.org>
Message-ID: <1608100043.17.0.560654515432.issue42646@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

If you're annoyed by having to use two lines, one to copy, one to call the mutating method, you can use the walrus operator:

(y := x.copy()).some_method()

or:

(y := deepcopy(x)).some_method()

Does that cover your use case?

For the list case, you'd normally just do:

arr = lis[::-1]

but:

(arr = lis.copy()).reverse()

also works.

Granted, not super pretty. But I'm not seeing enough cases where this ugliness is truly unavoidable (the two lines don't bother me that much, and for built-ins, there is usually a one-liner that works fine, e.g. the reversing slice as shown, sorted over list.sort, etc.).

I'll note: Unconditionally calling copy.copy is fine; it knows to try the __copy__ method of the things it is called on (and most things that offer copy alias it to __copy__ or are special-cased in copy.copy as well; if they don't, they should), so you're unlikely to need to perform the "try method, fall back to copy.copy" yourself.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42646>
_______________________________________

From report at bugs.python.org  Wed Dec 16 03:02:15 2020
From: report at bugs.python.org (Xinmeng Xia)
Date: Wed, 16 Dec 2020 08:02:15 +0000
Subject: [issue42651] Title: Recursive traceback crashes  Python Interpreter
Message-ID: <1608105735.03.0.523665122471.issue42651@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

=================
import traceback

def foo():
  traceback.print_exc()
  foo() 
    
foo()
================


Try running the above program, the interpreter is crashed with the error message like the following:

Fatal Python error: Cannot recover from stack overflow.
NoneType: None
NoneType: None
NoneType: None
NoneType: None

...
NoneType: None

NoneType: None
NoneType: <unprintable NoneType object>
NoneType: None
NoneType: None
...
NoneType: None
NoneType: None
NoneType: None
Fatal Python error: _Py_CheckRecursiveCall: Cannot recover from stack overflow.
Python runtime state: initialized

Current thread 0x00007fab0bdda700 (most recent call first):
  File "/usr/local/python310/lib/python3.10/traceback.py", line 155 in _some_str
  File "/usr/local/python310/lib/python3.10/traceback.py", line 515 in __init__
  File "/usr/local/python310/lib/python3.10/traceback.py", line 103 in print_exception
  File "/usr/local/python310/lib/python3.10/traceback.py", line 163 in print_exc
  File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 4 in foo
  File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5 in foo
  File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5 in foo
...
  File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5 in foo
  File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5 in foo
  File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5 in foo
  File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5 in foo
  ...
Aborted (core dumped)

----------
components: Interpreter Core
messages: 383118
nosy: xxm
priority: normal
severity: normal
status: open
title: Title: Recursive traceback crashes  Python Interpreter
type: crash
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42651>
_______________________________________

From report at bugs.python.org  Wed Dec 16 03:02:45 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 08:02:45 +0000
Subject: [issue42613] freeze.py doesn't support sys.platlibdir different than
 lib nor multiarch
In-Reply-To: <1607594518.8.0.0823964738983.issue42613@roundup.psfhosted.org>
Message-ID: <1608105765.15.0.357215713687.issue42613@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Tools/freeze/freeze.py is broken for 4 years, since Python 3.6 which added sys.implementation._multiarch to the config directory in sysconfig:

commit 5553231b91e05cf93827b33a79aebe62c4370a09
Author: doko at ubuntu.com <doko at ubuntu.com>
Date:   Tue Jun 14 08:55:19 2016 +0200

    - Issue #23968: Rename the platform directory from plat-$(MACHDEP) to
      plat-$(PLATFORM_TRIPLET).
      Rename the config directory (LIBPL) from config-$(LDVERSION) to
      config-$(LDVERSION)-$(PLATFORM_TRIPLET).
      Install the platform specifc _sysconfigdata module into the platform
      directory and rename it to include the ABIFLAGS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42613>
_______________________________________

From report at bugs.python.org  Wed Dec 16 03:03:24 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 08:03:24 +0000
Subject: [issue42613] freeze.py doesn't support sys.platlibdir different than
 lib nor multiarch
In-Reply-To: <1607594518.8.0.0823964738983.issue42613@roundup.psfhosted.org>
Message-ID: <1608105804.04.0.279473084826.issue42613@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I found this issue while working on bpo-42591 which exported the missing Py_FrozenMain() symbol.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42613>
_______________________________________

From report at bugs.python.org  Wed Dec 16 03:09:12 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 08:09:12 +0000
Subject: [issue42591] Method Py_FrozenMain missing in libpython3.9
In-Reply-To: <1607356833.89.0.498069278584.issue42591@roundup.psfhosted.org>
Message-ID: <1608106152.8.0.580663639161.issue42591@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Christian Bachmaier:
> Thus, when trying the provided freeze example via
> freeze.py hello.py & make

Do you mean freeze.py from Tools/freeze/freeze.py? This tool seems to be broken for 4 years, since Python 3.6: bpo-42613.

> 4. freeze.py wants wants this for a very long time:
>    ln -s /usr/local/lib/python3.10/config-3.10-x86_64-linux-gnu
>      /usr/local/lib/python3.10/config-3.10

Oh, you fixed manually freeze.py?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42591>
_______________________________________

From report at bugs.python.org  Wed Dec 16 03:09:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 08:09:21 +0000
Subject: [issue42613] freeze.py doesn't support sys.platlibdir different than
 lib nor multiarch
In-Reply-To: <1607594518.8.0.0823964738983.issue42613@roundup.psfhosted.org>
Message-ID: <1608106161.97.0.994492121929.issue42613@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

There are better maintained alternatives:

* PyOxidizer
* pyInstaller
* bbFreeze
* py2exe
* cx_Freeze
* py2app
* etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42613>
_______________________________________

From report at bugs.python.org  Wed Dec 16 03:13:00 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 08:13:00 +0000
Subject: [issue42613] freeze.py doesn't support sys.platlibdir different than
 lib nor multiarch
In-Reply-To: <1607594518.8.0.0823964738983.issue42613@roundup.psfhosted.org>
Message-ID: <1608106380.32.0.158156992328.issue42613@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +22648
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23792

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42613>
_______________________________________

From report at bugs.python.org  Wed Dec 16 03:16:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 08:16:58 +0000
Subject: [issue42519] [C API] Upgrade the C API in extension modules
In-Reply-To: <1606812935.61.0.224275559553.issue42519@roundup.psfhosted.org>
Message-ID: <1608106618.6.0.65122903134.issue42519@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42519>
_______________________________________

From report at bugs.python.org  Wed Dec 16 03:29:26 2020
From: report at bugs.python.org (Christian Bachmaier)
Date: Wed, 16 Dec 2020 08:29:26 +0000
Subject: [issue42591] Method Py_FrozenMain missing in libpython3.9
In-Reply-To: <1607356833.89.0.498069278584.issue42591@roundup.psfhosted.org>
Message-ID: <1608107366.99.0.723285363256.issue42591@roundup.psfhosted.org>


Christian Bachmaier <chris at infosun.fim.uni-passau.de> added the comment:

> Do you mean freeze.py from Tools/freeze/freeze.py?

Yes, unfortunately I have to keep a large old system running and there are only few options left. It is a University learning system, where students upload program code and then a huge amount of automtic quality checks are executed within a sandbox. The grading is done in a half automtic way. A real alternative is not existing, we tried hard to find one...

> This tool seems to 
> be broken for 4 years, since Python 3.6: bpo-42613.
> 4. freeze.py wants wants this for a very long time:
>    ln -s /usr/local/lib/python3.10/config-3.10-x86_64-linux-gnu
>      /usr/local/lib/python3.10/config-3.10

The symlink does the trick. So it may be easy for you to fix that, so it does operate out of the box again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42591>
_______________________________________

From report at bugs.python.org  Wed Dec 16 03:42:09 2020
From: report at bugs.python.org (Piotr Stanczyk)
Date: Wed, 16 Dec 2020 08:42:09 +0000
Subject: [issue42443] Provide Thread creation hook support
In-Reply-To: <1606144912.59.0.960330614449.issue42443@roundup.psfhosted.org>
Message-ID: <1608108129.93.0.942928613987.issue42443@roundup.psfhosted.org>


Piotr Stanczyk <stanczyk at google.com> added the comment:

Friendly ping - does the proposal sound fine?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42443>
_______________________________________

From report at bugs.python.org  Wed Dec 16 03:48:19 2020
From: report at bugs.python.org (Xinmeng Xia)
Date: Wed, 16 Dec 2020 08:48:19 +0000
Subject: [issue42652] recursive in finally clause cause Python interpreter
 crash.
Message-ID: <1608108499.51.0.334108279167.issue42652@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

Considering the following two program,running the program 1 will get expected output: RecursionError 

program 1
===========================
import traceback

def foo():
	try:
		1/0
	except Exception as e:
		traceback.print_exc()
	finally:
		a = 1
	foo()	
		
foo()

==========================
-----------------------------------------------------------------------------------
ZeroDivisionError: division by zero
Traceback (most recent call last):
  File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5, in foo
    1/0
ZeroDivisionError: division by zero
Traceback (most recent call last):
  File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5, in foo
    1/0
ZeroDivisionError: division by zero

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5, in foo
    1/0
ZeroDivisionError: division by zero
Traceback (most recent call last):
  File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5, in foo
    1/0
ZeroDivisionError: division by zero

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 12, in <module>

  File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 10, in foo
    foo()	
  File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 10, in foo
...
    foo()	
  File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 10, in foo
    foo()	
  File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 7, in foo
    traceback.print_exc()
  File "/usr/lib/python3.5/traceback.py", line 159, in print_exc
    print_exception(*sys.exc_info(), limit=limit, file=file, chain=chain)
  File "/usr/lib/python3.5/traceback.py", line 100, in print_exception
    type(value), value, tb, limit=limit).format(chain=chain):
  File "/usr/lib/python3.5/traceback.py", line 474, in __init__
    capture_locals=capture_locals)
  File "/usr/lib/python3.5/traceback.py", line 358, in extract
    f.line
  File "/usr/lib/python3.5/traceback.py", line 282, in line
    self._line = linecache.getline(self.filename, self.lineno).strip()
  File "/usr/lib/python3.5/linecache.py", line 16, in getline
    lines = getlines(filename, module_globals)
  File "/usr/lib/python3.5/linecache.py", line 43, in getlines
    if len(entry) != 1:
RecursionError: maximum recursion depth exceeded in comparison
------------------------------------------------------------------------

However when moving foo() into finally clause, the interpreter crashes.

program 2
==========================
import traceback

def foo():
	try:
		1/0
	except Exception as e:
		traceback.print_exc()
	finally:
		a = 1
		foo()	
		
foo()

==========================  
-----------------------------------------------------------------------------
File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 10 in foo
Traceback (most recent call last):
  File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5, in foo
    1/0
ZeroDivisionError: division by zero
Traceback (most recent call last):
  File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5, in foo
    1/0
ZeroDivisionError: division by zero
Traceback (most recent call last):
  File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5, in foo
    1/0
ZeroDivisionError: division by zero
Traceback (most recent call last):
  File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5, in foo
    1/0
ZeroDivisionError: division by zero
Traceback (most recent call last):
  File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5, in foo
    1/0
ZeroDivisionError: division by zero

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 7, in foo
    traceback.print_exc()
  File "/usr/lib/python3.5/traceback.py", line 159, in print_exc
    print_exception(*sys.exc_info(), limit=limit, file=file, chain=chain)
  File "/usr/lib/python3.5/traceback.py", line 100, in print_exception
    type(value), value, tb, limit=limit).format(chain=chain):
  File "/usr/lib/python3.5/traceback.py", line 474, in __init__
    capture_locals=capture_locals)
  File "/usr/lib/python3.5/traceback.py", line 358, in extract
    f.line
  File "/usr/lib/python3.5/traceback.py", line 282, in line
    self._line = linecache.getline(self.filename, self.lineno).strip()
  File "/usr/lib/python3.5/linecache.py", line 16, in getline
    lines = getlines(filename, module_globals)
  File "/usr/lib/python3.5/linecache.py", line 43, in getlines
    if len(entry) != 1:
RecursionError: maximum recursion depth exceeded in comparison

During handling of the above exception, another exception occurred:


Traceback (most recent call last):
  File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 5, in foo
    1/0

  File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 10 in foo
  File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 10 in foo
  File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 10 in foo
...
  File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 10 in foo
  File "/home/xxm/Desktop/nameChanging/myerror/test1.py", line 10 in foo
  ...
Aborted (core dumped)
-------------------------------------------------------------------------

----------
components: Interpreter Core
messages: 383125
nosy: xxm
priority: normal
severity: normal
status: open
title: recursive in finally clause cause Python interpreter crash.
type: crash
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42652>
_______________________________________

From report at bugs.python.org  Wed Dec 16 03:50:01 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 08:50:01 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1608108601.24.0.214143640783.issue1635741@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22649
pull_request: https://github.com/python/cpython/pull/23793

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Wed Dec 16 03:54:40 2020
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 16 Dec 2020 08:54:40 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1608108880.28.0.36876207861.issue10141@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
pull_requests: +22650
pull_request: https://github.com/python/cpython/pull/23794

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10141>
_______________________________________

From report at bugs.python.org  Wed Dec 16 04:07:06 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 16 Dec 2020 09:07:06 +0000
Subject: [issue42644] logging.disable('WARN') breaks AsyncIO
In-Reply-To: <1608026446.25.0.329181114873.issue42644@roundup.psfhosted.org>
Message-ID: <1608109626.53.0.019094968266.issue42644@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
components: +Library (Lib) -asyncio

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42644>
_______________________________________

From report at bugs.python.org  Wed Dec 16 04:07:23 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 16 Dec 2020 09:07:23 +0000
Subject: [issue42644] logging.disable('WARN') breaks AsyncIO
In-Reply-To: <1608026446.25.0.329181114873.issue42644@roundup.psfhosted.org>
Message-ID: <1608109643.44.0.932169316847.issue42644@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42644>
_______________________________________

From report at bugs.python.org  Wed Dec 16 04:17:42 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 09:17:42 +0000
Subject: [issue41804] test_epoll fails test_control_and_wait() randomly on
 aarch64 RHEL8 Refleaks 3.9
In-Reply-To: <1600360940.95.0.528440416873.issue41804@roundup.psfhosted.org>
Message-ID: <1608110262.29.0.0461588499607.issue41804@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +22651
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23795

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41804>
_______________________________________

From report at bugs.python.org  Wed Dec 16 04:19:11 2020
From: report at bugs.python.org (Stefan Tatschner)
Date: Wed, 16 Dec 2020 09:19:11 +0000
Subject: [issue42653] Expose ISO-TP Contants for Linux >= 5.10
Message-ID: <1608110351.71.0.562655830578.issue42653@roundup.psfhosted.org>


New submission from Stefan Tatschner <stefan at rumpelsepp.org>:

Linux >= 5.10 gained a new SocketCAN module called ISOTP. This is an implementation of ISO 15765-2 which is mainly used in vehicle CAN networks. Expose the constants from linux/can/isotp.h in the socket module.

These constants are not entirely new. Previously there was an out of tree kernel module available and a subset of these constants are already available in CPyton.

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/can/isotp.h
[2]: https://github.com/hartkopp/can-isotp

----------
components: Library (Lib)
messages: 383126
nosy: rumpelsepp
priority: normal
pull_requests: 22652
severity: normal
status: open
title: Expose ISO-TP Contants for Linux >= 5.10
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42653>
_______________________________________

From report at bugs.python.org  Wed Dec 16 04:38:32 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 09:38:32 +0000
Subject: [issue41473] test_gdb fails on AMD64 Fedora Rawhide 3.x [gdb 9.2 bug]
In-Reply-To: <1596550767.43.0.215651378336.issue41473@roundup.psfhosted.org>
Message-ID: <1608111512.2.0.49496917884.issue41473@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

test_gdb pass again on AMD64 Fedora Rawhide 3.x with "GNU gdb (GDB) Fedora 10.1-2.fc34":

https://buildbot.python.org/all/#/builders/285/builds/348
0:02:52 load avg: 11.34 [242/426] test_gdb passed (1 min 28 sec) (...)

I close the issue.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41473>
_______________________________________

From report at bugs.python.org  Wed Dec 16 04:39:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 09:39:48 +0000
Subject: [issue40949] test_socket altered the execution environment:
 threading_cleanup() failed to cleanup 0 threads (count: 0, dangling: 5)
In-Reply-To: <1591885643.11.0.227802495041.issue40949@roundup.psfhosted.org>
Message-ID: <1608111588.18.0.975253601485.issue40949@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I didn't see the failure recently, I close the issue.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40949>
_______________________________________

From report at bugs.python.org  Wed Dec 16 04:42:43 2020
From: report at bugs.python.org (Mario Corchero)
Date: Wed, 16 Dec 2020 09:42:43 +0000
Subject: [issue42654] Add folder for python customizations: __sitecustomize__
Message-ID: <1608111763.27.0.89032945983.issue42654@roundup.psfhosted.org>


New submission from Mario Corchero <mariocj89 at gmail.com>:

Following the conversations in https://bugs.python.org/issue33944, wanted to discuss the support for a __sitecustomize__ folder that will hold python scripts to be executed at startup. Similar to `sitecustomize.py` but allowing different stakeholders of a Python installation to add themselves.

This is basically a "supported way" of the current abuse of pth files to add startup code.

How will this be useful?
- Support administrators to add multiple "sitecustomize.py" files. As an example, today we are basically appending to sitecustomize when we need some additional behaviour.
- Support for library owners that need some startup customization like betterexceptions.
- Tools that include an interpreter like virtualenv or things like PyOxidizer by allowing them to customize the interpreter they expose to users.

It basically offers a better alternative to the currently abused feature of code execution in pth.

I this is something that is wanted in CPython, from the thread in https://bugs.python.org/issue33944 I see some open questions though:

- Look for `__sitecustomize__` only in site paths or in PYTHONPATH?
I'm honestly fine either way, but sightly incline more to @jaraco proposal to make this basically be a namespace package walking all its instances.

- Should we have a custom way to disable this? Or are we happy with just  `-S`. I think the `-S` is fine, it offers a similar behaviour to sitecustomize.

If you want to see "how it feels", see https://github.com/mariocj89/cpython/tree/pu/__sitecustomize__ (It's not finished).

If it seems interesting I would love to put a PR through. With this, we might be able to eventually remove code execution in pth files!

----------
components: Library (Lib)
messages: 383129
nosy: jaraco, mariocj89, ncoghlan
priority: normal
severity: normal
status: open
title: Add folder for python customizations: __sitecustomize__
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42654>
_______________________________________

From report at bugs.python.org  Wed Dec 16 04:43:32 2020
From: report at bugs.python.org (Mario Corchero)
Date: Wed, 16 Dec 2020 09:43:32 +0000
Subject: [issue42654] Add folder for python customizations: __sitecustomize__
In-Reply-To: <1608111763.27.0.89032945983.issue42654@roundup.psfhosted.org>
Message-ID: <1608111812.14.0.431117932261.issue42654@roundup.psfhosted.org>


Change by Mario Corchero <mariocj89 at gmail.com>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42654>
_______________________________________

From report at bugs.python.org  Wed Dec 16 04:43:47 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 16 Dec 2020 09:43:47 +0000
Subject: [issue42644] logging.disable('WARN') breaks AsyncIO
In-Reply-To: <1608026446.25.0.329181114873.issue42644@roundup.psfhosted.org>
Message-ID: <1608111827.18.0.246828330452.issue42644@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset b32d8b4f9bcd2e7d11240b6b9de0262cf8f5e09d by Matthias Bussonnier in branch 'master':
bpo-42644: Validate values in logging.disable() (#23786)
https://github.com/python/cpython/commit/b32d8b4f9bcd2e7d11240b6b9de0262cf8f5e09d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42644>
_______________________________________

From report at bugs.python.org  Wed Dec 16 04:43:57 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 16 Dec 2020 09:43:57 +0000
Subject: [issue42644] logging.disable('WARN') breaks AsyncIO
In-Reply-To: <1608026446.25.0.329181114873.issue42644@roundup.psfhosted.org>
Message-ID: <1608111837.06.0.857867786123.issue42644@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +22653
pull_request: https://github.com/python/cpython/pull/23796

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42644>
_______________________________________

From report at bugs.python.org  Wed Dec 16 04:44:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 09:44:04 +0000
Subject: [issue42654] Add folder for python customizations: __sitecustomize__
In-Reply-To: <1608111763.27.0.89032945983.issue42654@roundup.psfhosted.org>
Message-ID: <1608111844.26.0.115036054118.issue42654@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42654>
_______________________________________

From report at bugs.python.org  Wed Dec 16 04:44:07 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 16 Dec 2020 09:44:07 +0000
Subject: [issue42644] logging.disable('WARN') breaks AsyncIO
In-Reply-To: <1608026446.25.0.329181114873.issue42644@roundup.psfhosted.org>
Message-ID: <1608111847.2.0.887789516262.issue42644@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22654
pull_request: https://github.com/python/cpython/pull/23797

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42644>
_______________________________________

From report at bugs.python.org  Wed Dec 16 04:49:49 2020
From: report at bugs.python.org (conchylicultor)
Date: Wed, 16 Dec 2020 09:49:49 +0000
Subject: [issue33129] Add kwarg-only option to dataclass
In-Reply-To: <1521847997.9.0.467229070634.issue33129@psf.upfronthosting.co.za>
Message-ID: <1608112189.03.0.93082886816.issue33129@roundup.psfhosted.org>


conchylicultor <etiennefg.pot at gmail.com> added the comment:

For the API, I think we could add this feature with a single new `dataclass(kw_only: bool | str)`

```
@dataclasses.dataclass(kw_only=True)
class A:
  a: int
  b: int
  c: int

# A(*, a, b, c)


@dataclasses.dataclass(kw_only='b')
class A:
  a: int
  b: int
  c: int

# A(a, *, b, c)
```

I think this would be flexible enough for all use cases, while avoiding the boilerplate from the above proposals.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33129>
_______________________________________

From report at bugs.python.org  Wed Dec 16 05:05:22 2020
From: report at bugs.python.org (Jakub Kulik)
Date: Wed, 16 Dec 2020 10:05:22 +0000
Subject: [issue42655] Fix subprocess extra_groups gid conversion
Message-ID: <1608113122.79.0.244683118693.issue42655@roundup.psfhosted.org>


New submission from Jakub Kulik <kulikjak at gmail.com>:

C function `subprocess_fork_exec` incorrectly transforms gids from the `extra_groups` argument because it passes `unsigned long*` rather than `pid_t*` into the `_Py_Gid_Converter()`. Assuming that `gid_t` is 32 bit and `unsigned long` is 64 bit (which it often is), `*(gid_t *)p = gid;` then incorrectly overwrites only part of that variable, leaving the other one filled with previous garbage.

I found this on Solaris, but I am pretty sure that this doesn't work correctly on Linux as well, since both use `unsigned int` as `gid_t`.

----------
components: Extension Modules
messages: 383132
nosy: kulikjak
priority: normal
severity: normal
status: open
title: Fix subprocess extra_groups gid conversion
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42655>
_______________________________________

From report at bugs.python.org  Wed Dec 16 05:05:39 2020
From: report at bugs.python.org (Jakub Kulik)
Date: Wed, 16 Dec 2020 10:05:39 +0000
Subject: [issue42655] Fix subprocess extra_groups gid conversion
In-Reply-To: <1608113122.79.0.244683118693.issue42655@roundup.psfhosted.org>
Message-ID: <1608113139.74.0.76216849411.issue42655@roundup.psfhosted.org>


Change by Jakub Kulik <kulikjak at gmail.com>:


----------
keywords: +patch
pull_requests: +22655
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23762

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42655>
_______________________________________

From report at bugs.python.org  Wed Dec 16 05:10:54 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 16 Dec 2020 10:10:54 +0000
Subject: [issue42644] logging.disable('WARN') breaks AsyncIO
In-Reply-To: <1608026446.25.0.329181114873.issue42644@roundup.psfhosted.org>
Message-ID: <1608113454.97.0.548251081975.issue42644@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 0a24a57888798905e3b8891c59e61ed4f1bfc5a8 by Miss Islington (bot) in branch '3.8':
bpo-42644: Validate values in logging.disable() (GH-23786)
https://github.com/python/cpython/commit/0a24a57888798905e3b8891c59e61ed4f1bfc5a8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42644>
_______________________________________

From report at bugs.python.org  Wed Dec 16 05:12:17 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 16 Dec 2020 10:12:17 +0000
Subject: [issue42644] logging.disable('WARN') breaks AsyncIO
In-Reply-To: <1608026446.25.0.329181114873.issue42644@roundup.psfhosted.org>
Message-ID: <1608113537.58.0.278265910513.issue42644@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset db63da7e5d4a98925a04f903a19bf3595b9c2c46 by Miss Islington (bot) in branch '3.9':
bpo-42644: Validate values in logging.disable() (GH-23786)
https://github.com/python/cpython/commit/db63da7e5d4a98925a04f903a19bf3595b9c2c46


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42644>
_______________________________________

From report at bugs.python.org  Wed Dec 16 05:15:14 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 10:15:14 +0000
Subject: [issue40364] asyncio: replace _compute_returncode() with
 os.waitstatus_to_exitcode()
In-Reply-To: <1587574271.75.0.606427962214.issue40364@roundup.psfhosted.org>
Message-ID: <1608113714.82.0.404709119632.issue40364@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +22656
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23798

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40364>
_______________________________________

From report at bugs.python.org  Wed Dec 16 05:16:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 10:16:34 +0000
Subject: [issue41804] test_epoll fails test_control_and_wait() randomly on
 aarch64 RHEL8 Refleaks 3.9
In-Reply-To: <1600360940.95.0.528440416873.issue41804@roundup.psfhosted.org>
Message-ID: <1608113794.05.0.218437127803.issue41804@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 79782fe4f8cf73d7fdf8db02073bbadf7ff817b6 by Victor Stinner in branch 'master':
bpo-41804: Enhance test_epoll.test_control_and_wait() (GH-23795)
https://github.com/python/cpython/commit/79782fe4f8cf73d7fdf8db02073bbadf7ff817b6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41804>
_______________________________________

From report at bugs.python.org  Wed Dec 16 05:16:23 2020
From: report at bugs.python.org (=?utf-8?b?0JLQsNC70LXRgNGW0Lkg0JzQsNGA0YbQuNGI0LjQvQ==?=)
Date: Wed, 16 Dec 2020 10:16:23 +0000
Subject: [issue42656] prime numbers loop issue
Message-ID: <1608113783.31.0.191794615025.issue42656@roundup.psfhosted.org>


New submission from ??????? ???????? <valeriymartsyshyn at gmail.com>:

I have written a program which must show prime numbers. At the beginning it does, but from some moment it doesn't work properly, despite the fact that it is a loop. I suspect there is a bug somewhere, if not, I'll be thankful if you tell me the issue.





valera0639 at gmail.com

----------
components: Windows
files: main.py
messages: 383135
nosy: paul.moore, steve.dower, tim.golden, valeriymartsyshyn, zach.ware
priority: normal
severity: normal
status: open
title: prime numbers loop issue
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49685/main.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42656>
_______________________________________

From report at bugs.python.org  Wed Dec 16 05:16:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 10:16:59 +0000
Subject: [issue41804] test_epoll fails test_control_and_wait() randomly on
 aarch64 RHEL8 Refleaks 3.9
In-Reply-To: <1600360940.95.0.528440416873.issue41804@roundup.psfhosted.org>
Message-ID: <1608113819.51.0.359358291629.issue41804@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I failed to reproduce the issue. Let's hope that replacing send() with sendall() is enough to fix the issue.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10 -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41804>
_______________________________________

From report at bugs.python.org  Wed Dec 16 05:18:44 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 16 Dec 2020 10:18:44 +0000
Subject: [issue42654] Add folder for python customizations: __sitecustomize__
In-Reply-To: <1608111763.27.0.89032945983.issue42654@roundup.psfhosted.org>
Message-ID: <1608113924.09.0.53561536387.issue42654@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Shouldn't this be discussed on Python-Ideas? I'm pretty sure this is a big enough change that it will need a PEP.

If you need code run on startup, can't you just put it in the PYTHONSTARTUP file?

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42654>
_______________________________________

From report at bugs.python.org  Wed Dec 16 05:22:24 2020
From: report at bugs.python.org (Mario Corchero)
Date: Wed, 16 Dec 2020 10:22:24 +0000
Subject: [issue42654] Add folder for python customizations: __sitecustomize__
In-Reply-To: <1608111763.27.0.89032945983.issue42654@roundup.psfhosted.org>
Message-ID: <1608114144.71.0.944348492215.issue42654@roundup.psfhosted.org>


Mario Corchero <mariocj89 at gmail.com> added the comment:

> Shouldn't this be discussed on Python-Ideas? I'm pretty sure this is a big enough change that it will need a PEP.

Indeed, I wanted to see if there was interest in the feature. That is probably a better place to start.

> If you need code run on startup, can't you just put it in the PYTHONSTARTUP file?

My understanding is that PYTHONSTARTUP is only for interactive executions. Additionally, it suffers from the same issue as sitecustomize. It is a single file that won't be a real substitute for code execution in pth files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42654>
_______________________________________

From report at bugs.python.org  Wed Dec 16 05:26:17 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 16 Dec 2020 10:26:17 +0000
Subject: [issue42656] prime numbers loop issue
In-Reply-To: <1608113783.31.0.191794615025.issue42656@roundup.psfhosted.org>
Message-ID: <1608114377.94.0.191647087616.issue42656@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Hello valeriymartsyshyn,

This is for reporting bugs in the Python interpreter, it is not a help desk for learning how to program in Python. There are many places you can ask for help to debug your code, such as Reddit's r/learnpython, or Stackoverflow, or the tutor mailing list:

https://mail.python.org/mailman/listinfo/tutor

There are various Python IRC channels or Discuss, if you google you will soon find them.

In this case, your bug occurs because you are deleting items from the list as you are iterating over it. Don't do that.

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42656>
_______________________________________

From report at bugs.python.org  Wed Dec 16 05:30:33 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 16 Dec 2020 10:30:33 +0000
Subject: [issue42654] Add folder for python customizations: __sitecustomize__
In-Reply-To: <1608114144.71.0.944348492215.issue42654@roundup.psfhosted.org>
Message-ID: <20201216102952.GR9927@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> Additionally, it suffers from the same issue as 
> sitecustomize. It is a single file that won't be a real substitute for 
> code execution in pth files.

I thought that the consensus in b.p.o. #33944 is that code execution in 
pth files is an anti-feature that must be removed, not something to 
merely move into a new file type or location.

(I may be wrong, I'll admit I haven't read the entire thread in 33944.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42654>
_______________________________________

From report at bugs.python.org  Wed Dec 16 05:32:10 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 16 Dec 2020 10:32:10 +0000
Subject: [issue19733] Setting image parameter of a button crashes with Cocoa Tk
In-Reply-To: <1385212186.78.0.599244063108.issue19733@psf.upfronthosting.co.za>
Message-ID: <1608114730.41.0.767365074697.issue19733@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 5f0fe8ec70120f4586d08978b0911b436f82c421 by Serhiy Storchaka in branch 'master':
bpo-19733: Re-enable tests for -image option in Tkinter (GH-23785)
https://github.com/python/cpython/commit/5f0fe8ec70120f4586d08978b0911b436f82c421


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19733>
_______________________________________

From report at bugs.python.org  Wed Dec 16 05:32:46 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 16 Dec 2020 10:32:46 +0000
Subject: [issue19733] Setting image parameter of a button crashes with Cocoa Tk
In-Reply-To: <1385212186.78.0.599244063108.issue19733@psf.upfronthosting.co.za>
Message-ID: <1608114766.18.0.564533875634.issue19733@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +22657
pull_request: https://github.com/python/cpython/pull/23799

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19733>
_______________________________________

From report at bugs.python.org  Wed Dec 16 05:36:11 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 16 Dec 2020 10:36:11 +0000
Subject: [issue42641] Deprecate os.popen() function
In-Reply-To: <1607986363.29.0.33477455927.issue42641@roundup.psfhosted.org>
Message-ID: <1608114971.88.0.19341302238.issue42641@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

> There is also the os.system() function which exposes the libc system() function. Should we deprecate this one as well?

Please don't deprecate os.system. For quick and dirty scripts used in trusted environments with trusted data, it is simple to use, effective and safe enough.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42641>
_______________________________________

From report at bugs.python.org  Wed Dec 16 05:47:58 2020
From: report at bugs.python.org (xz_sophos)
Date: Wed, 16 Dec 2020 10:47:58 +0000
Subject: [issue42657] Python 3.9.1 building process could not use local
 standard library
Message-ID: <1608115678.17.0.390785883077.issue42657@roundup.psfhosted.org>


New submission from xz_sophos <xing.zhang at sophos.com>:

When trying to build python 3.9.1 on Mac OSX 10.15, one of the building step by make is to run this command: 

DYLD_FRAMEWORK_PATH=/Users/jenkins/BaseFolder/savmac-python ./python.exe -E -S -m sysconfig --generate-posix-vars ;\
 	if test $? -ne 0 ; then \
 		echo "generate-posix-vars failed" ; \
 		rm -f ./pybuilddir.txt ; \
 		exit 1 ; \
 	fi

It would produce this error message: 

Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Python path configuration:
  PYTHONHOME = (not set)
  PYTHONPATH = (not set)
  program name = '/Library/Frameworks/Python.framework/Versions/3.7/bin/python3'
  isolated = 0
  environment = 0
  user site = 1
  import site = 0
  sys._base_executable = '/Library/Frameworks/Python.framework/Versions/3.7/bin/python3'
  sys.base_prefix = '/Users/jenkins/BaseFolder/savmac-python/sophos/tmp/Python.framework/Versions/3.9'
  sys.base_exec_prefix = '/Users/jenkins/BaseFolder/savmac-python/sophos/tmp/Python.framework/Versions/3.9'
  sys.platlibdir = 'lib'
  sys.executable = '/Library/Frameworks/Python.framework/Versions/3.7/bin/python3'
  sys.prefix = '/Users/jenkins/BaseFolder/savmac-python/sophos/tmp/Python.framework/Versions/3.9'
  sys.exec_prefix = '/Users/jenkins/BaseFolder/savmac-python/sophos/tmp/Python.framework/Versions/3.9'
  sys.path = [
    '/Users/jenkins/BaseFolder/savmac-python/sophos/tmp/Python.framework/Versions/3.9/lib/python39.zip',
    '/Users/jenkins/BaseFolder/savmac-python/sophos/tmp/Python.framework/Versions/3.9/lib/python3.9',
    '/Users/jenkins/BaseFolder/savmac-python/sophos/tmp/Python.framework/Versions/3.9/lib/lib-dynload',
  ]
Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized
ModuleNotFoundError: No module named 'encodings'

Current thread 0x000000011668ddc0 (most recent call first):
<no Python frame>
15:08:54 stdout: generate-posix-vars failed
make: *** [pybuilddir.txt] Error 1


Please note that current working directory is : /Users/jenkins/BaseFolder/savmac-python

In the Mac, there is already a python 3.7 installed at: /Library/Frameworks/Python.framework/Versions/3.7/bin/python3

I wonder what's the root cause of the above ./python.exe error, as I don't have this error on a different MacOS 10.15 with an existing installation of "python launcher.app" (version 3.9.1)

----------
components: macOS
messages: 383144
nosy: ned.deily, ronaldoussoren, xz_sophos
priority: normal
severity: normal
status: open
title: Python 3.9.1 building process could not use local standard library
type: compile error
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42657>
_______________________________________

From report at bugs.python.org  Wed Dec 16 05:51:05 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 16 Dec 2020 10:51:05 +0000
Subject: [issue42644] logging.disable('WARN') breaks AsyncIO
In-Reply-To: <1608026446.25.0.329181114873.issue42644@roundup.psfhosted.org>
Message-ID: <1608115865.59.0.310864442125.issue42644@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42644>
_______________________________________

From report at bugs.python.org  Wed Dec 16 05:54:24 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 16 Dec 2020 10:54:24 +0000
Subject: [issue19733] Setting image parameter of a button crashes with Cocoa Tk
In-Reply-To: <1385212186.78.0.599244063108.issue19733@psf.upfronthosting.co.za>
Message-ID: <1608116064.72.0.277894441236.issue19733@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset cd7412e3c4a2805009d0baa948cd4026d6fa6f3d by Miss Islington (bot) in branch '3.9':
bpo-19733: Re-enable tests for -image option in Tkinter (GH-23785)
https://github.com/python/cpython/commit/cd7412e3c4a2805009d0baa948cd4026d6fa6f3d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19733>
_______________________________________

From report at bugs.python.org  Wed Dec 16 06:01:05 2020
From: report at bugs.python.org (=?utf-8?b?6ZuF6Zuv?=)
Date: Wed, 16 Dec 2020 11:01:05 +0000
Subject: [issue19733] Setting image parameter of a button crashes with Cocoa Tk
In-Reply-To: <1385212186.78.0.599244063108.issue19733@psf.upfronthosting.co.za>
Message-ID: <1608116465.74.0.353653812066.issue19733@roundup.psfhosted.org>


?? <zhtw1234 at gmail.com> added the comment:

?zhtw1234

----------
hgrepos: +395
nosy: +zhtw1234
Added file: https://bugs.python.org/file49686/IMAG0215(5).jpg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19733>
_______________________________________

From report at bugs.python.org  Wed Dec 16 06:03:39 2020
From: report at bugs.python.org (=?utf-8?b?6ZuF6Zuv?=)
Date: Wed, 16 Dec 2020 11:03:39 +0000
Subject: [issue19733] Setting image parameter of a button crashes with Cocoa Tk
In-Reply-To: <1385212186.78.0.599244063108.issue19733@psf.upfronthosting.co.za>
Message-ID: <1608116619.44.0.585672183285.issue19733@roundup.psfhosted.org>


?? <zhtw1234 at gmail.com> added the comment:

???

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19733>
_______________________________________

From report at bugs.python.org  Wed Dec 16 06:04:08 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 16 Dec 2020 11:04:08 +0000
Subject: [issue19733] Setting image parameter of a button crashes with Cocoa Tk
In-Reply-To: <1385212186.78.0.599244063108.issue19733@psf.upfronthosting.co.za>
Message-ID: <1608116648.73.0.901137518318.issue19733@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
Removed message: https://bugs.python.org/msg383146

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19733>
_______________________________________

From report at bugs.python.org  Wed Dec 16 06:04:40 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 16 Dec 2020 11:04:40 +0000
Subject: [issue19733] Setting image parameter of a button crashes with Cocoa Tk
In-Reply-To: <1385212186.78.0.599244063108.issue19733@psf.upfronthosting.co.za>
Message-ID: <1608116680.33.0.0843312227017.issue19733@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
Removed message: https://bugs.python.org/msg383147

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19733>
_______________________________________

From report at bugs.python.org  Wed Dec 16 06:05:50 2020
From: report at bugs.python.org (=?utf-8?b?6ZuF6Zuv?=)
Date: Wed, 16 Dec 2020 11:05:50 +0000
Subject: [issue19733] Setting image parameter of a button crashes with Cocoa Tk
In-Reply-To: <1385212186.78.0.599244063108.issue19733@psf.upfronthosting.co.za>
Message-ID: <1608116750.28.0.619192567951.issue19733@roundup.psfhosted.org>


?? <zhtw1234 at gmail.com> added the comment:

?????

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19733>
_______________________________________

From report at bugs.python.org  Wed Dec 16 06:06:41 2020
From: report at bugs.python.org (Julien Palard)
Date: Wed, 16 Dec 2020 11:06:41 +0000
Subject: [issue42238] Deprecate suspicious.py?
In-Reply-To: <1604274563.95.0.828690163802.issue42238@roundup.psfhosted.org>
Message-ID: <1608116801.31.0.606198841944.issue42238@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:

Today I spotted one error that suspicious could have spotted:

    -both ``Callable``s no longer validate their ``argtypes``, in 
    +both ``Callable``\ s no longer validate their ``argtypes``, in 

I'm fixing it in https://github.com/python/cpython/pull/23800 

`make suspicious` found it as:

    [whatsnew/changelog:23] "`" found in "Callable``s no longer validate their ``argtypes"

So I'll doodle around this to see if tools/rstlint.py or Sphinx itself can see the error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42238>
_______________________________________

From report at bugs.python.org  Wed Dec 16 06:10:22 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 16 Dec 2020 11:10:22 +0000
Subject: [issue19733] Setting image parameter of a button crashes with Cocoa Tk
In-Reply-To: <1385212186.78.0.599244063108.issue19733@psf.upfronthosting.co.za>
Message-ID: <1608117022.59.0.979418630501.issue19733@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
Removed message: https://bugs.python.org/msg383148

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19733>
_______________________________________

From report at bugs.python.org  Wed Dec 16 06:10:47 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 16 Dec 2020 11:10:47 +0000
Subject: [issue19733] Setting image parameter of a button crashes with Cocoa Tk
In-Reply-To: <1385212186.78.0.599244063108.issue19733@psf.upfronthosting.co.za>
Message-ID: <1608117047.44.0.59176723748.issue19733@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


Removed file: https://bugs.python.org/file49686/IMAG0215(5).jpg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19733>
_______________________________________

From report at bugs.python.org  Wed Dec 16 06:11:24 2020
From: report at bugs.python.org (Ned Deily)
Date: Wed, 16 Dec 2020 11:11:24 +0000
Subject: [issue19733] Setting image parameter of a button crashes with Cocoa Tk
In-Reply-To: <1385212186.78.0.599244063108.issue19733@psf.upfronthosting.co.za>
Message-ID: <1608117084.37.0.875512120724.issue19733@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
hgrepos:  -395

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19733>
_______________________________________

From report at bugs.python.org  Wed Dec 16 06:11:38 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 11:11:38 +0000
Subject: [issue40364] asyncio: replace _compute_returncode() with
 os.waitstatus_to_exitcode()
In-Reply-To: <1587574271.75.0.606427962214.issue40364@roundup.psfhosted.org>
Message-ID: <1608117098.74.0.0948330435307.issue40364@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 99d28c56708bff1f442e1df5748adb2620542c61 by Victor Stinner in branch 'master':
bpo-40364: asyncio uses os.waitstatus_to_exitcode() (GH-23798)
https://github.com/python/cpython/commit/99d28c56708bff1f442e1df5748adb2620542c61


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40364>
_______________________________________

From report at bugs.python.org  Wed Dec 16 06:11:45 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 11:11:45 +0000
Subject: [issue40364] asyncio: replace _compute_returncode() with
 os.waitstatus_to_exitcode()
In-Reply-To: <1587574271.75.0.606427962214.issue40364@roundup.psfhosted.org>
Message-ID: <1608117105.48.0.964244070478.issue40364@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10 -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40364>
_______________________________________

From report at bugs.python.org  Wed Dec 16 06:12:42 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 11:12:42 +0000
Subject: [issue42613] freeze.py doesn't support sys.platlibdir different than
 lib nor multiarch
In-Reply-To: <1607594518.8.0.0823964738983.issue42613@roundup.psfhosted.org>
Message-ID: <1608117162.59.0.811138771255.issue42613@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 1c653f17cb84d81df3a74ab0b42140d2bb68c5c4 by Victor Stinner in branch 'master':
bpo-42613: Fix freeze.py config directory (GH-23792)
https://github.com/python/cpython/commit/1c653f17cb84d81df3a74ab0b42140d2bb68c5c4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42613>
_______________________________________

From report at bugs.python.org  Wed Dec 16 06:13:01 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 11:13:01 +0000
Subject: [issue42613] freeze.py doesn't support sys.platlibdir different than
 lib nor multiarch
In-Reply-To: <1607594518.8.0.0823964738983.issue42613@roundup.psfhosted.org>
Message-ID: <1608117181.49.0.562894298.issue42613@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42613>
_______________________________________

From report at bugs.python.org  Wed Dec 16 06:16:26 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 16 Dec 2020 11:16:26 +0000
Subject: [issue42115] Caching infrastructure for the evaluation loop:
 specialised opcodes
In-Reply-To: <1603336898.74.0.366564812208.issue42115@roundup.psfhosted.org>
Message-ID: <1608117386.86.0.258962976181.issue42115@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Oh, I am quite confused about what's going on with pidigits and regex_v8. I will try to run the benchmarks again. Did you compare the current master against the PR? If that's the case we should rebase the PR it first to make sure we are comparing it correctly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42115>
_______________________________________

From report at bugs.python.org  Wed Dec 16 06:16:49 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 11:16:49 +0000
Subject: [issue42613] freeze.py doesn't support sys.platlibdir different than
 lib nor multiarch
In-Reply-To: <1607594518.8.0.0823964738983.issue42613@roundup.psfhosted.org>
Message-ID: <1608117409.17.0.66908368676.issue42613@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I tested my fix with these commands:
---
./configure --with-platlibdir=lib64 --enable-shared --prefix /opt/py310 CFLAGS="-O0"
make
make install
# move outside CPython source tree
cd

mkdir hello
cd hello
echo 'print("hello")' > hello.py

cp -R  ~/python/master/Tools/freeze/ .
LD_LIBRARY_PATH=/opt/py310/lib /opt/py310/bin/python3.10 freeze/freeze.py hello.py
---

Output:
---
$ LD_LIBRARY_PATH=/opt/py310/lib ./hello 
hello
---

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42613>
_______________________________________

From report at bugs.python.org  Wed Dec 16 06:17:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 11:17:17 +0000
Subject: [issue42591] Method Py_FrozenMain missing in libpython3.9
In-Reply-To: <1607356833.89.0.498069278584.issue42591@roundup.psfhosted.org>
Message-ID: <1608117437.0.0.17212293666.issue42591@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Christian Bachmaier:
> The symlink does the trick. So it may be easy for you to fix that, so it does operate out of the box again.

I pushed a fix in bpo-42613. It would be great if you could test it.

See my manual test: https://bugs.python.org/issue42613#msg383153

If you can test it, I can backport the fix to stable branches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42591>
_______________________________________

From report at bugs.python.org  Wed Dec 16 06:20:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 11:20:41 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1608117641.49.0.0795134124654.issue1635741@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 8203c73f3bb1f51614279b6e23af2ec587d1fa22 by Victor Stinner in branch 'master':
bpo-1635741: Refactor _threadmodule.c (GH-23793)
https://github.com/python/cpython/commit/8203c73f3bb1f51614279b6e23af2ec587d1fa22


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Wed Dec 16 07:11:30 2020
From: report at bugs.python.org (Christian Bachmaier)
Date: Wed, 16 Dec 2020 12:11:30 +0000
Subject: [issue42591] Method Py_FrozenMain missing in libpython3.9
In-Reply-To: <1607356833.89.0.498069278584.issue42591@roundup.psfhosted.org>
Message-ID: <1608120690.06.0.657697914404.issue42591@roundup.psfhosted.org>


Christian Bachmaier <chris at infosun.fim.uni-passau.de> added the comment:

Vistor Stinner:
> If you can test it, I can backport the fix to stable branches.

Seems to work like a charm. Basically I used the same testing setup as previously on Dec 10th under Debian testing/bullseye without step 2, as master already contains your fix.

Victor, many thanks again, you are great!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42591>
_______________________________________

From report at bugs.python.org  Wed Dec 16 07:11:38 2020
From: report at bugs.python.org (Philipp Gortan)
Date: Wed, 16 Dec 2020 12:11:38 +0000
Subject: [issue40821] os.getlogin() not working
In-Reply-To: <1590784290.42.0.113469889536.issue40821@roundup.psfhosted.org>
Message-ID: <1608120698.9.0.33558738779.issue40821@roundup.psfhosted.org>


Change by Philipp Gortan <mephinet at gmx.net>:


----------
nosy: +mephinet

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40821>
_______________________________________

From report at bugs.python.org  Wed Dec 16 07:18:25 2020
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 16 Dec 2020 12:18:25 +0000
Subject: [issue42615] Redundant jump instructions due to deleted unreachable
 bytecode blocks
In-Reply-To: <1607618833.17.0.897209602583.issue42615@roundup.psfhosted.org>
Message-ID: <1608121105.57.0.772285704091.issue42615@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset c71581c7a4192e6ba9a79eccc583aaadab300efa by Om G in branch 'master':
bpo-42615: Delete redundant jump instructions that only bypass empty blocks (GH-23733)
https://github.com/python/cpython/commit/c71581c7a4192e6ba9a79eccc583aaadab300efa


----------
nosy: +Mark.Shannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42615>
_______________________________________

From report at bugs.python.org  Wed Dec 16 07:25:47 2020
From: report at bugs.python.org (Steve Dower)
Date: Wed, 16 Dec 2020 12:25:47 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1608121547.01.0.0139268063831.issue42529@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Sorry, I haven't had a chance to set up a test machine with all the requirements.

It's almost certainly something in jpype, to be clear. Most likely it loads a DLL that hasn't been loaded yet, but does it under conditions where it won't load. Nothing we build as part of CPython should do anything interesting on load, at least nothing we can change/fix. So jpype will probably need an update to import something manually.

The only thing I can think of that changed along these lines in 3.9.0 is that we no longer LoadLibrary("api-ms-win-core-path-l1-1-0.dll") at startup (because we can assume that it's present now). That shouldn't matter at all unless jpype is doing some really weird stuff, as it's a system library with no code. But maybe it'll give someone a hint who knows the module better?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Wed Dec 16 07:29:22 2020
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 16 Dec 2020 12:29:22 +0000
Subject: [issue42246] Implement PEP 626 -- Precise line numbers for debugging
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1608121762.45.0.92354305698.issue42246@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

https://github.com/python/cpython/pull/23780 fixes the finally handling.
The if-break case was fixed by earlier changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42246>
_______________________________________

From report at bugs.python.org  Wed Dec 16 07:31:56 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 16 Dec 2020 12:31:56 +0000
Subject: [issue42115] Caching infrastructure for the evaluation loop:
 specialised opcodes
In-Reply-To: <1603336898.74.0.366564812208.issue42115@roundup.psfhosted.org>
Message-ID: <1608121916.03.0.309516121964.issue42115@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

OK, I have repeated the benchmarks after rebasing and this is what I get:

venv ? python -m pyperf compare_to json/2020-12-16_11-20-master-8203c73f3bb1.json.gz json/2020-12-16_11-22-load_method-21b1566125b3.json.gz -G --min-speed=1
Slower (13):
- regex_v8: 30.5 ms +- 0.1 ms -> 32.8 ms +- 0.2 ms: 1.08x slower (+8%)
- pidigits: 253 ms +- 0 ms -> 264 ms +- 0 ms: 1.05x slower (+5%)
- richards: 84.1 ms +- 1.1 ms -> 87.4 ms +- 1.4 ms: 1.04x slower (+4%)
- fannkuch: 573 ms +- 2 ms -> 589 ms +- 14 ms: 1.03x slower (+3%)
- regex_effbot: 3.87 ms +- 0.03 ms -> 3.98 ms +- 0.05 ms: 1.03x slower (+3%)
- scimark_sor: 223 ms +- 4 ms -> 227 ms +- 2 ms: 1.02x slower (+2%)
- pathlib: 20.9 ms +- 0.2 ms -> 21.3 ms +- 0.3 ms: 1.02x slower (+2%)
- regex_compile: 209 ms +- 1 ms -> 212 ms +- 3 ms: 1.01x slower (+1%)
- xml_etree_process: 93.7 ms +- 0.7 ms -> 94.9 ms +- 1.1 ms: 1.01x slower (+1%)
- nqueens: 122 ms +- 1 ms -> 123 ms +- 1 ms: 1.01x slower (+1%)
- regex_dna: 263 ms +- 1 ms -> 266 ms +- 1 ms: 1.01x slower (+1%)
- django_template: 56.1 ms +- 0.4 ms -> 56.7 ms +- 0.4 ms: 1.01x slower (+1%)
- raytrace: 566 ms +- 7 ms -> 572 ms +- 6 ms: 1.01x slower (+1%)

Faster (15):
- unpack_sequence: 80.4 ns +- 0.9 ns -> 70.8 ns +- 0.8 ns: 1.14x faster (-12%)
- scimark_sparse_mat_mult: 6.26 ms +- 0.02 ms -> 5.97 ms +- 0.06 ms: 1.05x faster (-5%)
- pickle_pure_python: 547 us +- 5 us -> 523 us +- 5 us: 1.05x faster (-4%)
- unpickle: 17.7 us +- 0.1 us -> 17.0 us +- 0.2 us: 1.04x faster (-4%)
- mako: 20.0 ms +- 0.1 ms -> 19.5 ms +- 0.1 ms: 1.02x faster (-2%)
- unpickle_pure_python: 361 us +- 4 us -> 353 us +- 4 us: 1.02x faster (-2%)
- logging_simple: 9.59 us +- 0.14 us -> 9.39 us +- 0.12 us: 1.02x faster (-2%)
- scimark_fft: 462 ms +- 4 ms -> 455 ms +- 4 ms: 1.02x faster (-2%)
- chameleon: 11.6 ms +- 0.2 ms -> 11.4 ms +- 0.1 ms: 1.02x faster (-2%)
- pickle: 13.0 us +- 0.1 us -> 12.8 us +- 0.1 us: 1.02x faster (-1%)
- telco: 8.30 ms +- 0.23 ms -> 8.18 ms +- 0.14 ms: 1.01x faster (-1%)
- go: 277 ms +- 2 ms -> 274 ms +- 2 ms: 1.01x faster (-1%)
- pickle_list: 5.30 us +- 0.07 us -> 5.23 us +- 0.06 us: 1.01x faster (-1%)
- logging_format: 10.3 us +- 0.1 us -> 10.2 us +- 0.1 us: 1.01x faster (-1%)
- meteor_contest: 136 ms +- 0 ms -> 134 ms +- 1 ms: 1.01x faster (-1%)

Benchmark hidden because not significant (32): 2to3, chaos, crypto_pyaes, deltablue, dulwich_log, float, genshi_text, genshi_xml, hexiom, json_dumps, json_loads, logging_silent, nbody, pickle_dict, pyflate, python_startup, python_startup_no_site, scimark_lu, scimark_monte_carlo, spectral_norm, sqlalchemy_declarative, sqlalchemy_imperative, sqlite_synth, sympy_expand, sympy_integrate, sympy_sum, sympy_str, tornado_http, unpickle_list, xml_etree_parse, xml_etree_iterparse, xml_etree_generate

----------
Added file: https://bugs.python.org/file49687/result.zip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42115>
_______________________________________

From report at bugs.python.org  Wed Dec 16 07:32:22 2020
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 16 Dec 2020 12:32:22 +0000
Subject: [issue40821] os.getlogin() not working
In-Reply-To: <1590784290.42.0.113469889536.issue40821@roundup.psfhosted.org>
Message-ID: <1608121942.56.0.356099712775.issue40821@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:

errno 6 is ENXIO. According to https://www.man7.org/linux/man-pages/man3/getlogin.3.html the error code means "The calling process has no controlling terminal.".

os.getlogin() returns the name of the user logged in on the controlling terminal of the process. Typically processes in user session (tty, X session) have a controlling terminal. Processes spawned by a service manager like init, systemd, or upstart usually do not have a controlling terminal. You have to get the user information by other means. Our documentation for os.getlogin() recommends getpass.getuser().

----------
resolution:  -> not a bug
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40821>
_______________________________________

From report at bugs.python.org  Wed Dec 16 07:33:04 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 16 Dec 2020 12:33:04 +0000
Subject: [issue42115] Caching infrastructure for the evaluation loop:
 specialised opcodes
In-Reply-To: <1603336898.74.0.366564812208.issue42115@roundup.psfhosted.org>
Message-ID: <1608121984.44.0.975465980185.issue42115@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I think I am closing the PR as it seems that the gains are not good enough (and there is quite a lot of noise by comparing the benchmarks together).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42115>
_______________________________________

From report at bugs.python.org  Wed Dec 16 07:44:26 2020
From: report at bugs.python.org (sogom)
Date: Wed, 16 Dec 2020 12:44:26 +0000
Subject: [issue42658] os.path.normcase() is inconsistent with Windows file
 system
Message-ID: <1608122666.52.0.137113409131.issue42658@roundup.psfhosted.org>


New submission from sogom <sogom at outlook.jp>:

On Windows file system, U+03A9 (Greek capital letter Omega) and U+2126 (Ohm sign) are distinguished. In fact, two distinct files "\u03A9.txt" and "\u2126.txt" can exist side by side in the same folder. But os.path.normcase() transforms both U+03A9 and U+2126 to U+03C9 (Greek small letter omega).

MSDN reads they use CompareStringOrdinal() to compare NTFS file names: https://docs.microsoft.com/en-us/windows/win32/intl/handling-sorting-in-your-applications#sort-strings-ordinally . This document also says "the function maps case using the operating system *uppercasing* table." But I made an experiment and found that at least in the Basic Multilingual Plane, "lowercase two strings by means of LCMapStringEx() and then wcscmp the two" always gives the same result as "compare the two strings with CompareStringOrdinal()". Though this fact is not explicitly mentioned in MSDN https://docs.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-lcmapstringex , the description of LCMAP_LINGUISTIC_CASING in this page implies that casing rules conform to file system's unless LCMAP_LINGUISTIC_CASING is used.

Therefore, I believe that os.path.normcase() should probably call LCMapStringEx(), with the first argument LOCALE_NAME_INVARIANT and the second argument LCMAP_LOWERCASE.

----------
components: Windows
messages: 383163
nosy: paul.moore, sogom, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.path.normcase() is inconsistent with Windows file system
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42658>
_______________________________________

From report at bugs.python.org  Wed Dec 16 07:59:41 2020
From: report at bugs.python.org (Mario Corchero)
Date: Wed, 16 Dec 2020 12:59:41 +0000
Subject: [issue42654] Add folder for python customizations: __sitecustomize__
In-Reply-To: <1608111763.27.0.89032945983.issue42654@roundup.psfhosted.org>
Message-ID: <1608123581.61.0.688947194772.issue42654@roundup.psfhosted.org>


Mario Corchero <mariocj89 at gmail.com> added the comment:

Thread open in Python ideas: https://discuss.python.org/t/add-folder-for-python-customizations-sitecustomize/6190/5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42654>
_______________________________________

From report at bugs.python.org  Wed Dec 16 08:07:11 2020
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 16 Dec 2020 13:07:11 +0000
Subject: [issue42645] break/continue or return in finally block occurs twice
 in trace.
In-Reply-To: <1608034892.59.0.529132946554.issue42645@roundup.psfhosted.org>
Message-ID: <1608124031.7.0.833992535862.issue42645@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset 5274b682bc93a04da8a69742528ac7f64633a96e by Mark Shannon in branch 'master':
bpo-42645: Make sure that return/break/continue are only traced once when exiting via a finally block. (GH-23780)
https://github.com/python/cpython/commit/5274b682bc93a04da8a69742528ac7f64633a96e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42645>
_______________________________________

From report at bugs.python.org  Wed Dec 16 09:08:32 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 14:08:32 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1608127712.1.0.0588097946591.issue1635741@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset fcc6935384b933fbe1a1ef659ed455a3b74c849a by Victor Stinner in branch 'master':
Add symbols of the stable ABI to python3dll.c (GH-23598)
https://github.com/python/cpython/commit/fcc6935384b933fbe1a1ef659ed455a3b74c849a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Wed Dec 16 09:08:32 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 14:08:32 +0000
Subject: [issue40421] [C API] Add getter functions for PyFrameObject and maybe
 move PyFrameObject to the internal C API
In-Reply-To: <1588079870.34.0.984904607646.issue40421@roundup.psfhosted.org>
Message-ID: <1608127712.04.0.333423288369.issue40421@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset fcc6935384b933fbe1a1ef659ed455a3b74c849a by Victor Stinner in branch 'master':
Add symbols of the stable ABI to python3dll.c (GH-23598)
https://github.com/python/cpython/commit/fcc6935384b933fbe1a1ef659ed455a3b74c849a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40421>
_______________________________________

From report at bugs.python.org  Wed Dec 16 09:08:32 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 14:08:32 +0000
Subject: [issue39947] [C API] Make the PyThreadState structure opaque (move it
 to the internal C API)
In-Reply-To: <1584035214.47.0.672795796186.issue39947@roundup.psfhosted.org>
Message-ID: <1608127712.28.0.60533840868.issue39947@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset fcc6935384b933fbe1a1ef659ed455a3b74c849a by Victor Stinner in branch 'master':
Add symbols of the stable ABI to python3dll.c (GH-23598)
https://github.com/python/cpython/commit/fcc6935384b933fbe1a1ef659ed455a3b74c849a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39947>
_______________________________________

From report at bugs.python.org  Wed Dec 16 09:08:31 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 14:08:31 +0000
Subject: [issue37194] Move new vector private declarations to the internal C
 API
In-Reply-To: <1559908440.37.0.746705371355.issue37194@roundup.psfhosted.org>
Message-ID: <1608127711.95.0.452860134378.issue37194@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset fcc6935384b933fbe1a1ef659ed455a3b74c849a by Victor Stinner in branch 'master':
Add symbols of the stable ABI to python3dll.c (GH-23598)
https://github.com/python/cpython/commit/fcc6935384b933fbe1a1ef659ed455a3b74c849a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37194>
_______________________________________

From report at bugs.python.org  Wed Dec 16 09:15:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 14:15:17 +0000
Subject: [issue37194] Move new vector private declarations to the internal C
 API
In-Reply-To: <1559908440.37.0.746705371355.issue37194@roundup.psfhosted.org>
Message-ID: <1608128117.59.0.524168133358.issue37194@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22660
pull_request: https://github.com/python/cpython/pull/23801

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37194>
_______________________________________

From report at bugs.python.org  Wed Dec 16 09:15:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 14:15:17 +0000
Subject: [issue39947] [C API] Make the PyThreadState structure opaque (move it
 to the internal C API)
In-Reply-To: <1584035214.47.0.672795796186.issue39947@roundup.psfhosted.org>
Message-ID: <1608128117.65.0.421391258534.issue39947@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22661
pull_request: https://github.com/python/cpython/pull/23801

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39947>
_______________________________________

From report at bugs.python.org  Wed Dec 16 09:15:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 14:15:17 +0000
Subject: [issue42415] python3.lib in Python3.9.0 Windows distribution does not
 contain PyObject_CallNoArgs symbol
In-Reply-To: <1605826065.75.0.910654545311.issue42415@roundup.psfhosted.org>
Message-ID: <1608128117.33.0.824000722743.issue42415@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
nosy: +vstinner
nosy_count: 7.0 -> 8.0
pull_requests: +22658
pull_request: https://github.com/python/cpython/pull/23801

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42415>
_______________________________________

From report at bugs.python.org  Wed Dec 16 09:15:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 14:15:17 +0000
Subject: [issue40421] [C API] Add getter functions for PyFrameObject and maybe
 move PyFrameObject to the internal C API
In-Reply-To: <1588079870.34.0.984904607646.issue40421@roundup.psfhosted.org>
Message-ID: <1608128117.52.0.383234737858.issue40421@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22659
pull_request: https://github.com/python/cpython/pull/23801

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40421>
_______________________________________

From report at bugs.python.org  Wed Dec 16 09:17:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 14:17:17 +0000
Subject: [issue42415] python3.lib in Python3.9.0 Windows distribution does not
 contain PyObject_CallNoArgs symbol
In-Reply-To: <1605826065.75.0.910654545311.issue42415@roundup.psfhosted.org>
Message-ID: <1608128237.68.0.876194791235.issue42415@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

commit fcc6935384b933fbe1a1ef659ed455a3b74c849a
Author: Victor Stinner <vstinner at python.org>
Date:   Wed Dec 16 15:08:23 2020 +0100

    Add symbols of the stable ABI to python3dll.c (GH-23598)
    
    Add the following symbols to python3dll.c:
    
    * PyFrame_GetCode (bpo-40421)
    * PyFrame_GetLineNumber (bpo-40421)
    * PyModule_AddObjectRef (bpo-1635741)
    * PyObject_CallNoArgs (bpo-37194)
    * PyThreadState_GetFrame (bpo-39947)
    * PyThreadState_GetID (bpo-39947)
    * PyThreadState_GetInterpreter (bpo-39947)

I backported the change manually to 3.9: PR 23801.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42415>
_______________________________________

From report at bugs.python.org  Wed Dec 16 09:20:05 2020
From: report at bugs.python.org (Julien Palard)
Date: Wed, 16 Dec 2020 14:20:05 +0000
Subject: [issue42238] Deprecate suspicious.py?
In-Reply-To: <1604274563.95.0.828690163802.issue42238@roundup.psfhosted.org>
Message-ID: <1608128405.54.0.0365907282938.issue42238@roundup.psfhosted.org>


Change by Julien Palard <julien+python at palard.fr>:


----------
pull_requests: +22662
pull_request: https://github.com/python/cpython/pull/23802

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42238>
_______________________________________

From report at bugs.python.org  Wed Dec 16 09:29:48 2020
From: report at bugs.python.org (Julien Palard)
Date: Wed, 16 Dec 2020 14:29:48 +0000
Subject: [issue42238] Deprecate suspicious.py?
In-Reply-To: <1604274563.95.0.828690163802.issue42238@roundup.psfhosted.org>
Message-ID: <1608128988.76.0.672016442269.issue42238@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:

I created https://github.com/python/cpython/pull/23802 with a port of the "wrong backtick detector" (at least, one aspect from it) from suspicious to rstlint.

I dropped the suspicious check three weeks ago, and found a single committed issue since then, which was fixable (and is fixed) in rstlint, so I'll continue this experience and see where it goes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42238>
_______________________________________

From report at bugs.python.org  Wed Dec 16 09:34:05 2020
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 16 Dec 2020 14:34:05 +0000
Subject: [issue42033] Seemingly unnecessary complexification of foo(**kw)
In-Reply-To: <1602672511.92.0.360571035375.issue42033@roundup.psfhosted.org>
Message-ID: <1608129245.74.0.0652595324485.issue42033@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Even if making a copy is necessary when the underlying function receives the dict "raw", preemptively performing the copy (before knowing if the function being called is a Vectorcall function) means that when it's a Vectorcall function (e.g. all user-defined functions, right?), instead of just copying from the original dict to the unpacked stack for vectorcall, it makes an intermediate copy, then copies from that copy to the unpacked stack later on; the copy is otherwise completely unused.

The extra bytecode isn't even defending against "dict-like" kwargs, because CALL_FUNCTION_EX itself already copies to a true dict for anything that's not an exact dict (that defense shouldn't even be there if the bytecode compiler is already guaranteeing a true dict).

Seems like, if preventing the caller's dict from being passed directly to the underlying function is necessary and intended, it should be done in PyObject_Call (which can avoid the copy entirely when call a Vectorcall function and when the reference count on the dict is 1), not at the bytecode interpreter layer. As is, PyObject_Call is already violating the documented behavior by *not* matching the behavior of callable(*args, **kwargs) (see #42629), so moving it to PyObject_Call would fix that problem and improve performance passing a single kwargs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42033>
_______________________________________

From report at bugs.python.org  Wed Dec 16 09:42:35 2020
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 16 Dec 2020 14:42:35 +0000
Subject: [issue42629] PyObject_Call not behaving as documented
In-Reply-To: <1607818885.74.0.707505524552.issue42629@roundup.psfhosted.org>
Message-ID: <1608129755.65.0.601953671024.issue42629@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

Pingback from #42033. Proper fix for that issue likely involves moving the work for copying kwargs into PyObject_Call, which would fix this bug by side-effect.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42629>
_______________________________________

From report at bugs.python.org  Wed Dec 16 09:43:48 2020
From: report at bugs.python.org (Om G)
Date: Wed, 16 Dec 2020 14:43:48 +0000
Subject: [issue42615] Redundant jump instructions due to deleted unreachable
 bytecode blocks
In-Reply-To: <1607618833.17.0.897209602583.issue42615@roundup.psfhosted.org>
Message-ID: <1608129828.98.0.309483378208.issue42615@roundup.psfhosted.org>


Change by Om G <im.omgupta+python at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42615>
_______________________________________

From report at bugs.python.org  Wed Dec 16 09:50:24 2020
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 16 Dec 2020 14:50:24 +0000
Subject: [issue42246] Implement PEP 626 -- Precise line numbers for debugging
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1608130224.68.0.162779606733.issue42246@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +22663
pull_request: https://github.com/python/cpython/pull/23803

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42246>
_______________________________________

From report at bugs.python.org  Wed Dec 16 10:12:58 2020
From: report at bugs.python.org (CrocoDuck)
Date: Wed, 16 Dec 2020 15:12:58 +0000
Subject: [issue42659] Objects of uname_result Class Cannot be Successfully
 Pickled
Message-ID: <1608131578.78.0.823168956156.issue42659@roundup.psfhosted.org>


New submission from CrocoDuck <crocoduck.oducks at gmail.com>:

See the code example below.

```python
import platform
import pickle

pack = {
    'uname_result': platform.uname()
}

with open('test.pickle', 'wb') as f:
    pickle.dump(pack, f, protocol=pickle.HIGHEST_PROTOCOL)

with open('test.pickle', 'rb') as f:
    data = pickle.load(f)

```

It works smoothly on Python 3.8.5. However, on Python 3.9.0, the last line produces this error:

```
Traceback (most recent call last):
  File "/Users/crocoduck/pickle/3.9.0/make_pickle.py", line 12, in <module>
    data = pickle.load(f)
TypeError: <lambda>() takes 6 positional arguments but 7 were given
```

The files produced by the code snipped above are attached for reference.

This was observed in macOS Catalina 10.15.7.

----------
files: pickles.zip
messages: 383174
nosy: CrocoDuck
priority: normal
severity: normal
status: open
title: Objects of uname_result Class Cannot be Successfully Pickled
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49688/pickles.zip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42659>
_______________________________________

From report at bugs.python.org  Wed Dec 16 10:25:07 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 15:25:07 +0000
Subject: [issue40686] Compiler warnings in _zoneinfo.c on Windows build in
 64-bit
In-Reply-To: <1589906488.33.0.285207996013.issue40686@roundup.psfhosted.org>
Message-ID: <1608132307.93.0.805711682637.issue40686@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The problem can be simplified to this x.c file:
---
static int invalid_day(unsigned int day)
{
    return (day < 0 || day > 6);
}

int main()
{
    invalid_day(3);
    return 0;
}
---

GCC emits the warning:

$ gcc x.c -o x -O3 -Wall -Wextra
x.c: In function 'invalid_day':
x.c:3:17: warning: comparison of unsigned expression in '< 0' is always false [-Wtype-limits]
    3 |     return (day < 0 || day > 6);
      |                 ^

There are different options to avoid the warning:


(A) Remove "day < 0" test

Easiest option, portable, simple: my PR 23614.


(B) Disable compiler warnings on the test

Solution currently implemented with pragma + PR 20619 to fix pragmas.


(C) Cast the 'day' variable to a signed type

I understand that Paul wants the code to be as generic as possible, and not depending on the "day" parameter type. For example, casting to "int8_t" may introduce a risk of integer overflow if day type is larger than 8 bits. Not my favorite option.


(D) Make "day < 0" conditional depending if day type is signed or not
(E) Check that day type is unsigned to ensure indirectly that "day >= 0"

Checking if *a type* is signed or not is easy using the C preprocessor:

#define _Py_IS_TYPE_UNSIGNED(type) (((type)-1) > (type)0) 

The problem is that there is no standard function to get a variable type. GCC and clang provide the __typeof__(var) extension, C++ provides decltype(var) (but CPython code base cannot be built with a C++ compiler if I recall correctly).

Paul's PR 20624 introduces Py_ASSERT_VAR_UNSIGNED(var) macro which fails during compilation if the variable is unsigned, or does nothing if the compiler doesn't provide a way to get a variable type (ex: MSC on Windows).


--


Most answers about "comparison of unsigned expression always false" question on the Internet are (A): remove the check which emits the warning.

My worry is also that outside _zoneinfo.c, they are tons of functions which rely on the fact that an unsigned type cannot be negativ. I don't want to start adding Py_ASSERT_VAR_UNSIGNED(). For me, it's part of the C language and there is no need to be explicit about it. If a developer changes a variable type, they have to check the type bounds and check of the variable is used.

I would prefer to be consistent and never check for "< 0" if the type is unsigned, nor ensure with an assertion that the type is unsigned.

Paul is in disagreement with that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40686>
_______________________________________

From report at bugs.python.org  Wed Dec 16 10:25:49 2020
From: report at bugs.python.org (Karl Nelson)
Date: Wed, 16 Dec 2020 15:25:49 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1608132349.09.0.350852588073.issue42529@roundup.psfhosted.org>


Karl Nelson <nelson85 at llnl.gov> added the comment:

I am fairly sure this is a Python "bug" in the sense that there was some change in undocumented change in requirements and the distutils pattern for building a module no longer reflects that requirement.   That said very likely JPype is the only module to be affected and thus I will have to manually adjust to account for the new requirement.

Unfortunately as far as developers, I am it so fixing it (with your assistance) is going to have to fall on me.  So lets do a run down of how this all working so you can point me where to look.

1) JPype gets built as an ordinary setup.py CPython module.  So it is possibly a bug in the build pattern of the customizers in JPype that was exposed by Python 3.9.   I am just going to cut and paste so that it is easy to follow along.

jpype/setup.py
```
...
from setuptools import Extension
...
import setupext
...
jpypeLib = Extension(name='_jpype', **setupext.platform.Platform(
    include_dirs=[Path('native', 'common', 'include'),
                  Path('native', 'python', 'include'),
                  Path('native', 'embedded', 'include')],
    sources=[Path('native', 'common', '*.cpp'),
             Path('native', 'python', '*.cpp'),
             Path('native', 'embedded', '*.cpp')], platform=platform,
))
```

We have two sets of customization in setup.py.  Both are included from a module called jpype/setupext/

The key one is the jpype/setupext/platform.py which defines the compiler flags.  There are two sections of interest...

jpype/setupext/platform.py contains these modifications for win32.   
(So there is the Advapi32, not sure why it appears there because this section is all before my time as this was started in 2001 and I joined in 2018)
```
    static = True
    if platform == 'win32':
        distutils.log.info("Add windows settings")
        platform_specific['libraries'] = ['Advapi32']
        platform_specific['define_macros'] = [('WIN32', 1)]
        if sys.version > '3':
            platform_specific['extra_compile_args'] = [
                '/Zi', '/EHsc', '/std:c++14']
        else:
            platform_specific['extra_compile_args'] = ['/Zi', '/EHsc']
        platform_specific['extra_link_args'] = ['/DEBUG']
        jni_md_platform = 'win32'
```

The second section is currently commented out.  Though it is relevant because JPype is exotic in one way.  It is a module which is loaded in three ways.   When imported from Python it is an ordinary library (1) which will later pull in Java which will then load library a second time (2) to bind Java native methods.   It can also be used to launch Python if Java starts the session (3).   In that case, it needs libpython.dll to be bound to module so that the Java equivalent to LoadLibrary can work.  When it does Java first manually loads libpython.dll then loads the module and calls the hook to get Python started. 
```
# This code is used to include python library in the build when starting Python from
# within Java.  It will be used in the future, but is not currently required.
#    if static and sysconfig.get_config_var('BLDLIBRARY') is not None:
#        platform_specific['extra_link_args'].append(sysconfig.get_config_var('BLDLIBRARY'))
```

The actual buildext has a few minor patches so that Java libraries can run through the normal process.  But nothing seems like a good candidate

We have one section tweeking some of the build options.
```
    def initialize_options(self, *args):
        """omit -Wstrict-prototypes from CFLAGS since its only valid for C code."""
        self.android = False
        self.makefile = False
        self.jar = False
        import distutils.sysconfig
        cfg_vars = distutils.sysconfig.get_config_vars()
        replacement = {
            '-Wstrict-prototypes': '',
            '-Wimplicit-function-declaration': '',
        }
        tracing = self.distribution.enable_tracing

        # Arguments to remove so we set debugging and optimization level
        remove_args = ['-O0', '-O1', '-O2', '-O3', '-g']

        for k, v in cfg_vars.items():
            if not isinstance(v, str):
                continue
            if not k == "OPT" and not "FLAGS" in k:
                continue

            args = v.split()
            for r in remove_args:
                args = list(filter((r).__ne__, args))

            cfg_vars[k] = " ".join(args)
        super().initialize_options()
```

Then later we interrupt the build process for Java.
```
    def build_extension(self, ext):
        if ext.language == "java":
            return self.build_java_ext(ext)
        if self.jar:
            return
        print("Call build ext")
        return super().build_extension(ext)
```

2) Next we have the module start.  I am guessing this is not the source of the error because adding a printf shows we never got to this point.

jpype/native/pyjp_module.cpp
```
PyMODINIT_FUNC PyInit__jpype()
{
        JP_PY_TRY("PyInit__jpype");
        JPContext_global = new JPContext();
        // This is required for python versions prior to 3.7.
        // It is called by the python initialization starting from 3.7,
        // but is safe to call afterwards.
        PyEval_InitThreads();

        // Initialize the module (depends on python version)
        PyObject* module = PyModule_Create(&moduledef);
        Py_INCREF(module);
        PyJPModule = module;
        PyModule_AddStringConstant(module, "__version__", "1.2.1_dev0");
         ... initialize a bunch of resources
     }

 ```

3) After this point we will start getting exotic.   JPype plugs into Python in with less that above board methods.  In order to operate it needs to derive a bunch of Python basic types in ways that the API does not allow. As Python does not support true multiple inheritance of concrete types and I need to add slots that should not exist, it will use a custom memory allocator to offset the addresses of object pointers such that a hidden Java slot appears on types type, object, long, double, exception, etc.  To do this it will forward declare some of the private Python symbols having to do with heap types and stacktrace frames, etc.   There is also one monkey patch for the "function" type in which it temporarily disables the "final" field so that we create a derived class that should not exist for Java methods, then restores the field immediately after.

This is relevant because if the symbols it is pulling in are missing for some reason then the dll will fail to load.   However, given it will load when it isn't compiled and not load when compiled there is not much chance the symbol table should be different.   Unless windows is really different from other architectures, this is a long shot.

3) Okay so on to module loading

```
import _jpype
```

This statement works when the debugger is attached, when called from a .py file but fails when called from a .pyc file.   I have looked at it all the way down to the byte code.   There appears to be nothing in JPype that is going into that process.  This just jumps straight into Python core code.

4) Post load a whole lot of stuff happens. We patch in the new types, and then use LoadLibrary to pull in jvm.dll.  As we work on many JVM versions and we won't know which is requested, JPype is not actually compiled against the jvm.  Instead it manually loads all its symbols using  GetProcAddress in jpype/native/jp_platform.cpp.

So that is all there is (dirty laundary and all).   Does anything look suspect?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Wed Dec 16 10:26:26 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 15:26:26 +0000
Subject: [issue40686] Compiler warnings in _zoneinfo.c on Windows build in
 64-bit
In-Reply-To: <1589906488.33.0.285207996013.issue40686@roundup.psfhosted.org>
Message-ID: <1608132386.42.0.126034111852.issue40686@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset aefb69b23f056c61e82ad228d950f348de090c70 by Victor Stinner in branch 'master':
bpo-40686: Fix compiler warnings on _zoneinfo.c (GH-23614)
https://github.com/python/cpython/commit/aefb69b23f056c61e82ad228d950f348de090c70


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40686>
_______________________________________

From report at bugs.python.org  Wed Dec 16 10:26:32 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 16 Dec 2020 15:26:32 +0000
Subject: [issue40686] Compiler warnings in _zoneinfo.c on Windows build in
 64-bit
In-Reply-To: <1589906488.33.0.285207996013.issue40686@roundup.psfhosted.org>
Message-ID: <1608132392.12.0.402329735458.issue40686@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +22664
pull_request: https://github.com/python/cpython/pull/23804

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40686>
_______________________________________

From report at bugs.python.org  Wed Dec 16 10:31:43 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 15:31:43 +0000
Subject: [issue40686] Compiler warnings in _zoneinfo.c on Windows build in
 64-bit
In-Reply-To: <1589906488.33.0.285207996013.issue40686@roundup.psfhosted.org>
Message-ID: <1608132703.76.0.025345759102.issue40686@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The 3 compiler warnings are now fixed in master, and a 3.9 backport will land as soon as the CI tests pass. Thanks everyone who helped to fix these warnings.

I know that the solution is not perfect, but we have to deal with C language limitations.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40686>
_______________________________________

From report at bugs.python.org  Wed Dec 16 10:56:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 15:56:27 +0000
Subject: [issue40686] Compiler warnings in _zoneinfo.c on Windows build in
 64-bit
In-Reply-To: <1589906488.33.0.285207996013.issue40686@roundup.psfhosted.org>
Message-ID: <1608134187.81.0.2209404916.issue40686@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Fixing these compiler warnings helps PR 18532 "[workflow] Use MSVC problem matcher for Windows action build".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40686>
_______________________________________

From report at bugs.python.org  Wed Dec 16 10:59:28 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Wed, 16 Dec 2020 15:59:28 +0000
Subject: [issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable
 in calenderrule_new
Message-ID: <1608134368.02.0.941471966425.issue42660@roundup.psfhosted.org>


New submission from Paul Ganssle <p.ganssle at gmail.com>:

This is a code style issue ? in https://github.com/python/cpython/pull/23614, a regression was deliberately introduced to satisfy an overzealous compiler. The `day` variable has logical bounds `0 <= day <= 6`. In the original code, both sides of this boundary condition were explicitly checked (since this logically documents the bounds of the variable).

Some compilers complain about checking `day < 0`, because `day` is an unsigned type. It is not an immutable fact that `day` will always be an unsigned type, and implicitly relying on this fact makes the code both less readable and more fragile. This was changed over my objections and despite the fact that I had a less fragile solution available that also satisfied the overzealous compiler.

In the short term, my preferred solution would be to add in a static assertion that `day` is an unsigned type ? this does not have to work on every platform, it simply needs to serve as a notification to make the code less fragile and to document our assumptions to both readers and the compiler.

In the long term, I think we need a way to solve the problem that it is apparently not possible to disable any compiler warnings even if they don't apply to the situation!

----------
components: Library (Lib)
messages: 383180
nosy: p-ganssle
priority: normal
severity: normal
stage: needs patch
status: open
title: _zoneinfo.c incorrectly checks bounds of `day` variable in calenderrule_new
type: behavior
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42660>
_______________________________________

From report at bugs.python.org  Wed Dec 16 11:02:08 2020
From: report at bugs.python.org (daniel hahler)
Date: Wed, 16 Dec 2020 16:02:08 +0000
Subject: [issue37961] Tracemalloc traces do not include original stack trace
 length
In-Reply-To: <1566894205.32.0.427554502238.issue37961@roundup.psfhosted.org>
Message-ID: <1608134528.93.0.724549582361.issue37961@roundup.psfhosted.org>


Change by daniel hahler <python-bugs at thequod.de>:


----------
nosy: +blueyed
nosy_count: 2.0 -> 3.0
pull_requests: +22665
pull_request: https://github.com/python/cpython/pull/23805

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37961>
_______________________________________

From report at bugs.python.org  Wed Dec 16 11:03:41 2020
From: report at bugs.python.org (Julien Palard)
Date: Wed, 16 Dec 2020 16:03:41 +0000
Subject: [issue23915] [doc] traceback set with BaseException.with_traceback()
 pushed back on raise
In-Reply-To: <1428769760.16.0.251757749986.issue23915@psf.upfronthosting.co.za>
Message-ID: <1608134621.84.0.881932515447.issue23915@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:


New changeset c590c2338e5a36cf3ce5b55e6d366a0675ed1db5 by Irit Katriel in branch 'master':
bpo-23915: update and elucidate documentation of with_traceback (GH-23680)
https://github.com/python/cpython/commit/c590c2338e5a36cf3ce5b55e6d366a0675ed1db5


----------
nosy: +mdk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23915>
_______________________________________

From report at bugs.python.org  Wed Dec 16 11:04:24 2020
From: report at bugs.python.org (Julien Palard)
Date: Wed, 16 Dec 2020 16:04:24 +0000
Subject: [issue23915] [doc] traceback set with BaseException.with_traceback()
 pushed back on raise
In-Reply-To: <1428769760.16.0.251757749986.issue23915@psf.upfronthosting.co.za>
Message-ID: <1608134664.16.0.776911996658.issue23915@roundup.psfhosted.org>


Change by Julien Palard <julien+python at palard.fr>:


----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23915>
_______________________________________

From report at bugs.python.org  Wed Dec 16 11:27:12 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 16 Dec 2020 16:27:12 +0000
Subject: [issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable
 in calenderrule_new
In-Reply-To: <1608134368.02.0.941471966425.issue42660@roundup.psfhosted.org>
Message-ID: <1608136032.24.0.886492282449.issue42660@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I do not think there is any problem *now*. The type of day is uint8_t, it cannot be negative.

BTW, why is it uint8_t? Would not be easier to use type int by default? I doubt that it saves memory or makes the code faster.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42660>
_______________________________________

From report at bugs.python.org  Wed Dec 16 11:31:07 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 16 Dec 2020 16:31:07 +0000
Subject: [issue42659] Objects of uname_result Class Cannot be Successfully
 Pickled
In-Reply-To: <1608131578.78.0.823168956156.issue42659@roundup.psfhosted.org>
Message-ID: <1608136267.4.0.855646150546.issue42659@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

See also issue42189.

----------
components: +Library (Lib)
nosy: +jaraco, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42659>
_______________________________________

From report at bugs.python.org  Wed Dec 16 11:33:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 16:33:15 +0000
Subject: [issue40686] Compiler warnings in _zoneinfo.c on Windows build in
 64-bit
In-Reply-To: <1589906488.33.0.285207996013.issue40686@roundup.psfhosted.org>
Message-ID: <1608136395.02.0.258801878876.issue40686@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 7492b55ea0ca993c353b6373341b92e40faa9c4d by Miss Islington (bot) in branch '3.9':
bpo-40686: Fix compiler warnings on _zoneinfo.c (GH-23614) (GH-23804)
https://github.com/python/cpython/commit/7492b55ea0ca993c353b6373341b92e40faa9c4d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40686>
_______________________________________

From report at bugs.python.org  Wed Dec 16 11:33:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 16:33:27 +0000
Subject: [issue40686] Compiler warnings in _zoneinfo.c on Windows build in
 64-bit
In-Reply-To: <1589906488.33.0.285207996013.issue40686@roundup.psfhosted.org>
Message-ID: <1608136407.06.0.767966490497.issue40686@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Paul created a follow-up issue: bpo-42660.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40686>
_______________________________________

From report at bugs.python.org  Wed Dec 16 11:38:20 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Wed, 16 Dec 2020 16:38:20 +0000
Subject: [issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable
 in calenderrule_new
In-Reply-To: <1608134368.02.0.941471966425.issue42660@roundup.psfhosted.org>
Message-ID: <1608136700.72.0.309400744061.issue42660@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

As I mentioned, it's a style issue. Yes this did not introduce any user-observable bugs, nor should it have changed the machine code emitted by the assembly on any competent compiler.

The issue is that I had deliberately chosen to do a "redundant" check to improve the readability and to be robust against someone saying, "Why is this a unit8_t instead of an int? I don't think it makes anything faster..." or some other justification for changing all the uint8_t fields to ints.

Previous to this, we had something where the compiler would fix any bugs caused by that by itself by emitting an additional bounds check. In my proposed fix to the compiler warnings, there was a static assertion where the machine would alert us if the situation changed. The problem is that we now have a non-machine-checked comment for something that would be difficult to issue tests for.

Frankly, I think that even the worst case scenario here isn't that bad ? TZif files malformed in a very specific way would be accepted as valid. As it's coded now, this would probably just lead to a crash later, or possibly some weird results in time zone math. Still, I think we need a solution to this problem because our blind adherence to an invalid compiler warning is leading us to write more fragile code, whic h is especially problematic in C, which is notoriously dangerous and problematic to write.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42660>
_______________________________________

From report at bugs.python.org  Wed Dec 16 11:48:22 2020
From: report at bugs.python.org (Ammar Askar)
Date: Wed, 16 Dec 2020 16:48:22 +0000
Subject: [issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable
 in calenderrule_new
In-Reply-To: <1608134368.02.0.941471966425.issue42660@roundup.psfhosted.org>
Message-ID: <1608137302.1.0.510275666551.issue42660@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

> Some compilers complain about checking `day < 0`, because `day` is an unsigned type

Just my two cents, this isn't just "some compilers". Everything from gcc, msvc, C# to the rust compiler complain about this sort of code. As they should, this is effectively dead code.

I think the more pragmatic way to enforce and document this assumption would be to have a unit test that actually checks that the constructor fails with "negative" days. It'll continue to fail right now as its interpretation as an unsigned int will be large and it will start failing if someone changes this to a signed type.

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42660>
_______________________________________

From report at bugs.python.org  Wed Dec 16 12:07:26 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Wed, 16 Dec 2020 17:07:26 +0000
Subject: [issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable
 in calenderrule_new
In-Reply-To: <1608134368.02.0.941471966425.issue42660@roundup.psfhosted.org>
Message-ID: <1608138446.98.0.251120235022.issue42660@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

> Just my two cents, this isn't just "some compilers". Everything from gcc, msvc, C# to the rust compiler complain about this sort of code. As they should, this is effectively dead code.

They complain because most of the time it's a sign that people were intending to use a signed integer, and it's an indicator that they may be susceptible to integer overflow.

In this case, it was a deliberate choice to include the extra check knowing it's dead code, because it is essentially a machine-checked documentation of the bounds of that particular variable.


> I think the more pragmatic way to enforce and document this assumption would be to have a unit test that actually checks that the constructor fails with "negative" days. It'll continue to fail right now as its interpretation as an unsigned int will be large and it will start failing if someone changes this to a signed type.

This would be helpful, but it's not an either-or situation. This particular thing would be tricky to write a targeted unit test for, because it's a very deep implementation detail. Such a unit test would also be quite physically separated from the code in question, whereas if we left the code as-is, we'd never see this type of bug, and if we added a static assertion we'd be told at compile time exactly what is wrong.

The biggest problem here is the fact that we cannot disable compiler warnings when complying with them makes the code less readable and/or less robust. This makes compiler warnings less useful, since it changes the calculus around whether or not it's worth it to introduce a new compiler warning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42660>
_______________________________________

From report at bugs.python.org  Wed Dec 16 12:12:39 2020
From: report at bugs.python.org (Mario Corchero)
Date: Wed, 16 Dec 2020 17:12:39 +0000
Subject: [issue42556] unittest.mock.patch() cannot properly mock methods
In-Reply-To: <1607006466.6.0.505250389966.issue42556@roundup.psfhosted.org>
Message-ID: <1608138759.73.0.579139211917.issue42556@roundup.psfhosted.org>


Mario Corchero <mariocj89 at gmail.com> added the comment:

Right, I believe this is indeed broken.

This code:
```
class A:
    def m(self, a=None): pass

from unittest import mock
with mock.patch.object(A, "m", autospec=True):
    A.m.side_effect = print
    A().m(1)
```

prints: <__main__.A object at 0x7f69cc7dc6a0> 1

Whilst the same code without autospec:
```
class A:
    def m(self, a=None): pass

from unittest import mock
with mock.patch.object(A, "m"):
    A.m.side_effect = print
    A().m(1)
```

prints: 1

This is a rather tricky issue though, as changing the behaviour to pass self would break too many people (even if it would probably the be "right" fix).

You can indeed use autospec or just write a descriptor that does the proper bound method logic:

```
class A:
    def m(self, a=None): pass

def descriptor(self, obj, objtype=None):
    self._self = obj
    def _(*args):
        return self(obj, *args)
    return _

from unittest import mock
with mock.patch.object(A, "m"):
    A.m.side_effect = print
    A.m.__get__ = descriptor
    A().m(1)
```

When patching a method at the class level, today Mock is basically hiding "self" when used without a spec. We should decide whether:
- that is OK and we want to "fix" autospec to do the same (remove self)
- Leave things as they are, even if not perfect
- Pass self, breaking most assertions across the world (sounds like a bad idea initially)
- Create some opt-in parameter or a custom thing like PropertyMock to pass self (MethodMock?).

TBH, I don't have a good answer :/. I'm subscribing other more insightful people to the issue, maybe this is the way it is intended to work :).

----------
nosy: +cjw296, mariocj89, michael.foord, xtreak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42556>
_______________________________________

From report at bugs.python.org  Wed Dec 16 12:33:37 2020
From: report at bugs.python.org (Irit Katriel)
Date: Wed, 16 Dec 2020 17:33:37 +0000
Subject: [issue1571878] Improvements to socket module exceptions
Message-ID: <1608140017.17.0.301476874976.issue1571878@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

This was indeed done by now - all these exception types now extend OSErrors, the hierarchy is very close to the one suggested here (with the exception of the AddressError superclass, which I don't think is that useful to have), and they have an errno field (derived from OSError).

----------
nosy: +iritkatriel
resolution:  -> out of date
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1571878>
_______________________________________

From report at bugs.python.org  Wed Dec 16 12:46:24 2020
From: report at bugs.python.org (Scott)
Date: Wed, 16 Dec 2020 17:46:24 +0000
Subject: [issue41354] filecmp.cmp documentation does not match actual code
In-Reply-To: <1595316543.83.0.558279011146.issue41354@roundup.psfhosted.org>
Message-ID: <1608140784.91.0.787865268674.issue41354@roundup.psfhosted.org>


Scott <scottalancorbett at yahoo.com> added the comment:

I suggest changing the documentation rather than the code.  The mix up is in the wording.

Documentation below
"If shallow is true, files with identical os.stat() signatures are taken to be equal. Otherwise, the contents of the files are compared."

The "Otherwise" appears to be referencing the "If shallow is true" cause, when it should be referring to the equality of the _sig()s.

Proposed Change 
"If shallow is true, files with identical os.stat() signatures are taken to be equal. If they are not equal, the contents of the files are compared."

----------
nosy: +FreeSandwiches

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41354>
_______________________________________

From report at bugs.python.org  Wed Dec 16 12:47:33 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 16 Dec 2020 17:47:33 +0000
Subject: [issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable
 in calenderrule_new
In-Reply-To: <1608134368.02.0.941471966425.issue42660@roundup.psfhosted.org>
Message-ID: <1608140853.27.0.895938619709.issue42660@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I propose to change the type of day to int. It will remove any objections againsy the range check and make the code less error-prone for integer overflow and sign loss.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42660>
_______________________________________

From report at bugs.python.org  Wed Dec 16 12:48:18 2020
From: report at bugs.python.org (Daniel Hahler)
Date: Wed, 16 Dec 2020 17:48:18 +0000
Subject: [issue39041] Support GitHub Actions in CI
In-Reply-To: <1576274167.03.0.917402415265.issue39041@roundup.psfhosted.org>
Message-ID: <1608140898.24.0.040333899276.issue39041@roundup.psfhosted.org>


Daniel Hahler <github at thequod.de> added the comment:

Is it planned to enable coverage uploads for PRs?
This would really help with seeing if code (to be merged) is covered etc.

----------
nosy: +blueyed2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39041>
_______________________________________

From report at bugs.python.org  Wed Dec 16 12:50:42 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 16 Dec 2020 17:50:42 +0000
Subject: [issue38323] asyncio: MultiLoopWatcher has a race condition
 (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)
In-Reply-To: <1569848255.08.0.155489980043.issue38323@roundup.psfhosted.org>
Message-ID: <1608141042.08.0.443671415644.issue38323@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset 66d3b589c44fcbcf9afe1e442d9beac3bd8bcd34 by Chris Jerdonek in branch 'master':
bpo-38323: Add guard clauses in MultiLoopChildWatcher. (#22756)
https://github.com/python/cpython/commit/66d3b589c44fcbcf9afe1e442d9beac3bd8bcd34


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38323>
_______________________________________

From report at bugs.python.org  Wed Dec 16 12:50:40 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 16 Dec 2020 17:50:40 +0000
Subject: [issue38323] asyncio: MultiLoopWatcher has a race condition
 (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)
In-Reply-To: <1569848255.08.0.155489980043.issue38323@roundup.psfhosted.org>
Message-ID: <1608141040.01.0.424742630572.issue38323@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 7.0 -> 8.0
pull_requests: +22666
pull_request: https://github.com/python/cpython/pull/23806

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38323>
_______________________________________

From report at bugs.python.org  Wed Dec 16 12:50:47 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 16 Dec 2020 17:50:47 +0000
Subject: [issue38323] asyncio: MultiLoopWatcher has a race condition
 (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)
In-Reply-To: <1569848255.08.0.155489980043.issue38323@roundup.psfhosted.org>
Message-ID: <1608141047.8.0.664294188051.issue38323@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22667
pull_request: https://github.com/python/cpython/pull/23807

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38323>
_______________________________________

From report at bugs.python.org  Wed Dec 16 12:56:21 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 16 Dec 2020 17:56:21 +0000
Subject: [issue39101] IsolatedAsyncioTestCase freezes when exception is raised
In-Reply-To: <1576784699.03.0.850711294275.issue39101@roundup.psfhosted.org>
Message-ID: <1608141381.61.0.738955803667.issue39101@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9d409d6b474c188feca6213b9601e06f97715b72 by Miss Islington (bot) in branch '3.9':
bpo-39101: Fixes BaseException hang in IsolatedAsyncioTestCase. (GH-22654)
https://github.com/python/cpython/commit/9d409d6b474c188feca6213b9601e06f97715b72


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39101>
_______________________________________

From report at bugs.python.org  Wed Dec 16 12:57:31 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 16 Dec 2020 17:57:31 +0000
Subject: [issue39101] IsolatedAsyncioTestCase freezes when exception is raised
In-Reply-To: <1576784699.03.0.850711294275.issue39101@roundup.psfhosted.org>
Message-ID: <1608141451.18.0.0381524609855.issue39101@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d549d0b5575b390431b7b26999151f79f74d4516 by Miss Islington (bot) in branch '3.8':
bpo-39101: Fixes BaseException hang in IsolatedAsyncioTestCase. (GH-22654)
https://github.com/python/cpython/commit/d549d0b5575b390431b7b26999151f79f74d4516


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39101>
_______________________________________

From report at bugs.python.org  Wed Dec 16 13:10:54 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 16 Dec 2020 18:10:54 +0000
Subject: [issue38323] asyncio: MultiLoopWatcher has a race condition
 (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)
In-Reply-To: <1569848255.08.0.155489980043.issue38323@roundup.psfhosted.org>
Message-ID: <1608142254.98.0.506560401147.issue38323@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset bf0eed3e60acc7e4969a4fae940bc615fa924c30 by Miss Islington (bot) in branch '3.9':
bpo-38323: Add guard clauses in MultiLoopChildWatcher. (GH-22756)
https://github.com/python/cpython/commit/bf0eed3e60acc7e4969a4fae940bc615fa924c30


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38323>
_______________________________________

From report at bugs.python.org  Wed Dec 16 13:11:52 2020
From: report at bugs.python.org (Samit Mohnot)
Date: Wed, 16 Dec 2020 18:11:52 +0000
Subject: [issue42661] Hashlib Bug
Message-ID: <1608142312.83.0.59041138794.issue42661@roundup.psfhosted.org>


New submission from Samit Mohnot <samit.mohnot.018 at k12.friscoisd.org>:

Complete output (6 lines):
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "C:\Users\Username\AppData\Local\Temp\pip-install-uyjqlzx9\hashlib_973e0ee3f102447498d1d4dca94b7942\setup.py", line 68
        print "unknown OS, please update setup.py"
              ^
    SyntaxError: Missing parentheses in call to 'print'. Did you mean print("unknown OS, please update setup.py")?
    ----------------------------------------
ERROR: Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output.

----------
components: Library (Lib)
messages: 383198
nosy: samit.mohnot.018
priority: normal
severity: normal
status: open
title: Hashlib Bug
type: compile error
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42661>
_______________________________________

From report at bugs.python.org  Wed Dec 16 13:12:03 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 16 Dec 2020 18:12:03 +0000
Subject: [issue38323] asyncio: MultiLoopWatcher has a race condition
 (test_asyncio: test_close_kill_running() hangs on AMD64 RHEL7 Refleaks 3.x)
In-Reply-To: <1569848255.08.0.155489980043.issue38323@roundup.psfhosted.org>
Message-ID: <1608142323.18.0.210873842465.issue38323@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset dd262ef46d2e2fff4c413cfa5faa9e72cd36220e by Miss Islington (bot) in branch '3.8':
bpo-38323: Add guard clauses in MultiLoopChildWatcher. (GH-22756)
https://github.com/python/cpython/commit/dd262ef46d2e2fff4c413cfa5faa9e72cd36220e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38323>
_______________________________________

From report at bugs.python.org  Wed Dec 16 13:47:18 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Wed, 16 Dec 2020 18:47:18 +0000
Subject: [issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable
 in calenderrule_new
In-Reply-To: <1608134368.02.0.941471966425.issue42660@roundup.psfhosted.org>
Message-ID: <1608144438.91.0.0268464921844.issue42660@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

There are at least two issues with this:

1. This is a constructor for a struct, and the struct would really unnecessarily balloon in size if we switched everything over to be 32-bit integers (which I think is your suggestion?). This is not a major concern because in typical operation there are not likely to be more than 500 of these structs in existence at any one time (due to the cache), but it's still a minor annoyance.

I would guess that accepting `int` in the constructor function and converting it to uint8_t as part of building the struct would be maybe neutral to negative, since it involves casting a large signed type to a small unsigned one. This could cause more problems with overflow, not less.

2. In the current implementation `day` is unsigned by its nature ? it represents a value indexed at 0 for which negative indices have no meaning. If we leave `day` as a uint8_t, then that tells the compiler at least something about the valid range of the value. By turning `day` (and presumably the other elements of this struct) into a less-suitable type, we're depriving ourselves of possibly *useful* compiler warnings.

Barring a solution where we have a simple and robust way to suppress warnings, I think the next-best solution is to add a static assertion about the signedness of the type for this particular case. I'd be happy to write it in a relatively general way so that it can be re-used elsewhere in CPython for the same purpose.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42660>
_______________________________________

From report at bugs.python.org  Wed Dec 16 13:53:16 2020
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 16 Dec 2020 18:53:16 +0000
Subject: [issue42661] Hashlib Bug
In-Reply-To: <1608142312.83.0.59041138794.issue42661@roundup.psfhosted.org>
Message-ID: <1608144796.36.0.72298154619.issue42661@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

`hashlib` is part of the standard library and thus does not need to be (and should not be :)) installed via pip.

----------
nosy: +zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42661>
_______________________________________

From report at bugs.python.org  Wed Dec 16 14:08:22 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 16 Dec 2020 19:08:22 +0000
Subject: [issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable
 in calenderrule_new
In-Reply-To: <1608134368.02.0.941471966425.issue42660@roundup.psfhosted.org>
Message-ID: <1608145702.5.0.555023615679.issue42660@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I propose to change types of function parameters and local variables. In any case the constructor checks the range of parameters, so there is no problem with packing them into compact structure.

This will help to avoid errors of implicit conversion between different integer types. Also it can help to avoid code duplication in parsing integers of different size and signedness.

Adding a static assertion about the signedness of uint8_t looks meaningless to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42660>
_______________________________________

From report at bugs.python.org  Wed Dec 16 14:24:28 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Wed, 16 Dec 2020 19:24:28 +0000
Subject: [issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable
 in calenderrule_new
In-Reply-To: <1608134368.02.0.941471966425.issue42660@roundup.psfhosted.org>
Message-ID: <1608146668.62.0.805219944362.issue42660@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

> Adding a static assertion about the signedness of uint8_t looks meaningless to me.

My proposal is to add a static assertion that `day` is an unsigned type. In the code it would look something like it does in the backports.zoneinfo code (https://github.com/pganssle/zoneinfo/blob/07ec80ad5dc7e7e4b4f861ddbb61a9b71e9f27c7/lib/zoneinfo_module.c#L1247-L1255):


```
    // The actual bounds of day are (day >= 0 && day <= 6), but since day is an
    // unsigned variable, day >= 0 is always true. To ensure that a bug is not
    // introduced in the event that someone changes day to a signed type, we
    // will assert that it is an unsigned type.
    Py_ASSERT_VAR_UNSIGNED(day);
    if (day > 6) {
        PyErr_Format(PyExc_ValueError, "Day must be in [0, 6]");
        return -1;
    }
```

> I propose to change types of function parameters and local variables. In any case the constructor checks the range of parameters, so there is no problem with packing them into compact structure.

> This will help to avoid errors of implicit conversion between different integer types. Also it can help to avoid code duplication in parsing integers of different size and signedness.

This is not entirely unreasonable in my opinion, though in this case everything is determined by the POSIX standard and an RFC, so it is unlikely that we'll ever see anything outside of 8 bit integers for these things. If you'd like to refactor the parsing code to use signed integers unconditionally and have them converted as part of the constructor that seems reasonable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42660>
_______________________________________

From report at bugs.python.org  Wed Dec 16 15:51:41 2020
From: report at bugs.python.org (Paul Bryan)
Date: Wed, 16 Dec 2020 20:51:41 +0000
Subject: [issue42662] Propose: Data model explict about __annotations__ key
 ordering.
Message-ID: <1608151901.48.0.662364122955.issue42662@roundup.psfhosted.org>


New submission from Paul Bryan <pbryan at anode.ca>:

Currently the data model documentation does not specify the order of keys in __annotations__ dictionary. It is currently in the order that arguments or attributes are declared. I propose to make this explicit.

Rationale: Having order explicitly specified in the documentation makes it a documented feature that code can depend on. Current code cannot safely rely on this behavior.

----------
assignee: docs at python
components: Documentation
messages: 383204
nosy: docs at python, pbryan
priority: normal
severity: normal
status: open
title: Propose: Data model explict about __annotations__ key ordering.
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42662>
_______________________________________

From report at bugs.python.org  Wed Dec 16 15:53:45 2020
From: report at bugs.python.org (Paul Bryan)
Date: Wed, 16 Dec 2020 20:53:45 +0000
Subject: [issue42662] Propose: Data model explict about __annotations__ key
 ordering.
In-Reply-To: <1608151901.48.0.662364122955.issue42662@roundup.psfhosted.org>
Message-ID: <1608152025.01.0.484324415282.issue42662@roundup.psfhosted.org>


Change by Paul Bryan <pbryan at anode.ca>:


----------
keywords: +patch
pull_requests: +22668
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23808

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42662>
_______________________________________

From report at bugs.python.org  Wed Dec 16 16:19:17 2020
From: report at bugs.python.org (Paul Bryan)
Date: Wed, 16 Dec 2020 21:19:17 +0000
Subject: [issue42662] Propose: Data model explict about __annotations__ key
 ordering.
In-Reply-To: <1608151901.48.0.662364122955.issue42662@roundup.psfhosted.org>
Message-ID: <1608153557.39.0.564844878776.issue42662@roundup.psfhosted.org>


Paul Bryan <pbryan at anode.ca> added the comment:

Retracting.

----------
resolution:  -> not a bug
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42662>
_______________________________________

From report at bugs.python.org  Wed Dec 16 16:33:53 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Wed, 16 Dec 2020 21:33:53 +0000
Subject: [issue42663] zoneinfo does not support full range of allowed
 transition hours in fallback string
Message-ID: <1608154433.49.0.318883425805.issue42663@roundup.psfhosted.org>


New submission from Paul Ganssle <p.ganssle at gmail.com>:

TZif files consist of a list of transitions followed by a POSIX TZ var-style string of a form like "AAA3BBB,M3.2.0/01:30,M11.1.0/02:15:45", which decodes to "AAA (UTC-3) is the standard time and BBB (UTC-2) is the DST time, DST applies starting at 02:15:45 local time on the 1st Sunday in November and ending at 1:30:00 local time on the 2nd Sunday in March". After the last listed transition, the rule specified by the TZ variable applies.

POSIX says that the "hours" part of the transition rule must be in the range ?24, but as mentioned in a TODO comment in _zoneinfo.c, RFC 8536 ?3.3.1 specifies that the hours part of transition times may range from -167 to 167 (see: https://github.com/python/cpython/blob/master/Modules/_zoneinfo.c#L1844-L1847 ).

Currently, zoneinfo does not support the full range of possible transitions, and a TZif file with a 3-digit transition hour would likely fail to parse. This isn't a terribly high priority at the moment, but if the tz project ever releases a TZif file with one of these TZ strings on it, it will all of a sudden become very critical to fix it, so we should probably try to get it fixed before Python 3.9 is EOL, so that all versions of Python with `zoneinfo` can handle this properly.

----------
components: Library (Lib)
messages: 383206
nosy: p-ganssle
priority: normal
severity: normal
stage: needs patch
status: open
title: zoneinfo does not support full range of allowed transition hours in fallback string
type: behavior
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42663>
_______________________________________

From report at bugs.python.org  Wed Dec 16 16:38:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 21:38:52 +0000
Subject: [issue37961] Tracemalloc traces do not include original stack trace
 length
In-Reply-To: <1566894205.32.0.427554502238.issue37961@roundup.psfhosted.org>
Message-ID: <1608154732.09.0.32716654739.issue37961@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 051b9818671625d125dee8198e0d2af5ad4c85b8 by Daniel Hahler in branch 'master':
bpo-37961: Fix regression in tracemalloc.Traceback.__repr__ (GH-23805)
https://github.com/python/cpython/commit/051b9818671625d125dee8198e0d2af5ad4c85b8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37961>
_______________________________________

From report at bugs.python.org  Wed Dec 16 16:39:23 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 16 Dec 2020 21:39:23 +0000
Subject: [issue37961] Tracemalloc traces do not include original stack trace
 length
In-Reply-To: <1566894205.32.0.427554502238.issue37961@roundup.psfhosted.org>
Message-ID: <1608154763.07.0.688250155388.issue37961@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +22670
pull_request: https://github.com/python/cpython/pull/23809

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37961>
_______________________________________

From report at bugs.python.org  Wed Dec 16 16:41:55 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 21:41:55 +0000
Subject: [issue40421] [C API] Add getter functions for PyFrameObject and maybe
 move PyFrameObject to the internal C API
In-Reply-To: <1588079870.34.0.984904607646.issue40421@roundup.psfhosted.org>
Message-ID: <1608154915.22.0.139142178627.issue40421@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 166286849048eccadecf02b242dbc4042b780944 by Victor Stinner in branch '3.9':
Add symbols of the stable ABI to python3dll.c (GH-23598) (GH-23801)
https://github.com/python/cpython/commit/166286849048eccadecf02b242dbc4042b780944


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40421>
_______________________________________

From report at bugs.python.org  Wed Dec 16 16:41:55 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 21:41:55 +0000
Subject: [issue37194] Move new vector private declarations to the internal C
 API
In-Reply-To: <1559908440.37.0.746705371355.issue37194@roundup.psfhosted.org>
Message-ID: <1608154915.15.0.163870199943.issue37194@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 166286849048eccadecf02b242dbc4042b780944 by Victor Stinner in branch '3.9':
Add symbols of the stable ABI to python3dll.c (GH-23598) (GH-23801)
https://github.com/python/cpython/commit/166286849048eccadecf02b242dbc4042b780944


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37194>
_______________________________________

From report at bugs.python.org  Wed Dec 16 16:41:55 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 21:41:55 +0000
Subject: [issue39947] [C API] Make the PyThreadState structure opaque (move it
 to the internal C API)
In-Reply-To: <1584035214.47.0.672795796186.issue39947@roundup.psfhosted.org>
Message-ID: <1608154915.28.0.851673794448.issue39947@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 166286849048eccadecf02b242dbc4042b780944 by Victor Stinner in branch '3.9':
Add symbols of the stable ABI to python3dll.c (GH-23598) (GH-23801)
https://github.com/python/cpython/commit/166286849048eccadecf02b242dbc4042b780944


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39947>
_______________________________________

From report at bugs.python.org  Wed Dec 16 16:43:38 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 21:43:38 +0000
Subject: [issue42415] python3.lib in Python3.9.0 Windows distribution does not
 contain PyObject_CallNoArgs symbol
In-Reply-To: <1605826065.75.0.910654545311.issue42415@roundup.psfhosted.org>
Message-ID: <1608155018.06.0.765568242072.issue42415@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks David Hewitt for the bug report, and Zackery Spytz for your fix!

3.9 fix:

commit 166286849048eccadecf02b242dbc4042b780944
Author: Victor Stinner <vstinner at python.org>
Date:   Wed Dec 16 22:41:47 2020 +0100

    Add symbols of the stable ABI to python3dll.c (GH-23598) (GH-23801)
    
    Add the following symbols to python3dll.c:
    
    * PyFrame_GetCode (bpo-40421)
    * PyFrame_GetLineNumber (bpo-40421)
    * PyObject_CallNoArgs (bpo-37194)
    * PyThreadState_GetFrame (bpo-39947)
    * PyThreadState_GetID (bpo-39947)
    * PyThreadState_GetInterpreter (bpo-39947)
    
    (cherry picked from commit fcc6935384b933fbe1a1ef659ed455a3b74c849a)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42415>
_______________________________________

From report at bugs.python.org  Wed Dec 16 17:00:43 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 16 Dec 2020 22:00:43 +0000
Subject: [issue42125] linecache cannot get source for the __main__ module with
 a custom loader
In-Reply-To: <1603430813.16.0.973913314648.issue42125@roundup.psfhosted.org>
Message-ID: <1608156043.21.0.213678289071.issue42125@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/issue42125>
_______________________________________

From report at bugs.python.org  Wed Dec 16 17:01:23 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 16 Dec 2020 22:01:23 +0000
Subject: [issue37961] Tracemalloc traces do not include original stack trace
 length
In-Reply-To: <1566894205.32.0.427554502238.issue37961@roundup.psfhosted.org>
Message-ID: <1608156083.62.0.413568162928.issue37961@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 78062e07bc7c3b47ffdcdec786b259dda376370c by Miss Islington (bot) in branch '3.9':
bpo-37961: Fix regression in tracemalloc.Traceback.__repr__ (GH-23805)
https://github.com/python/cpython/commit/78062e07bc7c3b47ffdcdec786b259dda376370c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37961>
_______________________________________

From report at bugs.python.org  Wed Dec 16 17:01:51 2020
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 16 Dec 2020 22:01:51 +0000
Subject: [issue39041] Support GitHub Actions in CI
In-Reply-To: <1576274167.03.0.917402415265.issue39041@roundup.psfhosted.org>
Message-ID: <1608156111.84.0.623321653953.issue39041@roundup.psfhosted.org>


Brett Cannon <brett at python.org> added the comment:

Your question is best directed at https://discuss.python.org/c/core-workflow/8, Daniel.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39041>
_______________________________________

From report at bugs.python.org  Wed Dec 16 17:08:27 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 16 Dec 2020 22:08:27 +0000
Subject: [issue42659] Objects of uname_result Class Cannot be Successfully
 Pickled
In-Reply-To: <1608131578.78.0.823168956156.issue42659@roundup.psfhosted.org>
Message-ID: <1608156507.26.0.620052838978.issue42659@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

The PR for the related issue does address pickling. Do you expect pickles to work across Python versions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42659>
_______________________________________

From report at bugs.python.org  Wed Dec 16 17:45:14 2020
From: report at bugs.python.org (CrocoDuck)
Date: Wed, 16 Dec 2020 22:45:14 +0000
Subject: [issue42659] Objects of uname_result Class Cannot be Successfully
 Pickled
In-Reply-To: <1608156507.26.0.620052838978.issue42659@roundup.psfhosted.org>
Message-ID: <5b08edb8-31ab-19c2-74f2-06deb0492129@gmail.com>


CrocoDuck <crocoduck.oducks at gmail.com> added the comment:

Hi, I somehow missed the other issue while searching for something 
similar to this, sorry about that.

The main issue is that files pickled with python 3.9.0 cannot be read 
back by using python 3.9.0 if they contain a `uname_result` object.

As for expecting pickle to work across different versions: I did not 
actually think about that. In the original message I mentioned python 
3.8.5 as I noticed this issue did not happen in python 3.8.5, so I 
though it was useful information. To my (hopefully correct) 
understanding if a python version supports the same protocol that was 
used to create the pickle file then it is expected to work. For example 
I have observed that files containing `uname_result` objects pickled 
with python 3.7.6 are still readable with python 3.8.5. As far as I 
understand this is the expected behavior.

On 16/12/2020 22:08, Jason R. Coombs wrote:
> Jason R. Coombs <jaraco at jaraco.com> added the comment:
>
> The PR for the related issue does address pickling. Do you expect pickles to work across Python versions?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue42659>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42659>
_______________________________________

From report at bugs.python.org  Wed Dec 16 18:24:25 2020
From: report at bugs.python.org (Daniel Hahler)
Date: Wed, 16 Dec 2020 23:24:25 +0000
Subject: [issue39041] Support GitHub Actions in CI
In-Reply-To: <1576274167.03.0.917402415265.issue39041@roundup.psfhosted.org>
Message-ID: <1608161065.16.0.523596461327.issue39041@roundup.psfhosted.org>


Daniel Hahler <github at thequod.de> added the comment:

Brett, thanks for the reference.

I've found https://discuss.python.org/t/coverage-report-in-github-ci-for-standard-library/2836/11, and https://bugs.python.org/issue40993 through it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39041>
_______________________________________

From report at bugs.python.org  Wed Dec 16 18:24:39 2020
From: report at bugs.python.org (Daniel Hahler)
Date: Wed, 16 Dec 2020 23:24:39 +0000
Subject: [issue39041] Support GitHub Actions in CI
In-Reply-To: <1576274167.03.0.917402415265.issue39041@roundup.psfhosted.org>
Message-ID: <1608161079.29.0.326189470607.issue39041@roundup.psfhosted.org>


Change by Daniel Hahler <github at thequod.de>:


----------
nosy: +blueyed -blueyed2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39041>
_______________________________________

From report at bugs.python.org  Wed Dec 16 18:25:26 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 16 Dec 2020 23:25:26 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1608161126.27.0.928045438808.issue1635741@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22671
pull_request: https://github.com/python/cpython/pull/23811

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Wed Dec 16 18:45:29 2020
From: report at bugs.python.org (sds)
Date: Wed, 16 Dec 2020 23:45:29 +0000
Subject: [issue42664] strptime(%c) fails to parse the output of strftime(%c)
Message-ID: <1608162329.64.0.12903130366.issue42664@roundup.psfhosted.org>


New submission from sds <sds at gnu.org>:

>>> import datetime, locale
>>> locale.getlocale()
('en_US', 'UTF-8')
>>> datetime.datetime.strptime("%c",datetime.datetime.now().strftime("%c"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.8/_strptime.py", line 568, in _strptime_datetime
    tt, fraction, gmtoff_fraction = _strptime(data_string, format)
  File "/usr/lib/python3.8/_strptime.py", line 349, in _strptime
    raise ValueError("time data %r does not match format %r" %
ValueError: time data '%c' does not match format 'Wed Dec 16 18:44:27 2020'

----------
components: Library (Lib)
messages: 383217
nosy: sam-s
priority: normal
severity: normal
status: open
title: strptime(%c) fails to parse the output of strftime(%c)
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42664>
_______________________________________

From report at bugs.python.org  Wed Dec 16 18:56:47 2020
From: report at bugs.python.org (Irit Katriel)
Date: Wed, 16 Dec 2020 23:56:47 +0000
Subject: [issue41478] Empty representation of AssertionError
In-Reply-To: <1596559644.4.0.529490005495.issue41478@roundup.psfhosted.org>
Message-ID: <1608163007.17.0.142699542982.issue41478@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41478>
_______________________________________

From report at bugs.python.org  Wed Dec 16 20:40:18 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 17 Dec 2020 01:40:18 +0000
Subject: [issue42090] zipfile.Path.joinpath API inconsistent with
 pathlib.Path.joinpath
In-Reply-To: <1603141108.13.0.969027124293.issue42090@roundup.psfhosted.org>
Message-ID: <1608169218.23.0.981567258179.issue42090@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42090>
_______________________________________

From report at bugs.python.org  Wed Dec 16 20:52:06 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 17 Dec 2020 01:52:06 +0000
Subject: [issue42664] strptime(%c) fails to parse the output of strftime(%c)
In-Reply-To: <1608162329.64.0.12903130366.issue42664@roundup.psfhosted.org>
Message-ID: <1608169926.17.0.641376883603.issue42664@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

You have the parameters to strptime backward.

>>> datetime.datetime.strptime(datetime.datetime.now().strftime("%c"), "%c")
datetime.datetime(2020, 12, 16, 20, 51, 38)

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42664>
_______________________________________

From report at bugs.python.org  Wed Dec 16 20:56:02 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 17 Dec 2020 01:56:02 +0000
Subject: [issue42664] strptime(%c) fails to parse the output of strftime(%c)
In-Reply-To: <1608162329.64.0.12903130366.issue42664@roundup.psfhosted.org>
Message-ID: <1608170162.08.0.600815731562.issue42664@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42664>
_______________________________________

From report at bugs.python.org  Wed Dec 16 20:57:33 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 17 Dec 2020 01:57:33 +0000
Subject: [issue42659] Objects of uname_result Class Cannot be Successfully
 Pickled
In-Reply-To: <1608131578.78.0.823168956156.issue42659@roundup.psfhosted.org>
Message-ID: <1608170253.77.0.803036185833.issue42659@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
keywords: +patch
pull_requests: +22672
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23010

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42659>
_______________________________________

From report at bugs.python.org  Wed Dec 16 21:12:34 2020
From: report at bugs.python.org (Matt Wozniski)
Date: Thu, 17 Dec 2020 02:12:34 +0000
Subject: [issue17140] Document multiprocessing.pool.ThreadPool
In-Reply-To: <1360116485.64.0.452267246232.issue17140@psf.upfronthosting.co.za>
Message-ID: <1608171154.32.0.564340313426.issue17140@roundup.psfhosted.org>


Change by Matt Wozniski <godlygeek at gmail.com>:


----------
keywords: +patch
nosy: +godlygeek
nosy_count: 7.0 -> 8.0
pull_requests: +22673
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/23812

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17140>
_______________________________________

From report at bugs.python.org  Wed Dec 16 23:57:40 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 17 Dec 2020 04:57:40 +0000
Subject: [issue41960] Add globalns and localns to the inspect.signature and
 inspect.Signature.from_callable
In-Reply-To: <1602016741.16.0.216443843373.issue41960@roundup.psfhosted.org>
Message-ID: <1608181060.84.0.426416248635.issue41960@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

It's been a while, I've lost context for this idea. What problem are you trying to solve here? Are there issues where people have reported problems that this would allow them to solve?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41960>
_______________________________________

From report at bugs.python.org  Thu Dec 17 01:44:33 2020
From: report at bugs.python.org (Xinmeng Xia)
Date: Thu, 17 Dec 2020 06:44:33 +0000
Subject: [issue42651] Recursive traceback crashes  Python Interpreter
In-Reply-To: <1608105735.03.0.523665122471.issue42651@roundup.psfhosted.org>
Message-ID: <1608187473.71.0.00197096735872.issue42651@roundup.psfhosted.org>


Change by Xinmeng Xia <xiaxm at smail.nju.edu.cn>:


----------
title: Title: Recursive traceback crashes  Python Interpreter -> Recursive traceback crashes  Python Interpreter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42651>
_______________________________________

From report at bugs.python.org  Thu Dec 17 02:43:06 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 17 Dec 2020 07:43:06 +0000
Subject: [issue41804] test_epoll fails test_control_and_wait() randomly on
 aarch64 RHEL8 Refleaks 3.9
In-Reply-To: <1600360940.95.0.528440416873.issue41804@roundup.psfhosted.org>
Message-ID: <1608190986.38.0.250032714415.issue41804@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 1.0 -> 2.0
pull_requests: +22674
pull_request: https://github.com/python/cpython/pull/23813

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41804>
_______________________________________

From report at bugs.python.org  Thu Dec 17 02:43:14 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 17 Dec 2020 07:43:14 +0000
Subject: [issue41804] test_epoll fails test_control_and_wait() randomly on
 aarch64 RHEL8 Refleaks 3.9
In-Reply-To: <1600360940.95.0.528440416873.issue41804@roundup.psfhosted.org>
Message-ID: <1608190994.55.0.357786948331.issue41804@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22675
pull_request: https://github.com/python/cpython/pull/23814

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41804>
_______________________________________

From report at bugs.python.org  Thu Dec 17 02:43:32 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Dec 2020 07:43:32 +0000
Subject: [issue41804] test_epoll fails test_control_and_wait() randomly on
 aarch64 RHEL8 Refleaks 3.9
In-Reply-To: <1600360940.95.0.528440416873.issue41804@roundup.psfhosted.org>
Message-ID: <1608191012.35.0.649612751566.issue41804@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Oh, test_epoll failed on 3.9. So I backported my change to 3.8 and 3.9, to see if it helps or not.

s390x RHEL8 Refleaks 3.9:
https://buildbot.python.org/all/#builders/326/builds/159

Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.9.edelsohn-rhel8-z.refleak/build/Lib/test/test_epoll.py", line 199, in test_control_and_wait
    self.assertEqual(events, expected)
AssertionError: Lists differ: [(5, 5)] != [(4, 5), (5, 5)]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41804>
_______________________________________

From report at bugs.python.org  Thu Dec 17 02:54:56 2020
From: report at bugs.python.org (Peixing Xin)
Date: Thu, 17 Dec 2020 07:54:56 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1608191696.36.0.688866472363.issue31904@roundup.psfhosted.org>


Change by Peixing Xin <peixing.xin at windriver.com>:


----------
pull_requests: +22676
pull_request: https://github.com/python/cpython/pull/23815

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Thu Dec 17 03:03:58 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 17 Dec 2020 08:03:58 +0000
Subject: [issue41804] test_epoll fails test_control_and_wait() randomly on
 aarch64 RHEL8 Refleaks 3.9
In-Reply-To: <1600360940.95.0.528440416873.issue41804@roundup.psfhosted.org>
Message-ID: <1608192238.77.0.904505426683.issue41804@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e962e3ad225a211b9f9689742db6e9771d07c505 by Miss Islington (bot) in branch '3.9':
bpo-41804: Enhance test_epoll.test_control_and_wait() (GH-23795)
https://github.com/python/cpython/commit/e962e3ad225a211b9f9689742db6e9771d07c505


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41804>
_______________________________________

From report at bugs.python.org  Thu Dec 17 03:30:29 2020
From: report at bugs.python.org (Lele Gaifax)
Date: Thu, 17 Dec 2020 08:30:29 +0000
Subject: [issue22228] Adapt bash readline operate-and-get-next function
In-Reply-To: <1408441328.29.0.0681426449148.issue22228@psf.upfronthosting.co.za>
Message-ID: <1608193829.15.0.148078007095.issue22228@roundup.psfhosted.org>


Lele Gaifax <lelegaifax at gmail.com> added the comment:

Apparently, now the operate-and-get-next function has been moved to the readline library, so hopefully it will be easier to get its advantage.

See point 2.j in https://lwn.net/Articles/839213/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22228>
_______________________________________

From report at bugs.python.org  Thu Dec 17 03:52:53 2020
From: report at bugs.python.org (Ganesh Kathiresan)
Date: Thu, 17 Dec 2020 08:52:53 +0000
Subject: [issue42665] Should PyLong_AsLongAndOverflow raise exception on
 overflow?
Message-ID: <1608195173.24.0.881331564131.issue42665@roundup.psfhosted.org>


Change by Ganesh Kathiresan <ganesh3597 at gmail.com>:


----------
components: C API
nosy: ganesh3597
priority: normal
severity: normal
status: open
title: Should PyLong_AsLongAndOverflow raise exception on overflow?
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42665>
_______________________________________

From report at bugs.python.org  Thu Dec 17 04:06:46 2020
From: report at bugs.python.org (Thomas Viehmann)
Date: Thu, 17 Dec 2020 09:06:46 +0000
Subject: [issue42666] getting a class source regresses in Python 3.9
Message-ID: <1608196006.88.0.643559446867.issue42666@roundup.psfhosted.org>


New submission from Thomas Viehmann <tv.python.org at beamnet.de>:

getting a class source regresses in Python 3.9 onwards.
The following worked in Python 3.8, now it doesn't anymore for 3.9.1 and 3.10.0a2:

(save as foo.py)

import inspect

class Foo:
    def spam(self):
        global Bar
        class Bar:
            pass
        print(inspect.getsource(Bar))

Foo().spam()


It seems that getsource is very brittle for classes.

----------
components: Library (Lib)
messages: 383223
nosy: t-vi
priority: normal
severity: normal
status: open
title: getting a class source regresses in Python 3.9
type: behavior
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42666>
_______________________________________

From report at bugs.python.org  Thu Dec 17 04:11:37 2020
From: report at bugs.python.org (Thomas Viehmann)
Date: Thu, 17 Dec 2020 09:11:37 +0000
Subject: [issue42666] getting a class source regresses in Python 3.9
In-Reply-To: <1608196006.88.0.643559446867.issue42666@roundup.psfhosted.org>
Message-ID: <1608196297.91.0.946590172702.issue42666@roundup.psfhosted.org>


Thomas Viehmann <tv.python.org at beamnet.de> added the comment:

I might add that this is a case I hit in the PyTorch test suite.

I tried to fix this a long time ago in a pricipled way in
https://bugs.python.org/issue33826

and Guido explained that fixing it was too heavy handed to be worthwile in

https://mail.python.org/archives/list/python-dev at python.org/thread/AC5B5VORS6FF6KJ3EG5DIV3ZLAQB6DIY/#UL376F3Y6FKJUZ2HZDA3ERFUDDOX67X4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42666>
_______________________________________

From report at bugs.python.org  Thu Dec 17 04:44:01 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 17 Dec 2020 09:44:01 +0000
Subject: [issue42665] Should PyLong_AsLongAndOverflow raise exception on
 overflow?
Message-ID: <1608198241.29.0.475035638972.issue42665@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

No, it should not.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42665>
_______________________________________

From report at bugs.python.org  Thu Dec 17 05:05:01 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 17 Dec 2020 10:05:01 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1608199501.78.0.131871109583.issue31904@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset ba760f3710eccdfae2b680a5f94fe0160ddb1536 by pxinwr in branch 'master':
bpo-31904: Skip some asyncio tests on VxWorks (#23815)
https://github.com/python/cpython/commit/ba760f3710eccdfae2b680a5f94fe0160ddb1536


----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Thu Dec 17 05:32:34 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 17 Dec 2020 10:32:34 +0000
Subject: [issue42665] Should PyLong_AsLongAndOverflow raise exception on
 overflow?
In-Reply-To: <1608198241.29.0.475035638972.issue42665@roundup.psfhosted.org>
Message-ID: <1608201154.42.0.911458916948.issue42665@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

> No, it should not.

I agree.

----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42665>
_______________________________________

From report at bugs.python.org  Thu Dec 17 06:03:49 2020
From: report at bugs.python.org (Irit Katriel)
Date: Thu, 17 Dec 2020 11:03:49 +0000
Subject: [issue23522] Misleading note in Statistics module documentation
In-Reply-To: <1424889646.1.0.160219400081.issue23522@psf.upfronthosting.co.za>
Message-ID: <1608203029.03.0.892931834785.issue23522@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

I agree with Jake's comment, but I think the solution is to remove that Note altogether. This document is a software manual, not a statistics textbook, and as such it should just state clearly what the statistics module does. If someone doesn't know whether they need the mean or the median, they really need to read a more fundamental text before writing their code.

----------
nosy: +iritkatriel

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23522>
_______________________________________

From report at bugs.python.org  Thu Dec 17 06:05:17 2020
From: report at bugs.python.org (gardener.willy)
Date: Thu, 17 Dec 2020 11:05:17 +0000
Subject: [issue42667] shelve module is not thread-safe during accessing
 different databases from different threads
Message-ID: <1608203117.3.0.00404135488038.issue42667@roundup.psfhosted.org>


New submission from gardener.willy <gardener.willy at yandex.ru>:

Shelve module uses "import dbm" instruction while opening database. Dbm module has global dictionary "_modules". This dictionary modifies during database opening operation. When different threads simultaneously try to open different databases, unexpected behavior occurred. In my case I've got such message: 

    with shelve.open('some_file') as f:
  File "/usr/local/lib/python3.6/shelve.py", line 243, in open
    return DbfilenameShelf(filename, flag, protocol, writeback)
  File "/usr/local/lib/python3.6/shelve.py", line 227, in init
    Shelf.init(self, dbm.open(filename, flag), protocol, writeback)
  File "/usr/local/lib/python3.6/dbm/__init__.py", line 94, in open
    return mod.open(file, flag, mode)
AttributeError: module 'dbm.ndbm' has no attribute 'open'

Behavior is the same on python 3.6 and 3.7. Error is spontaneous.

----------
components: Library (Lib)
messages: 383229
nosy: gardener.willy
priority: normal
severity: normal
status: open
title: shelve module is not thread-safe during accessing different databases from different threads
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42667>
_______________________________________

From report at bugs.python.org  Thu Dec 17 06:05:50 2020
From: report at bugs.python.org (hai shi)
Date: Thu, 17 Dec 2020 11:05:50 +0000
Subject: [issue42625] Segmentation fault of PyState_AddModule()
In-Reply-To: <1607785781.22.0.676457210715.issue42625@roundup.psfhosted.org>
Message-ID: <1608203150.65.0.298953742556.issue42625@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

Thanks victor, petr for your comment and review. I closed this bpo and PR.

I paste victor's explanation in here in case other developers have the same question too: Getting a crash is the
expected behaviour if you don't respect a function API. Most C
functions are designed like that. Only very few functions check their
arguments, tests are usually omitted for best performances.

Sorry for this noisy bpo.

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42625>
_______________________________________

From report at bugs.python.org  Thu Dec 17 06:14:55 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Dec 2020 11:14:55 +0000
Subject: [issue41804] test_epoll fails test_control_and_wait() randomly on
 aarch64 RHEL8 Refleaks 3.9
In-Reply-To: <1600360940.95.0.528440416873.issue41804@roundup.psfhosted.org>
Message-ID: <1608203695.34.0.643793766844.issue41804@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 718bf1a7a1a39ca6f2381a299d00d8318732104a by Miss Islington (bot) in branch '3.8':
bpo-41804: Enhance test_epoll.test_control_and_wait() (GH-23795) (GH-23814)
https://github.com/python/cpython/commit/718bf1a7a1a39ca6f2381a299d00d8318732104a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41804>
_______________________________________

From report at bugs.python.org  Thu Dec 17 06:15:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Dec 2020 11:15:27 +0000
Subject: [issue42375] subprocess DragonFlyBSD build update
In-Reply-To: <1605770664.07.0.832622101131.issue42375@roundup.psfhosted.org>
Message-ID: <1608203727.18.0.896594842137.issue42375@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 8d0a01c99b2a810bfe13d654b294c25a10151aa4 by Miss Islington (bot) in branch '3.9':
bpo-42375: subprocess DragonFlyBSD build update. (GH-23320) (GH-23388)
https://github.com/python/cpython/commit/8d0a01c99b2a810bfe13d654b294c25a10151aa4


----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42375>
_______________________________________

From report at bugs.python.org  Thu Dec 17 06:16:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Dec 2020 11:16:03 +0000
Subject: [issue42375] subprocess DragonFlyBSD build update
In-Reply-To: <1605770664.07.0.832622101131.issue42375@roundup.psfhosted.org>
Message-ID: <1608203763.5.0.462730187246.issue42375@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 4f65907f38339809532bc06ffc1382c2c09180e2 by Miss Islington (bot) in branch '3.8':
bpo-42375: subprocess DragonFlyBSD build update. (GH-23320) (GH-23389)
https://github.com/python/cpython/commit/4f65907f38339809532bc06ffc1382c2c09180e2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42375>
_______________________________________

From report at bugs.python.org  Thu Dec 17 06:16:13 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Dec 2020 11:16:13 +0000
Subject: [issue42375] subprocess DragonFlyBSD build update
In-Reply-To: <1605770664.07.0.832622101131.issue42375@roundup.psfhosted.org>
Message-ID: <1608203773.01.0.878102428377.issue42375@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42375>
_______________________________________

From report at bugs.python.org  Thu Dec 17 06:21:59 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 17 Dec 2020 11:21:59 +0000
Subject: [issue42613] freeze.py doesn't support sys.platlibdir different than
 lib nor multiarch
In-Reply-To: <1607594518.8.0.0823964738983.issue42613@roundup.psfhosted.org>
Message-ID: <1608204119.63.0.0207801263193.issue42613@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +22677
pull_request: https://github.com/python/cpython/pull/23817

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42613>
_______________________________________

From report at bugs.python.org  Thu Dec 17 06:22:11 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 17 Dec 2020 11:22:11 +0000
Subject: [issue42613] freeze.py doesn't support sys.platlibdir different than
 lib nor multiarch
In-Reply-To: <1607594518.8.0.0823964738983.issue42613@roundup.psfhosted.org>
Message-ID: <1608204131.81.0.0742625159084.issue42613@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22678
pull_request: https://github.com/python/cpython/pull/23818

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42613>
_______________________________________

From report at bugs.python.org  Thu Dec 17 06:34:44 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 17 Dec 2020 11:34:44 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1608204884.22.0.978399922613.issue42529@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Monkeypatching native types looks suspect as anything, but probably not the cause here. Good luck :)

So I checked some of our code around dynamic loads and it's got to be caused by the loader in our LoadLibrary call, not when we call your module init function. That rules out basically anything you're doing once the module is loaded.

The only thing I can think of that may be missing in the .pyc case is encodings. They *should* be being imported automatically on load, but perhaps not as we're constantly trying to improve startup time. You could try adding "import codecs" and then codecs.lookup some codecs.

You might also try running Python in verbose mode ("python -v ...") and comparing the output between the two cases. That could show up what extra things are being skipped in the failing case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Thu Dec 17 06:40:43 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 17 Dec 2020 11:40:43 +0000
Subject: [issue42613] freeze.py doesn't support sys.platlibdir different than
 lib nor multiarch
In-Reply-To: <1607594518.8.0.0823964738983.issue42613@roundup.psfhosted.org>
Message-ID: <1608205243.53.0.478376256725.issue42613@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 829272e67bbd4b2cc76c01cd20265eb114b392a2 by Miss Islington (bot) in branch '3.8':
bpo-42613: Fix freeze.py config directory (GH-23792)
https://github.com/python/cpython/commit/829272e67bbd4b2cc76c01cd20265eb114b392a2


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42613>
_______________________________________

From report at bugs.python.org  Thu Dec 17 06:50:41 2020
From: report at bugs.python.org (Irit Katriel)
Date: Thu, 17 Dec 2020 11:50:41 +0000
Subject: [issue26564] Malloc debug hooks: display memory block traceback on
 error
In-Reply-To: <1458002396.02.0.186265116381.issue26564@psf.upfronthosting.co.za>
Message-ID: <1608205841.45.0.180577013541.issue26564@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

I'm reopening this to commit a fix for a comment which became obsolete following this change: https://hg.python.org/cpython/rev/18a19e62bac5.

----------
nosy: +iritkatriel
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26564>
_______________________________________

From report at bugs.python.org  Thu Dec 17 06:50:46 2020
From: report at bugs.python.org (Irit Katriel)
Date: Thu, 17 Dec 2020 11:50:46 +0000
Subject: [issue26564] Malloc debug hooks: display memory block traceback on
 error
In-Reply-To: <1458002396.02.0.186265116381.issue26564@psf.upfronthosting.co.za>
Message-ID: <1608205846.73.0.233552232749.issue26564@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
pull_requests: +22679
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23819

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26564>
_______________________________________

From report at bugs.python.org  Thu Dec 17 07:00:52 2020
From: report at bugs.python.org (Martin Altmayer)
Date: Thu, 17 Dec 2020 12:00:52 +0000
Subject: [issue42668] re.escape does not correctly escape newlines
Message-ID: <1608206452.14.0.809229064925.issue42668@roundup.psfhosted.org>


New submission from Martin Altmayer <martin.altmayer at web.de>:

re.escape('\n') returns '\\\n', i.e. a string consisting of a backslash and a newline. I believe it should return '\\n', i.e. a backslash and an 'n'. If the escape-result still contains a verbatim newline, why escape this character at all?

Note that Python's regular expressions engine allows newlines, so re.match(re.escape('\n'), '\n') gives a match. Thus, while this looks like an undesired behavior, it is not functionally broken.

The same problem applies to some other characters: \t\r\v\f

----------
components: Regular Expressions
files: test.py
messages: 383237
nosy: MartinAltmayer, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: re.escape does not correctly escape newlines
type: behavior
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49689/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42668>
_______________________________________

From report at bugs.python.org  Thu Dec 17 07:01:17 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 17 Dec 2020 12:01:17 +0000
Subject: [issue42667] shelve module is not thread-safe during accessing
 different databases from different threads
In-Reply-To: <1608203117.3.0.00404135488038.issue42667@roundup.psfhosted.org>
Message-ID: <1608206477.41.0.766423124983.issue42667@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +brett.cannon, eric.snow, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42667>
_______________________________________

From report at bugs.python.org  Thu Dec 17 07:33:23 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 17 Dec 2020 12:33:23 +0000
Subject: [issue26564] Malloc debug hooks: display memory block traceback on
 error
In-Reply-To: <1458002396.02.0.186265116381.issue26564@psf.upfronthosting.co.za>
Message-ID: <1608208403.24.0.111399176865.issue26564@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +22680
pull_request: https://github.com/python/cpython/pull/23820

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26564>
_______________________________________

From report at bugs.python.org  Thu Dec 17 07:33:30 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 17 Dec 2020 12:33:30 +0000
Subject: [issue26564] Malloc debug hooks: display memory block traceback on
 error
In-Reply-To: <1458002396.02.0.186265116381.issue26564@psf.upfronthosting.co.za>
Message-ID: <1608208410.89.0.630675407399.issue26564@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22681
pull_request: https://github.com/python/cpython/pull/23821

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26564>
_______________________________________

From report at bugs.python.org  Thu Dec 17 07:33:44 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Dec 2020 12:33:44 +0000
Subject: [issue26564] Malloc debug hooks: display memory block traceback on
 error
In-Reply-To: <1458002396.02.0.186265116381.issue26564@psf.upfronthosting.co.za>
Message-ID: <1608208424.4.0.506874302757.issue26564@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 40125ab3252453bf205ed906e46bf9741c27bf9d by Irit Katriel in branch 'master':
bpo-26564: fix obsolete comment in traceback.c (GH-23819)
https://github.com/python/cpython/commit/40125ab3252453bf205ed906e46bf9741c27bf9d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26564>
_______________________________________

From report at bugs.python.org  Thu Dec 17 07:55:57 2020
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 17 Dec 2020 12:55:57 +0000
Subject: [issue42668] re.escape does not correctly escape newlines
In-Reply-To: <1608206452.14.0.809229064925.issue42668@roundup.psfhosted.org>
Message-ID: <1608209757.79.0.655058138665.issue42668@roundup.psfhosted.org>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

In a regex, putting a backslash before any character that's not an ASCII-range letter or digit makes it a literal. re.escape doesn't special-case control characters. Its purpose is to make a string that might contain metacharacters into one that's a literal, and it already does that, although it sometimes escapes more than necessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42668>
_______________________________________

From report at bugs.python.org  Thu Dec 17 08:02:31 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 17 Dec 2020 13:02:31 +0000
Subject: [issue42668] re.escape does not correctly escape newlines
In-Reply-To: <1608206452.14.0.809229064925.issue42668@roundup.psfhosted.org>
Message-ID: <1608210151.6.0.543225168966.issue42668@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> If the escape-result still contains a verbatim newline, why escape this character at all?

Because in verbose mode it is ignored. This is why \n and other ASCII whitespace characters, and '#', which starts a comment, should be escaped.

'\\\n' and '\\n' has identical meaning independent of mode and context, so there is no bug here. Escaping '\n' as '\\\n' is slightly simpler.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42668>
_______________________________________

From report at bugs.python.org  Thu Dec 17 08:19:58 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 17 Dec 2020 13:19:58 +0000
Subject: [issue26564] Malloc debug hooks: display memory block traceback on
 error
In-Reply-To: <1458002396.02.0.186265116381.issue26564@psf.upfronthosting.co.za>
Message-ID: <1608211198.17.0.896729628661.issue26564@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset cecbaa3a80d5ae28cdd4129d6d2c4395c12a89e4 by Miss Islington (bot) in branch '3.8':
bpo-26564: fix obsolete comment in traceback.c (GH-23819)
https://github.com/python/cpython/commit/cecbaa3a80d5ae28cdd4129d6d2c4395c12a89e4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26564>
_______________________________________

From report at bugs.python.org  Thu Dec 17 08:20:06 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 17 Dec 2020 13:20:06 +0000
Subject: [issue26564] Malloc debug hooks: display memory block traceback on
 error
In-Reply-To: <1458002396.02.0.186265116381.issue26564@psf.upfronthosting.co.za>
Message-ID: <1608211206.12.0.157620283631.issue26564@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1c70d40e94741578ce28b8851fb65372ac2e7942 by Miss Islington (bot) in branch '3.9':
bpo-26564: fix obsolete comment in traceback.c (GH-23819)
https://github.com/python/cpython/commit/1c70d40e94741578ce28b8851fb65372ac2e7942


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26564>
_______________________________________

From report at bugs.python.org  Thu Dec 17 08:20:48 2020
From: report at bugs.python.org (Irit Katriel)
Date: Thu, 17 Dec 2020 13:20:48 +0000
Subject: [issue26564] Malloc debug hooks: display memory block traceback on
 error
In-Reply-To: <1458002396.02.0.186265116381.issue26564@psf.upfronthosting.co.za>
Message-ID: <1608211248.76.0.296160287658.issue26564@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26564>
_______________________________________

From report at bugs.python.org  Thu Dec 17 08:27:57 2020
From: report at bugs.python.org (Colin Watson)
Date: Thu, 17 Dec 2020 13:27:57 +0000
Subject: [issue42669] "except" documentation still suggests nested tuples are
 allowed
Message-ID: <1608211677.22.0.0507603390583.issue42669@roundup.psfhosted.org>


New submission from Colin Watson <cjwatson at users.sourceforge.net>:

In Python 2, it was possible to use `except` with a nested tuple, and occasionally natural.  For example, `zope.formlib.interfaces.InputErrors` is a tuple of several exception classes, and one might reasonably think to do something like this (this is real code used in several places in https://git.launchpad.net/launchpad):

    try:
        self.getInputValue()
        return True
    except (InputErrors, SomethingElse):
        return False

As of Python 3.0, this raises "TypeError: catching classes that do not inherit from BaseException is not allowed" instead: one must instead either break it up into multiple "except" clauses or flatten the tuple.  The change was mentioned in https://bugs.python.org/issue2380 and seems to have been intentional: I'm not requesting that the previous behaviour be restored, since it's a fairly rare porting issue and by now well-established in Python 3.

However, the relevant sentences of documentation in https://docs.python.org/2/reference/compound_stmts.html#try and https://docs.python.org/3/reference/compound_stmts.html#the-try-statement are identical aside from punctuation, and they both read:

     For an except clause with an expression, that expression is evaluated, and the clause matches the exception if the resulting object is ?compatible? with the exception.  An object is compatible with an exception if it is the class or a base class of the exception object or a tuple containing an item compatible with the exception.

I think this admits a recursive reading: I certainly read it that way.  It should make it clear that nested tuples are not allowed.

----------
assignee: docs at python
components: Documentation
messages: 383243
nosy: cjwatson, docs at python
priority: normal
severity: normal
status: open
title: "except" documentation still suggests nested tuples are allowed
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42669>
_______________________________________

From report at bugs.python.org  Thu Dec 17 08:30:45 2020
From: report at bugs.python.org (Colin Watson)
Date: Thu, 17 Dec 2020 13:30:45 +0000
Subject: [issue42669] "except" documentation still suggests nested tuples are
 allowed
In-Reply-To: <1608211677.22.0.0507603390583.issue42669@roundup.psfhosted.org>
Message-ID: <1608211845.0.0.348571779942.issue42669@roundup.psfhosted.org>


Change by Colin Watson <cjwatson at users.sourceforge.net>:


----------
keywords: +patch
pull_requests: +22682
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23822

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42669>
_______________________________________

From report at bugs.python.org  Thu Dec 17 08:48:32 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 17 Dec 2020 13:48:32 +0000
Subject: [issue26564] Malloc debug hooks: display memory block traceback on
 error
In-Reply-To: <1458002396.02.0.186265116381.issue26564@psf.upfronthosting.co.za>
Message-ID: <1608212912.26.0.202049862669.issue26564@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I am wondering why 53/22? 5/2 is as good for 8-bytes long -- both gives 21-bytes buffer.

I do not propose to change anything. It is just curiosity.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26564>
_______________________________________

From report at bugs.python.org  Thu Dec 17 08:55:38 2020
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 17 Dec 2020 13:55:38 +0000
Subject: [issue42246] Implement PEP 626 -- Precise line numbers for debugging
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1608213338.12.0.764040909299.issue42246@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset bf353f3c2d937772a8cf30b15fd8eb7b82665ccb by Mark Shannon in branch 'master':
bpo-42246: Make sure that `f_lasti`, and thus `f_lineno`, is set correctly after raising or reraising an exception (GH-23803)
https://github.com/python/cpython/commit/bf353f3c2d937772a8cf30b15fd8eb7b82665ccb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42246>
_______________________________________

From report at bugs.python.org  Thu Dec 17 08:56:51 2020
From: report at bugs.python.org (Mark Shannon)
Date: Thu, 17 Dec 2020 13:56:51 +0000
Subject: [issue42645] break/continue or return in finally block occurs twice
 in trace.
In-Reply-To: <1608034892.59.0.529132946554.issue42645@roundup.psfhosted.org>
Message-ID: <1608213411.14.0.0457326845129.issue42645@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42645>
_______________________________________

From report at bugs.python.org  Thu Dec 17 08:58:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Dec 2020 13:58:11 +0000
Subject: [issue26564] Malloc debug hooks: display memory block traceback on
 error
In-Reply-To: <1458002396.02.0.186265116381.issue26564@psf.upfronthosting.co.za>
Message-ID: <1608213491.97.0.671186060367.issue26564@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I am wondering why 53/22? 5/2 is as good for 8-bytes long -- both gives 21-bytes buffer.

53/22 is closer to math.log(256)/math.log(10) than 5/2, and 8*53 should not overflow :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26564>
_______________________________________

From report at bugs.python.org  Thu Dec 17 09:01:31 2020
From: report at bugs.python.org (Martin Altmayer)
Date: Thu, 17 Dec 2020 14:01:31 +0000
Subject: [issue42668] re.escape does not correctly escape newlines
In-Reply-To: <1608206452.14.0.809229064925.issue42668@roundup.psfhosted.org>
Message-ID: <1608213691.61.0.156241652511.issue42668@roundup.psfhosted.org>


Martin Altmayer <martin.altmayer at web.de> added the comment:

Thanks for the explanation, I did not know re.VERBOSE. I still think the behavior is a bit confusing, but it's probably not worth the effort to change this.

----------
type: behavior -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42668>
_______________________________________

From report at bugs.python.org  Thu Dec 17 09:29:45 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Dec 2020 14:29:45 +0000
Subject: [issue42613] freeze.py doesn't support sys.platlibdir different than
 lib nor multiarch
In-Reply-To: <1607594518.8.0.0823964738983.issue42613@roundup.psfhosted.org>
Message-ID: <1608215385.52.0.304042853435.issue42613@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 79c535796da4a1377364910e309b97e53c3e51ef by Miss Islington (bot) in branch '3.9':
bpo-42613: Fix freeze.py config directory (GH-23792) (GH-23817)
https://github.com/python/cpython/commit/79c535796da4a1377364910e309b97e53c3e51ef


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42613>
_______________________________________

From report at bugs.python.org  Thu Dec 17 09:29:52 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Dec 2020 14:29:52 +0000
Subject: [issue42613] freeze.py doesn't support sys.platlibdir different than
 lib nor multiarch
In-Reply-To: <1607594518.8.0.0823964738983.issue42613@roundup.psfhosted.org>
Message-ID: <1608215392.7.0.936102722768.issue42613@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42613>
_______________________________________

From report at bugs.python.org  Thu Dec 17 09:41:45 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 17 Dec 2020 14:41:45 +0000
Subject: [issue42668] re.escape does not correctly escape newlines
In-Reply-To: <1608206452.14.0.809229064925.issue42668@roundup.psfhosted.org>
Message-ID: <1608216105.39.0.631367462025.issue42668@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/issue42668>
_______________________________________

From report at bugs.python.org  Thu Dec 17 10:31:06 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 17 Dec 2020 15:31:06 +0000
Subject: [issue42651] Recursive traceback crashes  Python Interpreter
In-Reply-To: <1608105735.03.0.523665122471.issue42651@roundup.psfhosted.org>
Message-ID: <1608219066.39.0.949869152971.issue42651@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This might be related to #42500

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42651>
_______________________________________

From report at bugs.python.org  Thu Dec 17 10:36:21 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 17 Dec 2020 15:36:21 +0000
Subject: [issue42652] recursive in finally clause cause Python interpreter
 crash.
In-Reply-To: <1608108499.51.0.334108279167.issue42652@roundup.psfhosted.org>
Message-ID: <1608219381.28.0.488699902287.issue42652@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This might be related to #42500

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42652>
_______________________________________

From report at bugs.python.org  Thu Dec 17 11:23:01 2020
From: report at bugs.python.org (Karl Nelson)
Date: Thu, 17 Dec 2020 16:23:01 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1608222181.06.0.954022943882.issue42529@roundup.psfhosted.org>


Karl Nelson <nelson85 at llnl.gov> added the comment:

Thanks, I will see if I can get additional diagnostics today.  Otherwise I will have to start recompiling Python with diagnostic hooks.  I have never had to rebuild python on windows so it may take a while to figure out how to make progress.

The monkey patch is less scary than it looks.   Since I only need these slots of specific basic types that I designate (not user selected), the extra types all extend without altering the underlaying type, and the class layout is controlled by a meta class so that only Java can create these type objects, it is reasonably robust.   However, yes changes in Python can break it.  It is basically an attempt to create a mixin for concrete classes without the benefit of a dictoffset type slot.  It took about a month do develop something that safely added the slot without overrunning, leaking or creating other memory issues (and played nice when Python added its own dict slot). 

Unfortunately, as I do many 100s on JSlot tests during method resolution using a dict based approach was unacceptably slow.  I would love if there was a formal method to create multiple inheritance mixins for Python basic types, but that is another issue.


```
/**
 * Allocate a new Python object with a slot for Java.
 *
 * We need extra space to store our values, but because there
 * is no way to do so without disturbing the object layout.
 * Fortunately, Python already handles this for dict and weakref.
 * Python aligns the ends of the structure and increases the
 * base type size to add additional slots to a standard object.
 *
 * We will use the same trick to add an additional slot for Java
 * after the end of the object outside of where Python is looking.
 * As the memory is aligned this is safe to do.  We will use
 * the alloc and finalize slot to recognize which objects have this
 * extra slot appended.
 */
PyObject* PyJPValue_alloc(PyTypeObject* type, Py_ssize_t nitems )
{
	// Modification from Python to add size elements
	const size_t size = _PyObject_VAR_SIZE(type, nitems + 1) + sizeof (JPValue);
	PyObject *obj = (PyType_IS_GC(type)) ? _PyObject_GC_Malloc(size)
			: (PyObject *) PyObject_MALLOC(size);
	if (obj == NULL)
		return PyErr_NoMemory(); // GCOVR_EXCL_LINE
	memset(obj, 0, size);

	Py_ssize_t refcnt = ((PyObject*) type)->ob_refcnt;
	if (type->tp_itemsize == 0)
		PyObject_Init(obj, type);
	else
		PyObject_InitVar((PyVarObject *) obj, type, nitems);

	// This line is required to deal with Python bug (GH-11661)
	// Some versions of Python fail to increment the reference counter of
	// heap types properly.
	if (refcnt == ((PyObject*) type)->ob_refcnt)
		Py_INCREF(type);  // GCOVR_EXCL_LINE

	if (PyType_IS_GC(type))
	{
		PyObject_GC_Track(obj);
	}
	return obj;
}

bool PyJPValue_hasJavaSlot(PyTypeObject* type)
{
	if (type == NULL
			|| type->tp_alloc != (allocfunc) PyJPValue_alloc
			|| type->tp_finalize != (destructor) PyJPValue_finalize)
		return false;  // GCOVR_EXCL_LINE
	return true;
}

// Check for a Java slot (must work on all object types)
Py_ssize_t PyJPValue_getJavaSlotOffset(PyObject* self)
{
	PyTypeObject *type = Py_TYPE(self);
	if (type == NULL
			|| type->tp_alloc != (allocfunc) PyJPValue_alloc
			|| type->tp_finalize != (destructor) PyJPValue_finalize)
		return 0;
	Py_ssize_t offset;
	Py_ssize_t sz = Py_SIZE(self);
	// I have no clue what negative sizes mean
	if (sz < 0)
		sz = -sz;
	if (type->tp_itemsize == 0)
		offset = _PyObject_VAR_SIZE(type, 1);
	else
		offset = _PyObject_VAR_SIZE(type, sz + 1);
	return offset;
}

JPValue* PyJPValue_getJavaSlot(PyObject* self)
{
	Py_ssize_t offset = PyJPValue_getJavaSlotOffset(self);
	if (offset == 0)
		return NULL;
	JPValue* value = (JPValue*) (((char*) self) + offset);
	if (value->getClass() == NULL)
		return NULL;
	return value;
}

void PyJPValue_free(void* obj)
{
	// Normally finalize is not run on simple classes.
	PyTypeObject *type = Py_TYPE(obj);
	if (type->tp_finalize != NULL)
		type->tp_finalize((PyObject*) obj);
	if (type->tp_flags & Py_TPFLAGS_HAVE_GC)
		PyObject_GC_Del(obj);
	else
		PyObject_Free(obj);  // GCOVR_EXCL_LINE
}

void PyJPValue_finalize(void* obj)
{
	JPValue* value = PyJPValue_getJavaSlot((PyObject*) obj);
	... destroy the objects hidden slot if it exists
}

```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Thu Dec 17 11:33:57 2020
From: report at bugs.python.org (Xinmeng Xia)
Date: Thu, 17 Dec 2020 16:33:57 +0000
Subject: [issue42652] recursive in finally clause cause Python interpreter
 crash.
In-Reply-To: <1608108499.51.0.334108279167.issue42652@roundup.psfhosted.org>
Message-ID: <1608222837.8.0.0595818813816.issue42652@roundup.psfhosted.org>


Xinmeng Xia <xiaxm at smail.nju.edu.cn> added the comment:

In issue #42500, crashes is resulted by recursion and try-except. Program like following will crash the interpreter.
=====
def foo():
	try:
		1/0
	except:
		pass
	foo()
foo()
=====
However with traceback module, program will no longer crash the interpreter. A recursive Error is returned as expected. 
=====
import traceback
def foo():
	try:
		1/0
	except:
		traceback.print_exc()
	foo()
foo()
=====
But it is still crash the interpreter in finally clause. I think this might be a new but and it is different from #42500. It should be related to traceback module, finally clause and recursion. what do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42652>
_______________________________________

From report at bugs.python.org  Thu Dec 17 11:40:45 2020
From: report at bugs.python.org (Xinmeng Xia)
Date: Thu, 17 Dec 2020 16:40:45 +0000
Subject: [issue42651] Recursive traceback crashes  Python Interpreter
In-Reply-To: <1608105735.03.0.523665122471.issue42651@roundup.psfhosted.org>
Message-ID: <1608223245.47.0.496666269266.issue42651@roundup.psfhosted.org>


Xinmeng Xia <xiaxm at smail.nju.edu.cn> added the comment:

In issue#36272, they discuss a bug in logging module. They show an example which is similar as this one. So I think I think there might be a similar bug in traceback module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42651>
_______________________________________

From report at bugs.python.org  Thu Dec 17 11:50:58 2020
From: report at bugs.python.org (Karl Nelson)
Date: Thu, 17 Dec 2020 16:50:58 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1608223858.59.0.7205588339.issue42529@roundup.psfhosted.org>


Karl Nelson <nelson85 at llnl.gov> added the comment:

Without the pyc everything goes fine...

```
...
_bootlocale' # <_frozen_importlib_external.SourceFileLoader object at 0x00000222E9FD5A30>
import 'site' # <_frozen_importlib_external.SourceFileLoader object at 0x00000222E9F88F40>
Python 3.9.0 (tags/v3.9.0:9cf6752, Oct  5 2020, 15:34:40) [MSC v.1927 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
# code object from c:\users\nelson85\documents\devel\open\jpype\jpype\__init__.py
# created 'c:\\users\\nelson85\\documents\\devel\\open\\jpype\\jpype\\__pycache__\\__init__.cpython-39.pyc'
# extension module '_jpype' loaded from 'c:\\users\\nelson85\\documents\\devel\\open\\jpype\\_jpype.cp39-win_amd64.pyd'
# extension module '_jpype' executed from 'c:\\users\\nelson85\\documents\\devel\\open\\jpype\\_jpype.cp39-win_amd64.pyd'
import '_jpype' # <_frozen_importlib_external.ExtensionFileLoader object at 0x00000222EA4C6250>
# c:\users\nelson85\documents\devel\open\jpype\jpype\__pycache__\_jinit.cpython-39.pyc matches c:\users\nelson85\documents\devel\open\jpype\jpype\_jinit.py
# code o
...
```

With the pyc file, failure... 

```
...
_bootlocale' # <_frozen_importlib_external.SourceFileLoader object at 0x0000015278445A30>
import 'site' # <_frozen_importlib_external.SourceFileLoader object at 0x00000152783F8F40>
Python 3.9.0 (tags/v3.9.0:9cf6752, Oct  5 2020, 15:34:40) [MSC v.1927 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
# c:\users\nelson85\documents\devel\open\jpype\jpype\__pycache__\__init__.cpython-39.pyc matches c:\users\nelson85\documents\devel\open\jpype\jpype\__init__.py
# code object from 'c:\\users\\nelson85\\documents\\devel\\open\\jpype\\jpype\\__pycache__\\__init__.cpython-39.pyc'
Traceback (most recent call last):
  File "C:\Users\nelson85\Documents\test.py", line 1, in <module>
    import jpype
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 790, in exec_module
  File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
  File "c:\users\nelson85\documents\devel\open\jpype\jpype\__init__.py", line 18, in <module>
    import _jpype
  File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
  File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 666, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 565, in module_from_spec
  File "<frozen importlib._bootstrap_external>", line 1108, in create_module
  File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
ImportError: DLL load failed while importing _jpype: A dynamic link library (DLL) initialization routine failed.
# clear builtins._
# clear sys.path
# clear sys.argv
# clear sys.ps1
# clear sys.ps2
# clear sys.last_type
# clear sys.last_value
# clear sys.last_traceback
# destroy jpype
# clear sys.path_hooks
# clear sys.path_importer_cache
# clear sys.meta_path
# clear sys.__interactivehook__
# restore sys.stdin
# restore sys.stdout
# restore sys.stderr
...
```

I see the codecs all get loaded earlier in the trace, so that can't be the issue.  There were no differences (other than memory addresses) up to this point.  So it must be going wrong at bootstrap_external:1108.

So guessing from the message we failed in.

```
    def exec_module(self, module):
        """Initialize an extension module"""
        _bootstrap._call_with_frames_removed(_imp.exec_dynamic, module)
        _bootstrap._verbose_message('extension module {!r} executed from {!r}',
                         self.name, self.path)
```

After that point it gets really fuzzy.  I would guess we are going to import.c#_imp_create_dynamic_impl which takes us to _PyImport_LoadDynamicModuleWithSpec.  But I will need some time to read code to see if this guess is correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Thu Dec 17 12:39:50 2020
From: report at bugs.python.org (Steve Dower)
Date: Thu, 17 Dec 2020 17:39:50 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1608226790.9.0.766389045628.issue42529@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

You'll find it leads up to a LoadLibraryExW call in Python/dynload_win.c that is failing with ERROR_DLL_INIT_FAILED (1114) in GetLastError(). From that point on, it's looking solely at _jpype.pyd and its dependencies, and it could be any of them failing to load.

You can rule out anything that's already loaded at that stage, since it won't be calling the initialization routine. And anything in your module initialization would cause an error later than this, so it's clean too.

However, I think some static variables may be initialised at this point? So if you've got any statics, those might be working too hard (and statics in C++ can easily do too much work).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Thu Dec 17 12:48:31 2020
From: report at bugs.python.org (Karl Nelson)
Date: Thu, 17 Dec 2020 17:48:31 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1608227311.62.0.883705187495.issue42529@roundup.psfhosted.org>


Karl Nelson <nelson85 at llnl.gov> added the comment:

Well that gives me a place to search from.   Unfortunately statics are not likely the source of the issue.   I scrubbed all C++ structures from the project into a big structure which has only a single global pointer which I initialize in the init method.   It is possible that one crept back in at some point, but it is a possibility.   The use of actual C++ in this project is nearly zero.  Other than exceptions, strings and the vector on the buried in some class, the rest has been purged already.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Thu Dec 17 12:49:53 2020
From: report at bugs.python.org (Scott Noyes)
Date: Thu, 17 Dec 2020 17:49:53 +0000
Subject: [issue42670] Missing word in itertools.product
Message-ID: <1608227393.01.0.305034051579.issue42670@roundup.psfhosted.org>


New submission from Scott Noyes <snoyes at gmail.com>:

-Accordingly, it only useful with finite inputs.
+Accordingly, it is only useful with finite inputs.

----------
assignee: docs at python
components: Documentation
messages: 383257
nosy: docs at python, snoyes
priority: normal
severity: normal
status: open
title: Missing word in itertools.product
type: behavior
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42670>
_______________________________________

From report at bugs.python.org  Thu Dec 17 12:55:53 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 17 Dec 2020 17:55:53 +0000
Subject: [issue42670] Missing word in itertools.product
In-Reply-To: <1608227393.01.0.305034051579.issue42670@roundup.psfhosted.org>
Message-ID: <1608227753.92.0.482907591389.issue42670@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 2.0 -> 3.0
pull_requests: +22683
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23823

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42670>
_______________________________________

From report at bugs.python.org  Thu Dec 17 13:00:36 2020
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 17 Dec 2020 18:00:36 +0000
Subject: [issue42667] shelve module is not thread-safe during accessing
 different databases from different threads
In-Reply-To: <1608203117.3.0.00404135488038.issue42667@roundup.psfhosted.org>
Message-ID: <1608228036.06.0.454825698356.issue42667@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/issue42667>
_______________________________________

From report at bugs.python.org  Thu Dec 17 13:55:25 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 17 Dec 2020 18:55:25 +0000
Subject: [issue42667] shelve module is not thread-safe during accessing
 different databases from different threads
In-Reply-To: <1608203117.3.0.00404135488038.issue42667@roundup.psfhosted.org>
Message-ID: <1608231325.75.0.117402495169.issue42667@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I added import experts because the issue looks relates to race condition in import.

Willy, can the issue be reproduced on more modern Python releases (3.8 or 3.9)? It could help if you provide minimal script which reproduces it.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42667>
_______________________________________

From report at bugs.python.org  Thu Dec 17 14:22:38 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Dec 2020 19:22:38 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1608232958.19.0.636279257701.issue31904@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 75dabfe7a8324a16687959cc401deb72b104a575 by pxinwr in branch 'master':
bpo-31904: posixpath.expanduser() handles None user home on VxWorks (GH-23530)
https://github.com/python/cpython/commit/75dabfe7a8324a16687959cc401deb72b104a575


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Thu Dec 17 14:43:54 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 17 Dec 2020 19:43:54 +0000
Subject: [issue42115] Caching infrastructure for the evaluation loop:
 specialised opcodes
In-Reply-To: <1603336898.74.0.366564812208.issue42115@roundup.psfhosted.org>
Message-ID: <1608234234.61.0.440931723249.issue42115@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> I think I am closing the PR as it seems that the gains are not good enough (and there is quite a lot of noise by comparing the benchmarks together).

IMO you need to implement LOAD_METHOD support for all kinds of calls, including the ones that use kwargs, to see any improvement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42115>
_______________________________________

From report at bugs.python.org  Thu Dec 17 15:08:33 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 17 Dec 2020 20:08:33 +0000
Subject: [issue42115] Caching infrastructure for the evaluation loop:
 specialised opcodes
In-Reply-To: <1603336898.74.0.366564812208.issue42115@roundup.psfhosted.org>
Message-ID: <1608235713.74.0.108640187462.issue42115@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> IMO you need to implement LOAD_METHOD support for all kinds of calls, including the ones that use kwargs, to see any improvement.

I will try to do some prototyping around that to see how much can we gain in that route. In any case, adding LOAD_METHOD support for all kinds of calls should be an improvement by itself even without caching, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42115>
_______________________________________

From report at bugs.python.org  Thu Dec 17 15:22:48 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 17 Dec 2020 20:22:48 +0000
Subject: [issue42115] Caching infrastructure for the evaluation loop:
 specialised opcodes
In-Reply-To: <1603336898.74.0.366564812208.issue42115@roundup.psfhosted.org>
Message-ID: <1608236568.64.0.152222858058.issue42115@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

> I will try to do some prototyping around that to see how much can we gain in that route. In any case, adding LOAD_METHOD support for all kinds of calls should be an improvement by itself even without caching, no?

Exactly.

As one argument for generalizing of LOAD_METHOD is that I, for example, try not to use kwargs in hot paths because I know it will be slower, which feels very wrong. I shouldn't care of internal implementation details of CPython and focus on writing readable code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42115>
_______________________________________

From report at bugs.python.org  Thu Dec 17 15:24:51 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 17 Dec 2020 20:24:51 +0000
Subject: [issue42670] Missing word in itertools.product
In-Reply-To: <1608227393.01.0.305034051579.issue42670@roundup.psfhosted.org>
Message-ID: <1608236691.76.0.711590295977.issue42670@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 074ad5123f18923bdb5fa0b6e4bf24de45e32ba9 by Zackery Spytz in branch 'master':
bpo-42670: Fix a missing word in the itertools.product() docs (GH-23823)
https://github.com/python/cpython/commit/074ad5123f18923bdb5fa0b6e4bf24de45e32ba9


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42670>
_______________________________________

From report at bugs.python.org  Thu Dec 17 15:25:12 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 17 Dec 2020 20:25:12 +0000
Subject: [issue42670] Missing word in itertools.product
In-Reply-To: <1608227393.01.0.305034051579.issue42670@roundup.psfhosted.org>
Message-ID: <1608236712.22.0.515900268846.issue42670@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22684
pull_request: https://github.com/python/cpython/pull/23824

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42670>
_______________________________________

From report at bugs.python.org  Thu Dec 17 15:27:30 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 17 Dec 2020 20:27:30 +0000
Subject: [issue42600] Cancelling tasks waiting for asyncio.Conditions crashes
 w/ RuntimeError: Lock is not acquired.
In-Reply-To: <1607430956.17.0.934441920245.issue42600@roundup.psfhosted.org>
Message-ID: <1608236850.45.0.981288160893.issue42600@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Hey Hynek! :) Can you submit a PR?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42600>
_______________________________________

From report at bugs.python.org  Thu Dec 17 15:40:51 2020
From: report at bugs.python.org (Peixing Xin)
Date: Thu, 17 Dec 2020 20:40:51 +0000
Subject: [issue10496] Python startup should not require passwd entry
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1608237651.57.0.504087789149.issue10496@roundup.psfhosted.org>


Change by Peixing Xin <peixing.xin at windriver.com>:


----------
nosy: +pxinwr
nosy_count: 28.0 -> 29.0
pull_requests: +22685
pull_request: https://github.com/python/cpython/pull/23530

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue10496>
_______________________________________

From report at bugs.python.org  Thu Dec 17 16:05:55 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 17 Dec 2020 21:05:55 +0000
Subject: [issue42663] zoneinfo does not support full range of allowed
 transition hours in fallback string
In-Reply-To: <1608154433.49.0.318883425805.issue42663@roundup.psfhosted.org>
Message-ID: <1608239155.26.0.81390701361.issue42663@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
nosy: +serhiy.storchaka
nosy_count: 1.0 -> 2.0
pull_requests: +22686
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/23825

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42663>
_______________________________________

From report at bugs.python.org  Thu Dec 17 16:05:55 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 17 Dec 2020 21:05:55 +0000
Subject: [issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable
 in calenderrule_new
In-Reply-To: <1608134368.02.0.941471966425.issue42660@roundup.psfhosted.org>
Message-ID: <1608239155.35.0.229781703037.issue42660@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +22687
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/23825

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42660>
_______________________________________

From report at bugs.python.org  Thu Dec 17 16:13:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Dec 2020 21:13:20 +0000
Subject: [issue42671] Make the Python finalization more deterministic
Message-ID: <1608239600.62.0.0456277879965.issue42671@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

At exit, Python calls Py_Finalize() which tries to clear every single Python objects. The order is which Python objects are cleared is not fully deterministic. Py_Finalize() uses an heuristic to attempt to clear modules of sys.modules in the "best" order.

The current code creates a weak reference to a module, set sys.modules[name] to None, and then clears the module attribute if and only if the module object was not destroyed (if the weak reference still points to the module).

The problem is that even if a module object is destroyed, the module dictionary can remain alive thanks for various kinds of strong references to it.

Worst case example:
---
class VerboseDel:
    def __del__(self):
        print("Goodbye Cruel World")
obj = VerboseDel()

def func():
    pass

import os
os.register_at_fork(after_in_child=func)
del os
del func

print("exit")
---

Output:
---
$ python3.9 script.py
exit
---

=> The VerboseDel object is never destroyed :-( BUG!


Explanation:

* os.register_at_fork(after_in_child=func) stores func in PyInterpreterState.after_forkers_child -> func() is kept alive until interpreter_clear() calls Py_CLEAR(interp->after_forkers_child);

* func() has reference to the module dictionary

I'm not sure why the VerboseDel object is not destroyed.


I propose to rewrite the finalize_modules() to clear modules in a more deterministic order:

* start by clearing __main__ module variables
* then iterate on reversed(sys.modules.values()) and clear the module variables
* Module attributes are cleared by _PyModule_ClearDict(): iterate on reversed(module.__dict__) and set dict values to None


Drawback: it is a backward incompatible change. Code which worked by luck previously no longer works. I'm talking about applications which rely on __del__() methods being calling in an exact order and expect Python being in a specific state.

Example:
---
class VerboseDel:
    def __init__(self, name):
        self.name = name
    def __del__(self):
        print(self.name)

a = VerboseDel("a")
b = VerboseDel("b")
c = VerboseDel("c")
---

Output:
---
c
b
a
---

=> Module attributes are deleted in the reverse order of their definition: the most recent object is deleted first, the oldest is deleted last.


Example 2 with 3 modules (4 files):
---
$ cat a.py 
class VerboseDel:
    def __init__(self, name):
        self.name = name
    def __del__(self):
        print(self.name)

a = VerboseDel("a")


$ cat b.py 
class VerboseDel:
    def __init__(self, name):
        self.name = name
    def __del__(self):
        print(self.name)

b = VerboseDel("b")


$ cat c.py 
class VerboseDel:
    def __init__(self, name):
        self.name = name
    def __del__(self):
        print(self.name)

c = VerboseDel("c")


$ cat z.py 
import a
import b
import c
---

Output:
---
$ ./python z.py 
c
b
a
---

=> Modules are deleted from the most recently imported (import c) to the least recently imported module (import a).

----------
components: Interpreter Core
messages: 383265
nosy: vstinner
priority: normal
severity: normal
status: open
title: Make the Python finalization more deterministic
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42671>
_______________________________________

From report at bugs.python.org  Thu Dec 17 16:16:01 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 17 Dec 2020 21:16:01 +0000
Subject: [issue42660] _zoneinfo.c incorrectly checks bounds of `day` variable
 in calenderrule_new
In-Reply-To: <1608134368.02.0.941471966425.issue42660@roundup.psfhosted.org>
Message-ID: <1608239761.12.0.437353221789.issue42660@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

PR 23825 refactors parsing. There is now a single function for parsing numbers. It saves around 70 lines of code and makes easy to implement support of full range of transition hours.

It could be possible to represent transition time as 32-bit offset in seconds in CalendarRule and DayRule instead of 16-bit hour, and 8-bit minute and second. In any case we need that value instead of separate values of hour, minute and second.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42660>
_______________________________________

From report at bugs.python.org  Thu Dec 17 16:16:50 2020
From: report at bugs.python.org (Ivo Shipkaliev)
Date: Thu, 17 Dec 2020 21:16:50 +0000
Subject: [issue42672] tkinter/__init__.py raises a NameError if NoDefaultRoot()
Message-ID: <1608239810.27.0.625507020812.issue42672@roundup.psfhosted.org>


Change by Ivo Shipkaliev <ivo.shipkaliev at gmail.com>:


----------
components: Tkinter
files: default_root.diff
keywords: patch
nosy: shippo_
priority: normal
severity: normal
status: open
title: tkinter/__init__.py raises a NameError if NoDefaultRoot()
type: behavior
versions: Python 3.10
Added file: https://bugs.python.org/file49690/default_root.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42672>
_______________________________________

From report at bugs.python.org  Thu Dec 17 16:45:21 2020
From: report at bugs.python.org (Steve Stagg)
Date: Thu, 17 Dec 2020 21:45:21 +0000
Subject: [issue42651] Recursive traceback crashes  Python Interpreter
In-Reply-To: <1608105735.03.0.523665122471.issue42651@roundup.psfhosted.org>
Message-ID: <1608241521.36.0.544912303998.issue42651@roundup.psfhosted.org>


Steve Stagg <stestagg at gmail.com> added the comment:

Confirmed that bpo-42500 fixes this traceback, in commit 4e7a69bdb6 

Parent commit:

user at obsidian ~/t/f/cpython (master)> git checkout  93a0ef7
Note: switching to '93a0ef7'.
HEAD is now at 93a0ef7647 Correct return type in Modules/_ssl.c::sslmodule_legacy (GH-23609)

user at obsidian ~/t/f/cpython ((93a0ef76?))> ../test.sh
+ make distclean
+ CFLAGS=-O0
+ ./configure --prefix=/home/user/prefix --exec-prefix=/home/user/prefix --cache-file=../config.cache --with-pydebug --without-ensurepip
+ CFLAGS=-O0
+ make -j8 install
/home/user/cpython/Lib/runpy.py:111: PendingDeprecationWarning: lib2to3 package is deprecated and may not be able to parse Python 3.10+
  __import__(pkg_name)
/home/user/cpython/Lib/runpy.py:111: PendingDeprecationWarning: lib2to3 package is deprecated and may not be able to parse Python 3.10+
  __import__(pkg_name)
++ realpath /home/user/prefix/include/python3.10d/
+ INCLUDE_DIR=/home/user/prefix/include/python3.10d
+ set +e
+ PYTHONHOME=/home/user/prefix
+ /home/user/prefix/bin/python3 ../test.py
NoneType: None
...
NoneType: None
Fatal Python error: _Py_CheckRecursiveCall: Cannot recover from stack overflow.
Python runtime state: initialized

Current thread 0x00007f483d4bd740 (most recent call first):
  File "/home/user/prefix/lib/python3.10/traceback.py", line 165 in _some_str
  File "/home/user/prefix/lib/python3.10/traceback.py", line 524 in __init__
  File "/home/user/prefix/lib/python3.10/traceback.py", line 113 in print_exception
  File "/home/user/prefix/lib/python3.10/traceback.py", line 173 in print_exc
  File "/home/user/cpython/../test.py", line 4 in foo
  ...
../test.sh: line 33: 50081 Aborted                 (core dumped) PYTHONHOME=$PREFIX $EPREFIX/bin/python3 ../test.py
+ [[ 134 -eq 139 ]]
+ exit 0

After fix merged:

user at obsidian ~/t/f/cpython ((93a0ef76?)) [1]> git checkout 4e7a69bdb6
Previous HEAD position was 93a0ef7647 Correct return type in Modules/_ssl.c::sslmodule_legacy (GH-23609)
HEAD is now at 4e7a69bdb6 bpo-42500: Fix recursion in or after except (GH-23568)
user at obsidian ~/t/f/cpython ((4e7a69bd?))> ../test.sh
+ make distclean
+ CFLAGS=-O0
+ ./configure --prefix=/home/user/prefix --exec-prefix=/home/user/prefix --cache-file=../config.cache --with-pydebug --without-ensurepip
+ CFLAGS=-O0
+ make -j8 install
/home/user/cpython/Lib/runpy.py:111: PendingDeprecationWarning: lib2to3 package is deprecated and may not be able to parse Python 3.10+
  __import__(pkg_name)
/home/user/cpython/Lib/runpy.py:111: PendingDeprecationWarning: lib2to3 package is deprecated and may not be able to parse Python 3.10+
  __import__(pkg_name)
++ realpath /home/user/prefix/include/python3.10d/
+ INCLUDE_DIR=/home/user/prefix/include/python3.10d
+ set +e
+ PYTHONHOME=/home/user/prefix
+ /home/user/prefix/bin/python3 ../test.py
NoneType: None
...
NoneType: None
Traceback (most recent call last):
  File "/home/user/prefix/lib/python3.10/traceback.py", line 165, in _some_str
    return str(value)
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 "/home/user/cpython/../test.py", line 7, in <module>
    foo()
  File "/home/user/cpython/../test.py", line 5, in foo
    foo() 
  File "/home/user/cpython/../test.py", line 5, in foo
    foo() 
  File "/home/user/cpython/../test.py", line 5, in foo
    foo() 
  [Previous line repeated 989 more times]
  File "/home/user/cpython/../test.py", line 4, in foo
    traceback.print_exc()
  File "/home/user/prefix/lib/python3.10/traceback.py", line 173, in print_exc
    print_exception(*sys.exc_info(), limit=limit, file=file, chain=chain)
  File "/home/user/prefix/lib/python3.10/traceback.py", line 113, in print_exception
    for line in TracebackException(
  File "/home/user/prefix/lib/python3.10/traceback.py", line 632, in format
    yield from self.format_exception_only()
  File "/home/user/prefix/lib/python3.10/traceback.py", line 580, in format_exception_only
    yield _format_final_exc_line(stype, self._str)
  File "/home/user/prefix/lib/python3.10/traceback.py", line 156, in _format_final_exc_line
    valuestr = _some_str(value)
  File "/home/user/prefix/lib/python3.10/traceback.py", line 167, in _some_str
    return '<unprintable %s object>' % type(value).__name__
RecursionError: maximum recursion depth exceeded while calling a Python object
+ [[ 1 -eq 139 ]]
+ exit 0

----------
nosy: +stestagg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42651>
_______________________________________

From report at bugs.python.org  Thu Dec 17 16:46:17 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Dec 2020 21:46:17 +0000
Subject: [issue42671] Make the Python finalization more deterministic
In-Reply-To: <1608239600.62.0.0456277879965.issue42671@roundup.psfhosted.org>
Message-ID: <1608241577.13.0.189396660711.issue42671@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +22688
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23826

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42671>
_______________________________________

From report at bugs.python.org  Thu Dec 17 16:46:19 2020
From: report at bugs.python.org (Steve Stagg)
Date: Thu, 17 Dec 2020 21:46:19 +0000
Subject: [issue42651] Recursive traceback crashes  Python Interpreter
In-Reply-To: <1608105735.03.0.523665122471.issue42651@roundup.psfhosted.org>
Message-ID: <1608241579.56.0.60376240013.issue42651@roundup.psfhosted.org>


Steve Stagg <stestagg at gmail.com> added the comment:

Sorry, previous should have read "Fixes the abort"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42651>
_______________________________________

From report at bugs.python.org  Thu Dec 17 16:56:05 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Dec 2020 21:56:05 +0000
Subject: [issue42671] Make the Python finalization more deterministic
In-Reply-To: <1608239600.62.0.0456277879965.issue42671@roundup.psfhosted.org>
Message-ID: <1608242165.18.0.445121279386.issue42671@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I wrote this issue to attempt to fix a leak in PR 23811 which converts the _thread extension module to the multiphase initialization API (PEP 489).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42671>
_______________________________________

From report at bugs.python.org  Thu Dec 17 17:00:23 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 17 Dec 2020 22:00:23 +0000
Subject: [issue42671] Make the Python finalization more deterministic
In-Reply-To: <1608239600.62.0.0456277879965.issue42671@roundup.psfhosted.org>
Message-ID: <1608242423.36.0.390791063865.issue42671@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Modules are already cleared in the reverse order.

Clearing module attributes in the reverse order looks interesting. It increases chance that modules and other imported names which can be used in __del__ will be deleted after executing __del__ if the module has references to an instance of a class defined in the same module. And if the class was defined in other module, it will be deleted later because dependencies are cleared after depended modules.

On other hand, private attributes are currently removed first, so we perhaps need to change it to make the strategy working.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42671>
_______________________________________

From report at bugs.python.org  Thu Dec 17 17:05:48 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Dec 2020 22:05:48 +0000
Subject: [issue42671] Make the Python finalization more deterministic
In-Reply-To: <1608239600.62.0.0456277879965.issue42671@roundup.psfhosted.org>
Message-ID: <1608242748.14.0.0960707187925.issue42671@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Modules are already cleared in the reverse order.

In Python 3.9, _PyImport_Cleanup() of Python/import.c contains the comment:

        /* Since dict is ordered in CPython 3.6+, modules are saved in
           importing order.  First clear modules imported later. */

But using Python 3.9, the z.py example output is:
---
a
b
c
---

The most recently imported module is the last one to be deleted.

The first loop iterates on sys.modules, not on reversed(sys.modules).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42671>
_______________________________________

From report at bugs.python.org  Thu Dec 17 17:08:08 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 17 Dec 2020 22:08:08 +0000
Subject: [issue42671] Make the Python finalization more deterministic
In-Reply-To: <1608239600.62.0.0456277879965.issue42671@roundup.psfhosted.org>
Message-ID: <1608242888.5.0.507707712811.issue42671@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I took some notes on latest changes of the Python finalization order:
https://pythondev.readthedocs.io/finalization.html#reorder-python-finalization

Not directly related, I also took notes on the "weird GC behavior during Python finalization" (such as the issue that I have with my _thread change):
https://pythondev.readthedocs.io/finalization.html#weird-gc-behavior-during-python-finalization

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42671>
_______________________________________

From report at bugs.python.org  Thu Dec 17 17:14:21 2020
From: report at bugs.python.org (Steve Stagg)
Date: Thu, 17 Dec 2020 22:14:21 +0000
Subject: [issue42652] recursive in finally clause cause Python interpreter
 crash.
In-Reply-To: <1608108499.51.0.334108279167.issue42652@roundup.psfhosted.org>
Message-ID: <1608243261.06.0.749495012546.issue42652@roundup.psfhosted.org>


Steve Stagg <stestagg at gmail.com> added the comment:

This was also fixed by bpo-42500, in commit 4e7a69bdb6 
===
user at obsidian ~/t/f/cpython ((93a0ef76?))> git checkout 4e7a69bd^
HEAD is now at 93a0ef7647 Correct return type in Modules/_ssl.c::sslmodule_legacy (GH-23609)
+ make distclean
+ CFLAGS=-O0
+ ./configure --prefix=/home/user/prefix --exec-prefix=/home/user/prefix --cache-file=../config.cache --with-pydebug --without-ensurepip
+ CFLAGS=-O0
+ make -j8 install
/home/user/cpython/Lib/runpy.py:111: PendingDeprecationWarning: lib2to3 package is deprecated and may not be able to parse Python 3.10+
  __import__(pkg_name)
/home/user/cpython/Lib/runpy.py:111: PendingDeprecationWarning: lib2to3 package is deprecated and may not be able to parse Python 3.10+
  __import__(pkg_name)
++ realpath /home/user/prefix/include/python3.10d/
+ INCLUDE_DIR=/home/user/prefix/include/python3.10d
+ set +e
+ PYTHONHOME=/home/user/prefix
+ /home/user/prefix/bin/python3 ../test.py
Traceback (most recent call last):
  File "/home/user/cpython/../test.py", line 5, in foo
    1/0
ZeroDivisionError: division by zero
Traceback (most recent call last):
  File "/home/user/cpython/../test.py", line 5, in foo
    1/0
ZeroDivisionError: division by zero
...
  File "/home/user/cpython/../test.py", line 10 in foo
  File "/home/user/cpython/../test.py", line 10 in foo
  ...
../test.sh: line 33: 384713 Aborted                 (core dumped) PYTHONHOME=$PREFIX $EPREFIX/bin/python3 ../test.py
+ RESULT=134
+ [[ 134 -eq 139 ]]
+ [[ 134 -eq 134 ]]
+ exit 1
====
user at obsidian ~/t/f/cpython ((93a0ef76?)) [1]> git checkout 4e7a69bd
Previous HEAD position was 93a0ef7647 Correct return type in Modules/_ssl.c::sslmodule_legacy (GH-23609)
HEAD is now at 4e7a69bdb6 bpo-42500: Fix recursion in or after except (GH-23568)
====
user at obsidian ~/t/f/cpython ((4e7a69bd?))> ../test.sh
+ make distclean
+ CFLAGS=-O0
+ ./configure --prefix=/home/user/prefix --exec-prefix=/home/user/prefix --cache-file=../config.cache --with-pydebug --without-ensurepip
+ CFLAGS=-O0
+ make -j8 install
/home/user/cpython/Lib/runpy.py:111: PendingDeprecationWarning: lib2to3 package is deprecated and may not be able to parse Python 3.10+
  __import__(pkg_name)
/home/user/cpython/Lib/runpy.py:111: PendingDeprecationWarning: lib2to3 package is deprecated and may not be able to parse Python 3.10+
  __import__(pkg_name)
+ /home/user/prefix/bin/python3 ../test.py
Traceback (most recent call last):
  File "/home/user/cpython/../test.py", line 5, in foo
    1/0
...
  File "/home/user/cpython/../test.py", line 10, in foo
    foo()	
  File "/home/user/cpython/../test.py", line 10, in foo
    foo()	
  [Previous line repeated 996 more times]
RecursionError: maximum recursion depth exceeded
+ RESULT=1
+ [[ 1 -eq 139 ]]
+ [[ 1 -eq 134 ]]
+ exit 0

----------
nosy: +stestagg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42652>
_______________________________________

From report at bugs.python.org  Thu Dec 17 18:50:25 2020
From: report at bugs.python.org (Yurii Karabas)
Date: Thu, 17 Dec 2020 23:50:25 +0000
Subject: [issue42600] Cancelling tasks waiting for asyncio.Conditions crashes
 w/ RuntimeError: Lock is not acquired.
In-Reply-To: <1607430956.17.0.934441920245.issue42600@roundup.psfhosted.org>
Message-ID: <1608249025.95.0.12147854797.issue42600@roundup.psfhosted.org>


Change by Yurii Karabas <1998uriyyo at gmail.com>:


----------
keywords: +patch
nosy: +uriyyo
nosy_count: 4.0 -> 5.0
pull_requests: +22689
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23829

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42600>
_______________________________________

From report at bugs.python.org  Thu Dec 17 18:57:38 2020
From: report at bugs.python.org (Yurii Karabas)
Date: Thu, 17 Dec 2020 23:57:38 +0000
Subject: [issue42600] Cancelling tasks waiting for asyncio.Conditions crashes
 w/ RuntimeError: Lock is not acquired.
In-Reply-To: <1607430956.17.0.934441920245.issue42600@roundup.psfhosted.org>
Message-ID: <1608249458.39.0.1546785286.issue42600@roundup.psfhosted.org>


Yurii Karabas <1998uriyyo at gmail.com> added the comment:

Hey Yurii, I have fixed this issue.
The actual problem was that `wait_for` cancels passed future but doesn't wait until it finished.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42600>
_______________________________________

From report at bugs.python.org  Thu Dec 17 19:30:39 2020
From: report at bugs.python.org (Dino Viehland)
Date: Fri, 18 Dec 2020 00:30:39 +0000
Subject: [issue42199] bytecode_helper assertNotInBytecode fails too eagerly
In-Reply-To: <1604006526.43.0.914046612592.issue42199@roundup.psfhosted.org>
Message-ID: <1608251439.63.0.124615950466.issue42199@roundup.psfhosted.org>


Dino Viehland <dinoviehland at gmail.com> added the comment:


New changeset 6e799be0a18d0bb5bbbdc77cd3c30a229d31dfb4 by Max Bernstein in branch 'master':
bpo-42199: Fix bytecode_helper assertNotInBytecode (#23031)
https://github.com/python/cpython/commit/6e799be0a18d0bb5bbbdc77cd3c30a229d31dfb4


----------
nosy: +dino.viehland

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42199>
_______________________________________

From report at bugs.python.org  Thu Dec 17 19:39:08 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Dec 2020 00:39:08 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1608251948.45.0.450860108556.issue1635741@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 6104013838e181e3c698cb07316f449a0c31ea96 by Victor Stinner in branch 'master':
bpo-1635741: Port _thread to multiphase init (GH-23811)
https://github.com/python/cpython/commit/6104013838e181e3c698cb07316f449a0c31ea96


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Thu Dec 17 19:40:14 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Dec 2020 00:40:14 +0000
Subject: [issue15674] PEP 3121, 384 Refactoring applied to _thread module
In-Reply-To: <1345043183.1.0.612175209954.issue15674@psf.upfronthosting.co.za>
Message-ID: <1608252014.98.0.0639801144896.issue15674@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Fixed by:

New changeset 6104013838e181e3c698cb07316f449a0c31ea96 by Victor Stinner in branch 'master':
bpo-1635741: Port _thread to multiphase init (GH-23811)
https://github.com/python/cpython/commit/6104013838e181e3c698cb07316f449a0c31ea96

----------
nosy: +vstinner
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Py_Finalize() doesn't clear all Python objects at exit

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15674>
_______________________________________

From report at bugs.python.org  Thu Dec 17 19:42:47 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Dec 2020 00:42:47 +0000
Subject: [issue15712] PEP 3121, 384 Refactoring applied to unicodedata module
In-Reply-To: <1345153580.3.0.0817770117233.issue15712@psf.upfronthosting.co.za>
Message-ID: <1608252167.63.0.959025369135.issue15712@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Fixed by multiple changes, especially:

commit c8c4200b65b2159bbb13cee10d67dfb3676fef26
Author: Victor Stinner <vstinner at python.org>
Date:   Mon Oct 26 23:19:22 2020 +0100

    bpo-42157: Convert unicodedata.UCD to heap type (GH-22991)
    
    Convert the unicodedata extension module to the multiphase
    initialization API (PEP 489) and convert the unicodedata.UCD static
    type to a heap type.
    
    Co-Authored-By: Mohamed Koubaa <koubaa.m at gmail.com>

----------
nosy: +vstinner
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Cleanup the unicodedata module

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15712>
_______________________________________

From report at bugs.python.org  Thu Dec 17 19:43:53 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Dec 2020 00:43:53 +0000
Subject: [issue15650] PEP 3121, 384 refactoring applied to dbm module
In-Reply-To: <1344968074.48.0.47544287235.issue15650@psf.upfronthosting.co.za>
Message-ID: <1608252233.57.0.176260951254.issue15650@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Fixed by:

commit bf69a8f99f1b0e19a59509c6c4d7015a31d881a1
Author: Dong-hee Na <donghee.na92 at gmail.com>
Date:   Tue Jun 16 01:20:54 2020 +0900

    bpo-1635741: Port _dbm module to multiphase initialization (GH-20848)

----------
nosy: +vstinner
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Py_Finalize() doesn't clear all Python objects at exit

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15650>
_______________________________________

From report at bugs.python.org  Thu Dec 17 19:45:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Dec 2020 00:45:03 +0000
Subject: [issue15651] PEP 3121, 384 refactoring applied to elementtree module
In-Reply-To: <1344968721.44.0.689766020196.issue15651@psf.upfronthosting.co.za>
Message-ID: <1608252303.88.0.0588782737739.issue15651@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Fixed by:

commit a6109ef68d421712ba368ef502c4789e8de113e0
Author: Erlend Egeberg Aasland <erlend.aasland at innova.no>
Date:   Fri Nov 20 13:36:23 2020 +0100

    bpo-1635741: Convert _sre types to heap types and establish module state (PEP 384) (GH-23393)

----------
nosy: +vstinner
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Py_Finalize() doesn't clear all Python objects at exit

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15651>
_______________________________________

From report at bugs.python.org  Thu Dec 17 19:47:20 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Dec 2020 00:47:20 +0000
Subject: [issue15848] PEP 3121, 384 Refactoring applied to xxsubtype module
In-Reply-To: <1346596167.75.0.401355088857.issue15848@psf.upfronthosting.co.za>
Message-ID: <1608252440.54.0.705102449067.issue15848@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

See bpo-41111 "[C API] Convert a few stdlib extensions to the limited C API (PEP 384)" for the PEP 384 part.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15848>
_______________________________________

From report at bugs.python.org  Thu Dec 17 19:49:01 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Dec 2020 00:49:01 +0000
Subject: [issue15669] PEP 3121, 384 Refactoring applied to sre module
In-Reply-To: <1345040333.3.0.897611485757.issue15669@psf.upfronthosting.co.za>
Message-ID: <1608252541.82.0.00683196508852.issue15669@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Fixed by:

commit a6109ef68d421712ba368ef502c4789e8de113e0
Author: Erlend Egeberg Aasland <erlend.aasland at innova.no>
Date:   Fri Nov 20 13:36:23 2020 +0100

    bpo-1635741: Convert _sre types to heap types and establish module state (PEP 384) (GH-23393)

----------
nosy: +vstinner
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
superseder:  -> Py_Finalize() doesn't clear all Python objects at exit

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15669>
_______________________________________

From report at bugs.python.org  Thu Dec 17 19:50:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Dec 2020 00:50:16 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1608252616.67.0.704445429673.issue1635741@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I marked the following issues as duplicates of this one:

* bpo-15651: PEP 3121, 384 refactoring applied to elementtree module
* bpo-15650: PEP 3121, 384 refactoring applied to dbm module
* bpo-15712: PEP 3121, 384 Refactoring applied to unicodedata module
* bpo-15674: PEP 3121, 384 Refactoring applied to _thread module
* bpo-15669: PEP 3121, 384 Refactoring applied to sre module

I also closed bpo-15848 "PEP 3121, 384 Refactoring applied to xxsubtype module" (but not marked it as a duplicate of this one).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Thu Dec 17 19:52:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Dec 2020 00:52:15 +0000
Subject: [issue15725] PyType_FromSpecWithBases bugfix
In-Reply-To: <1345381967.41.0.932282182002.issue15725@psf.upfronthosting.co.za>
Message-ID: <1608252735.49.0.0761223834286.issue15725@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Tons of extension modules have been ported to the multiphase initialization API (PEP 489) in bpo-1635741 without this fix. I don't think that it's needed.

----------
nosy: +vstinner
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15725>
_______________________________________

From report at bugs.python.org  Thu Dec 17 19:58:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Dec 2020 00:58:46 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1608253126.73.0.849936590565.issue1635741@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Statistics on C extension modules using the new API (PyModuleDef_Init) / total:

* 3.9: 52 / 120 (43%)
* master: 94 / 119 (79%)

25 extension modules are still using the old API (PyModule_Create).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Thu Dec 17 20:06:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Dec 2020 01:06:06 +0000
Subject: [issue15651] PEP 3121, 384 refactoring applied to elementtree module
In-Reply-To: <1344968721.44.0.689766020196.issue15651@psf.upfronthosting.co.za>
Message-ID: <1608253566.21.0.178914766143.issue15651@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Fixed by: (...) bpo-1635741: Convert _sre types to heap types...

Oops, I commented the wrong issue. I reopen it.

----------
resolution: duplicate -> 
status: closed -> open
superseder: Py_Finalize() doesn't clear all Python objects at exit -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15651>
_______________________________________

From report at bugs.python.org  Thu Dec 17 20:06:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Dec 2020 01:06:40 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1608253600.27.0.940858578836.issue1635741@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> * bpo-15651: PEP 3121, 384 refactoring applied to elementtree module

Oops, this was a mistake. This one is not fixed yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Fri Dec 18 02:36:43 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 18 Dec 2020 07:36:43 +0000
Subject: [issue42671] Make the Python finalization more deterministic
In-Reply-To: <1608239600.62.0.0456277879965.issue42671@roundup.psfhosted.org>
Message-ID: <1608277003.15.0.927138590111.issue42671@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I experimented with different approaches last evening. Just changing the order of clearing the module dict does not help your first example, because the __main__ module is garbage collected, but its dict is not cleared. Adding _PyModule_ClearDict() in tp_dealloc and tp_clear helps with that example, but it causes several failures and crashes in tests. I have found issue7140 and issue18214 for not clearing module dicts.

So in conclusion, your approach may work. It clears dicts of all modules, but only at shutdown. It did not worked before, when the order of dicts was undetermined, but now we can utilize deterministic order of sys.modules and module dicts.

----------
nosy: +eric.snow, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42671>
_______________________________________

From report at bugs.python.org  Fri Dec 18 04:24:27 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Dec 2020 09:24:27 +0000
Subject: [issue39096] "Format Specification Mini-Language" doc mistake for
 Decimal
In-Reply-To: <1576750280.17.0.548410545235.issue39096@roundup.psfhosted.org>
Message-ID: <1608283467.91.0.76598414912.issue39096@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22690
pull_request: https://github.com/python/cpython/pull/23831

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39096>
_______________________________________

From report at bugs.python.org  Fri Dec 18 04:24:33 2020
From: report at bugs.python.org (Julien Palard)
Date: Fri, 18 Dec 2020 09:24:33 +0000
Subject: [issue39096] "Format Specification Mini-Language" doc mistake for
 Decimal
In-Reply-To: <1576750280.17.0.548410545235.issue39096@roundup.psfhosted.org>
Message-ID: <1608283473.38.0.550194918965.issue39096@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:


New changeset 886b2e5c7a2caf87070728dba8f18c3d65e51071 by Mark Dickinson in branch 'master':
bpo-39096: Format specification documentation fixes for numeric types (GH-23575)
https://github.com/python/cpython/commit/886b2e5c7a2caf87070728dba8f18c3d65e51071


----------
nosy: +mdk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39096>
_______________________________________

From report at bugs.python.org  Fri Dec 18 04:25:05 2020
From: report at bugs.python.org (Julien Palard)
Date: Fri, 18 Dec 2020 09:25:05 +0000
Subject: [issue39096] "Format Specification Mini-Language" doc mistake for
 Decimal
In-Reply-To: <1576750280.17.0.548410545235.issue39096@roundup.psfhosted.org>
Message-ID: <1608283505.8.0.624296413493.issue39096@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/issue39096>
_______________________________________

From report at bugs.python.org  Fri Dec 18 04:26:33 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Dec 2020 09:26:33 +0000
Subject: [issue39096] "Format Specification Mini-Language" doc mistake for
 Decimal
In-Reply-To: <1576750280.17.0.548410545235.issue39096@roundup.psfhosted.org>
Message-ID: <1608283593.39.0.228704975221.issue39096@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22691
pull_request: https://github.com/python/cpython/pull/23832

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39096>
_______________________________________

From report at bugs.python.org  Fri Dec 18 04:34:31 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Dec 2020 09:34:31 +0000
Subject: [issue39096] "Format Specification Mini-Language" doc mistake for
 Decimal
In-Reply-To: <1576750280.17.0.548410545235.issue39096@roundup.psfhosted.org>
Message-ID: <1608284071.76.0.926259432844.issue39096@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 12032cdec5ae1e56d4e4b8206fb2e9cccc5a9f58 by Miss Islington (bot) in branch '3.8':
bpo-39096: Format specification documentation fixes for numeric types (GH-23575)
https://github.com/python/cpython/commit/12032cdec5ae1e56d4e4b8206fb2e9cccc5a9f58


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39096>
_______________________________________

From report at bugs.python.org  Fri Dec 18 04:35:27 2020
From: report at bugs.python.org (Jurjen N.E. Bos)
Date: Fri, 18 Dec 2020 09:35:27 +0000
Subject: [issue42673] Optimize round_size for rehashing
Message-ID: <1608284127.41.0.53520654621.issue42673@roundup.psfhosted.org>


New submission from Jurjen N.E. Bos <jneb at users.sourceforge.net>:

There's a trivial optimization in the round_size in hashtable.c:
a loop is used to compute the lowest power of two >= s,
while this can be done in one step with bit_length.
I am making a pull request for this.

----------
components: Interpreter Core
messages: 383291
nosy: jneb
priority: normal
severity: normal
status: open
title: Optimize round_size for rehashing
type: performance
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42673>
_______________________________________

From report at bugs.python.org  Fri Dec 18 04:36:43 2020
From: report at bugs.python.org (Jurjen N.E. Bos)
Date: Fri, 18 Dec 2020 09:36:43 +0000
Subject: [issue42673] Optimize round_size for rehashing
In-Reply-To: <1608284127.41.0.53520654621.issue42673@roundup.psfhosted.org>
Message-ID: <1608284203.31.0.752927006314.issue42673@roundup.psfhosted.org>


Change by Jurjen N.E. Bos <jneb at users.sourceforge.net>:


----------
keywords: +patch
pull_requests: +22692
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23833

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42673>
_______________________________________

From report at bugs.python.org  Fri Dec 18 04:48:14 2020
From: report at bugs.python.org (Julien Palard)
Date: Fri, 18 Dec 2020 09:48:14 +0000
Subject: [issue42238] Deprecate suspicious.py?
In-Reply-To: <1604274563.95.0.828690163802.issue42238@roundup.psfhosted.org>
Message-ID: <1608284894.94.0.896692088874.issue42238@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:


New changeset b9735420aa8ecd2555fe3dc000863bc50487334b by Julien Palard in branch 'master':
bpo-42238: Check Misc/NEWS.d/next/ for reStructuredText issues. (GH-23802)
https://github.com/python/cpython/commit/b9735420aa8ecd2555fe3dc000863bc50487334b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42238>
_______________________________________

From report at bugs.python.org  Fri Dec 18 04:49:22 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Dec 2020 09:49:22 +0000
Subject: [issue39096] "Format Specification Mini-Language" doc mistake for
 Decimal
In-Reply-To: <1576750280.17.0.548410545235.issue39096@roundup.psfhosted.org>
Message-ID: <1608284962.95.0.613146223868.issue39096@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b812e236df506603e592086269e088b00d021460 by Miss Islington (bot) in branch '3.9':
bpo-39096: Format specification documentation fixes for numeric types (GH-23575)
https://github.com/python/cpython/commit/b812e236df506603e592086269e088b00d021460


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39096>
_______________________________________

From report at bugs.python.org  Fri Dec 18 05:14:35 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 18 Dec 2020 10:14:35 +0000
Subject: [issue42673] Optimize round_size for rehashing
In-Reply-To: <1608284127.41.0.53520654621.issue42673@roundup.psfhosted.org>
Message-ID: <1608286475.2.0.0748575310835.issue42673@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Do you have any benchmarks?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42673>
_______________________________________

From report at bugs.python.org  Fri Dec 18 05:47:41 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Dec 2020 10:47:41 +0000
Subject: [issue42671] Make the Python finalization more deterministic
In-Reply-To: <1608239600.62.0.0456277879965.issue42671@roundup.psfhosted.org>
Message-ID: <1608288461.4.0.428721081869.issue42671@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I wrote this issue to attempt to fix a leak in PR 23811 which converts the _thread extension module to the multiphase initialization API (PEP 489).

I fixed this bug by adding a traverse function to the _thread lock type. So I don't *need* this issue to unblock PR 23811 anymore.

But I'm still interested to make the finalization more determistic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42671>
_______________________________________

From report at bugs.python.org  Fri Dec 18 05:51:28 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Dec 2020 10:51:28 +0000
Subject: [issue42671] Make the Python finalization more deterministic
In-Reply-To: <1608239600.62.0.0456277879965.issue42671@roundup.psfhosted.org>
Message-ID: <1608288688.59.0.345978359093.issue42671@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Drawback: it is a backward incompatible change. Code which worked by luck previously no longer works. I'm talking about applications which rely on __del__() methods being calling in an exact order and expect Python being in a specific state.

Python does not provide any warranty in which order finalizers are called:
https://docs.python.org/dev/reference/datamodel.html#object.__del__

PyPy is a good concrete example of finalizers being called in a different order.

An application must not rely on the finalizer order, but manage resources explicitly by calling close() methods or using context managers. Python emits ResourceWarning on this purpose.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42671>
_______________________________________

From report at bugs.python.org  Fri Dec 18 06:17:49 2020
From: report at bugs.python.org (Chris Gahagan)
Date: Fri, 18 Dec 2020 11:17:49 +0000
Subject: [issue42674] __init_subclass__ only called for first subclass when
 class has multiple inheritance
Message-ID: <1608290269.17.0.332705663862.issue42674@roundup.psfhosted.org>


Change by Chris Gahagan <chris at ccgahagan.com>:


----------
files: SubClass.py
nosy: ccgahagan
priority: normal
severity: normal
status: open
title: __init_subclass__ only called for first subclass when class has multiple inheritance
type: behavior
versions: Python 3.8
Added file: https://bugs.python.org/file49691/SubClass.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42674>
_______________________________________

From report at bugs.python.org  Fri Dec 18 08:06:04 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 18 Dec 2020 13:06:04 +0000
Subject: [issue17140] Document multiprocessing.pool.ThreadPool
In-Reply-To: <1360116485.64.0.452267246232.issue17140@psf.upfronthosting.co.za>
Message-ID: <1608296764.55.0.500713522023.issue17140@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 84ebcf271a2cc8bfd1762acb279502b8b6ef236e by Matt Wozniski in branch 'master':
bpo-17140: Document multiprocessing's ThreadPool (GH-23812)
https://github.com/python/cpython/commit/84ebcf271a2cc8bfd1762acb279502b8b6ef236e


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17140>
_______________________________________

From report at bugs.python.org  Fri Dec 18 08:06:06 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Dec 2020 13:06:06 +0000
Subject: [issue17140] Document multiprocessing.pool.ThreadPool
In-Reply-To: <1360116485.64.0.452267246232.issue17140@psf.upfronthosting.co.za>
Message-ID: <1608296766.02.0.83728498832.issue17140@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 9.0 -> 10.0
pull_requests: +22693
pull_request: https://github.com/python/cpython/pull/23834

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17140>
_______________________________________

From report at bugs.python.org  Fri Dec 18 08:06:14 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Dec 2020 13:06:14 +0000
Subject: [issue17140] Document multiprocessing.pool.ThreadPool
In-Reply-To: <1360116485.64.0.452267246232.issue17140@psf.upfronthosting.co.za>
Message-ID: <1608296774.0.0.531979932252.issue17140@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22694
pull_request: https://github.com/python/cpython/pull/23835

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17140>
_______________________________________

From report at bugs.python.org  Fri Dec 18 08:06:25 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Dec 2020 13:06:25 +0000
Subject: [issue17140] Document multiprocessing.pool.ThreadPool
In-Reply-To: <1360116485.64.0.452267246232.issue17140@psf.upfronthosting.co.za>
Message-ID: <1608296785.11.0.468784867148.issue17140@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22695
pull_request: https://github.com/python/cpython/pull/23836

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17140>
_______________________________________

From report at bugs.python.org  Fri Dec 18 08:27:06 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Dec 2020 13:27:06 +0000
Subject: [issue17140] Document multiprocessing.pool.ThreadPool
In-Reply-To: <1360116485.64.0.452267246232.issue17140@psf.upfronthosting.co.za>
Message-ID: <1608298026.19.0.408654009994.issue17140@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 14619924c36435e356135988c244cbc28652c82b by Miss Islington (bot) in branch '3.9':
bpo-17140: Document multiprocessing's ThreadPool (GH-23812)
https://github.com/python/cpython/commit/14619924c36435e356135988c244cbc28652c82b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17140>
_______________________________________

From report at bugs.python.org  Fri Dec 18 09:05:22 2020
From: report at bugs.python.org (mattip)
Date: Fri, 18 Dec 2020 14:05:22 +0000
Subject: [issue42604] EXT_SUFFIX too short on FreeBSD and AIX
In-Reply-To: <1607464402.35.0.336960410788.issue42604@roundup.psfhosted.org>
Message-ID: <1608300322.62.0.054023313765.issue42604@roundup.psfhosted.org>


mattip <matti.picus at gmail.com> added the comment:

vstinner: ping. Are merge builds still failing or can I close this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42604>
_______________________________________

From report at bugs.python.org  Fri Dec 18 09:10:09 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 18 Dec 2020 14:10:09 +0000
Subject: [issue42665] Should PyLong_AsLongAndOverflow raise exception on
 overflow?
In-Reply-To: <1608198241.29.0.475035638972.issue42665@roundup.psfhosted.org>
Message-ID: <1608300609.29.0.349022895221.issue42665@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

@ganesh3597. PyLong_AsLongAndOverflow is behaving as intended, and changes to the behaviour would break existing code.

If you think there's a case for changing the behaviour, you'd need to provide your rationale for the change, details of what you propose as the new behaviour and what steps you'd take for backwards compatibility.

If you were confused by the documentation, please identify which part of the documentation was misleading, and we can look into whether it needs fixing.

----------
nosy: +mark.dickinson
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42665>
_______________________________________

From report at bugs.python.org  Fri Dec 18 09:25:45 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 18 Dec 2020 14:25:45 +0000
Subject: [issue40956] Use Argument Clinic in sqlite3
In-Reply-To: <1591956335.72.0.553737405887.issue40956@roundup.psfhosted.org>
Message-ID: <1608301545.66.0.55742463589.issue40956@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:


New changeset 1ba82bbc50a52f40ad05f3c4aaf2e159e0ce126d by Erlend Egeberg Aasland in branch 'master':
bpo-40956: Convert _sqlite3.Connection to Argument Clinic (GH-23341)
https://github.com/python/cpython/commit/1ba82bbc50a52f40ad05f3c4aaf2e159e0ce126d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40956>
_______________________________________

From report at bugs.python.org  Fri Dec 18 09:47:44 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 18 Dec 2020 14:47:44 +0000
Subject: [issue40956] Use Argument Clinic in sqlite3
In-Reply-To: <1591956335.72.0.553737405887.issue40956@roundup.psfhosted.org>
Message-ID: <1608302864.28.0.0359722302898.issue40956@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
pull_requests: +22696
pull_request: https://github.com/python/cpython/pull/23837

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40956>
_______________________________________

From report at bugs.python.org  Fri Dec 18 10:33:12 2020
From: report at bugs.python.org (Jakub Stasiak)
Date: Fri, 18 Dec 2020 15:33:12 +0000
Subject: [issue42673] Optimize round_size for rehashing
In-Reply-To: <1608284127.41.0.53520654621.issue42673@roundup.psfhosted.org>
Message-ID: <1608305592.69.0.974759437584.issue42673@roundup.psfhosted.org>


Jakub Stasiak <jakub+python.org at stasiak.at> added the comment:

I'd be especially curious about branch (mis)prediction stats before and after applying this patch ??including such information seems necessary in a patch that's about optimization.

----------
nosy: +jstasiak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42673>
_______________________________________

From report at bugs.python.org  Fri Dec 18 10:41:40 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Fri, 18 Dec 2020 15:41:40 +0000
Subject: [issue40956] Use Argument Clinic in sqlite3
In-Reply-To: <1591956335.72.0.553737405887.issue40956@roundup.psfhosted.org>
Message-ID: <1608306100.42.0.406062151931.issue40956@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:


New changeset 2179349d8cf45b1202775547df384b1fde31630a by Dong-hee Na in branch 'master':
bpo-40956: Fix sqlite3 AC code (GH-23837)
https://github.com/python/cpython/commit/2179349d8cf45b1202775547df384b1fde31630a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40956>
_______________________________________

From report at bugs.python.org  Fri Dec 18 10:48:48 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Fri, 18 Dec 2020 15:48:48 +0000
Subject: [issue40956] Use Argument Clinic in sqlite3
In-Reply-To: <1591956335.72.0.553737405887.issue40956@roundup.psfhosted.org>
Message-ID: <1608306528.88.0.715677596659.issue40956@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
pull_requests: +22697
pull_request: https://github.com/python/cpython/pull/23838

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40956>
_______________________________________

From report at bugs.python.org  Fri Dec 18 11:38:34 2020
From: report at bugs.python.org (Ken Jin)
Date: Fri, 18 Dec 2020 16:38:34 +0000
Subject: [issue42675] Document changes made in bpo-42195
Message-ID: <1608309514.56.0.184586625269.issue42675@roundup.psfhosted.org>


New submission from Ken Jin <kenjin4096 at gmail.com>:

A whatsnew is probably needed as this change causes backwards incompatibility in some code working with Python 3.9.0 and 3.9.1. I think the patch for Python 3.9.2 should mention that a DeprecationWarning is emitted for some invalid use cases, which will eventually become a TypeError.

----------
assignee: docs at python
components: Documentation
messages: 383304
nosy: docs at python, gvanrossum, kj
priority: normal
severity: normal
status: open
title: Document changes made in bpo-42195
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42675>
_______________________________________

From report at bugs.python.org  Fri Dec 18 11:41:49 2020
From: report at bugs.python.org (Ken Jin)
Date: Fri, 18 Dec 2020 16:41:49 +0000
Subject: [issue42675] Document changes made in bpo-42195
In-Reply-To: <1608309514.56.0.184586625269.issue42675@roundup.psfhosted.org>
Message-ID: <1608309709.82.0.365206285297.issue42675@roundup.psfhosted.org>


Change by Ken Jin <kenjin4096 at gmail.com>:


----------
keywords: +patch
pull_requests: +22698
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23839

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42675>
_______________________________________

From report at bugs.python.org  Fri Dec 18 11:41:49 2020
From: report at bugs.python.org (Ken Jin)
Date: Fri, 18 Dec 2020 16:41:49 +0000
Subject: [issue42195] Inconsistent __args__ between typing.Callable and
 collections.abc.Callable
In-Reply-To: <1603974319.88.0.166786801787.issue42195@roundup.psfhosted.org>
Message-ID: <1608309709.9.0.943080986855.issue42195@roundup.psfhosted.org>


Change by Ken Jin <kenjin4096 at gmail.com>:


----------
pull_requests: +22699
pull_request: https://github.com/python/cpython/pull/23839

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42195>
_______________________________________

From report at bugs.python.org  Fri Dec 18 11:45:12 2020
From: report at bugs.python.org (Ken Jin)
Date: Fri, 18 Dec 2020 16:45:12 +0000
Subject: [issue42195] Inconsistent __args__ between typing.Callable and
 collections.abc.Callable
In-Reply-To: <1603974319.88.0.166786801787.issue42195@roundup.psfhosted.org>
Message-ID: <1608309912.54.0.759670779881.issue42195@roundup.psfhosted.org>


Change by Ken Jin <kenjin4096 at gmail.com>:


----------
pull_requests:  -22699

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42195>
_______________________________________

From report at bugs.python.org  Fri Dec 18 12:01:49 2020
From: report at bugs.python.org (Karl Nelson)
Date: Fri, 18 Dec 2020 17:01:49 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1608310909.8.0.192504310249.issue42529@roundup.psfhosted.org>


Karl Nelson <nelson85 at llnl.gov> added the comment:

I attempted another deep dive on this one.

1) Removed manual library add
   platform_specific['libraries'] = ['Advapi32']
No change.

2) Compared symbol wise imports
Two imports changed
PyIndex_Check
PyObject_CheckBuffer
plus one additional "fflush" dependency in api-ms-win-crt-stdio-l1-1-0.dll 

3) Compared symbol wise exports 
No changes detected.

4) Disassembled both binaries
Other than a addressing that is about a 0x1000 change in the relocation tables.  Guessing that this is just a change in the number of pages.  There were functional changes likely related to Python macros differences.

5) Removed all references to printf and flush to remove api-ms-win-crt-stdio-l1-1-0.dll dependency.
No change.

6) Scanned the changelog and Code changes for the past year in  Python/dynload_win.c.  
Nothing appears likely to trigger this change.

7) Deleted the _jpype module entirely to verify that the error message is related to the copy that I am working on and not some other copy on system.
Error message changes to "ModuleNotFoundError: No module named '_jpype'"

8) Scanned the source code for static variables.
None detected thus far.  But it is a many hours long process.  Structurally these should not exist based on the module design.

Statics found thus far.
2 jobject and jmethodID pointer types
One C++ class called PLATFORM_ADAPTER which is the required routine determining whether to load jvm.dll or jvm.so using LoadLibrary or dlopen or shload.
The global pointer to the context C++ class;
a bunch of statics related to logging when enabled.
Python C style structure definitions.

Everything was a primitive or pointer with the exception of one class.  All pointers I found were initialized to constant values.

I rewrote the PLATFORM_ADAPTER to use a pointer rather than be initialized at load time.  No joy.

(after scanning through 17k lines of code take break and ponder life)

It is certainly possible I missed something here but it looks pretty unlikely this is the source of the error.


9) Verified that the behavior does not occur on Python 3.8.5 with the current source code.  
Pass.  This only happens on Python 3.9.0

10) Scanned the linker line for differences.
One major difference.  In Python 3.8 the linker line contains quotes around all the arguments while in Python 3.9 the linker line is missing the quotes on all /LIBPATH statements.  However this must be a logging difference as the statement without the quotes would not work.

11) Manually ran linker command.  
Nothing changed, same behavior.  So link command is a red herring.

12) Profit???

Okay I have once again exhausted everything that I can think of on the JPype side.   So that leaves something in the build process that does not appear in the logs, a symbol conflict that so how only triggers on one path, or Python3.9.0 has a corrupt build in the wild.   

Steve is there anything else that I can try here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Fri Dec 18 12:23:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 18 Dec 2020 17:23:34 +0000
Subject: [issue42604] EXT_SUFFIX too short on FreeBSD and AIX
In-Reply-To: <1607464402.35.0.336960410788.issue42604@roundup.psfhosted.org>
Message-ID: <1608312214.0.0.13719806341.issue42604@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

test_sysconfig still fails:

* POWER6 AIX 3.x: https://buildbot.python.org/all/#/builders/302/builds/563
* PPC64 AIX 3.x: https://buildbot.python.org/all/#/builders/438/builds/593
* AMD64 FreeBSD Shared 3.x: https://buildbot.python.org/all/#/builders/483/builds/572

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42604>
_______________________________________

From report at bugs.python.org  Fri Dec 18 12:26:20 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 18 Dec 2020 17:26:20 +0000
Subject: [issue41891] asyncio.wait_for does not wait for task/future to be
 completed in all cases
In-Reply-To: <1601463712.11.0.444677837126.issue41891@roundup.psfhosted.org>
Message-ID: <1608312380.3.0.413585227038.issue41891@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 17ef4319a34f5a2f95e7823dfb5f5b8cff11882d by Richard Kojedzinszky in branch 'master':
bpo-41891: ensure asyncio.wait_for waits for task completion (#22461)
https://github.com/python/cpython/commit/17ef4319a34f5a2f95e7823dfb5f5b8cff11882d


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41891>
_______________________________________

From report at bugs.python.org  Fri Dec 18 12:26:26 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Dec 2020 17:26:26 +0000
Subject: [issue41891] asyncio.wait_for does not wait for task/future to be
 completed in all cases
In-Reply-To: <1601463712.11.0.444677837126.issue41891@roundup.psfhosted.org>
Message-ID: <1608312386.01.0.613433708056.issue41891@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +22700
pull_request: https://github.com/python/cpython/pull/23840

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41891>
_______________________________________

From report at bugs.python.org  Fri Dec 18 12:26:36 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 18 Dec 2020 17:26:36 +0000
Subject: [issue41891] asyncio.wait_for does not wait for task/future to be
 completed in all cases
In-Reply-To: <1601463712.11.0.444677837126.issue41891@roundup.psfhosted.org>
Message-ID: <1608312396.37.0.89482598022.issue41891@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

Thanks for the PR, Richard!

----------
nosy:  -miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41891>
_______________________________________

From report at bugs.python.org  Fri Dec 18 12:26:37 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Dec 2020 17:26:37 +0000
Subject: [issue41891] asyncio.wait_for does not wait for task/future to be
 completed in all cases
In-Reply-To: <1601463712.11.0.444677837126.issue41891@roundup.psfhosted.org>
Message-ID: <1608312397.6.0.979156444972.issue41891@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +22701
pull_request: https://github.com/python/cpython/pull/23841

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41891>
_______________________________________

From report at bugs.python.org  Fri Dec 18 12:26:50 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 18 Dec 2020 17:26:50 +0000
Subject: [issue41891] asyncio.wait_for does not wait for task/future to be
 completed in all cases
In-Reply-To: <1601463712.11.0.444677837126.issue41891@roundup.psfhosted.org>
Message-ID: <1608312410.91.0.535095188852.issue41891@roundup.psfhosted.org>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
nosy:  -miss-islington
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41891>
_______________________________________

From report at bugs.python.org  Fri Dec 18 12:28:20 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 18 Dec 2020 17:28:20 +0000
Subject: [issue42600] Cancelling tasks waiting for asyncio.Conditions crashes
 w/ RuntimeError: Lock is not acquired.
In-Reply-To: <1607430956.17.0.934441920245.issue42600@roundup.psfhosted.org>
Message-ID: <1608312500.53.0.350584735688.issue42600@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:

This has been actually first fixed in #41891 but somehow wasn't yet merged. Yurii, thanks so much for working on this and making a PR, there was just another PR to fix the same issue that was there first, so I had to merge that one.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
superseder:  -> asyncio.wait_for does not wait for task/future to be completed in all cases

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42600>
_______________________________________

From report at bugs.python.org  Fri Dec 18 12:39:28 2020
From: report at bugs.python.org (Ken Jin)
Date: Fri, 18 Dec 2020 17:39:28 +0000
Subject: [issue42195] Inconsistent __args__ between typing.Callable and
 collections.abc.Callable
In-Reply-To: <1603974319.88.0.166786801787.issue42195@roundup.psfhosted.org>
Message-ID: <1608313168.97.0.769826839878.issue42195@roundup.psfhosted.org>


Change by Ken Jin <kenjin4096 at gmail.com>:


----------
pull_requests: +22702
pull_request: https://github.com/python/cpython/pull/23839

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42195>
_______________________________________

From report at bugs.python.org  Fri Dec 18 12:39:35 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 18 Dec 2020 17:39:35 +0000
Subject: [issue42675] Document changes made in bpo-42195
In-Reply-To: <1608309514.56.0.184586625269.issue42675@roundup.psfhosted.org>
Message-ID: <1608313175.51.0.244597925468.issue42675@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset d75f6f78e6ca230d0dacc116dca9d8bf91509b68 by kj in branch 'master':
bpo-42675: Document collections.abc.Callable changes (GH-23839)
https://github.com/python/cpython/commit/d75f6f78e6ca230d0dacc116dca9d8bf91509b68


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42675>
_______________________________________

From report at bugs.python.org  Fri Dec 18 12:45:33 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Dec 2020 17:45:33 +0000
Subject: [issue41891] asyncio.wait_for does not wait for task/future to be
 completed in all cases
In-Reply-To: <1601463712.11.0.444677837126.issue41891@roundup.psfhosted.org>
Message-ID: <1608313533.0.0.713625223187.issue41891@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a3dec9d8ec5ae142946ff6b94947a183d7c48f35 by Miss Islington (bot) in branch '3.8':
bpo-41891: ensure asyncio.wait_for waits for task completion (GH-22461)
https://github.com/python/cpython/commit/a3dec9d8ec5ae142946ff6b94947a183d7c48f35


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41891>
_______________________________________

From report at bugs.python.org  Fri Dec 18 12:47:19 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 18 Dec 2020 17:47:19 +0000
Subject: [issue42667] shelve module is not thread-safe during accessing
 different databases from different threads
In-Reply-To: <1608203117.3.0.00404135488038.issue42667@roundup.psfhosted.org>
Message-ID: <1608313639.64.0.324979915951.issue42667@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I suggest removing the global state from dbm and just recomputing the underlying database for every call to open().

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42667>
_______________________________________

From report at bugs.python.org  Fri Dec 18 12:57:06 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 18 Dec 2020 17:57:06 +0000
Subject: [issue23522] Misleading note in Statistics module documentation
In-Reply-To: <1424889646.1.0.160219400081.issue23522@psf.upfronthosting.co.za>
Message-ID: <1608314226.84.0.320086435544.issue23522@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
nosy: +rhettinger
nosy_count: 4.0 -> 5.0
pull_requests: +22703
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23842

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23522>
_______________________________________

From report at bugs.python.org  Fri Dec 18 13:09:32 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 18 Dec 2020 18:09:32 +0000
Subject: [issue42676] zoneinfo uses locale depending functions for parsing
Message-ID: <1608314972.2.0.724558479843.issue42676@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

zoneinfo uses locale depending functions isalpha(), isdigit(), isalnum() to parse data. It may be correct when parse the TZ environment variable (although they do not work with multibytes locale encodings like UTF-8), I think that parsing the content of data files should not rely on current locale. Later the parsed data is decoded implying UTF-8 (for abbr) or ASCII (for numbers).

----------
components: Library (Lib)
messages: 383313
nosy: p-ganssle, serhiy.storchaka
priority: normal
severity: normal
status: open
title: zoneinfo uses locale depending functions for parsing
type: behavior
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42676>
_______________________________________

From report at bugs.python.org  Fri Dec 18 13:10:01 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 18 Dec 2020 18:10:01 +0000
Subject: [issue42559] random.getrandbits: Should it be explicit that it
 returns unsigned/non-negative integer?
In-Reply-To: <1607018036.1.0.534167707073.issue42559@roundup.psfhosted.org>
Message-ID: <1608315001.46.0.244025454959.issue42559@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
pull_requests: +22704
pull_request: https://github.com/python/cpython/pull/23843

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42559>
_______________________________________

From report at bugs.python.org  Fri Dec 18 13:11:31 2020
From: report at bugs.python.org (=?utf-8?q?Eric_Engestr=C3=B6m?=)
Date: Fri, 18 Dec 2020 18:11:31 +0000
Subject: [issue34690] Store startup modules as C structures for 20%+ startup
 speed improvement
In-Reply-To: <1536960230.65.0.956365154283.issue34690@psf.upfronthosting.co.za>
Message-ID: <1608315091.63.0.567998060163.issue34690@roundup.psfhosted.org>


Change by Eric Engestr?m <python at engestrom.ch>:


----------
nosy: +1ace

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34690>
_______________________________________

From report at bugs.python.org  Fri Dec 18 13:20:24 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 18 Dec 2020 18:20:24 +0000
Subject: [issue42667] shelve module is not thread-safe during accessing
 different databases from different threads
In-Reply-To: <1608203117.3.0.00404135488038.issue42667@roundup.psfhosted.org>
Message-ID: <1608315624.66.0.0450777000071.issue42667@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Loading modules every time without using a cache (sys.modules) can add significant overhead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42667>
_______________________________________

From report at bugs.python.org  Fri Dec 18 13:38:05 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Dec 2020 18:38:05 +0000
Subject: [issue17140] Document multiprocessing.pool.ThreadPool
In-Reply-To: <1360116485.64.0.452267246232.issue17140@psf.upfronthosting.co.za>
Message-ID: <1608316685.34.0.422861283373.issue17140@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d21d29ab5b8741da056ac09c49c759b6ccbf264a by Miss Islington (bot) in branch '3.8':
[3.8] bpo-17140: Document multiprocessing's ThreadPool (GH-23812) (GH-23835)
https://github.com/python/cpython/commit/d21d29ab5b8741da056ac09c49c759b6ccbf264a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17140>
_______________________________________

From report at bugs.python.org  Fri Dec 18 13:38:57 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 18 Dec 2020 18:38:57 +0000
Subject: [issue17140] Document multiprocessing.pool.ThreadPool
In-Reply-To: <1360116485.64.0.452267246232.issue17140@psf.upfronthosting.co.za>
Message-ID: <1608316737.75.0.306723115735.issue17140@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:


New changeset 00278d4e616315e64557bff014574c079e6e96ff by Miss Islington (bot) in branch '3.7':
bpo-17140: Document multiprocessing's ThreadPool (GH-23812) (GH-23836)
https://github.com/python/cpython/commit/00278d4e616315e64557bff014574c079e6e96ff


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17140>
_______________________________________

From report at bugs.python.org  Fri Dec 18 13:42:54 2020
From: report at bugs.python.org (Ned Deily)
Date: Fri, 18 Dec 2020 18:42:54 +0000
Subject: [issue17140] Document multiprocessing.pool.ThreadPool
In-Reply-To: <1360116485.64.0.452267246232.issue17140@psf.upfronthosting.co.za>
Message-ID: <1608316974.04.0.459622372176.issue17140@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Thanks, Matt, for the documentation PR.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17140>
_______________________________________

From report at bugs.python.org  Fri Dec 18 13:47:51 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 18 Dec 2020 18:47:51 +0000
Subject: [issue34805] Explicitly specify `MyClass.__subclasses__()` returns
 classes in definition order
In-Reply-To: <1537942683.07.0.545547206417.issue34805@psf.upfronthosting.co.za>
Message-ID: <1608317271.64.0.404460868717.issue34805@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
pull_requests: +22705
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/23844

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34805>
_______________________________________

From report at bugs.python.org  Fri Dec 18 13:53:15 2020
From: report at bugs.python.org (Julien Palard)
Date: Fri, 18 Dec 2020 18:53:15 +0000
Subject: [issue12800] 'tarfile.StreamError: seeking backwards is not allowed'
 when extract symlink
In-Reply-To: <1313881060.54.0.449889075101.issue12800@psf.upfronthosting.co.za>
Message-ID: <1608317595.4.0.342233053022.issue12800@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/issue12800>
_______________________________________

From report at bugs.python.org  Fri Dec 18 13:59:02 2020
From: report at bugs.python.org (Julien Palard)
Date: Fri, 18 Dec 2020 18:59:02 +0000
Subject: [issue42042] sphinx3 renders diffrently docs.python.org for 3.10
In-Reply-To: <1602763041.43.0.432643801896.issue42042@roundup.psfhosted.org>
Message-ID: <1608317942.18.0.519787493287.issue42042@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:

Is it fixed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42042>
_______________________________________

From report at bugs.python.org  Fri Dec 18 14:00:59 2020
From: report at bugs.python.org (Julien Palard)
Date: Fri, 18 Dec 2020 19:00:59 +0000
Subject: [issue34398] Docs search should prominently show definitions and
 glossary items
In-Reply-To: <1534233148.48.0.56676864532.issue34398@psf.upfronthosting.co.za>
Message-ID: <1608318059.06.0.536183867368.issue34398@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:


New changeset 8c5d0347efd16f16dfb9596715e449cd928b89c8 by Ammar Askar in branch 'master':
bpo-34398: Allow glossary results to show up on search page (GH-8773)
https://github.com/python/cpython/commit/8c5d0347efd16f16dfb9596715e449cd928b89c8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34398>
_______________________________________

From report at bugs.python.org  Fri Dec 18 14:10:28 2020
From: report at bugs.python.org (Julien Palard)
Date: Fri, 18 Dec 2020 19:10:28 +0000
Subject: [issue36769] doc Document that fnmatch.filter supports any kind of
 iterable not just lists
In-Reply-To: <1556719965.28.0.191162970906.issue36769@roundup.psfhosted.org>
Message-ID: <1608318628.34.0.127420715782.issue36769@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:


New changeset e8d22642105d57007ab1242848a8cbadc7f179df by Andre Delfino in branch 'master':
bpo-36769: Document that fnmatch.filter supports any kind of iterable (#13039)
https://github.com/python/cpython/commit/e8d22642105d57007ab1242848a8cbadc7f179df


----------
nosy: +mdk

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36769>
_______________________________________

From report at bugs.python.org  Fri Dec 18 14:11:24 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Dec 2020 19:11:24 +0000
Subject: [issue36769] doc Document that fnmatch.filter supports any kind of
 iterable not just lists
In-Reply-To: <1556719965.28.0.191162970906.issue36769@roundup.psfhosted.org>
Message-ID: <1608318684.76.0.248306221911.issue36769@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +22706
pull_request: https://github.com/python/cpython/pull/23845

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36769>
_______________________________________

From report at bugs.python.org  Fri Dec 18 14:11:34 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Dec 2020 19:11:34 +0000
Subject: [issue36769] doc Document that fnmatch.filter supports any kind of
 iterable not just lists
In-Reply-To: <1556719965.28.0.191162970906.issue36769@roundup.psfhosted.org>
Message-ID: <1608318694.56.0.0677061602773.issue36769@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22707
pull_request: https://github.com/python/cpython/pull/23846

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36769>
_______________________________________

From report at bugs.python.org  Fri Dec 18 14:15:45 2020
From: report at bugs.python.org (Thomas Nabelek)
Date: Fri, 18 Dec 2020 19:15:45 +0000
Subject: [issue42677] Support comments in argparse fromfile_prefix_chars files
Message-ID: <1608318945.24.0.0639471792025.issue42677@roundup.psfhosted.org>


New submission from Thomas Nabelek <nabelekt at gmail.com>:

For input argument files, specified with the fromfile_prefix_chars argument to argparse.ArgumentParser, argparse should ignore lines beginning with '#' so that comments can be used in those files.

----------
components: Library (Lib)
messages: 383321
nosy: nabelekt
priority: normal
severity: normal
status: open
title: Support comments in argparse fromfile_prefix_chars files
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42677>
_______________________________________

From report at bugs.python.org  Fri Dec 18 14:19:23 2020
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 18 Dec 2020 19:19:23 +0000
Subject: [issue41891] asyncio.wait_for does not wait for task/future to be
 completed in all cases
In-Reply-To: <1601463712.11.0.444677837126.issue41891@roundup.psfhosted.org>
Message-ID: <1608319163.33.0.319732611363.issue41891@roundup.psfhosted.org>


Yury Selivanov <yselivanov at gmail.com> added the comment:


New changeset 82dbfd5a04863d8b6363527e6a34a90c9aa5691b by Miss Islington (bot) in branch '3.9':
bpo-41891: ensure asyncio.wait_for waits for task completion (GH-22461) (#23840)
https://github.com/python/cpython/commit/82dbfd5a04863d8b6363527e6a34a90c9aa5691b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41891>
_______________________________________

From report at bugs.python.org  Fri Dec 18 14:34:36 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 18 Dec 2020 19:34:36 +0000
Subject: [issue36769] doc Document that fnmatch.filter supports any kind of
 iterable not just lists
In-Reply-To: <1556719965.28.0.191162970906.issue36769@roundup.psfhosted.org>
Message-ID: <1608320076.64.0.110080200669.issue36769@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4b412e830d0a7d3f30af60b9eb285558511d90af by Miss Islington (bot) in branch '3.9':
bpo-36769: Document that fnmatch.filter supports any kind of iterable (GH-13039)
https://github.com/python/cpython/commit/4b412e830d0a7d3f30af60b9eb285558511d90af


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36769>
_______________________________________

From report at bugs.python.org  Fri Dec 18 15:07:22 2020
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 18 Dec 2020 20:07:22 +0000
Subject: [issue42678] [Enum] _sunder_ methods only looked up in the last Enum
 class in the mro
Message-ID: <1608322042.6.0.824129277027.issue42678@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
assignee: ethan.furman
components: Library (Lib)
nosy: ethan.furman
priority: normal
severity: normal
stage: needs patch
status: open
title: [Enum] _sunder_ methods only looked up in the last Enum class in the mro
type: behavior
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42678>
_______________________________________

From report at bugs.python.org  Fri Dec 18 15:13:02 2020
From: report at bugs.python.org (Yurii Karabas)
Date: Fri, 18 Dec 2020 20:13:02 +0000
Subject: [issue41891] asyncio.wait_for does not wait for task/future to be
 completed in all cases
In-Reply-To: <1601463712.11.0.444677837126.issue41891@roundup.psfhosted.org>
Message-ID: <1608322382.71.0.24083591815.issue41891@roundup.psfhosted.org>


Yurii Karabas <1998uriyyo at gmail.com> added the comment:

Yurii no worries, I am happy that this issue is resolved)

----------
nosy: +uriyyo

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41891>
_______________________________________

From report at bugs.python.org  Fri Dec 18 15:52:49 2020
From: report at bugs.python.org (Karl Nelson)
Date: Fri, 18 Dec 2020 20:52:49 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1608324769.66.0.729060426031.issue42529@roundup.psfhosted.org>


Karl Nelson <nelson85 at llnl.gov> added the comment:

Just for reference here are all the dependencies that _jpype has

```
MSVCP140.dll                                                                                                                                                                python39.dll                                                                                                                                                                KERNEL32.dll                                                                                                                                                                VCRUNTIME140_1.dll                                                                                                                                                          VCRUNTIME140.dll                                                                                                                                                            api-ms-win-crt-runtime-l1-1-0.dll                                                                                                                                           api-ms-win-crt-string-l1-1-0.dll                                                                                                                                            api-ms-win-crt-heap-l1-1-0.dll
```

So it isn't like there are a whole lot of things that I am doing that are likely to trigger a dependency problem.

As far as I can see the only items that are not already on python39.dll dependency list are VCRUNTIME140_1.dll and MSVCP140.dll.  But if that were the case then surely other projects would also be hitting this bug.  So this error message makes no sense at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Fri Dec 18 16:12:18 2020
From: report at bugs.python.org (Joshua Bronson)
Date: Fri, 18 Dec 2020 21:12:18 +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: <1608325938.65.0.94180491091.issue31861@roundup.psfhosted.org>


Change by Joshua Bronson <jabronson at gmail.com>:


----------
pull_requests: +22708
pull_request: https://github.com/python/cpython/pull/23847

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31861>
_______________________________________

From report at bugs.python.org  Fri Dec 18 16:18:53 2020
From: report at bugs.python.org (Joshua Bronson)
Date: Fri, 18 Dec 2020 21:18:53 +0000
Subject: [issue31861] add aiter() and anext() functions
In-Reply-To: <1508851575.6.0.213398074469.issue31861@psf.upfronthosting.co.za>
Message-ID: <1608326333.43.0.121983469094.issue31861@roundup.psfhosted.org>


Joshua Bronson <jabronson at gmail.com> added the comment:

Please see https://github.com/python/cpython/pull/23847 for the C implementation of aiter and anext added to builtins, as requested.

----------
title: add aiter() and anext() functions to operator module -> add aiter() and anext() functions

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31861>
_______________________________________

From report at bugs.python.org  Fri Dec 18 16:23:53 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Fri, 18 Dec 2020 21:23:53 +0000
Subject: [issue39560] PyUnicode_FromKindAndData kind transformation is not
 documented
In-Reply-To: <1580907133.21.0.114993814029.issue39560@roundup.psfhosted.org>
Message-ID: <1608326633.03.0.769742681232.issue39560@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 3.0 -> 4.0
pull_requests: +22710
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23848

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39560>
_______________________________________

From report at bugs.python.org  Fri Dec 18 16:36:55 2020
From: report at bugs.python.org (Olvin)
Date: Fri, 18 Dec 2020 21:36:55 +0000
Subject: [issue42679] Minor improvement in datetime.timestamp() docs
Message-ID: <1608327415.79.0.704757539161.issue42679@roundup.psfhosted.org>


New submission from Olvin <olvinroght at protonmail.com>:

Answering question on StackOverflow I've found next example in docs of datetime.timestamp() ( https://docs.python.org/3/library/datetime.html#datetime.datetime.timestamp ) which returns UTC timestamp:

timestamp = (dt - datetime(1970, 1, 1)) / timedelta(seconds=1)

While it works I think there's more explicit way using timedelta.total_seconds() :

timestamp = (dt - datetime(1970, 1, 1)).total_seconds()

In same article few lines above there's example using total_seconds() so I think it will be good to use same method in both examples.

----------
assignee: docs at python
components: Documentation
messages: 383328
nosy: docs at python, olvinroght
priority: normal
severity: normal
status: open
title: Minor improvement in datetime.timestamp() docs
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42679>
_______________________________________

From report at bugs.python.org  Fri Dec 18 17:22:23 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Dec 2020 22:22:23 +0000
Subject: [issue42624] sqlite3 package document mistake
In-Reply-To: <1607762869.89.0.42414804314.issue42624@roundup.psfhosted.org>
Message-ID: <1608330143.1.0.659087188419.issue42624@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The doc is the same in 3.10.

What OS and exact Python release? Can you post minimal code that verifies your claim?  (Someone what have to verify with 3.10 also.)

This would strike me as an error in the code.  We can fix 'wrong Exception' in the next release.  I am not sure whether we would do so in a current release.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42624>
_______________________________________

From report at bugs.python.org  Fri Dec 18 17:33:55 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Fri, 18 Dec 2020 22:33:55 +0000
Subject: [issue24139] Use sqlite3 extended error codes
In-Reply-To: <1430990375.51.0.367829317248.issue24139@psf.upfronthosting.co.za>
Message-ID: <1608330835.45.0.270388222095.issue24139@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
nosy: +erlendaasland

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24139>
_______________________________________

From report at bugs.python.org  Fri Dec 18 17:37:53 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Fri, 18 Dec 2020 22:37:53 +0000
Subject: [issue42624] sqlite3 package document mistake
In-Reply-To: <1607762869.89.0.42414804314.issue42624@roundup.psfhosted.org>
Message-ID: <1608331073.92.0.853544162373.issue42624@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
nosy: +erlendaasland

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42624>
_______________________________________

From report at bugs.python.org  Fri Dec 18 17:43:44 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 18 Dec 2020 22:43:44 +0000
Subject: [issue42677] Support comments in argparse fromfile_prefix_chars files
In-Reply-To: <1608318945.24.0.0639471792025.issue42677@roundup.psfhosted.org>
Message-ID: <1608331424.52.0.754573666269.issue42677@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I think you could achieve this by overriding convert_arg_line_to_args.

If this were baked in to argparse, there would need to be an argument to argparse.ArgumentParser to turn on this behavior, with the default being to not support comments. That's because enabling this by default would be a non backward compatible change.

Personally, I think argparse.ArgumentParser is already too complex, and this shouldn't be added.

----------
nosy: +eric.smith, paul.j3, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42677>
_______________________________________

From report at bugs.python.org  Fri Dec 18 18:03:30 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Fri, 18 Dec 2020 23:03:30 +0000
Subject: [issue40866] Use PyModule_AddType() in posix module initialisation
In-Reply-To: <1591302632.33.0.545094297594.issue40866@roundup.psfhosted.org>
Message-ID: <1608332610.14.0.570992828849.issue40866@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40866>
_______________________________________

From report at bugs.python.org  Fri Dec 18 18:13:40 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 18 Dec 2020 23:13:40 +0000
Subject: [issue37572] email lib bug
In-Reply-To: <1562935441.75.0.460848575163.issue37572@roundup.psfhosted.org>
Message-ID: <1608333220.0.0.718299089559.issue37572@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +rhettinger
nosy_count: 5.0 -> 6.0
pull_requests: +22712
pull_request: https://github.com/python/cpython/pull/23849

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37572>
_______________________________________

From report at bugs.python.org  Fri Dec 18 18:13:39 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 18 Dec 2020 23:13:39 +0000
Subject: [issue42572] Better path handling with argparse
In-Reply-To: <1607121735.85.0.926277593776.issue42572@roundup.psfhosted.org>
Message-ID: <1608333219.88.0.683004678704.issue42572@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
pull_requests: +22711
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23849

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42572>
_______________________________________

From report at bugs.python.org  Fri Dec 18 18:13:40 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 18 Dec 2020 23:13:40 +0000
Subject: [issue35005] argparse should accept json and yaml argument types
In-Reply-To: <1539735338.04.0.788709270274.issue35005@psf.upfronthosting.co.za>
Message-ID: <1608333220.08.0.10966389085.issue35005@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
pull_requests: +22713
pull_request: https://github.com/python/cpython/pull/23849

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35005>
_______________________________________

From report at bugs.python.org  Fri Dec 18 18:20:18 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 18 Dec 2020 23:20:18 +0000
Subject: [issue42572] Better path handling with argparse
In-Reply-To: <1607121735.85.0.926277593776.issue42572@roundup.psfhosted.org>
Message-ID: <1608333618.81.0.497733382127.issue42572@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Eric and Paul, I've attached a substantial rewrite of the docs for the *type* parameter:

* Document the exceptions that are handled.
* Show a wider range of examples that work with *type*.
* Discuss when *type* shouldn't be used:  bool, JSONDecoder, etc.
* Create a less whimsical example of a user-defined type converter.
* Explain the interaction between *type* and *default*.

Let me know what you think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42572>
_______________________________________

From report at bugs.python.org  Fri Dec 18 18:30:30 2020
From: report at bugs.python.org (Eugene Toder)
Date: Fri, 18 Dec 2020 23:30:30 +0000
Subject: [issue42125] linecache cannot get source for the __main__ module with
 a custom loader
In-Reply-To: <1603430813.16.0.973913314648.issue42125@roundup.psfhosted.org>
Message-ID: <1608334230.25.0.403628155507.issue42125@roundup.psfhosted.org>


Change by Eugene Toder <eltoder at gmail.com>:


----------
nosy: +ncoghlan, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42125>
_______________________________________

From report at bugs.python.org  Fri Dec 18 18:45:56 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 18 Dec 2020 23:45:56 +0000
Subject: [issue42633] Wave documentation doesn't mention signed/unsigned
 requirements
In-Reply-To: <1607929400.79.0.578872374659.issue42633@roundup.psfhosted.org>
Message-ID: <1608335156.51.0.123424944356.issue42633@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I not sure about 'very useful'.  One has to know a lot more than the sample width in bytes, which can be 1 to 4 (according to the code), not just 1 to 2 (as implied by https://en.wikipedia.org/wiki/WAV), to effectively use the module.  Such things as the endianess of multibyte samples and what is 'linear pulse code modulation'.  The docs assume that one know all this from another source.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42633>
_______________________________________

From report at bugs.python.org  Fri Dec 18 18:55:22 2020
From: report at bugs.python.org (William Pickard)
Date: Fri, 18 Dec 2020 23:55:22 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1608335722.62.0.0730180582488.issue42529@roundup.psfhosted.org>


William Pickard <lollol222gg at gmail.com> added the comment:

You may need to inject a LoadLibraryExW detour into your python runtime before _jpype is loaded and output all the library names its requesting.

You may need to detour all Load 
Library functions for maximum coverage.

----------
nosy: +WildCard65

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Fri Dec 18 19:09:08 2020
From: report at bugs.python.org (Irit Katriel)
Date: Sat, 19 Dec 2020 00:09:08 +0000
Subject: [issue3735] allow multiple threads to efficiently send the same
 requests to a processing.Pool without incurring duplicate processing
In-Reply-To: <1220051229.09.0.236623735385.issue3735@psf.upfronthosting.co.za>
Message-ID: <1608336548.86.0.640183321977.issue3735@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
stage: needs patch -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3735>
_______________________________________

From report at bugs.python.org  Fri Dec 18 19:10:03 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 19 Dec 2020 00:10:03 +0000
Subject: [issue24792] zipimporter masks import errors
In-Reply-To: <1438764662.95.0.423222705195.issue24792@psf.upfronthosting.co.za>
Message-ID: <1608336603.2.0.90459795353.issue24792@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset fb34096140bbb74c81500dd8bbc3c69c1d24d9ab by Irit Katriel in branch 'master':
bpo-24792: Fix zipimporter masking the cause of import errors (GH-22204)
https://github.com/python/cpython/commit/fb34096140bbb74c81500dd8bbc3c69c1d24d9ab


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24792>
_______________________________________

From report at bugs.python.org  Fri Dec 18 19:12:12 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 19 Dec 2020 00:12:12 +0000
Subject: [issue23522] Misleading note in Statistics module documentation
In-Reply-To: <1608314226.89.0.559603805586.issue23522@roundup.psfhosted.org>
Message-ID: <20201219001124.GA28254@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I strongly oppose this change, and I dispute the characterisation of 
this as a misleading note. It is not misleading, and I argue that every 
word of it is factually correct. Jake, if you disagree, then please 
provide some citations.

Irit: it is ridiculous to describe a two paragraph (nine line) note as 
"a statistics textbook". That is an exaggerated position that doesn't 
help the discussion. It's not a textbook, it is a short note that helps 
users whose knowledge of statistics is naive to understand which 
statistic is better for them.

"If someone doesn't know whether they need the mean or the median, they 
really need to read a more fundamental text before writing their code."

I totally disagree. This module is not intended only for statisticians 
and experts, and the user who isn't sure which average to use shouldn't 
have to read a textbook on the fundamentals of statistics.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23522>
_______________________________________

From report at bugs.python.org  Fri Dec 18 19:23:12 2020
From: report at bugs.python.org (Irit Katriel)
Date: Sat, 19 Dec 2020 00:23:12 +0000
Subject: [issue32112] Should uuid.UUID() accept another UUID() instance?
In-Reply-To: <1511347956.68.0.213398074469.issue32112@psf.upfronthosting.co.za>
Message-ID: <1608337392.12.0.822210793832.issue32112@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32112>
_______________________________________

From report at bugs.python.org  Fri Dec 18 19:27:18 2020
From: report at bugs.python.org (Martin Chase)
Date: Sat, 19 Dec 2020 00:27:18 +0000
Subject: [issue42680] unicode identifiers not accessible or assignable through
 globals()
Message-ID: <1608337638.31.0.282266859185.issue42680@roundup.psfhosted.org>


New submission from Martin Chase <outofculture at gmail.com>:

This behavior is best described by the code below:

```
>>> meow = 1
>>> 'meow' in globals()
True
>>> ?meow = 1e-6
>>> '?meow' in globals()
False
>>> globals()['woof'] = 1
>>> woof
1
>>> globals()['?woof'] = 1e-6
>>> ?woof
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name '?woof' is not defined
>>> import sys
>>> sys.getdefaultencoding()
'utf-8'
>>> [(k, bytes(k, 'utf-8')) for k in globals()]
..., ('?meow', b'\xce\xbcmeow'), ('?woof', b'\xc2\xb5woof')]
>>> '?'.encode('utf-8')
b'\xc2\xb5'
```

Testing was done on linux and windows, variously using 3.6.12, 3.7.6, 3.8.6 and 3.9.0+.

----------
components: Unicode
messages: 383336
nosy: ezio.melotti, outofculture, vstinner
priority: normal
severity: normal
status: open
title: unicode identifiers not accessible or assignable through globals()
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42680>
_______________________________________

From report at bugs.python.org  Fri Dec 18 19:32:51 2020
From: report at bugs.python.org (Karl Nelson)
Date: Sat, 19 Dec 2020 00:32:51 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1608337971.12.0.990721160657.issue42529@roundup.psfhosted.org>


Karl Nelson <nelson85 at llnl.gov> added the comment:

Can you be so kind as pointing me to a LoadLibraryExW detour example for Python?   I have shimmed a DLL before to capture transaction logs in the past, but not with a Python or a system library.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Fri Dec 18 19:33:21 2020
From: report at bugs.python.org (Martin Chase)
Date: Sat, 19 Dec 2020 00:33:21 +0000
Subject: [issue42680] unicode identifiers not accessible or assignable through
 globals()
In-Reply-To: <1608337638.31.0.282266859185.issue42680@roundup.psfhosted.org>
Message-ID: <1608338001.12.0.0164579326915.issue42680@roundup.psfhosted.org>


Martin Chase <outofculture at gmail.com> added the comment:

Oh, I just gave a cursory using `locals()`, and the same misbehavior is present.

A workaround, for anyone needing to assign or access unicode globals, is to use `exec`, e.g. `exec("?meow = 1e-6", globals())`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42680>
_______________________________________

From report at bugs.python.org  Fri Dec 18 19:34:41 2020
From: report at bugs.python.org (William Pickard)
Date: Sat, 19 Dec 2020 00:34:41 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1608338081.91.0.786596059152.issue42529@roundup.psfhosted.org>


William Pickard <lollol222gg at gmail.com> added the comment:

https://www.microsoft.com/en-us/research/project/detours/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Fri Dec 18 19:35:17 2020
From: report at bugs.python.org (Irit Katriel)
Date: Sat, 19 Dec 2020 00:35:17 +0000
Subject: [issue1289136] distutils extension library path bug on cygwin
Message-ID: <1608338117.22.0.0502040217741.issue1289136@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
resolution:  -> out of date
stage: needs patch -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1289136>
_______________________________________

From report at bugs.python.org  Fri Dec 18 19:42:26 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 19 Dec 2020 00:42:26 +0000
Subject: [issue42680] unicode identifiers not accessible or assignable through
 globals()
In-Reply-To: <1608337638.31.0.282266859185.issue42680@roundup.psfhosted.org>
Message-ID: <1608338546.04.0.294434154145.issue42680@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I'm pretty sure this is not a bug, but is working as designed.

The interpreter normalises unicode identifiers, but key lookup in the dict does not.

Sorry, I don't have time right now to give a more detailed answer, but there are two distinct mu characters:

    ? U+03BC
    ? U+00B5

and my prediction is that the identifier is normalised to the first, the actual Greek mu, but you are looking up the second, the micro sign.

(I'll be able to give a longer response in a couple of hours, if still needed.)

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42680>
_______________________________________

From report at bugs.python.org  Fri Dec 18 19:54:06 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 19 Dec 2020 00:54:06 +0000
Subject: [issue34805] Explicitly specify `MyClass.__subclasses__()` returns
 classes in definition order
In-Reply-To: <1537942683.07.0.545547206417.issue34805@psf.upfronthosting.co.za>
Message-ID: <1608339246.69.0.714646907608.issue34805@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 7.0 -> 8.0
pull_requests: +22714
pull_request: https://github.com/python/cpython/pull/23850

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34805>
_______________________________________

From report at bugs.python.org  Fri Dec 18 19:54:09 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Dec 2020 00:54:09 +0000
Subject: [issue34805] Explicitly specify `MyClass.__subclasses__()` returns
 classes in definition order
In-Reply-To: <1537942683.07.0.545547206417.issue34805@psf.upfronthosting.co.za>
Message-ID: <1608339249.84.0.933689120949.issue34805@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 51f4688254ebb7b30215de424360ba5c92c63fe8 by Raymond Hettinger in branch 'master':
bpo-34805:  Guarantee that __subclasses__() is in definition order. (GH-23844)
https://github.com/python/cpython/commit/51f4688254ebb7b30215de424360ba5c92c63fe8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34805>
_______________________________________

From report at bugs.python.org  Fri Dec 18 19:56:00 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Dec 2020 00:56:00 +0000
Subject: [issue42670] Missing word in itertools.product
In-Reply-To: <1608227393.01.0.305034051579.issue42670@roundup.psfhosted.org>
Message-ID: <1608339360.19.0.63210752909.issue42670@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset eef33e6d49d05aad4111da4ad2d9cb34e7a5206c by Miss Islington (bot) in branch '3.9':
bpo-42670: Fix a missing word in the itertools.product() docs (GH-23823) (GH-23824)
https://github.com/python/cpython/commit/eef33e6d49d05aad4111da4ad2d9cb34e7a5206c


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42670>
_______________________________________

From report at bugs.python.org  Fri Dec 18 19:56:16 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Dec 2020 00:56:16 +0000
Subject: [issue42670] Missing word in itertools.product
In-Reply-To: <1608227393.01.0.305034051579.issue42670@roundup.psfhosted.org>
Message-ID: <1608339376.25.0.788817865558.issue42670@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/issue42670>
_______________________________________

From report at bugs.python.org  Fri Dec 18 19:57:36 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Dec 2020 00:57:36 +0000
Subject: [issue23522] Misleading note in Statistics module documentation
In-Reply-To: <1424889646.1.0.160219400081.issue23522@psf.upfronthosting.co.za>
Message-ID: <1608339456.02.0.925976422526.issue23522@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

FWIW, Allen Downey also had concerns about this wording.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23522>
_______________________________________

From report at bugs.python.org  Fri Dec 18 19:57:51 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Dec 2020 00:57:51 +0000
Subject: [issue23522] Misleading note in Statistics module documentation
In-Reply-To: <1424889646.1.0.160219400081.issue23522@psf.upfronthosting.co.za>
Message-ID: <1608339471.58.0.124692041231.issue23522@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: docs at python -> steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23522>
_______________________________________

From report at bugs.python.org  Fri Dec 18 19:58:57 2020
From: report at bugs.python.org (Robert T McQuaid)
Date: Sat, 19 Dec 2020 00:58:57 +0000
Subject: [issue42681] mistake in curses documentation
Message-ID: <1608339537.48.0.496910027234.issue42681@roundup.psfhosted.org>


New submission from Robert T McQuaid <rtmq at fixcas.com>:

The description of color_pair starts with

curses.color_pair(color_number)

It should be

curses.color_pair(pair_number)

----------
assignee: docs at python
components: Documentation
messages: 383344
nosy: arbor, docs at python
priority: normal
severity: normal
status: open
title: mistake in curses documentation
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42681>
_______________________________________

From report at bugs.python.org  Fri Dec 18 19:58:59 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Dec 2020 00:58:59 +0000
Subject: [issue23522] Misleading note in Statistics module documentation
In-Reply-To: <1424889646.1.0.160219400081.issue23522@psf.upfronthosting.co.za>
Message-ID: <1608339539.4.0.604819401766.issue23522@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
Removed message: https://bugs.python.org/msg383343

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23522>
_______________________________________

From report at bugs.python.org  Fri Dec 18 20:00:59 2020
From: report at bugs.python.org (Tillmann Karras)
Date: Sat, 19 Dec 2020 01:00:59 +0000
Subject: [issue17140] Document multiprocessing.pool.ThreadPool
In-Reply-To: <1360116485.64.0.452267246232.issue17140@psf.upfronthosting.co.za>
Message-ID: <1608339659.57.0.0873441420919.issue17140@roundup.psfhosted.org>


Change by Tillmann Karras <tilkax at gmail.com>:


----------
nosy:  -Tilka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue17140>
_______________________________________

From report at bugs.python.org  Fri Dec 18 20:03:17 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Dec 2020 01:03:17 +0000
Subject: [issue42559] random.getrandbits: Should it be explicit that it
 returns unsigned/non-negative integer?
In-Reply-To: <1607018036.1.0.534167707073.issue42559@roundup.psfhosted.org>
Message-ID: <1608339797.52.0.962597422501.issue42559@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 5646414ae1fce620b919056f7999dfd15da78e9c by Raymond Hettinger in branch 'master':
bpo-42559: Not that getrandbits() is non-negative. (GH-23843)
https://github.com/python/cpython/commit/5646414ae1fce620b919056f7999dfd15da78e9c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42559>
_______________________________________

From report at bugs.python.org  Fri Dec 18 20:03:22 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 19 Dec 2020 01:03:22 +0000
Subject: [issue42559] random.getrandbits: Should it be explicit that it
 returns unsigned/non-negative integer?
In-Reply-To: <1607018036.1.0.534167707073.issue42559@roundup.psfhosted.org>
Message-ID: <1608339802.22.0.0973015611721.issue42559@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +22715
pull_request: https://github.com/python/cpython/pull/23851

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42559>
_______________________________________

From report at bugs.python.org  Fri Dec 18 20:06:00 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 19 Dec 2020 01:06:00 +0000
Subject: [issue42042] sphinx3 renders diffrently docs.python.org for 3.10
In-Reply-To: <1602763041.43.0.432643801896.issue42042@roundup.psfhosted.org>
Message-ID: <1608339960.49.0.0178714532243.issue42042@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:

@mdk

No https://github.com/python/python-docs-theme/pull/57 must be fixed ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42042>
_______________________________________

From report at bugs.python.org  Fri Dec 18 20:11:25 2020
From: report at bugs.python.org (Martin Chase)
Date: Sat, 19 Dec 2020 01:11:25 +0000
Subject: [issue42680] unicode identifiers not accessible or assignable through
 globals()
In-Reply-To: <1608337638.31.0.282266859185.issue42680@roundup.psfhosted.org>
Message-ID: <1608340285.48.0.354001326354.issue42680@roundup.psfhosted.org>


Martin Chase <outofculture at gmail.com> added the comment:

Ah! So then the proper code for me would be e.g.:

```
>>> globals()[unicodedata.normalize("NFKC", "?meow")]
1e-06
```

Yes, it's clear when I read https://www.python.org/dev/peps/pep-3131/ that the normalization is going to happen. Is it also worth adding a note in the documentation for `globals()` and `locals()`? That's the first place I looked to try to find out what was wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42680>
_______________________________________

From report at bugs.python.org  Fri Dec 18 20:14:39 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Dec 2020 01:14:39 +0000
Subject: [issue42042] sphinx3 renders diffrently docs.python.org for 3.10
In-Reply-To: <1602763041.43.0.432643801896.issue42042@roundup.psfhosted.org>
Message-ID: <1608340479.69.0.902362747977.issue42042@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The code background highlights really do need to be restored.  Readability has been significantly impaired in 3.10.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42042>
_______________________________________

From report at bugs.python.org  Fri Dec 18 20:17:39 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Dec 2020 01:17:39 +0000
Subject: [issue34805] Explicitly specify `MyClass.__subclasses__()` returns
 classes in definition order
In-Reply-To: <1537942683.07.0.545547206417.issue34805@psf.upfronthosting.co.za>
Message-ID: <1608340659.68.0.735706046522.issue34805@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 782665885c983e88aac12f7e082485cac2df8007 by Miss Islington (bot) in branch '3.9':
bpo-34805:  Guarantee that __subclasses__() is in definition order. (GH-23844) (GH-23850)
https://github.com/python/cpython/commit/782665885c983e88aac12f7e082485cac2df8007


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34805>
_______________________________________

From report at bugs.python.org  Fri Dec 18 20:17:58 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Dec 2020 01:17:58 +0000
Subject: [issue34805] Explicitly specify `MyClass.__subclasses__()` returns
 classes in definition order
In-Reply-To: <1537942683.07.0.545547206417.issue34805@psf.upfronthosting.co.za>
Message-ID: <1608340678.45.0.408041022552.issue34805@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/issue34805>
_______________________________________

From report at bugs.python.org  Fri Dec 18 20:48:32 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 19 Dec 2020 01:48:32 +0000
Subject: [issue42649] RecursionError when parsing unwieldy expression
 (regression from 2.7 -> 3.x)
In-Reply-To: <1608054957.39.0.0382114401229.issue42649@roundup.psfhosted.org>
Message-ID: <1608342512.64.0.691309945022.issue42649@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

One can use sys.setrecursionlimit to increase allowed recursion depth.

But...  When I ran code from 3.10.0a3 IDLE editor, something hung.  Without touching recursion limit, when I split statement apart into

ex = compile("""<300 lines>""", '', 'eval')
print(eval(ex))

I got 106994.5 in under a second.  With exec, ditto except that None is printed.  Same last result with 3.9.1.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42649>
_______________________________________

From report at bugs.python.org  Fri Dec 18 20:48:58 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 19 Dec 2020 01:48:58 +0000
Subject: [issue42042] sphinx3 renders diffrently docs.python.org for 3.10
In-Reply-To: <1602763041.43.0.432643801896.issue42042@roundup.psfhosted.org>
Message-ID: <1608342538.79.0.641576746395.issue42042@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

https://github.com/python/python-docs-theme/pull/57 is landed. We just need a new release of the package to pypi

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42042>
_______________________________________

From report at bugs.python.org  Fri Dec 18 20:55:00 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 19 Dec 2020 01:55:00 +0000
Subject: [issue42672] tkinter/__init__.py raises a NameError if NoDefaultRoot()
Message-ID: <1608342900.91.0.851834852359.issue42672@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42672>
_______________________________________

From report at bugs.python.org  Fri Dec 18 21:04:37 2020
From: report at bugs.python.org (paul j3)
Date: Sat, 19 Dec 2020 02:04:37 +0000
Subject: [issue42677] Support comments in argparse fromfile_prefix_chars files
In-Reply-To: <1608318945.24.0.0639471792025.issue42677@roundup.psfhosted.org>
Message-ID: <1608343477.97.0.516022197021.issue42677@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

https://docs.python.org/3/library/argparse.html#customizing-file-parsing

in the docs describes how to customize the @file reading.  This particular extension handles several strings on a line, but that's not the limit of what you could do.

You can also read a file before parsing and construct a custom `argv` list, as described in https://docs.python.org/3/library/argparse.html#beyond-sys-argv

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42677>
_______________________________________

From report at bugs.python.org  Fri Dec 18 21:38:15 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 19 Dec 2020 02:38:15 +0000
Subject: [issue18140] urlparse,
 urlsplit confused when password includes fragment (#), query (?)
In-Reply-To: <1370425503.35.0.436511643169.issue18140@psf.upfronthosting.co.za>
Message-ID: <1608345495.63.0.624307581474.issue18140@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
versions: +Python 3.10 -Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18140>
_______________________________________

From report at bugs.python.org  Fri Dec 18 22:10:15 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Dec 2020 03:10:15 +0000
Subject: [issue42559] random.getrandbits: Should it be explicit that it
 returns unsigned/non-negative integer?
In-Reply-To: <1607018036.1.0.534167707073.issue42559@roundup.psfhosted.org>
Message-ID: <1608347415.03.0.516653303842.issue42559@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset d458d8dab0abaf781c923f80f8eb832d0c683e88 by Miss Islington (bot) in branch '3.9':
bpo-42559: Not that getrandbits() is non-negative. (GH-23843) (GH-23851)
https://github.com/python/cpython/commit/d458d8dab0abaf781c923f80f8eb832d0c683e88


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42559>
_______________________________________

From report at bugs.python.org  Fri Dec 18 22:10:57 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Dec 2020 03:10:57 +0000
Subject: [issue42559] random.getrandbits: Should it be explicit that it
 returns unsigned/non-negative integer?
In-Reply-To: <1607018036.1.0.534167707073.issue42559@roundup.psfhosted.org>
Message-ID: <1608347457.44.0.757051085119.issue42559@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/issue42559>
_______________________________________

From report at bugs.python.org  Fri Dec 18 23:01:34 2020
From: report at bugs.python.org (Karl Nelson)
Date: Sat, 19 Dec 2020 04:01:34 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1608350494.77.0.373058041208.issue42529@roundup.psfhosted.org>


Karl Nelson <nelson85 at llnl.gov> added the comment:

I used Detours with trclnk64 to get the following log:

```
20201218193836960 4332 50.60: trclnk64: 001   GetProcAddress(,) -> 7ffc4ccebef0
20201218193836960 4332 50.60: trclnk64: 001   GetProcAddress(7ffc4ccd0000,LCMapStringEx)
20201218193836960 4332 50.60: trclnk64: 001   GetProcAddress(,) -> 7ffc4cce6640
======== <= This is the point where it differs from a clean run.
20201218193838163 4332 50.60: trclnk64: 001   GetProcAddress(7ffc4c710000,FlsFree)
20201218193838163 4332 50.60: trclnk64: 001   GetProcAddress(,) -> 7ffc4c78b000
20201218193838163 4332 50.60: trclnk64: 001   FAIL LoadLibraryExW(c:\users\nelson85\documents\devel\open\jpype\_jpype.cp39-win_amd64.pyd,0,1100)
20201218193838164 4332 50.60: trclnk64: 001 LoadLibraryExW(,,) -> 0
```

It really is nothing to go on...  Everything succeeds, then we get an extra successful request for FlsFree then it immediately returns with a fail.

In the successful run (without the cache) we get...
```
20201218192451068 20440 50.60: trclnk64: 001   GetProcAddress(7ffc4ccd0000,LCMapStringEx)
20201218192451068 20440 50.60: trclnk64: 001   GetProcAddress(,) -> 7ffc4cce6640
20201218192451068 20440 50.60: trclnk64: 001 LoadLibraryExW(,,) -> 7ffc349f0000
20201218192451068 20440 50.60: trclnk64: ### 349f0000: c:\users\nelson85\documents\devel\open\jpype\_jpype.cp39-win_amd64.pyd 00000000
20201218192451068 20440 50.60: trclnk64: MSVCP140.dll [7ffc34a7af48 7ffc34a5a0c8]
20201218192451068 20440 50.60: trclnk64:   ?_Lock@?$basic_streambuf at DU?$char_traits at D@std@@@std@@UEAAXXZ    0 7ffc36f22350
20201218192451068 20440 50.60: trclnk64:   ?_Unlock@?$basic_streambuf at DU?$char_traits at D@std@@@std@@UEAAXXZ    0 7ffc36f22350
```

So the failure appears to be internal to the call before we load MSVCP140.dll.   Unfortunately, I am way outside my element here as a Linux/Java/CPython programmer.   My next guess would be to instrument the set system error and if we are within LoadLibrary then execute "int *i=0; *i=0;"  and hope the debugger would get me the point of failure so that I can examine the stack trace to find out where we are.  But if you have another direction I would be happy to hear it.   Is there some function I should add to trclnk64 to that may have gone wrong?  It must be something that fetched the address of LCMapStringEx, but I have no clue what that may be.

This really does not look like a JPype bug.  Yes, two minutes in the future from where the car ran over the pedestrian, he was going to run into the bank and demand money (monkey patch and other bad things).  But at the point in time the car hit, the pedestrian was just minding his own business.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Fri Dec 18 23:05:42 2020
From: report at bugs.python.org (William Pickard)
Date: Sat, 19 Dec 2020 04:05:42 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1608350742.76.0.559790017361.issue42529@roundup.psfhosted.org>


William Pickard <lollol222gg at gmail.com> added the comment:

I was just expecting only detours for LoadLibraryExW (and variants) to find out which dll failed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Fri Dec 18 23:20:07 2020
From: report at bugs.python.org (Ganesh Kathiresan)
Date: Sat, 19 Dec 2020 04:20:07 +0000
Subject: [issue42665] Should PyLong_AsLongAndOverflow raise exception on
 overflow?
In-Reply-To: <1608198241.29.0.475035638972.issue42665@roundup.psfhosted.org>
Message-ID: <1608351607.15.0.81131639216.issue42665@roundup.psfhosted.org>


Ganesh Kathiresan <ganesh3597 at gmail.com> added the comment:

Hi All, thanks for the input. Yeah, the current behavior makes sense, if overflow exception is needed, we can use PyLong_AsLong. I guess my confusion was from the doc: 
> set *overflow to 1 or -1, respectively, and return -1;
> Returns -1 on error. Use PyErr_Occurred() to disambiguate.

It's not particularly clear if overflow is an `error` here, but again a quick compile and run will give you the answer. You can take a call if we have to have an explicit statement saying: no exception raised on overflow

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42665>
_______________________________________

From report at bugs.python.org  Fri Dec 18 23:21:38 2020
From: report at bugs.python.org (Karl Nelson)
Date: Sat, 19 Dec 2020 04:21:38 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1608351698.77.0.209512375985.issue42529@roundup.psfhosted.org>


Karl Nelson <nelson85 at llnl.gov> added the comment:

The last libraries loaded prior to the failure were...

```
20201218192451066 20440 50.60: trclnk64: api-ms-win-eventing-provider-l1-1-0.dll [7ffc4c974108 7ffc4c8b7808]
20201218192451066 20440 50.60: trclnk64:   EventUnregister    0 7ffc4eab37a0
20201218192451066 20440 50.60: trclnk64:   EventRegister    0 7ffc4ea6a640
20201218192451066 20440 50.60: trclnk64:   EventActivityIdControl    0 7ffc4eac6190
20201218192451066 20440 50.60: trclnk64:   EventWriteTransfer    0 7ffc4eab2cf0
20201218192451066 20440 50.60: trclnk64:   EventSetInformation    0 7ffc4ea6a3e0
20201218192451066 20440 50.60: trclnk64: api-ms-win-core-apiquery-l1-1-0.dll [7ffc4c9740e8 7ffc4c8b77e8]
20201218192451066 20440 50.60: trclnk64:   ApiSetQueryApiSetPresence    0 7ffc4ead5030
20201218192451066 20440 50.60: trclnk64: api-ms-win-core-apiquery-l1-1-1.dll [7ffc4c9740f8 7ffc4c8b77f8]
20201218192451066 20440 50.60: trclnk64:   ApiSetQueryApiSetPresenceEx    0 7ffc4eb35730
```

And as far as I can tell that was successful.  Perhaps there is another library at this point, but my reading of the log is that LoadLibraryExW was called run though all required elements to load, got the end section before it started to load dependencies of _jpype, started fetching things that have to do with locale and then hit a failure point inside of LoadLibrary.   If I look at the successful trace then I see the next action is to start linking in C++ symbols.   

But perhaps I am misreading...   Looking farther back in the log, the last LoadLibrary to get called before the failure is.

```
20201218192451054 20440 50.60: trclnk64: 001   LoadLibraryExW(api-ms-win-core-fibers-l1-1-1,0,800)
20201218192451054 20440 50.60: trclnk64: 001   LoadLibraryExW(,,) -> 7ffc4c710000
20201218192451054 20440 50.60: trclnk64: ### 4c710000: C:\WINDOWS\System32\KERNELBASE.dll 002b306b
20201218192451054 20440 50.60: trclnk64: ntdll.dll [7ffc4c974138 7ffc4c8b7838]
```

Fibers?  I have no clue at this point.   Is this a Python bug or a windows bug?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Fri Dec 18 23:33:44 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Dec 2020 04:33:44 +0000
Subject: [issue42470] DeprecationWarning triggers for sequences which happen
 to be sets as well
In-Reply-To: <1606379035.36.0.842330798084.issue42470@roundup.psfhosted.org>
Message-ID: <1608352424.49.0.657536893491.issue42470@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 1e27b57dbc8c1b758e37a531487813aef2d111ca by masklinn in branch 'master':
bpo-42470: Do not warn on sequences which are also sets in random.sample() (GH-23665)
https://github.com/python/cpython/commit/1e27b57dbc8c1b758e37a531487813aef2d111ca


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42470>
_______________________________________

From report at bugs.python.org  Fri Dec 18 23:35:57 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Dec 2020 04:35:57 +0000
Subject: [issue42470] DeprecationWarning triggers for sequences which happen
 to be sets as well
In-Reply-To: <1606379035.36.0.842330798084.issue42470@roundup.psfhosted.org>
Message-ID: <1608352557.2.0.822208923053.issue42470@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Given that this is rare and that it is a behavior change, I'm only applying this to 3.10.  If you think it is essential for 3.9, feel free to reopen and we'll discuss it with the release manager.

----------
components: +Library (Lib)
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10 -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42470>
_______________________________________

From report at bugs.python.org  Sat Dec 19 00:02:01 2020
From: report at bugs.python.org (Ken Jin)
Date: Sat, 19 Dec 2020 05:02:01 +0000
Subject: [issue42675] Document changes made in bpo-42195
In-Reply-To: <1608309514.56.0.184586625269.issue42675@roundup.psfhosted.org>
Message-ID: <1608354121.34.0.653352706347.issue42675@roundup.psfhosted.org>


Change by Ken Jin <kenjin4096 at gmail.com>:


----------
pull_requests: +22716
pull_request: https://github.com/python/cpython/pull/23852

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42675>
_______________________________________

From report at bugs.python.org  Sat Dec 19 00:02:01 2020
From: report at bugs.python.org (Ken Jin)
Date: Sat, 19 Dec 2020 05:02:01 +0000
Subject: [issue42195] Inconsistent __args__ between typing.Callable and
 collections.abc.Callable
In-Reply-To: <1603974319.88.0.166786801787.issue42195@roundup.psfhosted.org>
Message-ID: <1608354121.71.0.680473475655.issue42195@roundup.psfhosted.org>


Change by Ken Jin <kenjin4096 at gmail.com>:


----------
pull_requests: +22717
pull_request: https://github.com/python/cpython/pull/23852

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42195>
_______________________________________

From report at bugs.python.org  Sat Dec 19 00:42:47 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Dec 2020 05:42:47 +0000
Subject: [issue23522] Misleading note in Statistics module documentation
In-Reply-To: <1424889646.1.0.160219400081.issue23522@psf.upfronthosting.co.za>
Message-ID: <1608356567.89.0.654151710862.issue23522@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Steven, you are the module maintainer.  So if you're sure about the current wording, go ahead and close this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23522>
_______________________________________

From report at bugs.python.org  Sat Dec 19 01:32:31 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 19 Dec 2020 06:32:31 +0000
Subject: [issue23522] Misleading note in Statistics module documentation
In-Reply-To: <1608356567.89.0.654151710862.issue23522@roundup.psfhosted.org>
Message-ID: <20201219063143.GH28254@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I'm willing to give Irit and Jake opportunity to make their case. 
Particularly if they can demonstrate that I got my facts wrong.

I'm going to close the ticket, but if anyone feels strongly enough to 
respond with a good argument, or better still citations demonstrating 
that the comment is factually wrong, I am open to revising or removing 
the wording.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23522>
_______________________________________

From report at bugs.python.org  Sat Dec 19 01:40:34 2020
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 19 Dec 2020 06:40:34 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1608360034.67.0.00944560349466.issue42529@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> ImportError: DLL load failed while importing _jpype: 
> A dynamic link library (DLL) initialization routine failed.

With loader snaps enabled for python[_d].exe (i.e. loader debug messages), you can attach a debugger to discover which DLL's init routine is failing. For example, you'll see a debug message like the following:

    xxxx:xxxx @ xxxxxxxx - LdrpInitializeNode - ERROR:
    Init routine XXXXXXXXXXXXXXXX for DLL "Path\To\DLL"
    failed during DLL_PROCESS_ATTACH

The entry point of a DLL is typically _DllMainCRTStartup, which initializes the CRT for the DLL and calls DllMain(). In any case, you can find the relative address of the entry point in the PE header, via dumpbin.exe or the debugger !dh command. Set a breakpoint on it and step through to find where it fails in comparison with a working environment.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Sat Dec 19 02:24:04 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 19 Dec 2020 07:24:04 +0000
Subject: [issue23522] Misleading note in Statistics module documentation
In-Reply-To: <1424889646.1.0.160219400081.issue23522@psf.upfronthosting.co.za>
Message-ID: <1608362644.73.0.946512584145.issue23522@roundup.psfhosted.org>


Change by Steven D'Aprano <steve+python at pearwood.info>:


----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23522>
_______________________________________

From report at bugs.python.org  Sat Dec 19 03:09:24 2020
From: report at bugs.python.org (lilydjwg)
Date: Sat, 19 Dec 2020 08:09:24 +0000
Subject: [issue42682] awaiting a wrapped asyncio.Task multiple times gives
 long, repeative tracebacks
Message-ID: <1608365364.67.0.620283086401.issue42682@roundup.psfhosted.org>


New submission from lilydjwg <lilydjwg at gmail.com>:

import asyncio

async def crash(key):
  raise Exception('crash!')

async def wait(fu):
  await fu

async def main():
  crasher = asyncio.create_task(crash(()))
  fs = [wait(crasher) for _ in range(10)]
  for fu in asyncio.as_completed(fs):
    try:
      await fu
    except Exception:
      import traceback
      traceback.print_exc()

if __name__ == '__main__':
  asyncio.run(main())

This code will give a very long traceback 10 times. I expect it to be short.

I'm caching the result of an async function like this:

  async def get(
    self,
    key: Hashable,
    func: Callable[[Hashable], Coroutine[Any, Any, Any]],
  ) -> Any:
    async with self.lock:
      cached = self.cache.get(key)
      if cached is None:
        coro = func(key)
        fu = asyncio.create_task(coro)
        self.cache[key] = fu

    if asyncio.isfuture(cached): # pending
      return await cached # type: ignore
    elif cached is not None: # cached
      return cached
    else: # not cached
      r = await fu
      self.cache[key] = r
      return r

It works fine, except that when there is an exception the traceback is very long.

----------
components: asyncio
messages: 383364
nosy: asvetlov, lilydjwg, yselivanov
priority: normal
severity: normal
status: open
title: awaiting a wrapped asyncio.Task multiple times gives long, repeative tracebacks
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42682>
_______________________________________

From report at bugs.python.org  Sat Dec 19 03:43:06 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Dec 2020 08:43:06 +0000
Subject: [issue42672] tkinter/__init__.py raises a NameError if NoDefaultRoot()
Message-ID: <1608367386.14.0.0446530971309.issue42672@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

The patch is not correct. Its first part negates the correct behavior, its second part does not affect behavior at all, and all this does not have any effect on NameError.

This issue looks like a duplication of 42630.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Variable.__init__ raises obscure AttributeError

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42672>
_______________________________________

From report at bugs.python.org  Sat Dec 19 05:17:11 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Dec 2020 10:17:11 +0000
Subject: [issue42630] Variable.__init__ raises obscure AttributeError
In-Reply-To: <1607901840.62.0.626631020476.issue42630@roundup.psfhosted.org>
Message-ID: <1608373031.33.0.313329722851.issue42630@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 3d569fd6dccf9f582bafaca04d3535094cae393e by Serhiy Storchaka in branch 'master':
bpo-42630: Improve error reporting in Tkinter for absent default root (GH-23781)
https://github.com/python/cpython/commit/3d569fd6dccf9f582bafaca04d3535094cae393e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42630>
_______________________________________

From report at bugs.python.org  Sat Dec 19 05:17:20 2020
From: report at bugs.python.org (LIU Qingyuan)
Date: Sat, 19 Dec 2020 10:17:20 +0000
Subject: [issue42624] sqlite3 package document mistake
In-Reply-To: <1607762869.89.0.42414804314.issue42624@roundup.psfhosted.org>
Message-ID: <1608373040.89.0.232616572705.issue42624@roundup.psfhosted.org>


LIU Qingyuan <possnioo2 at gmail.com> added the comment:

Python 3.9.1 (default, Dec 11 2020, 14:32:07) 
[GCC 7.3.0] :: Anaconda, Inc. on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sqlite3
>>> conn = sqlite3.connect("test.db")
>>> conn.execute("CREATE TABLE test (id INTEGER, str TEXT);")
<sqlite3.Cursor object at 0x7ff99f2df3b0>
>>> conn.execute("CREATE TABLE test (id INTEGER, str TEXT);")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
sqlite3.OperationalError: table test already exists
>>> 


I think the reproduction is way too easy and has nothing special so I didn't include one at the very beginning. That's a simple reproduction on interactive console.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42624>
_______________________________________

From report at bugs.python.org  Sat Dec 19 05:21:10 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 19 Dec 2020 10:21:10 +0000
Subject: [issue23522] Misleading note in Statistics module documentation
In-Reply-To: <1608339456.02.0.925976422526.issue23522@roundup.psfhosted.org>
Message-ID: <20201219102022.GK28254@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Sorry Raymond, I missed this before closing the task.

> FWIW, Allen Downey also had concerns about this wording.

I don't recognise the name, who is Allen Downey and what concerns does 
he have?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23522>
_______________________________________

From report at bugs.python.org  Sat Dec 19 05:33:28 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Dec 2020 10:33:28 +0000
Subject: [issue42630] Variable.__init__ raises obscure AttributeError
In-Reply-To: <1607901840.62.0.626631020476.issue42630@roundup.psfhosted.org>
Message-ID: <1608374008.87.0.473010711655.issue42630@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +22718
pull_request: https://github.com/python/cpython/pull/23853

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42630>
_______________________________________

From report at bugs.python.org  Sat Dec 19 06:08:31 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Dec 2020 11:08:31 +0000
Subject: [issue42630] Variable.__init__ raises obscure AttributeError
In-Reply-To: <1607901840.62.0.626631020476.issue42630@roundup.psfhosted.org>
Message-ID: <1608376111.49.0.994225720865.issue42630@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 87e7a14ee3bd7dc495e51166598453114342d0bf by Serhiy Storchaka in branch '3.9':
[3.9] bpo-42630: Improve error reporting in Tkinter for absent default root (GH-23781) (GH-23853)
https://github.com/python/cpython/commit/87e7a14ee3bd7dc495e51166598453114342d0bf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42630>
_______________________________________

From report at bugs.python.org  Sat Dec 19 06:15:59 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Dec 2020 11:15:59 +0000
Subject: [issue42630] Variable.__init__ raises obscure AttributeError
In-Reply-To: <1607901840.62.0.626631020476.issue42630@roundup.psfhosted.org>
Message-ID: <1608376559.96.0.902402914692.issue42630@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +22719
pull_request: https://github.com/python/cpython/pull/23854

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42630>
_______________________________________

From report at bugs.python.org  Sat Dec 19 06:26:28 2020
From: report at bugs.python.org (Paul Moore)
Date: Sat, 19 Dec 2020 11:26:28 +0000
Subject: [issue42683] asyncio should handle keyboard interrupt while the event
 loop is running
Message-ID: <1608377188.51.0.0510456786918.issue42683@roundup.psfhosted.org>


New submission from Paul Moore <p.f.moore at gmail.com>:

See the comment on Discourse here: https://discuss.python.org/t/feeding-data-generated-via-asyncio-into-a-synchronous-main-loop/5436/28 (and the thread leading up to this comment).

In the thread, @njs states that if the user hits Ctrl-C while the asyncio event loop is running, it's possible for internal asyncio data structures to end up in an inconsistent state. If that's the case, then this would make asyncio-based code unreliable in real-world use.

I don't have a way to reproduce this - from the Discourse thread, I had assumed that ctrl-C was safe to use on an asyncio-based program, but was told otherwise, and I can't find anything definitive either way.

At a minimum, the asyncio documentation should confirm that it is exception-safe (specifically against Ctrl-C, but in general I'd assume that asyncio is safe in the face of uncaught exceptions in user-written async code).

----------
components: asyncio
messages: 383370
nosy: asvetlov, paul.moore, yselivanov
priority: normal
severity: normal
status: open
title: asyncio should handle keyboard interrupt while the event loop is running
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42683>
_______________________________________

From report at bugs.python.org  Sat Dec 19 06:27:02 2020
From: report at bugs.python.org (Paul Moore)
Date: Sat, 19 Dec 2020 11:27:02 +0000
Subject: [issue42683] asyncio should handle keyboard interrupt while the event
 loop is running
In-Reply-To: <1608377188.51.0.0510456786918.issue42683@roundup.psfhosted.org>
Message-ID: <1608377222.97.0.44931636184.issue42683@roundup.psfhosted.org>


Change by Paul Moore <p.f.moore at gmail.com>:


----------
nosy: +njs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42683>
_______________________________________

From report at bugs.python.org  Sat Dec 19 06:39:21 2020
From: report at bugs.python.org (FX Coudert)
Date: Sat, 19 Dec 2020 11:39:21 +0000
Subject: [issue42480] Python Tkinter crashes on macOS 11.1 beta
In-Reply-To: <1606468409.23.0.371615995189.issue42480@roundup.psfhosted.org>
Message-ID: <1608377961.71.0.398409913772.issue42480@roundup.psfhosted.org>


FX Coudert <fxcoudert at gmail.com> added the comment:

Hi, Homebrew developer here, we're seeing this with macOS 11.1 and I think it's not a python issue but an Apple's Tcl/Tk issue. The backtrace I have is:

0   libsystem_kernel.dylib        	0x00007fff2031f462 __pthread_kill + 10
1   libsystem_pthread.dylib       	0x00007fff2034d610 pthread_kill + 263
2   libsystem_c.dylib             	0x00007fff202a0720 abort + 120
3   Tcl                           	0x00007fff6fe1eb55 Tcl_PanicVA + 398
4   Tcl                           	0x00007fff6fe1ebd5 Tcl_Panic + 128
5   Tk                            	0x00007fff6ff1ead5 TkpInit + 385
6   Tk                            	0x00007fff6fe9e788 0x7fff6fe6d000 + 202632
7   _tkinter.cpython-39-darwin.so 	0x0000000102d2d701 Tcl_AppInit + 84
8   _tkinter.cpython-39-darwin.so 	0x0000000102d289fa _tkinter_create + 975
9   org.python.python             	0x00000001027251bb cfunction_vectorcall_FASTCALL + 203
10  org.python.python             	0x000000010279cff3 call_function + 403
11  org.python.python             	0x000000010279a184 _PyEval_EvalFrameDefault + 27452
12  org.python.python             	0x000000010279db3b _PyEval_EvalCode + 1998
13  org.python.python             	0x00000001026f55d8 _PyFunction_Vectorcall + 248
14  org.python.python             	0x00000001026f4e67 _PyObject_FastCallDictTstate + 212
15  org.python.python             	0x00000001026f5891 _PyObject_Call_Prepend + 139
16  org.python.python             	0x000000010273de96 slot_tp_init + 87
17  org.python.python             	0x00000001027376f7 type_call + 150
18  org.python.python             	0x00000001026f4fa3 _PyObject_MakeTpCall + 266
19  org.python.python             	0x000000010279d027 call_function + 455
20  org.python.python             	0x000000010279a184 _PyEval_EvalFrameDefault + 27452
21  org.python.python             	0x000000010279db3b _PyEval_EvalCode + 1998
22  org.python.python             	0x000000010279356d PyEval_EvalCode + 79
23  org.python.python             	0x00000001027ce5b5 run_eval_code_obj + 110
24  org.python.python             	0x00000001027cd9ad run_mod + 103
25  org.python.python             	0x00000001027cc9dc PyRun_StringFlags + 182
26  org.python.python             	0x00000001027cc8e9 PyRun_SimpleStringFlags + 69
27  org.python.python             	0x00000001027e3802 Py_RunMain + 425
28  org.python.python             	0x00000001027e40c1 pymain_main + 306
29  org.python.python             	0x00000001027e410f Py_BytesMain + 42

This seems confirmed by the fact that I can reproduce with Apple's own python:

$ /usr/bin/python3 
Python 3.8.2 (default, Nov  4 2020, 21:23:28) 
[Clang 12.0.0 (clang-1200.0.32.28)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import tkinter
>>> root = tkinter.Tk()
macOS 11 or later required !
zsh: abort      /usr/bin/python3

I will file a bug report with Apple.

----------
nosy: +fxcoudert

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42480>
_______________________________________

From report at bugs.python.org  Sat Dec 19 06:40:13 2020
From: report at bugs.python.org (Austin Scola)
Date: Sat, 19 Dec 2020 11:40:13 +0000
Subject: [issue42572] Better path handling with argparse
In-Reply-To: <1607121735.85.0.926277593776.issue42572@roundup.psfhosted.org>
Message-ID: <1608378013.65.0.962287063669.issue42572@roundup.psfhosted.org>


Austin Scola <austinscola at gmail.com> added the comment:

Thank you Raymond! I learned a few things by reading the proposed documentation updates.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42572>
_______________________________________

From report at bugs.python.org  Sat Dec 19 06:46:20 2020
From: report at bugs.python.org (Steve Dower)
Date: Sat, 19 Dec 2020 11:46:20 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1608378380.42.0.0972167849935.issue42529@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> Everything succeeds, then we get an extra successful request for FlsFree then it immediately returns with a fail.

That makes it sound like the CRT is uninitialising itself, so this may be a conflict between statically linked vcruntime140.dll and dynamically linked. More likely to occur with msvcp140.dll in the mix, since CPython does not include it.

I'm not seeing full paths for the dependent DLLs, so I have no way to know whether it's mixing and matching versions. CPython installs include vcruntime140.dll, which should be the one loaded by python.exe. However, there are some extension modules that statically link what is required from it, and that should lead to multiple FLS calls when the embedded CRT initialises/uninitialises its state. That will happen during DLL load, but normally fails with a more obvious error than what you're getting.

However, if you've got a different version msvcp140.dll, it might be managing to load a mismatched vcruntime140.dll. Or something that's happening during initialisation (which should include C++ stuff) is failing in a way that doesn't bubble out properly.

Looking through "C:\Program Files (x86)\Windows Kits\10\Source\10.0.19041.0\ucrt\internal\initialization.cpp" (on my machine at least, yours may be different), there's *a lot* that could fail.

If you're able to coerce a _jpype build that links to vcruntime140d.dll/msvcp140d.dll (the debug versions, typically specified with /MDd instead of /MD to the compiler - might require patching setuptools though), and use a CPython debug build, you may get a more informative failure. If not, I can try and find someone from the C++ libraries team at Microsoft to help out, but that's not going to happen until early January at this point of the year.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Sat Dec 19 06:53:51 2020
From: report at bugs.python.org (Steve Dower)
Date: Sat, 19 Dec 2020 11:53:51 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1608378831.13.0.720984323616.issue42529@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

Looking at the winapi_thunks.cpp source file from the CRT, it may be that LCIDToLocaleName is failing to be loaded for some reason. That's the one that comes after LCMapStringEx, so if it's failing, that could abort the whole process.

Alternatively, LCMapStringEx might be being called immediately after loading it and failing, which would explain why we don't see a failed LoadLibrary entry (which I'd expect if we're just loading lots of entry points here). I don't see any calls in the CRT itself, so perhaps during initialization of something in the C++ runtime? Might be due to your locale settings?

More ideas than answers, I'm afraid.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Sat Dec 19 07:11:35 2020
From: report at bugs.python.org (William Pickard)
Date: Sat, 19 Dec 2020 12:11:35 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1608379895.01.0.422819495944.issue42529@roundup.psfhosted.org>


William Pickard <lollol222gg at gmail.com> added the comment:

Msvcp140.dll from what I can find is part of the VS 2015 Redstributable package.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Sat Dec 19 07:11:59 2020
From: report at bugs.python.org (FX Coudert)
Date: Sat, 19 Dec 2020 12:11:59 +0000
Subject: [issue42480] Python Tkinter crashes on macOS 11.1 beta
In-Reply-To: <1606468409.23.0.371615995189.issue42480@roundup.psfhosted.org>
Message-ID: <1608379919.35.0.252755911075.issue42480@roundup.psfhosted.org>


FX Coudert <fxcoudert at gmail.com> added the comment:

Reported to Apple as FB8945560

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42480>
_______________________________________

From report at bugs.python.org  Sat Dec 19 07:40:55 2020
From: report at bugs.python.org (Ivo Shipkaliev)
Date: Sat, 19 Dec 2020 12:40:55 +0000
Subject: [issue42672] tkinter/__init__.py raises a NameError if NoDefaultRoot()
In-Reply-To: <1608367386.14.0.0446530971309.issue42672@roundup.psfhosted.org>
Message-ID: <1608381655.35.0.365360709811.issue42672@roundup.psfhosted.org>


Ivo Shipkaliev <ivo.shipkaliev at gmail.com> added the comment:

Thank you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42672>
_______________________________________

From report at bugs.python.org  Sat Dec 19 07:51:17 2020
From: report at bugs.python.org (Antony Lee)
Date: Sat, 19 Dec 2020 12:51:17 +0000
Subject: [issue42684] Improvements to documentation for PyUnicode_FS{Converter, 
 Decoder}
Message-ID: <1608382277.1.0.605007079577.issue42684@roundup.psfhosted.org>


New submission from Antony Lee <anntzer.lee at gmail.com>:

The docs for PyUnicode_FSConverter and PyUnicode_FSDecoder could be improved on two points:

- The functions also reject str/bytes that contain null bytes (one can easily verify that there's a specific check for them in the C implementations).  Currently the docs only say that the converters use PyUnicode_EncodeFSDefault/PyUnicode_DecodeFSDefaultAndSize, but those don't check for null bytes.

- The functions only ever return 1 or 0 (indicating success or failures), which means that one can just use e.g. `if (!PyUnicode_FSConverter(foo, &bar)) { goto error; } ...` (this pattern occurs repeatedly in the CPython codebase).  In theory, given that the functions are only documented as being "O&"-converters, they could also be returning Py_CLEANUP_SUPPORTED in which case they'd need to be called a second time on failure to release allocated memory.

----------
assignee: docs at python
components: C API, Documentation
messages: 383378
nosy: Antony.Lee, docs at python
priority: normal
severity: normal
status: open
title: Improvements to documentation for PyUnicode_FS{Converter,Decoder}

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42684>
_______________________________________

From report at bugs.python.org  Sat Dec 19 08:07:55 2020
From: report at bugs.python.org (Christopher A. Chavez)
Date: Sat, 19 Dec 2020 13:07:55 +0000
Subject: [issue42122] macOS complains about how fonts are accessed
In-Reply-To: <1603409230.0.0.859933553088.issue42122@roundup.psfhosted.org>
Message-ID: <1608383275.84.0.578826382099.issue42122@roundup.psfhosted.org>


Christopher A. Chavez <chrischavez at gmx.us> added the comment:

This was already reported to Tcl/Tk: https://core.tcl-lang.org/tk/info/855049e799 . They determined it was caused by a bug in macOS 10.15.1. There are workarounds implemented for this in Tcl/Tk 8.6.10 and the upcoming 8.6.11 releases.

----------
nosy: +chrstphrchvz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42122>
_______________________________________

From report at bugs.python.org  Sat Dec 19 09:38:20 2020
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sat, 19 Dec 2020 14:38:20 +0000
Subject: [issue42655] Fix subprocess extra_groups gid conversion
In-Reply-To: <1608113122.79.0.244683118693.issue42655@roundup.psfhosted.org>
Message-ID: <1608388700.55.0.947525296182.issue42655@roundup.psfhosted.org>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

This bug would have been caught at compile time if `_Py_Gid_Converter()` used `gid_t *` instead of `void *`. I couldn't find any call sites where `void *` would be needed, so probably `_Py_Gid_Converter()` should be fixed too (in a separate PR/issue?). The same applies to `_Py_Uid_Converter()`.

----------
nosy: +gregory.p.smith, izbyshev

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42655>
_______________________________________

From report at bugs.python.org  Sat Dec 19 09:38:52 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Dec 2020 14:38:52 +0000
Subject: [issue42630] Variable.__init__ raises obscure AttributeError
In-Reply-To: <1607901840.62.0.626631020476.issue42630@roundup.psfhosted.org>
Message-ID: <1608388732.93.0.19788848776.issue42630@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 80c445cafbdfb16c4a882e3ff6fe28b471aacdfc by Serhiy Storchaka in branch '3.8':
[3.8] bpo-42630: Improve error reporting in Tkinter for absent default root (GH-23781) (GH-23854)
https://github.com/python/cpython/commit/80c445cafbdfb16c4a882e3ff6fe28b471aacdfc


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42630>
_______________________________________

From report at bugs.python.org  Sat Dec 19 09:58:46 2020
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Blondon?=)
Date: Sat, 19 Dec 2020 14:58:46 +0000
Subject: [issue41724] SQLite returns "str" instead of "datetime.datetime" with
 aggregate queries.
In-Reply-To: <1599287033.27.0.142696776365.issue41724@roundup.psfhosted.org>
Message-ID: <1608389926.86.0.74402356514.issue41724@roundup.psfhosted.org>


Change by St?phane Blondon <stephane.blondon at gmail.com>:


----------
keywords: +patch
nosy: +sblondon
nosy_count: 5.0 -> 6.0
pull_requests: +22720
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23855

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41724>
_______________________________________

From report at bugs.python.org  Sat Dec 19 10:29:47 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Dec 2020 15:29:47 +0000
Subject: [issue42685] Improve placing of simple query windows.
Message-ID: <1608391787.71.0.662938082611.issue42685@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Currently simple query windows in Tkinter (such as tkinter.simpledialog.askinteger()) are placed at position 50 pixels right and 50 pixels below of the top left corner of the parent widget (even if it is not visible). If the parent is not specified, the initial position was determined by a windows manager before issue1538878, after issue1538878 it was placed at position 50 pixels right and 50 pixels below the default root widget (even if it is not visible).

Issue42630 restored the pre-issue1538878 behavior, but it is still has many quirks.

The proposed patch makes the placing algorithm similar to native Tk dialogs.

* If parent is specified and mapped, the query widget is centered at the center of parent. Its position and size can be corrected so that it fits in the virtual root window.
* Otherwise it is centered at the center of the screen.

----------
components: Tkinter
messages: 383382
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Improve placing of simple query windows.
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42685>
_______________________________________

From report at bugs.python.org  Sat Dec 19 10:32:41 2020
From: report at bugs.python.org (Big Stone)
Date: Sat, 19 Dec 2020 15:32:41 +0000
Subject: [issue42686] include built-in Math functions in SQLite to 3.35.0 of
 march 2021
Message-ID: <1608391961.58.0.717857253057.issue42686@roundup.psfhosted.org>


New submission from Big Stone <stonebig34 at gmail.com>:

SQlite-3.35.0 of mach 2021 will have Built-In Math Functions option.

https://sqlite.org/draft/releaselog/3_35_0.html

Would it be possible to have it activated in the following versions update of Python ? It's pretty usefull for some basic statistics

----------
messages: 383383
nosy: Big Stone
priority: normal
severity: normal
status: open
title: include built-in Math functions in SQLite to 3.35.0 of march 2021
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42686>
_______________________________________

From report at bugs.python.org  Sat Dec 19 10:36:12 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Dec 2020 15:36:12 +0000
Subject: [issue42685] Improve placing of simple query windows.
In-Reply-To: <1608391787.71.0.662938082611.issue42685@roundup.psfhosted.org>
Message-ID: <1608392172.21.0.189360455672.issue42685@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +22721
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23856

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42685>
_______________________________________

From report at bugs.python.org  Sat Dec 19 10:36:43 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Dec 2020 15:36:43 +0000
Subject: [issue42630] Variable.__init__ raises obscure AttributeError
In-Reply-To: <1607901840.62.0.626631020476.issue42630@roundup.psfhosted.org>
Message-ID: <1608392203.73.0.847491661396.issue42630@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/issue42630>
_______________________________________

From report at bugs.python.org  Sat Dec 19 10:46:27 2020
From: report at bugs.python.org (Erik Soma)
Date: Sat, 19 Dec 2020 15:46:27 +0000
Subject: [issue42687] tokenize module does not recognize Barry as FLUFL
Message-ID: <1608392787.93.0.861284496438.issue42687@roundup.psfhosted.org>


New submission from Erik Soma <stillusingirc at gmail.com>:

'<>' is not recognized by the tokenize module as a single token, instead it is two tokens.

```
$ python -c "import tokenize; import io; import pprint; pprint.pprint(list(tokenize.tokenize(io.BytesIO(b'<>').readline)))"
[TokenInfo(type=62 (ENCODING), string='utf-8', start=(0, 0), end=(0, 0), line=''),
 TokenInfo(type=54 (OP), string='<', start=(1, 0), end=(1, 1), line='<>'),
 TokenInfo(type=54 (OP), string='>', start=(1, 1), end=(1, 2), line='<>'),
 TokenInfo(type=4 (NEWLINE), string='', start=(1, 2), end=(1, 3), line=''),
 TokenInfo(type=0 (ENDMARKER), string='', start=(2, 0), end=(2, 0), line='')]
```


I would expect:
```
[TokenInfo(type=62 (ENCODING), string='utf-8', start=(0, 0), end=(0, 0), line=''),
 TokenInfo(type=54 (OP), string='<>', start=(1, 0), end=(1, 2), line='<>'),
 TokenInfo(type=4 (NEWLINE), string='', start=(1, 2), end=(1, 3), line=''),
 TokenInfo(type=0 (ENDMARKER), string='', start=(2, 0), end=(2, 0), line='')]
```

This is the behavior of the CPython tokenizer which the tokenizer module tries "to match the working of".

----------
messages: 383384
nosy: esoma
priority: normal
severity: normal
status: open
title: tokenize module does not recognize Barry as FLUFL
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42687>
_______________________________________

From report at bugs.python.org  Sat Dec 19 11:01:57 2020
From: report at bugs.python.org (Erik Soma)
Date: Sat, 19 Dec 2020 16:01:57 +0000
Subject: [issue42687] tokenize module does not recognize Barry as FLUFL
In-Reply-To: <1608392787.93.0.861284496438.issue42687@roundup.psfhosted.org>
Message-ID: <1608393717.31.0.397468826783.issue42687@roundup.psfhosted.org>


Change by Erik Soma <stillusingirc at gmail.com>:


----------
keywords: +patch
pull_requests: +22722
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23857

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42687>
_______________________________________

From report at bugs.python.org  Sat Dec 19 11:10:28 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 19 Dec 2020 16:10:28 +0000
Subject: [issue42681] mistake in curses documentation
In-Reply-To: <1608339537.48.0.496910027234.issue42681@roundup.psfhosted.org>
Message-ID: <1608394228.46.0.379115082673.issue42681@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

Please explain why you believe this is a mistake.

----------
nosy: +ZackerySpytz

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42681>
_______________________________________

From report at bugs.python.org  Sat Dec 19 11:21:14 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 19 Dec 2020 16:21:14 +0000
Subject: [issue42686] include built-in Math functions in SQLite to 3.35.0 of
 march 2021
In-Reply-To: <1608391961.58.0.717857253057.issue42686@roundup.psfhosted.org>
Message-ID: <1608394874.57.0.941738701478.issue42686@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

As far as I can tell, every one of those are already available in Python.

https://docs.python.org/3/library/math.html

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42686>
_______________________________________

From report at bugs.python.org  Sat Dec 19 11:53:04 2020
From: report at bugs.python.org (mattip)
Date: Sat, 19 Dec 2020 16:53:04 +0000
Subject: [issue42604] EXT_SUFFIX too short on FreeBSD and AIX
In-Reply-To: <1607464402.35.0.336960410788.issue42604@roundup.psfhosted.org>
Message-ID: <1608396784.12.0.208191288292.issue42604@roundup.psfhosted.org>


mattip <matti.picus at gmail.com> added the comment:

The linked PR 23708 is meant to fix the failures. Any chance you can take a look?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42604>
_______________________________________

From report at bugs.python.org  Sat Dec 19 11:57:49 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 19 Dec 2020 16:57:49 +0000
Subject: [issue42683] asyncio should handle keyboard interrupt while the event
 loop is running
In-Reply-To: <1608377188.51.0.0510456786918.issue42683@roundup.psfhosted.org>
Message-ID: <1608397069.24.0.661555970156.issue42683@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42683>
_______________________________________

From report at bugs.python.org  Sat Dec 19 12:29:08 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Dec 2020 17:29:08 +0000
Subject: [issue40219] ttk LabeledScale: label covered by hidden element
In-Reply-To: <1586292175.49.0.452846630354.issue40219@roundup.psfhosted.org>
Message-ID: <1608398948.91.0.20191622061.issue40219@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 6ad5fd14825fc6039a9684dfdc14f5d12b86e25f by Miss Islington (bot) in branch '3.9':
bpo-40219: Lowered ttk LabeledScale dummy (GH-21467) (GH-23788)
https://github.com/python/cpython/commit/6ad5fd14825fc6039a9684dfdc14f5d12b86e25f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40219>
_______________________________________

From report at bugs.python.org  Sat Dec 19 12:29:36 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Dec 2020 17:29:36 +0000
Subject: [issue40219] ttk LabeledScale: label covered by hidden element
In-Reply-To: <1586292175.49.0.452846630354.issue40219@roundup.psfhosted.org>
Message-ID: <1608398976.03.0.906727620738.issue40219@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/issue40219>
_______________________________________

From report at bugs.python.org  Sat Dec 19 12:31:30 2020
From: report at bugs.python.org (Karl Nelson)
Date: Sat, 19 Dec 2020 17:31:30 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1608360034.67.0.00944560349466.issue42529@roundup.psfhosted.org>
Message-ID: <SJ0PR09MB740695D3B85744D18FCE799DB0C20@SJ0PR09MB7406.namprd09.prod.outlook.com>


Karl Nelson <nelson85 at llnl.gov> added the comment:

Eryk,

Unfortunately, this particular bug is resistant to attaching the debugger.  Whenever the debugger is attached the bug disappears.   Fortunately the suggestion to use Detours by WildCard65 appears to offer a way to diagnose the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Sat Dec 19 12:44:36 2020
From: report at bugs.python.org (Karl Nelson)
Date: Sat, 19 Dec 2020 17:44:36 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1608399876.05.0.0283384493265.issue42529@roundup.psfhosted.org>


Karl Nelson <nelson85 at llnl.gov> added the comment:

I looked more at the logs to see if I can find out what to instrument next.   The log files unfortunately don't diff well because every line contains a timestamp so I can't a proper alignment as well as all the real addresses.  So I wrote a short program to convert all the numbers into an "X".

After doing so I find there is a single difference in the process between loading from a py file and a pyc file.


##### import _jpype
## Only if loaded from a Py file
trclnk64: 001 GetProcAddress(7ffc4c710000,FlsGetValue)
X X X trclnk64: 001 GetProcAddress(,) -> X
## All
X X X trclnk64: 001 LoadLibraryExW(C:\Users\nelson85\AppData\Local\Programs\Python\Python39\python3,0,1000)
X X X trclnk64: 001 LoadLibraryExW(,,) -> X
X X X trclnk64: ### X C:\Users\nelson85\AppData\Local\Programs\Python\Python39\python3.DLL 000140bc
####  So here is the call that fails....
X X X trclnk64: 001 LoadLibraryExW(c:\users\nelson85\documents\devel\open\jpype\_jpype.cp39-win_amd64.pyd,0,1100)
X X X trclnk64: 001 LoadLibraryExW(api-ms-win-core-synch-l1-2-0,0,800)
X X X trclnk64: 001 LoadLibraryExW(,,) -> X
X X X trclnk64: ### X C:\WINDOWS\System32\KERNELBASE.dll 002b306b
X X X trclnk64: ntdll.dll [7ffc4c974138 X

So the problem is something that happened before the LoadLibraryExW call when python3.dll was accessed.  The correct path called FlsGetValue  while the incorrect one skipped it which lead to a failure.

Thus my conclusion is that the vehicle left the edge of the cliff just prior to LoadLibraryExW(_jpype) and hit the ocean when C++ runtime library was requested.

Does that point to anything we can use to solve this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Sat Dec 19 12:46:05 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Dec 2020 17:46:05 +0000
Subject: [issue39171] Missing default root in tkinter simpledialog.py
In-Reply-To: <1577780147.06.0.429247944585.issue39171@roundup.psfhosted.org>
Message-ID: <1608399965.51.0.871310375556.issue39171@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It is addressed in issue42630. Now a RuntimeError with relevant error message is raised when call askinteger() without explicit parent if there is no default root widget.

Autocreating a top-level root window is not good idea. It pops up an empty window with default size and title and left it open after closing the dialog window. If withdraw it right after creation, it would look less weird, but it may break the following code which calls Tk() and expects it to be set as a default root window.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39171>
_______________________________________

From report at bugs.python.org  Sat Dec 19 12:47:23 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Dec 2020 17:47:23 +0000
Subject: [issue38661] Changes to tkinter result in (unexpected) widget map
 call return changes wrt. 3.7
In-Reply-To: <1572618747.95.0.320564330748.issue38661@roundup.psfhosted.org>
Message-ID: <1608400043.96.0.186778890436.issue38661@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38661>
_______________________________________

From report at bugs.python.org  Sat Dec 19 12:47:47 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Dec 2020 17:47:47 +0000
Subject: [issue19733] Setting image parameter of a button crashes with Cocoa Tk
In-Reply-To: <1385212186.78.0.599244063108.issue19733@psf.upfronthosting.co.za>
Message-ID: <1608400067.58.0.492271062145.issue19733@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/issue19733>
_______________________________________

From report at bugs.python.org  Sat Dec 19 12:49:00 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Dec 2020 17:49:00 +0000
Subject: [issue19733] Setting image parameter of a button crashes with Cocoa Tk
In-Reply-To: <1385212186.78.0.599244063108.issue19733@psf.upfronthosting.co.za>
Message-ID: <1608400140.62.0.836129011198.issue19733@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for tracking it Ronald. Could this issue be closed now?

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19733>
_______________________________________

From report at bugs.python.org  Sat Dec 19 12:50:15 2020
From: report at bugs.python.org (William Pickard)
Date: Sat, 19 Dec 2020 17:50:15 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1608400215.53.0.948623936115.issue42529@roundup.psfhosted.org>


William Pickard <lollol222gg at gmail.com> added the comment:

I recommend first doing a capture of these functions first, incase Windows is routing some through them:

LoadLibrary(Ex)(W|A)

W is the Unicode variant while A is the Ascii variant.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Sat Dec 19 13:57:36 2020
From: report at bugs.python.org (Steve Dower)
Date: Sat, 19 Dec 2020 18:57:36 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1608404256.83.0.0125763381934.issue42529@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

> I recommend first doing a capture of these functions first

I don't think that'll be necessary - the logging output ought to be enough. Capturing or redirecting those functions would be great if the debugger was working, but since that spoils it, it's not.

> Does that point to anything we can use to solve this?

It would be great to know what's calling FlsGetValue there. Obviously something within the CRT, since CPython doesn't use fibers anywhere. I guess it's probably some kind of locale settings that are only necessary when opening a file in text mode? But I don't know that we do that specially here.

Is there an option to capture full stack traces?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Sat Dec 19 14:19:03 2020
From: report at bugs.python.org (Karl Nelson)
Date: Sat, 19 Dec 2020 19:19:03 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1608405543.16.0.153210429295.issue42529@roundup.psfhosted.org>


Karl Nelson <nelson85 at llnl.gov> added the comment:

I will look through the list of samples in Detours to see if there is something that can give us better stacktrace information.   If we really need a stack trace I can make Detours bust by creating an intentional segfault and see if we can attach the debugger after the source of the problem has been triggered.  Unfortunately as my windows programming knowledge is all from 1994 I may be missing something obvious.

In the meantime I am upgrading the sample with some more hooks for any other potential LoadLibrary variants and FlsGetValue.  Though given the GetProcAddress calls I think that it must be something in the chain leading up so the variants are likely not envolved.

The other thing I can do is look at instrumenting SetErrorMode so that I can give myself a marker of when we are entering and leaving the dyload code.

```

        /* Don't display a message box when Python can't load a DLL */
        old_mode = SetErrorMode(SEM_FAILCRITICALERRORS);

        /* bpo-36085: We use LoadLibraryEx with restricted search paths
           to avoid DLL preloading attacks and enable use of the
           AddDllDirectory function. We add SEARCH_DLL_LOAD_DIR to
           ensure DLLs adjacent to the PYD are preferred. */
        Py_BEGIN_ALLOW_THREADS
        hDLL = LoadLibraryExW(wpathname, NULL,
                              LOAD_LIBRARY_SEARCH_DEFAULT_DIRS |
                              LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR);
        Py_END_ALLOW_THREADS
#if !USE_UNICODE_WCHAR_CACHE
        PyMem_Free(wpathname);
#endif /* USE_UNICODE_WCHAR_CACHE */

        /* restore old error mode settings */
        SetErrorMode(old_mode);
```

I will post back once I get some results.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Sat Dec 19 14:33:50 2020
From: report at bugs.python.org (Irit Katriel)
Date: Sat, 19 Dec 2020 19:33:50 +0000
Subject: [issue3722] print followed by exception eats print with doctest
In-Reply-To: <1220007253.68.0.614144600028.issue3722@psf.upfronthosting.co.za>
Message-ID: <1608406430.74.0.911674877117.issue3722@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
keywords: +easy -patch
versions: +Python 3.10 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3722>
_______________________________________

From report at bugs.python.org  Sat Dec 19 14:49:12 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Dec 2020 19:49:12 +0000
Subject: [issue42681] mistake in curses documentation
In-Reply-To: <1608339537.48.0.496910027234.issue42681@roundup.psfhosted.org>
Message-ID: <1608407352.5.0.246202353659.issue42681@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42681>
_______________________________________

From report at bugs.python.org  Sat Dec 19 14:50:55 2020
From: report at bugs.python.org (Thomas Nabelek)
Date: Sat, 19 Dec 2020 19:50:55 +0000
Subject: [issue42677] Support comments in argparse fromfile_prefix_chars files
In-Reply-To: <1608318945.24.0.0639471792025.issue42677@roundup.psfhosted.org>
Message-ID: <1608407455.09.0.507401847478.issue42677@roundup.psfhosted.org>


Thomas Nabelek <nabelekt at gmail.com> added the comment:

While overloading convert_arg_line_to_args may work, I think that @file reading is kind of the odd ball out in not recognizing '#' as the beginning of a comment.

Besides, I'm not sure that overloading just convert_arg_line_to_args is sufficient. Here is what I have:


import argparse
import re


class ArgumentParserCustom(argparse.ArgumentParser):
    
    def convert_arg_line_to_args(self, arg_line):
    
        if re.match(r'(\s+)?#', arg_line):  # Look for any number of whitespace characters up to a `#` character
            return ['']
        else:
            return [arg_line]


If I return [''], I get:
  "error: unrecognized arguments:".

If I return [None], I get:
  File "C:\Users\tnabelek\AppData\Local\Programs\Python\Python38-32\lib\argparse.py", line 1771, in parse_args
    self.error(msg % ' '.join(argv))
TypeError: sequence item 0: expected str instance, NoneType found


Is there a better solution?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42677>
_______________________________________

From report at bugs.python.org  Sat Dec 19 14:53:36 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 19 Dec 2020 19:53:36 +0000
Subject: [issue42677] Support comments in argparse fromfile_prefix_chars files
In-Reply-To: <1608318945.24.0.0639471792025.issue42677@roundup.psfhosted.org>
Message-ID: <1608407616.59.0.391002608536.issue42677@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Have you tried returning an empty list?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42677>
_______________________________________

From report at bugs.python.org  Sat Dec 19 14:56:28 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Dec 2020 19:56:28 +0000
Subject: [issue9694] argparse required arguments displayed under "optional
 arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1608407788.31.0.917615807525.issue9694@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
Removed message: https://bugs.python.org/msg374042

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9694>
_______________________________________

From report at bugs.python.org  Sat Dec 19 14:58:42 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Dec 2020 19:58:42 +0000
Subject: [issue9694] argparse required arguments displayed under "optional
 arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1608407922.78.0.163145318987.issue9694@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


Added file: https://bugs.python.org/file49692/argparse_optional.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9694>
_______________________________________

From report at bugs.python.org  Sat Dec 19 14:59:21 2020
From: report at bugs.python.org (Thomas Nabelek)
Date: Sat, 19 Dec 2020 19:59:21 +0000
Subject: [issue42677] Support comments in argparse fromfile_prefix_chars files
In-Reply-To: <1608318945.24.0.0639471792025.issue42677@roundup.psfhosted.org>
Message-ID: <1608407961.87.0.237264972627.issue42677@roundup.psfhosted.org>


Thomas Nabelek <nabelekt at gmail.com> added the comment:

Oh, yes, returning [] does work. Thanks guys.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42677>
_______________________________________

From report at bugs.python.org  Sat Dec 19 15:08:57 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Dec 2020 20:08:57 +0000
Subject: [issue9694] argparse required arguments displayed under "optional
 arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1608408537.8.0.721378977862.issue9694@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Based on the attached survey of practices, I propose a minimal edit to the help display.  Instead of "optional arguments:", we say "the options are as follows:".

The use of the word "option" is dominant is in the CLI world, followed by "action" and "switch".  The noun form "option" doesn't seem to cause the same confusion that arises in the adjective form "optional arguments" which strongly implies "not required".

For the documentation, I suggest adding a sentence or two in the introduction to explain the terminology used throughout the rest of the argparse docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9694>
_______________________________________

From report at bugs.python.org  Sat Dec 19 15:09:46 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Dec 2020 20:09:46 +0000
Subject: [issue9694] argparse required arguments displayed under "optional
 arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1608408586.27.0.3237792316.issue9694@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
components: +Documentation
type: enhancement -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9694>
_______________________________________

From report at bugs.python.org  Sat Dec 19 15:14:27 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Dec 2020 20:14:27 +0000
Subject: [issue29030] argparse: choices override metavar
In-Reply-To: <1482281546.0.0.613026945443.issue29030@psf.upfronthosting.co.za>
Message-ID: <1608408867.59.0.693710109462.issue29030@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
components: +Documentation -Library (Lib)
versions: +Python 3.10, Python 3.9 -Python 2.7, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29030>
_______________________________________

From report at bugs.python.org  Sat Dec 19 15:26:32 2020
From: report at bugs.python.org (Irit Katriel)
Date: Sat, 19 Dec 2020 20:26:32 +0000
Subject: [issue26003] Issues with PyEval_InitThreads and PyGILState_Ensure
In-Reply-To: <1451847866.91.0.926666566382.issue26003@psf.upfronthosting.co.za>
Message-ID: <1608409592.95.0.412103874778.issue26003@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

Since PyEval_InitThreads is now an empty function and to be removed, this issue seems out of date. A I right?

----------
nosy: +iritkatriel
resolution:  -> out of date
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26003>
_______________________________________

From report at bugs.python.org  Sat Dec 19 15:34:04 2020
From: report at bugs.python.org (Thomas Nabelek)
Date: Sat, 19 Dec 2020 20:34:04 +0000
Subject: [issue42677] Support comments in argparse fromfile_prefix_chars files
In-Reply-To: <1608318945.24.0.0639471792025.issue42677@roundup.psfhosted.org>
Message-ID: <1608410044.92.0.155379670425.issue42677@roundup.psfhosted.org>


Thomas Nabelek <nabelekt at gmail.com> added the comment:

For anyone else, here is my implementation. I decided not to do anything to support comments on the same lines as arguments.


import argparse
import re

# Override argparse's convert_arg_line_to_args method to allow for comments and empty lines

class ArgumentParserCustom(argparse.ArgumentParser):
    
    def convert_arg_line_to_args(self, arg_line):
    
        if (re.match(r'^[\s]*#', arg_line) or   # Look for any number of whitespace characters up to a `#` character
            re.match(r'^[\s]*$', arg_line)):  # Look for lines containing nothing or just whitespace
            return []
        else:
            return [arg_line]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42677>
_______________________________________

From report at bugs.python.org  Sat Dec 19 15:36:30 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Dec 2020 20:36:30 +0000
Subject: [issue9694] argparse required arguments displayed under "optional
 arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1608410190.57.0.986828803616.issue9694@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
pull_requests: +22723
pull_request: https://github.com/python/cpython/pull/23858

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9694>
_______________________________________

From report at bugs.python.org  Sat Dec 19 15:37:50 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Dec 2020 20:37:50 +0000
Subject: [issue9694] argparse required arguments displayed under "optional
 arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1608410270.59.0.593260115008.issue9694@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Since any chance to the help output will likely break tests, marking this as 3.10 only.

----------
components: +Library (Lib) -Documentation
versions:  -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9694>
_______________________________________

From report at bugs.python.org  Sat Dec 19 16:09:18 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 19 Dec 2020 21:09:18 +0000
Subject: [issue42681] mistake in curses documentation
In-Reply-To: <1608339537.48.0.496910027234.issue42681@roundup.psfhosted.org>
Message-ID: <1608412158.24.0.886401583216.issue42681@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Good catch! And it is not only documentation issue now. Since color numbers and pair numbers use different range checks, this prevents using this function with pair numbers larger that COLORS (should be accepted up to COLOR_PAIRS-1).

Seems there is also other bug which prevents using pair number 0 (constant white on black).

----------
assignee: docs at python -> serhiy.storchaka
components: +Library (Lib)
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42681>
_______________________________________

From report at bugs.python.org  Sat Dec 19 16:37:26 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 19 Dec 2020 21:37:26 +0000
Subject: [issue9694] argparse required arguments displayed under "optional
 arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1608413846.4.0.671043433526.issue9694@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I also like Eric'c suggestion of just using "options:" instead of "optional arguments".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9694>
_______________________________________

From report at bugs.python.org  Sat Dec 19 16:51:02 2020
From: report at bugs.python.org (Martin Burger)
Date: Sat, 19 Dec 2020 21:51:02 +0000
Subject: [issue9694] argparse required arguments displayed under "optional
 arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1608414662.41.0.318487317674.issue9694@roundup.psfhosted.org>


Change by Martin Burger <m at rtin-burger.net>:


----------
nosy:  -mburger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9694>
_______________________________________

From report at bugs.python.org  Sat Dec 19 17:06:32 2020
From: report at bugs.python.org (Steven Geerts)
Date: Sat, 19 Dec 2020 22:06:32 +0000
Subject: [issue30480] samefile and sameopenfile fail for WebDAV mapped drives
In-Reply-To: <1495788627.48.0.260495922264.issue30480@psf.upfronthosting.co.za>
Message-ID: <1608415592.55.0.197507305886.issue30480@roundup.psfhosted.org>


Steven Geerts <steven.geerts at gmail.com> added the comment:

still an issue with Python 3.8 and 3.9.
A copy between 2 files on webdave mapped drives can't be done, although src and dst are different.

----------
nosy: +steven.geerts
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30480>
_______________________________________

From report at bugs.python.org  Sat Dec 19 17:32:14 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 19 Dec 2020 22:32:14 +0000
Subject: [issue42675] Document changes made in bpo-42195
In-Reply-To: <1608309514.56.0.184586625269.issue42675@roundup.psfhosted.org>
Message-ID: <1608417134.45.0.797752165922.issue42675@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 597ebc8cf604de49eabbc7b83be2debd005d7819 by kj in branch '3.9':
[3.9] bpo-42675: Document collections.abc.Callable changes (GH-23839) (#23852)
https://github.com/python/cpython/commit/597ebc8cf604de49eabbc7b83be2debd005d7819


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42675>
_______________________________________

From report at bugs.python.org  Sat Dec 19 17:32:27 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 19 Dec 2020 22:32:27 +0000
Subject: [issue42675] Document changes made in bpo-42195
In-Reply-To: <1608309514.56.0.184586625269.issue42675@roundup.psfhosted.org>
Message-ID: <1608417147.49.0.947793621105.issue42675@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Can this be closed now?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42675>
_______________________________________

From report at bugs.python.org  Sat Dec 19 17:52:52 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 19 Dec 2020 22:52:52 +0000
Subject: [issue41724] SQLite returns "str" instead of "datetime.datetime" with
 aggregate queries.
In-Reply-To: <1599287033.27.0.142696776365.issue41724@roundup.psfhosted.org>
Message-ID: <1608418372.48.0.0971314291818.issue41724@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset 09a36cdfb7c22f44df45b44e5561776206bcedfb by sblondon in branch 'master':
bpo-41724: Explain when the conversion is not possible with detect_types enabled (GH-23855)
https://github.com/python/cpython/commit/09a36cdfb7c22f44df45b44e5561776206bcedfb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41724>
_______________________________________

From report at bugs.python.org  Sat Dec 19 17:53:18 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 19 Dec 2020 22:53:18 +0000
Subject: [issue41724] SQLite returns "str" instead of "datetime.datetime" with
 aggregate queries.
In-Reply-To: <1599287033.27.0.142696776365.issue41724@roundup.psfhosted.org>
Message-ID: <1608418398.63.0.150736177183.issue41724@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 6.0 -> 7.0
pull_requests: +22724
pull_request: https://github.com/python/cpython/pull/23862

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41724>
_______________________________________

From report at bugs.python.org  Sat Dec 19 17:53:26 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 19 Dec 2020 22:53:26 +0000
Subject: [issue41724] SQLite returns "str" instead of "datetime.datetime" with
 aggregate queries.
In-Reply-To: <1599287033.27.0.142696776365.issue41724@roundup.psfhosted.org>
Message-ID: <1608418406.98.0.763395258505.issue41724@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22725
pull_request: https://github.com/python/cpython/pull/23863

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41724>
_______________________________________

From report at bugs.python.org  Sat Dec 19 18:08:59 2020
From: report at bugs.python.org (paul j3)
Date: Sat, 19 Dec 2020 23:08:59 +0000
Subject: [issue37717] argparse subcommand docs has non-existent parameter
 "action"
In-Reply-To: <1564472681.57.0.734846453793.issue37717@roundup.psfhosted.org>
Message-ID: <1608419339.26.0.990625914822.issue37717@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

I'm closing the is as a duplicate of https://bugs.python.org/issue23487, which is already closed.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37717>
_______________________________________

From report at bugs.python.org  Sat Dec 19 19:02:38 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 20 Dec 2020 00:02:38 +0000
Subject: [issue41724] SQLite returns "str" instead of "datetime.datetime" with
 aggregate queries.
In-Reply-To: <1599287033.27.0.142696776365.issue41724@roundup.psfhosted.org>
Message-ID: <1608422558.91.0.0680956092246.issue41724@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset a34ab8188e0352e4066da4f79ed3cc24d1b61a63 by Miss Islington (bot) in branch '3.9':
bpo-41724: Explain when the conversion is not possible with detect_types enabled (GH-23855) (GH-23862)
https://github.com/python/cpython/commit/a34ab8188e0352e4066da4f79ed3cc24d1b61a63


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41724>
_______________________________________

From report at bugs.python.org  Sat Dec 19 19:03:02 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 20 Dec 2020 00:03:02 +0000
Subject: [issue41724] SQLite returns "str" instead of "datetime.datetime" with
 aggregate queries.
In-Reply-To: <1599287033.27.0.142696776365.issue41724@roundup.psfhosted.org>
Message-ID: <1608422582.19.0.339042276134.issue41724@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset 24862b02dfd1e2843727f28fa2ba05828fdfa8de by Miss Islington (bot) in branch '3.8':
bpo-41724: Explain when the conversion is not possible with detect_types enabled (GH-23855) (GH-23863)
https://github.com/python/cpython/commit/24862b02dfd1e2843727f28fa2ba05828fdfa8de


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41724>
_______________________________________

From report at bugs.python.org  Sat Dec 19 19:03:47 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 20 Dec 2020 00:03:47 +0000
Subject: [issue41724] SQLite returns "str" instead of "datetime.datetime" with
 aggregate queries.
In-Reply-To: <1599287033.27.0.142696776365.issue41724@roundup.psfhosted.org>
Message-ID: <1608422627.31.0.908003291269.issue41724@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> 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/issue41724>
_______________________________________

From report at bugs.python.org  Sat Dec 19 21:27:10 2020
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 20 Dec 2020 02:27:10 +0000
Subject: [issue29595] Expose max_queue_size in ThreadPoolExecutor
In-Reply-To: <1487369423.42.0.265838648983.issue29595@psf.upfronthosting.co.za>
Message-ID: <1608431230.63.0.447282539117.issue29595@roundup.psfhosted.org>


Change by Roundup Robot <devnull at psf.upfronthosting.co.za>:


----------
keywords: +patch
nosy: +python-dev
nosy_count: 8.0 -> 9.0
pull_requests: +22726
pull_request: https://github.com/python/cpython/pull/23864

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29595>
_______________________________________

From report at bugs.python.org  Sat Dec 19 21:40:45 2020
From: report at bugs.python.org (tianc777)
Date: Sun, 20 Dec 2020 02:40:45 +0000
Subject: [issue29595] Expose max_queue_size in ThreadPoolExecutor
In-Reply-To: <1487369423.42.0.265838648983.issue29595@psf.upfronthosting.co.za>
Message-ID: <1608432045.07.0.332297071007.issue29595@roundup.psfhosted.org>


Change by tianc777 <18702287721 at 163.com>:


----------
nosy: +tianc777
nosy_count: 9.0 -> 10.0
pull_requests: +22727
pull_request: https://github.com/python/cpython/pull/23865

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29595>
_______________________________________

From report at bugs.python.org  Sat Dec 19 21:57:06 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 20 Dec 2020 02:57:06 +0000
Subject: [issue42604] EXT_SUFFIX too short on FreeBSD and AIX
In-Reply-To: <1607464402.35.0.336960410788.issue42604@roundup.psfhosted.org>
Message-ID: <1608433026.21.0.995351658916.issue42604@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset a44ce6c9f725d336aea51a946b42769f29fed613 by Matti Picus in branch 'master':
bpo-42604: always set EXT_SUFFIX=${SOABI}${SHLIB_SUFFIX} when using configure (GH-23708)
https://github.com/python/cpython/commit/a44ce6c9f725d336aea51a946b42769f29fed613


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42604>
_______________________________________

From report at bugs.python.org  Sat Dec 19 21:57:22 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 20 Dec 2020 02:57:22 +0000
Subject: [issue42604] EXT_SUFFIX too short on FreeBSD and AIX
In-Reply-To: <1607464402.35.0.336960410788.issue42604@roundup.psfhosted.org>
Message-ID: <1608433042.09.0.0459656178677.issue42604@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22729
pull_request: https://github.com/python/cpython/pull/23867

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42604>
_______________________________________

From report at bugs.python.org  Sat Dec 19 21:57:13 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 20 Dec 2020 02:57:13 +0000
Subject: [issue42604] EXT_SUFFIX too short on FreeBSD and AIX
In-Reply-To: <1607464402.35.0.336960410788.issue42604@roundup.psfhosted.org>
Message-ID: <1608433033.78.0.642043439282.issue42604@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +22728
pull_request: https://github.com/python/cpython/pull/23866

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42604>
_______________________________________

From report at bugs.python.org  Sat Dec 19 22:17:49 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 20 Dec 2020 03:17:49 +0000
Subject: [issue42604] EXT_SUFFIX too short on FreeBSD and AIX
In-Reply-To: <1607464402.35.0.336960410788.issue42604@roundup.psfhosted.org>
Message-ID: <1608434269.55.0.27069423237.issue42604@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b01091a3e71e6636d2df4db45920e820cdf7df3b by Miss Islington (bot) in branch '3.8':
bpo-42604: always set EXT_SUFFIX=${SOABI}${SHLIB_SUFFIX} when using configure (GH-23708)
https://github.com/python/cpython/commit/b01091a3e71e6636d2df4db45920e820cdf7df3b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42604>
_______________________________________

From report at bugs.python.org  Sat Dec 19 22:38:24 2020
From: report at bugs.python.org (Ken Jin)
Date: Sun, 20 Dec 2020 03:38:24 +0000
Subject: [issue42675] Document changes made in bpo-42195
In-Reply-To: <1608309514.56.0.184586625269.issue42675@roundup.psfhosted.org>
Message-ID: <1608435504.5.0.225083668092.issue42675@roundup.psfhosted.org>


Change by Ken Jin <kenjin4096 at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42675>
_______________________________________

From report at bugs.python.org  Sat Dec 19 23:54:26 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 20 Dec 2020 04:54:26 +0000
Subject: [issue42604] EXT_SUFFIX too short on FreeBSD and AIX
In-Reply-To: <1607464402.35.0.336960410788.issue42604@roundup.psfhosted.org>
Message-ID: <1608440066.27.0.928861161741.issue42604@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset 4b155967b3e743cbdc31600f13f1bfcf07f7b6ce by Miss Islington (bot) in branch '3.9':
bpo-42604: always set EXT_SUFFIX=${SOABI}${SHLIB_SUFFIX} when using configure (GH-23708) (GH-23866)
https://github.com/python/cpython/commit/4b155967b3e743cbdc31600f13f1bfcf07f7b6ce


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42604>
_______________________________________

From report at bugs.python.org  Sat Dec 19 23:54:34 2020
From: report at bugs.python.org (Karl Nelson)
Date: Sun, 20 Dec 2020 04:54:34 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1608440074.98.0.406838264241.issue42529@roundup.psfhosted.org>


Karl Nelson <nelson85 at llnl.gov> added the comment:

Gave another series of shots at the problem.  So the reason that attaching the debugger fixes the issue is that it calls LoadLibraryExW for a bunch libraries when it attaches.  

I was also able to unconditionally trigger the bug even when loading without the pyc.   It appears that calling "import _ssh"  will cause whatever conflict is happening to trigger immediately.

Other than than progress was minimal.  Attaching the debugger causes so many changes to the control flow that I can't get the bad path to trigger and I can't get the debugger to attach once you start down the path.   I tried creating a segfault but again I can't get the debugger to attach because Detours is interfering with the attachment process.

I also tried disabling some of the flags that JPype was adding to the python build process to see if any are related.   "/DEBUG" on the linker does not do anything to the problem.  The other options were '/Zi', '/EHsc', '/std:c++14'.   Nothing here is out of the ordinary.  

I do not see anything in the link line that shows evidence of static linkage or likely to cause a conflict.  The exact same line is being used with Python 3.8.

link.exe /nologo /INCREMENTAL:NO /LTCG /DLL /MANIFEST:EMBED,ID=2 /MANIFESTUAC:NO /LIBPATH:C:\Users\nelson85\AppData\Local\Programs\Python\Python39\libs /LIBPATH:C:\Users\nelson85\AppData\Local\Programs\Python\Python39\PCbuild\amd64 /LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29333\ATLMFC\lib\x64 /LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29333\lib\x64 /LIBPATH:C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\lib\um\x64 /LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.18362.0\ucrt\x64 /LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.18362.0\um\x64 /LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29333\ATLMFC\lib\x64 /LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.28.29333\lib\x64 /LIBPATH:C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\lib\um\x64 /LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.18362.0\ucrt\x64 /LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.18362.0\um\x64 /EXPORT:PyInit__jpype 
$(OBJECTS) /OUT:build\lib.win-amd64-3.9\_jpype.cp39-win_amd64.pyd /IMPLIB:build\temp.win-amd64-3.9\Release\native\common\_jpype.cp39-win_amd64.lib

So I remain at a loss how to proceed forward.  Nothing has changed in JPype or its symbols since Python 3.8 so this is clearly taking place in Python or at the OS level.  Is it possible that Python shipped with bad dlls for the 3.9.0 build?  If so then looking at the source code may be the wrong approach.   After all depending on the order of libraries I trigger or don't trigger the bug.

I should note that the difference between loading successfully py and pyc seems to have been triggered in PC/getpathc.c .... could it be the change to remove loading api-ms-win-core-path?


```
 static void
 join(wchar_t *buffer, const wchar_t *stuff)
 {
-    if (_PathCchCombineEx_Initialized == 0) {
-        HMODULE pathapi = LoadLibraryExW(L"api-ms-win-core-path-l1-1-0.dll", NULL,
-                                         LOAD_LIBRARY_SEARCH_SYSTEM32);
-        if (pathapi) {
-            _PathCchCombineEx = (PPathCchCombineEx)GetProcAddress(pathapi, "PathCchCombineEx");
-        }
-        else {
-            _PathCchCombineEx = NULL;
-        }
-        _PathCchCombineEx_Initialized = 1;
-    }
-
-    if (_PathCchCombineEx) {
-        if (FAILED(_PathCchCombineEx(buffer, MAXPATHLEN+1, buffer, stuff, 0))) {
-            Py_FatalError("buffer overflow in getpathp.c's join()");
-        }
-    } else {
-        if (!PathCombineW(buffer, buffer, stuff)) {
-            Py_FatalError("buffer overflow in getpathp.c's join()");
-        }
+    if (FAILED(PathCchCombineEx(buffer, MAXPATHLEN+1, buffer, stuff, 0))) {
+        Py_FatalError("buffer overflow in getpathp.c's join()");
     }
 }
```

Also given JPype is really a generic C++ CPython module (with no special options other than /Zi /EHsc why hasn't anyone else triggered this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Sat Dec 19 23:55:05 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 20 Dec 2020 04:55:05 +0000
Subject: [issue42604] EXT_SUFFIX too short on FreeBSD and AIX
In-Reply-To: <1607464402.35.0.336960410788.issue42604@roundup.psfhosted.org>
Message-ID: <1608440105.99.0.471035020459.issue42604@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Thanks for the PR, mattip!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42604>
_______________________________________

From report at bugs.python.org  Sun Dec 20 00:38:06 2020
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 20 Dec 2020 05:38:06 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1608442686.74.0.229255712517.issue42529@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

I built JPype normally in release mode and was able to analyze the problem using the platform debugger (cdb or WinDbg). I think the issue is pretty straight forward. The static initializer for classMagic in "native\python\pyjp_class.cpp" is calling PyDict_New(). That's not kosher because the GIL isn't held during the LoadLibraryExW call. It seems to be okay without a cached PYC because the new_dict() call has an available dict on the freelist in this case. In the PYC case, new_dict() happens to instead call PyObject_GC_New, which fails with an access violation. I modified "pyjp_class.cpp" to set the static value of classMagic to NULL and moved the initialization to PyJPClass_new. This resolved the problem. So I think this issue should be closed as a third-party bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Sun Dec 20 00:52:54 2020
From: report at bugs.python.org (Eli Rykoff)
Date: Sun, 20 Dec 2020 05:52:54 +0000
Subject: [issue42688] ctypes memory error on Apple Silicon with external libffi
Message-ID: <1608443574.61.0.0166938419217.issue42688@roundup.psfhosted.org>


New submission from Eli Rykoff <erykoff at stanford.edu>:

Building python 3.9.1 on Apple Silicon compiled against a external (non-os-provided) libffi makes the following code return a MemoryError:

Test:

import ctypes

@ctypes.CFUNCTYPE(None, ctypes.c_int, ctypes.c_char_p)
def error_handler(fif, message):
    pass

I have tracked this down to the following code in malloc_closure.c:

#if USING_APPLE_OS_LIBFFI && HAVE_FFI_CLOSURE_ALLOC
    if (__builtin_available(macos 10.15, ios 13, watchos 6, tvos 13, *)) {
        ffi_closure_free(p);
        return;
    }
#endif

and

#if USING_APPLE_OS_LIBFFI && HAVE_FFI_CLOSURE_ALLOC
    if (__builtin_available(macos 10.15, ios 13, watchos 6, tvos 13, *)) {
        return ffi_closure_alloc(size, codeloc);
    }
#endif

In fact, while the __builtin_available() call should be guarded by USING_APPLE_OS_LIBFFI, the call to ffi_closure_alloc() should only be guarded by HAVE_FFI_CLOSURE_ALLOC, as this is set as the result of an independent check in setup.py and should be used with external libffi when supported.

The following code does work instead:

#if HAVE_FFI_CLOSURE_ALLOC
#if USING_APPLE_OS_LIBFFI
    if (__builtin_available(macos 10.15, ios 13, watchos 6, tvos 13, *)) {
#endif
        ffi_closure_free(p);
        return;
#if USING_APPLE_OS_LIBFFI
    }
#endif
#endif


#if HAVE_FFI_CLOSURE_ALLOC
#if USING_APPLE_OS_LIBFFI
    if (__builtin_available(macos 10.15, ios 13, watchos 6, tvos 13, *)) {
#endif
        return ffi_closure_alloc(size, codeloc);
        return;
#if USING_APPLE_OS_LIBFFI
    }
#endif
#endif

----------
components: ctypes
messages: 383419
nosy: erykoff
priority: normal
severity: normal
status: open
title: ctypes memory error on Apple Silicon with external libffi
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42688>
_______________________________________

From report at bugs.python.org  Sun Dec 20 01:09:39 2020
From: report at bugs.python.org (Eli Rykoff)
Date: Sun, 20 Dec 2020 06:09:39 +0000
Subject: [issue42688] ctypes memory error on Apple Silicon with external libffi
In-Reply-To: <1608443574.61.0.0166938419217.issue42688@roundup.psfhosted.org>
Message-ID: <1608444579.58.0.688379491982.issue42688@roundup.psfhosted.org>


Change by Eli Rykoff <erykoff at stanford.edu>:


----------
keywords: +patch
pull_requests: +22730
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23868

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42688>
_______________________________________

From report at bugs.python.org  Sun Dec 20 02:12:56 2020
From: report at bugs.python.org (Karl Nelson)
Date: Sun, 20 Dec 2020 07:12:56 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1608448376.27.0.760513993629.issue42529@roundup.psfhosted.org>


Karl Nelson <nelson85 at llnl.gov> added the comment:

Drat I missed that one when I was scanning for statics because I was focusing C++ resource rather than looking for Python resources.  I also wouldn't have expected this to happen on only one platform, but that was my bad.  

Is it possible to improve the error reporting for this?  This was a horrible error to trace down at least for a non-windows programmer.  At least a mention in the doc as to the symptoms so someone else can google it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Sun Dec 20 02:19:59 2020
From: report at bugs.python.org (Karl Nelson)
Date: Sun, 20 Dec 2020 07:19:59 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1608448799.93.0.532006481009.issue42529@roundup.psfhosted.org>


Karl Nelson <nelson85 at llnl.gov> added the comment:

I found it.  The change that hit JPype is https://bugs.python.org/issue33895

Thanks, Eryk Sun for figuring this out.  I would never have gotten myself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Sun Dec 20 02:31:59 2020
From: report at bugs.python.org (Rafael)
Date: Sun, 20 Dec 2020 07:31:59 +0000
Subject: [issue42689] Installation
Message-ID: <1608449519.45.0.28337310335.issue42689@roundup.psfhosted.org>


New submission from Rafael <greenspore35 at gmail.com>:

I'm very new to python. I went to download 3.9.1 and it said "There was an error creating a temporary file that is needed to complete this installation." I was wondering how I can fix this problem so I can start learning

----------
components: Windows
messages: 383422
nosy: Gimmesomo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Installation
type: crash
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42689>
_______________________________________

From report at bugs.python.org  Sun Dec 20 02:32:12 2020
From: report at bugs.python.org (Rafael)
Date: Sun, 20 Dec 2020 07:32:12 +0000
Subject: [issue42689] Installation
In-Reply-To: <1608449519.45.0.28337310335.issue42689@roundup.psfhosted.org>
Message-ID: <1608449532.52.0.478086777958.issue42689@roundup.psfhosted.org>


Rafael <greenspore35 at gmail.com> added the comment:

I'm very new to python. I went to download 3.9.1 and it said "There was an error creating a temporary file that is needed to complete this installation." I was wondering how I can fix this problem so I can start learning

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42689>
_______________________________________

From report at bugs.python.org  Sun Dec 20 02:34:08 2020
From: report at bugs.python.org (Rafael)
Date: Sun, 20 Dec 2020 07:34:08 +0000
Subject: [issue42689] Installation
In-Reply-To: <1608449519.45.0.28337310335.issue42689@roundup.psfhosted.org>
Message-ID: <1608449648.39.0.75735931132.issue42689@roundup.psfhosted.org>


Rafael <greenspore35 at gmail.com> added the comment:

I'm very new to python. I went to download 3.9.1 and it said "There was an error creating a temporary file that is needed to complete this installation." I was wondering how I can fix this problem so I can start learning. Error code is 2502

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42689>
_______________________________________

From report at bugs.python.org  Sun Dec 20 03:16:56 2020
From: report at bugs.python.org (JasperTecHK)
Date: Sun, 20 Dec 2020 08:16:56 +0000
Subject: [issue42690] Aiohttp fails when using intel ax200 wireless card
Message-ID: <1608452216.56.0.63748155919.issue42690@roundup.psfhosted.org>


New submission from JasperTecHK <jasperchun122441 at gmail.com>:

Not sure what the protocol is for reporting the bug, but based on my, albeit limited, testing, on two separate machines running the same model of wireless card(but different cards), the Intel AX200 wireless card, aiohttp fails to finish scraping from webpages. The issue does not occur when both machines are using ethernet. The issue was tested on a AWS instance as well to try and eliminate the issue as well.

Further information is here, but I only got around to checking on a second machine a few minutes ago.

https://www.reddit.com/r/learnpython/comments/jiu452/asyncio_erroring_on_one_machine/

Things done to eliminate variables:
Tested on different network access methods (wlan0 vs eth0)
Tested on two different machines
Tested on two different OSes (Win 10, Ubuntu 20.04)

Interestingly, I did test with three different networks. First one was AWS, which worked as expected. The two others exhibited strange behavior.

Network A is a cable modem network from xfinity. We use our own router. When connected via wifi on either machine and run, the error as shown in my reddit thread above occurs, but if I run an ethernet line to it(though through a wifi-to-ethernet bridge on a rpi4 due to my room being unable to run a direct line of ethernet there, which is connected to the exact same wifi source as the two machines mentioned above), it will complete without errors.

Network B is my mobile tethering. Windows being Windows, it has a hissy fit and doesn't want to play nice. So I was only able to run a test on my Ubuntu machine. This time, I get an error that stated the server disconnected, but if I add in a wg vpn through a EC2 server, it completes, albeit slowly, but that's understandable.

Tldr: Network A was tested two ways.
wifi ap > Win10/ubuntu = fail. Error message is what is shown in the reddit thread.
wifi ap > rpi wlan-eth bridge > win10/ubuntu = pass.
Note: The vpn mentioned in Network B was also tested on Network A but did not make a difference.

Network B
mobile tethering > ubuntu = fail. Error is a Server Disconnect. Full error is attached.
mobile tethering > ubuntu + wg to EC2 = pass.

I understand that since this doesn't appear to be a widespread issue, not a lot of help would be available for this. But it would be nice to at least be able to figure out what the problem is.

----------
components: asyncio
files: tetherror.txt
messages: 383425
nosy: JasperTecHK, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Aiohttp fails when using intel ax200 wireless card
versions: Python 3.8
Added file: https://bugs.python.org/file49693/tetherror.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42690>
_______________________________________

From report at bugs.python.org  Sun Dec 20 03:17:06 2020
From: report at bugs.python.org (JasperTecHK)
Date: Sun, 20 Dec 2020 08:17:06 +0000
Subject: [issue42690] Aiohttp fails when using intel ax200 wireless card
In-Reply-To: <1608452216.56.0.63748155919.issue42690@roundup.psfhosted.org>
Message-ID: <1608452226.67.0.989234299974.issue42690@roundup.psfhosted.org>


Change by JasperTecHK <jasperchun122441 at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42690>
_______________________________________

From report at bugs.python.org  Sun Dec 20 04:52:11 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 20 Dec 2020 09:52:11 +0000
Subject: [issue42688] ctypes memory error on Apple Silicon with external libffi
In-Reply-To: <1608443574.61.0.0166938419217.issue42688@roundup.psfhosted.org>
Message-ID: <1608457931.42.0.487624212082.issue42688@roundup.psfhosted.org>


Change by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
components: +macOS
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42688>
_______________________________________

From report at bugs.python.org  Sun Dec 20 04:56:29 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 20 Dec 2020 09:56:29 +0000
Subject: [issue42688] ctypes memory error on Apple Silicon with external libffi
In-Reply-To: <1608443574.61.0.0166938419217.issue42688@roundup.psfhosted.org>
Message-ID: <1608458189.32.0.298960394083.issue42688@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Could you  please sign the CLA? (See the PR for details on that)

The PR looks sane.

Out of interest: why do you use an external version of libffi? AFAIK the system copy of libffi contains some magic sauce to work nicer with signed binaries.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42688>
_______________________________________

From report at bugs.python.org  Sun Dec 20 05:55:47 2020
From: report at bugs.python.org (Yurii Karabas)
Date: Sun, 20 Dec 2020 10:55:47 +0000
Subject: [issue42525] Optimize class/module level annotation
In-Reply-To: <1606836637.51.0.505503737654.issue42525@roundup.psfhosted.org>
Message-ID: <1608461747.66.0.245692894188.issue42525@roundup.psfhosted.org>


Yurii Karabas <1998uriyyo at gmail.com> added the comment:

After several attempts to optimize class/module annotations, I didn't find a solution that won't break existing code and can cover all existing edge cases.

The root cause was mentioned by Inada, the problem that `__annotations__` is exposed to locals and can be dynamically modified and that can't be predicted at compilation time.

Sorry about this issue, when I was creating this issue, I didn't realize the whole problem state.

We can close this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42525>
_______________________________________

From report at bugs.python.org  Sun Dec 20 07:06:24 2020
From: report at bugs.python.org (Steve Dower)
Date: Sun, 20 Dec 2020 12:06:24 +0000
Subject: [issue42689] Installation
In-Reply-To: <1608449519.45.0.28337310335.issue42689@roundup.psfhosted.org>
Message-ID: <1608465984.34.0.119158530751.issue42689@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

It sounds like you need administrative permissions on your device.

Can I suggest searching the Microsoft Store for Python 3.9 and getting it that way? That installer shouldn't have this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42689>
_______________________________________

From report at bugs.python.org  Sun Dec 20 07:31:11 2020
From: report at bugs.python.org (Steve Dower)
Date: Sun, 20 Dec 2020 12:31:11 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1608467471.77.0.174640270752.issue42529@roundup.psfhosted.org>


Steve Dower <steve.dower at python.org> added the comment:

I doubt there's anything more we can do about Windows swallowing an access violation and turning it into a generic error. There's a very low chance you'd have found any notes about it in the docs, so this bug will probably stand as the best available reference for future.

We also can't really add more checks for every method that assumes the GIL is held, because that will hurt runtime performance for everyone. And I doubt even debug checks would help here - DLL load is pretty well protected, and there's really nothing but a debugger that can diagnose issues anyway. 

I've pushed back in the past on adding a "how to debug apps on Windows" section to our docs, because it is such a huge topic that we can't possibly cover well enough to be useful in all the cases that come up.

"Don't use functions that require the GIL without holding the GIL" is already documented generally enough. So I'm glad we got this figured out, but I'm not sure there's anything we can fix long-term to prevent it (other than entirely replacing the C API ;) ).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Sun Dec 20 08:02:26 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Dec 2020 13:02:26 +0000
Subject: [issue42525] Optimize class/module level annotation
In-Reply-To: <1606836637.51.0.505503737654.issue42525@roundup.psfhosted.org>
Message-ID: <1608469346.5.0.0457474594963.issue42525@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/issue42525>
_______________________________________

From report at bugs.python.org  Sun Dec 20 08:15:35 2020
From: report at bugs.python.org (Lele Gaifax)
Date: Sun, 20 Dec 2020 13:15:35 +0000
Subject: [issue22228] Adapt bash readline operate-and-get-next function
In-Reply-To: <1408441328.29.0.0681426449148.issue22228@psf.upfronthosting.co.za>
Message-ID: <1608470135.66.0.374305010686.issue22228@roundup.psfhosted.org>


Lele Gaifax <lelegaifax at gmail.com> added the comment:

Hey, recompiling current master against readline 8.1 gives an interpreter where this is already working: rl_operate_and_get_next() is bound to Control-o in the standard emacs keymap!

http://git.savannah.gnu.org/cgit/readline.git/tree/emacs_keymap.c?h=readline-8.1-rc3&id=acb676c4a529f4147b3087e9e66d372cee2564ca#n50

(for some reason, they didn't tag 8.1 final yet).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue22228>
_______________________________________

From report at bugs.python.org  Sun Dec 20 09:29:06 2020
From: report at bugs.python.org (Jakub Kulik)
Date: Sun, 20 Dec 2020 14:29:06 +0000
Subject: [issue42655] Fix subprocess extra_groups gid conversion
In-Reply-To: <1608113122.79.0.244683118693.issue42655@roundup.psfhosted.org>
Message-ID: <1608474546.88.0.893821462933.issue42655@roundup.psfhosted.org>


Jakub Kulik <kulikjak at gmail.com> added the comment:

I checked and indeed there seems to be no reason as for why should we use `void *` rather than `gid_t *` and `uid_t *`. I changed that in the attached PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42655>
_______________________________________

From report at bugs.python.org  Sun Dec 20 10:12:58 2020
From: report at bugs.python.org (Karl Nelson)
Date: Sun, 20 Dec 2020 15:12:58 +0000
Subject: [issue42529] CPython DLL initialization routine failed from PYC cache
 file
In-Reply-To: <1606845783.12.0.45647033223.issue42529@roundup.psfhosted.org>
Message-ID: <1608477178.24.0.548604852532.issue42529@roundup.psfhosted.org>


Karl Nelson <nelson85 at llnl.gov> added the comment:

Okay, well at least now googling Python + "A dynamic link library (DLL) initialization routine failed." give something which could point a user may be able to identify the issue.  It wasn't obvious to me that imports did not hold the GIL, but it is clear in retrospect that it should have been.

Thanks very much and sorry for the wild goose chase.

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42529>
_______________________________________

From report at bugs.python.org  Sun Dec 20 10:15:32 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 20 Dec 2020 15:15:32 +0000
Subject: [issue42650] Can people use dest=argparse.SUPPRESS in custom Action
 classes?
In-Reply-To: <1608058165.01.0.505230302489.issue42650@roundup.psfhosted.org>
Message-ID: <1608477332.64.0.198628200454.issue42650@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
nosy: +paul.j3, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42650>
_______________________________________

From report at bugs.python.org  Sun Dec 20 11:22:46 2020
From: report at bugs.python.org (Big Stone)
Date: Sun, 20 Dec 2020 16:22:46 +0000
Subject: [issue35943] PyImport_GetModule() can return partially-initialized
 module
In-Reply-To: <1549646017.22.0.395154635441.issue35943@roundup.psfhosted.org>
Message-ID: <1608481366.25.0.476613719558.issue35943@roundup.psfhosted.org>


Big Stone <stonebig34 at gmail.com> added the comment:

Is this bug causing the Dask-Jupyterlab failure ? 
https://github.com/dask/distributed/issues/4168

----------
nosy: +Big Stone

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35943>
_______________________________________

From report at bugs.python.org  Sun Dec 20 12:06:13 2020
From: report at bugs.python.org (Irit Katriel)
Date: Sun, 20 Dec 2020 17:06:13 +0000
Subject: [issue24792] zipimporter masks import errors
In-Reply-To: <1438764662.95.0.423222705195.issue24792@psf.upfronthosting.co.za>
Message-ID: <1608483973.91.0.247011172764.issue24792@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
resolution:  -> fixed
versions:  -Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24792>
_______________________________________

From report at bugs.python.org  Sun Dec 20 12:06:37 2020
From: report at bugs.python.org (Irit Katriel)
Date: Sun, 20 Dec 2020 17:06:37 +0000
Subject: [issue24792] zipimporter masks import errors
In-Reply-To: <1438764662.95.0.423222705195.issue24792@psf.upfronthosting.co.za>
Message-ID: <1608483997.5.0.889052968765.issue24792@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24792>
_______________________________________

From report at bugs.python.org  Sun Dec 20 13:14:57 2020
From: report at bugs.python.org (Josh Rosenberg)
Date: Sun, 20 Dec 2020 18:14:57 +0000
Subject: [issue42689] Installation
In-Reply-To: <1608449519.45.0.28337310335.issue42689@roundup.psfhosted.org>
Message-ID: <1608488097.7.0.764605600748.issue42689@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/issue42689>
_______________________________________

From report at bugs.python.org  Sun Dec 20 13:15:02 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 20 Dec 2020 18:15:02 +0000
Subject: [issue42572] Better path handling with argparse
In-Reply-To: <1607121735.85.0.926277593776.issue42572@roundup.psfhosted.org>
Message-ID: <1608488102.49.0.667385764821.issue42572@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset b0398a4b7fb5743f6dbb72ac6b2926e0a0c11498 by Raymond Hettinger in branch 'master':
bpo-42572:  Improve argparse docs for the type parameter. (GH-23849)
https://github.com/python/cpython/commit/b0398a4b7fb5743f6dbb72ac6b2926e0a0c11498


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42572>
_______________________________________

From report at bugs.python.org  Sun Dec 20 13:15:14 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 20 Dec 2020 18:15:14 +0000
Subject: [issue42572] Better path handling with argparse
In-Reply-To: <1607121735.85.0.926277593776.issue42572@roundup.psfhosted.org>
Message-ID: <1608488114.17.0.620488698672.issue42572@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +22731
pull_request: https://github.com/python/cpython/pull/23869

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42572>
_______________________________________

From report at bugs.python.org  Sun Dec 20 13:24:17 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 20 Dec 2020 18:24:17 +0000
Subject: [issue42669] "except" documentation still suggests nested tuples are
 allowed
In-Reply-To: <1608211677.22.0.0507603390583.issue42669@roundup.psfhosted.org>
Message-ID: <1608488657.75.0.134325179656.issue42669@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c95f8bc2700b42f4568886505a819816c9b0ba28 by Colin Watson in branch 'master':
bpo-42669: Document that `except` rejects nested tuples (GH-23822)
https://github.com/python/cpython/commit/c95f8bc2700b42f4568886505a819816c9b0ba28


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42669>
_______________________________________

From report at bugs.python.org  Sun Dec 20 13:24:24 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 20 Dec 2020 18:24:24 +0000
Subject: [issue42669] "except" documentation still suggests nested tuples are
 allowed
In-Reply-To: <1608211677.22.0.0507603390583.issue42669@roundup.psfhosted.org>
Message-ID: <1608488664.24.0.650304665584.issue42669@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22732
pull_request: https://github.com/python/cpython/pull/23870

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42669>
_______________________________________

From report at bugs.python.org  Sun Dec 20 13:24:33 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 20 Dec 2020 18:24:33 +0000
Subject: [issue42669] "except" documentation still suggests nested tuples are
 allowed
In-Reply-To: <1608211677.22.0.0507603390583.issue42669@roundup.psfhosted.org>
Message-ID: <1608488673.82.0.948428065419.issue42669@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22733
pull_request: https://github.com/python/cpython/pull/23871

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42669>
_______________________________________

From report at bugs.python.org  Sun Dec 20 13:27:46 2020
From: report at bugs.python.org (=?utf-8?b?0J/RkdGC0YAg0KHQuNGA0LXQvdC60L4=?=)
Date: Sun, 20 Dec 2020 18:27:46 +0000
Subject: [issue42691] macOS 11.1 + Homebrew 2.6.2 + Python 3.9.1 = "IDLE" crash
In-Reply-To: <1608488832.09.0.347546053982.issue42691@roundup.psfhosted.org>
Message-ID: <1608488866.33.0.961915401234.issue42691@roundup.psfhosted.org>


Change by ???? ??????? <p.sirenko.94 at gmail.com>:


----------
title: macOS 11.1 + Homebrew 2.6.2 + python 3.9.1 = idle crash -> macOS 11.1 + Homebrew 2.6.2 + Python 3.9.1 = "IDLE" crash

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42691>
_______________________________________

From report at bugs.python.org  Sun Dec 20 13:27:40 2020
From: report at bugs.python.org (Joshua Root)
Date: Sun, 20 Dec 2020 18:27:40 +0000
Subject: [issue42692] Build fails on macOS when compiler doesn't define
 __has_builtin
Message-ID: <1608488860.71.0.844167332987.issue42692@roundup.psfhosted.org>


New submission from Joshua Root <josh+python at root.id.au>:

The line in posixmodule.c that checks for __builtin_available is rejected by compilers that don't have __has_builtin. The second check needs to be in a nested #if.

----------
components: Build, macOS
messages: 383437
nosy: jmr, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Build fails on macOS when compiler doesn't define __has_builtin
type: compile error
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42692>
_______________________________________

From report at bugs.python.org  Sun Dec 20 13:29:21 2020
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Blondon?=)
Date: Sun, 20 Dec 2020 18:29:21 +0000
Subject: [issue42589] doc: Wrong "from" keyword link in Exceptions doc
In-Reply-To: <1607356415.63.0.620558354489.issue42589@roundup.psfhosted.org>
Message-ID: <1608488961.84.0.561068444819.issue42589@roundup.psfhosted.org>


Change by St?phane Blondon <stephane.blondon at gmail.com>:


----------
keywords: +patch
nosy: +sblondon
nosy_count: 2.0 -> 3.0
pull_requests: +22734
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23872

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42589>
_______________________________________

From report at bugs.python.org  Sun Dec 20 13:35:21 2020
From: report at bugs.python.org (Justin)
Date: Sun, 20 Dec 2020 18:35:21 +0000
Subject: [issue42640] tkinter throws exception when key is pressed
In-Reply-To: <1607970157.48.0.157059469848.issue42640@roundup.psfhosted.org>
Message-ID: <1608489321.24.0.94630285133.issue42640@roundup.psfhosted.org>


Justin <justin.a.black at gmail.com> added the comment:

FYI, I just brew installed python and with:
```
Python 3.9.1 (default, Dec 17 2020, 03:56:09) 
[Clang 11.0.0 (clang-1100.0.33.17)] on darwin
```
This issue still happens

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42640>
_______________________________________

From report at bugs.python.org  Sun Dec 20 13:35:53 2020
From: report at bugs.python.org (Joshua Root)
Date: Sun, 20 Dec 2020 18:35:53 +0000
Subject: [issue42692] Build fails on macOS when compiler doesn't define
 __has_builtin
In-Reply-To: <1608488860.71.0.844167332987.issue42692@roundup.psfhosted.org>
Message-ID: <1608489353.63.0.428454567504.issue42692@roundup.psfhosted.org>


Change by Joshua Root <josh+python at root.id.au>:


----------
keywords: +patch
pull_requests: +22735
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23873

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42692>
_______________________________________

From report at bugs.python.org  Sun Dec 20 13:51:27 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 20 Dec 2020 18:51:27 +0000
Subject: [issue42572] Better path handling with argparse
In-Reply-To: <1607121735.85.0.926277593776.issue42572@roundup.psfhosted.org>
Message-ID: <1608490287.84.0.0159489587339.issue42572@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 40b4c405f98f2d35835ef5d183f0327c0c55da6f by Miss Islington (bot) in branch '3.9':
bpo-42572:  Improve argparse docs for the type parameter. (GH-23849) (GH-23869)
https://github.com/python/cpython/commit/40b4c405f98f2d35835ef5d183f0327c0c55da6f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42572>
_______________________________________

From report at bugs.python.org  Sun Dec 20 13:51:41 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 20 Dec 2020 18:51:41 +0000
Subject: [issue42572] Better path handling with argparse
In-Reply-To: <1607121735.85.0.926277593776.issue42572@roundup.psfhosted.org>
Message-ID: <1608490301.58.0.30661584732.issue42572@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/issue42572>
_______________________________________

From report at bugs.python.org  Sun Dec 20 13:56:37 2020
From: report at bugs.python.org (Ned Deily)
Date: Sun, 20 Dec 2020 18:56:37 +0000
Subject: [issue42640] tkinter throws exception when key is pressed
In-Reply-To: <1607970157.48.0.157059469848.issue42640@roundup.psfhosted.org>
Message-ID: <1608490597.41.0.639200700407.issue42640@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

As explained above, this crash will happen with any Python that links to the deprecated Apple-supplied system Tk framework in macOS versions from macOS 10.7 to 11 Big Sur. If you want to use tkinter, you need to use a Python that links to a newer version of Tk. If Homebrew?s Python is not doing that, you should bring it up with the Homebrew project.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42640>
_______________________________________

From report at bugs.python.org  Sun Dec 20 14:12:44 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sun, 20 Dec 2020 19:12:44 +0000
Subject: [issue31861] add aiter() and anext() functions
In-Reply-To: <1508851575.6.0.213398074469.issue31861@psf.upfronthosting.co.za>
Message-ID: <1608491564.53.0.759222010108.issue31861@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

I don't have anything to add to this beside the name choice is safe and won't clash with anything (but honestly I would prefer it to be discussed on the ML before implementing something after 3 years). I checked a limited dataset to search for aiter and only found examples from 2 different projects. Elastic have something for themselves and the other usages are coming from the tests of aioitertools.
https://github.com/elastic/elasticsearch-py/blob/5fe9ff721ce493fbf2fc8b94d5ab02fc7e55fd5a/elasticsearch/_async/helpers.py#L85-L96

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31861>
_______________________________________

From report at bugs.python.org  Sun Dec 20 14:28:57 2020
From: report at bugs.python.org (paul j3)
Date: Sun, 20 Dec 2020 19:28:57 +0000
Subject: [issue42650] Can people use dest=argparse.SUPPRESS in custom Action
 classes?
In-Reply-To: <1608058165.01.0.505230302489.issue42650@roundup.psfhosted.org>
Message-ID: <1608492537.36.0.10805124524.issue42650@roundup.psfhosted.org>


paul j3 <ajipanca at gmail.com> added the comment:

I'd have to study the code (and docs), but I'm not sure setting the `dest` to 'SUPPRESS' does anything meaningful.

    default=argparse.SUPPRESS

is useful, keeping the default out of the namespace.  That argument appears only if the user has used the option.

But with `dest` (in a default 'store'), I get a namespace like

    Namespace(**{'==SUPPRESS==': 'foo'})

'help' and 'version' exit right after displaying their message, so I'm no sure the 'SUPPRESS' is doing anything.  The parser doesn't return a namespace.

It appears that the 'dest' is passed to the Action.  A custom Action could act on that 'dest'.  The default 'store' just uses it as the attribute for storing the value in the namespace.

Anyways, this is not the kind of thing that we'll be tweaking in the source.  I don't recall any bug/issue touching on this behavior (but we could do a search).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42650>
_______________________________________

From report at bugs.python.org  Sun Dec 20 14:44:38 2020
From: report at bugs.python.org (Justin)
Date: Sun, 20 Dec 2020 19:44:38 +0000
Subject: [issue42640] tkinter throws exception when key is pressed
In-Reply-To: <1607970157.48.0.157059469848.issue42640@roundup.psfhosted.org>
Message-ID: <1608493478.98.0.97142193951.issue42640@roundup.psfhosted.org>


Justin <justin.a.black at gmail.com> added the comment:

Thank you very much. I understand and just wanted to let you know.
In brew I opened up this ticket(https://github.com/Homebrew/homebrew-core/issues/67327) with that team.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42640>
_______________________________________

From report at bugs.python.org  Sun Dec 20 14:49:09 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 20 Dec 2020 19:49:09 +0000
Subject: [issue39158] ast.literal_eval() doesn't support empty sets
In-Reply-To: <1577655730.41.0.646692068238.issue39158@roundup.psfhosted.org>
Message-ID: <1608493749.24.0.0894530597347.issue39158@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39158>
_______________________________________

From report at bugs.python.org  Sun Dec 20 14:56:30 2020
From: report at bugs.python.org (Chris Withers)
Date: Sun, 20 Dec 2020 19:56:30 +0000
Subject: [issue3722] print followed by exception eats print with doctest
In-Reply-To: <1220007253.68.0.614144600028.issue3722@psf.upfronthosting.co.za>
Message-ID: <1608494190.71.0.257007656969.issue3722@roundup.psfhosted.org>


Chris Withers <chris at withers.org> added the comment:

@iritkatriel - if Tim thinks this is hard, it probably is hard ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3722>
_______________________________________

From report at bugs.python.org  Sun Dec 20 14:56:52 2020
From: report at bugs.python.org (Chris Withers)
Date: Sun, 20 Dec 2020 19:56:52 +0000
Subject: [issue3722] print followed by exception eats print with doctest
In-Reply-To: <1220007253.68.0.614144600028.issue3722@psf.upfronthosting.co.za>
Message-ID: <1608494212.76.0.567830318282.issue3722@roundup.psfhosted.org>


Change by Chris Withers <chris at withers.org>:


----------
keywords:  -easy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue3722>
_______________________________________

From report at bugs.python.org  Sun Dec 20 15:39:21 2020
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Blondon?=)
Date: Sun, 20 Dec 2020 20:39:21 +0000
Subject: [issue18163] Add a 'key' attribute to KeyError
In-Reply-To: <1370638316.1.0.167534610168.issue18163@psf.upfronthosting.co.za>
Message-ID: <1608496761.59.0.651292375325.issue18163@roundup.psfhosted.org>


St?phane Blondon <stephane.blondon at gmail.com> added the comment:

Orian: your patch formats the error message but the original suggested  solution is to store the missing key in a new attribute. 

I don't know if you go in the good direction.

Adding an attribute is also suggested by issue #614557.

----------
nosy: +sblondon
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18163>
_______________________________________

From report at bugs.python.org  Sun Dec 20 15:43:50 2020
From: report at bugs.python.org (Eli Rykoff)
Date: Sun, 20 Dec 2020 20:43:50 +0000
Subject: [issue42688] ctypes memory error on Apple Silicon with external libffi
In-Reply-To: <1608443574.61.0.0166938419217.issue42688@roundup.psfhosted.org>
Message-ID: <1608497030.78.0.117741888642.issue42688@roundup.psfhosted.org>


Eli Rykoff <erykoff at stanford.edu> added the comment:

Thanks for your quick feedback!  I signed the CLA after submitting the PR, but I think it takes a bit of time to percolate through the system.

As for the "why", until 3.9.1 conda-forge had been successfully using an external ffi (with 3.9.0 + osx-arm64 patches) and then suddenly it broke.  For the time being conda-forge is using the system ffi, which does have other advantages as well, having all the latest patches.  However, I was curious as to _why_ it broke, and that led me to discover this bug, and it seemed straightforward to fix.  When/if conda-forge will switch back to external ffi is TBD, but if that decision is made this issue (at least) will be taken care of.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42688>
_______________________________________

From report at bugs.python.org  Sun Dec 20 15:44:05 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 20 Dec 2020 20:44:05 +0000
Subject: [issue25478] Consider adding a normalize() method to
 collections.Counter()
In-Reply-To: <1445826280.05.0.307309053044.issue25478@psf.upfronthosting.co.za>
Message-ID: <1608497045.86.0.0501068788391.issue25478@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Here's what I propose to add:

    def total(self):
        return sum(self.values())

    def scaled_by(self, factor):
        return Counter({elem : count * factor for elem, count in self.items()})

    def scaled_to(self, target_total=1.0):
        ratio = target_total / self.total()
        return self.scaled_by(ratio)

These cover the common cases and they don't mutate the counter.

----------
versions: +Python 3.10 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25478>
_______________________________________

From report at bugs.python.org  Sun Dec 20 15:45:49 2020
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 20 Dec 2020 20:45:49 +0000
Subject: [issue42634] Incorrect line number in bytecode for try-except-finally
In-Reply-To: <1607930696.05.0.974303425196.issue42634@roundup.psfhosted.org>
Message-ID: <1608497149.25.0.210577864889.issue42634@roundup.psfhosted.org>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

I checked on this with CPython commit c95f8bc270.  The code above is fixed, but this code has a similar problem:

a, b, c = 1, 1, 1
try:
    try:
        a = 4/0         # ZeroDivisionError
    except ValueError:
        b = 6
    except IndexError:
        a = 8           # Line 8
    finally:
        c = 10
except ZeroDivisionError:
    pass
assert a == 1 and b == 1 and c == 10


Using a simple trace program (https://github.com/nedbat/coveragepy/blob/master/lab/run_trace.py), it produces this output:

call <string> 1 @-1
    line <string> 1 @0
    line <string> 2 @10
    line <string> 3 @12
    line <string> 4 @16
    exception <string> 4 @20
    line <string> 5 @28
    line <string> 7 @48
    line <string> 8 @68
    line <string> 10 @78
    line <string> 11 @88
    line <string> 12 @100
    line <string> 13 @106
    return <string> 13 @136

Line 8 should never be executed.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42634>
_______________________________________

From report at bugs.python.org  Sun Dec 20 15:47:27 2020
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 20 Dec 2020 20:47:27 +0000
Subject: [issue42634] Incorrect line number in bytecode for try-except-finally
In-Reply-To: <1607930696.05.0.974303425196.issue42634@roundup.psfhosted.org>
Message-ID: <1608497247.52.0.105373861473.issue42634@roundup.psfhosted.org>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

(Rather: line 8 isn't executed, and so should not be traced.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42634>
_______________________________________

From report at bugs.python.org  Sun Dec 20 15:54:10 2020
From: report at bugs.python.org (Allen Downey)
Date: Sun, 20 Dec 2020 20:54:10 +0000
Subject: [issue25478] Consider adding a normalize() method to
 collections.Counter()
In-Reply-To: <1445826280.05.0.307309053044.issue25478@psf.upfronthosting.co.za>
Message-ID: <1608497650.06.0.0852966415559.issue25478@roundup.psfhosted.org>


Allen Downey <allen.downey at olin.edu> added the comment:

This API would work well for my use cases.

And looking back at previous comments in this thread, I think this proposal avoids the most objectionable pitfalls.

----------
nosy: +AllenDowney

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25478>
_______________________________________

From report at bugs.python.org  Sun Dec 20 15:54:49 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 20 Dec 2020 20:54:49 +0000
Subject: [issue42691] macOS 11.1 + Homebrew 2.6.2 + Python 3.9.1 = "IDLE" crash
In-Reply-To: <1608488832.09.0.347546053982.issue42691@roundup.psfhosted.org>
Message-ID: <1608497689.95.0.213654668931.issue42691@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This is a 'ancient, buggy tcl/tk 8.5.9 on OS11' issue, not an IDLE issue.  Only 8.6.10 has a chance with OS11, and even that is a bit flakey.  But I have no issues so far running 3.9.1 and IDLE with the Universal2 OS11 build from python.org on Mohave.

What happens if you run 'python3.9' on a command line?  What about 'python 3.9 -c "import tkinter; tkinter.Tk()"'?

Ned & Ronald: I expect we should close this as 3rd party (Apple, Active State (tcl/tk), and homebrew).  Do either of you want to add anything?

----------
assignee: terry.reedy -> 
components: +Tkinter, macOS -IDLE
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42691>
_______________________________________

From report at bugs.python.org  Sun Dec 20 16:06:08 2020
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 20 Dec 2020 21:06:08 +0000
Subject: [issue42693] "if 0:" lines are traced; they didn't use to be
Message-ID: <1608498368.47.0.692310939381.issue42693@roundup.psfhosted.org>


New submission from Ned Batchelder <ned at nedbatchelder.com>:

(Using CPython commit c95f8bc270.)

This program has an "if 0:" line that becomes a NOP bytecode.  It didn't used to in Python 3.9

print(1)
if 0:               # line 2
    print(3)
print(4)

Using a simple trace program (https://github.com/nedbat/coveragepy/blob/master/lab/run_trace.py), it produces this output:

call <string> 1 @-1
    line <string> 1 @0
1
    line <string> 2 @8
    line <string> 4 @10
4
    return <string> 4 @20

Using Python3.9 gives this output:

call <string> 1 @-1
    line <string> 1 @0
1
    line <string> 4 @8
4
    return <string> 4 @18

Is this change intentional?

----------
messages: 383452
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: "if 0:" lines are traced; they didn't use to be
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42693>
_______________________________________

From report at bugs.python.org  Sun Dec 20 16:10:00 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Dec 2020 21:10:00 +0000
Subject: [issue42694] Failed test_new_curses_panel in test_curses
Message-ID: <1608498600.94.0.0759010269747.issue42694@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

======================================================================
FAIL: test_new_curses_panel (test.test_curses.TestCurses)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/test/test_curses.py", line 425, in test_new_curses_panel
    self.assertRaises(TypeError, type(panel))
AssertionError: TypeError not raised by panel

----------------------------------------------------------------------

The regression was introduced in 1baf030a902392fe92d934ed0fb6a385cf7d8869 (issue1635741). It can lead to crash because creation of non-initialized object is allowed now. See issue23815 for details.

----------
messages: 383453
nosy: serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Failed test_new_curses_panel in test_curses
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42694>
_______________________________________

From report at bugs.python.org  Sun Dec 20 16:10:44 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Dec 2020 21:10:44 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1608498644.5.0.733729432365.issue1635741@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

These changes introduced a regression in test_curses (see issue42694). And I afraid then introduced regressions in other modules for which there were not purposed tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Sun Dec 20 16:12:09 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Dec 2020 21:12:09 +0000
Subject: [issue42693] "if 0:" lines are traced; they didn't use to be
In-Reply-To: <1608498368.47.0.692310939381.issue42693@roundup.psfhosted.org>
Message-ID: <1608498729.93.0.349802488069.issue42693@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

All NOP bytecodes should be removed. If any is left it is a regression.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42693>
_______________________________________

From report at bugs.python.org  Sun Dec 20 13:27:12 2020
From: report at bugs.python.org (=?utf-8?b?0J/RkdGC0YAg0KHQuNGA0LXQvdC60L4=?=)
Date: Sun, 20 Dec 2020 18:27:12 +0000
Subject: [issue42691] macOS 11.1 + Homebrew 2.6.2 + python 3.9.1 = idle crash
Message-ID: <1608488832.09.0.347546053982.issue42691@roundup.psfhosted.org>


New submission from ???? ??????? <p.sirenko.94 at gmail.com>:

Process:               Python [3355]
Path:                  /usr/local/Cellar/python at 3.9/3.9.1_1/IDLE 3.app/Contents/MacOS/Python
Identifier:            org.python.IDLE
Version:               3.9.1 (3.9.1)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           Python [3355]
User ID:               502

Date/Time:             2020-12-20 21:22:43.045 +0300
OS Version:            macOS 11.1 (20C69)
Report Version:        12
Bridge OS Version:     5.1 (18P3030)
Anonymous UUID:        0607359F-0422-4E24-D0EC-3FDFB0D5A17C


Time Awake Since Boot: 940 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        	0x00007fff20307462 __pthread_kill + 10
1   libsystem_pthread.dylib       	0x00007fff20335610 pthread_kill + 263
2   libsystem_c.dylib             	0x00007fff20288720 abort + 120
3   Tcl                           	0x00007fff6fe06b55 Tcl_PanicVA + 398
4   Tcl                           	0x00007fff6fe06bd5 Tcl_Panic + 128
5   Tk                            	0x00007fff6ff06ad5 TkpInit + 385
6   Tk                            	0x00007fff6fe86788 0x7fff6fe55000 + 202632
7   _tkinter.cpython-39-darwin.so 	0x0000000101dbe701 Tcl_AppInit + 84
8   _tkinter.cpython-39-darwin.so 	0x0000000101db99fa _tkinter_create + 975
9   org.python.python             	0x00000001018b11bb cfunction_vectorcall_FASTCALL + 203
10  org.python.python             	0x0000000101928ff3 call_function + 403
11  org.python.python             	0x0000000101926184 _PyEval_EvalFrameDefault + 27452
12  org.python.python             	0x0000000101929b3b _PyEval_EvalCode + 1998
13  org.python.python             	0x00000001018815d8 _PyFunction_Vectorcall + 248
14  org.python.python             	0x0000000101880e28 _PyObject_FastCallDictTstate + 149
15  org.python.python             	0x0000000101881891 _PyObject_Call_Prepend + 139
16  org.python.python             	0x00000001018c9e96 slot_tp_init + 87
17  org.python.python             	0x00000001018c36f7 type_call + 150
18  org.python.python             	0x0000000101880fa3 _PyObject_MakeTpCall + 266
19  org.python.python             	0x0000000101929027 call_function + 455
20  org.python.python             	0x00000001019262ee _PyEval_EvalFrameDefault + 27814
21  org.python.python             	0x0000000101929b3b _PyEval_EvalCode + 1998
22  org.python.python             	0x00000001018815d8 _PyFunction_Vectorcall + 248
23  org.python.python             	0x0000000101928ff3 call_function + 403
24  org.python.python             	0x0000000101926230 _PyEval_EvalFrameDefault + 27624
25  org.python.python             	0x0000000101929b3b _PyEval_EvalCode + 1998
26  org.python.python             	0x000000010191f56d PyEval_EvalCode + 79
27  org.python.python             	0x000000010195a5b5 run_eval_code_obj + 110
28  org.python.python             	0x00000001019599ad run_mod + 103
29  org.python.python             	0x0000000101958871 PyRun_FileExFlags + 241
30  org.python.python             	0x0000000101957e61 PyRun_SimpleFileExFlags + 271
31  org.python.python             	0x000000010196fd88 Py_RunMain + 1839
32  org.python.python             	0x00000001019700c1 pymain_main + 306
33  org.python.python             	0x000000010197010f Py_BytesMain + 42
34  libdyld.dylib                 	0x00007fff20350621 start + 1

Thread 1:
0   libsystem_pthread.dylib       	0x00007fff20331458 start_wqthread + 0

Thread 2:
0   libsystem_pthread.dylib       	0x00007fff20331458 start_wqthread + 0

Thread 3:
0   libsystem_pthread.dylib       	0x00007fff20331458 start_wqthread + 0

Thread 4:
0   libsystem_pthread.dylib       	0x00007fff20331458 start_wqthread + 0

Thread 5:
0   libsystem_pthread.dylib       	0x00007fff20331458 start_wqthread + 0

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000000  rbx: 0x000000010a905e00  rcx: 0x00007ffeee3c1068  rdx: 0x0000000000000000
  rdi: 0x0000000000000307  rsi: 0x0000000000000006  rbp: 0x00007ffeee3c1090  rsp: 0x00007ffeee3c1068
   r8: 0x00000000000130a8   r9: 0x00007fff889950e8  r10: 0x000000010a905e00  r11: 0x0000000000000246
  r12: 0x0000000000000307  r13: 0x00007fb37d04b790  r14: 0x0000000000000006  r15: 0x0000000000000016
  rip: 0x00007fff20307462  rfl: 0x0000000000000246  cr2: 0x00007fff8d152f70
  
Logical CPU:     0
Error Code:      0x02000148
Trap Number:     133

Thread 0 instruction stream not available.

Thread 0 last branch register state not available.


Binary Images:
       0x10183d000 -        0x101840fff +Python (0) <4C3C8936-2066-3937-B7A8-51F29B2BA552> /usr/local/Cellar/python at 3.9/3.9.1_1/IDLE 3.app/Contents/MacOS/Python
       0x10184c000 -        0x101a4bfff +org.python.python (3.9.1, [c] 2001-2019 Python Software Foundation. - 3.9.1) <0DBC6564-AB58-3938-9A54-89BAC0129512> /usr/local/Cellar/python at 3.9/3.9.1_1/Frameworks/Python.framework/Versions/3.9/Python
       0x101b1b000 -        0x101b1efff  libCyrillicConverter.dylib (90) <046BCE34-B5CD-363F-AB24-2DFD3B85D593> /System/Library/CoreServices/Encodings/libCyrillicConverter.dylib
       0x101d28000 -        0x101d2bfff +_heapq.cpython-39-darwin.so (0) <08F4CDC9-229B-3576-BE1E-A3E3DB380BB5> /usr/local/Cellar/python at 3.9/3.9.1_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/_heapq.cpython-39-darwin.so
       0x101db8000 -        0x101dbffff +_tkinter.cpython-39-darwin.so (0) <EEEFD40E-0472-30C1-AE20-DBAB8144DED2> /usr/local/Cellar/python at 3.9/3.9.1_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/_tkinter.cpython-39-darwin.so
       0x101e90000 -        0x101e93fff +grp.cpython-39-darwin.so (0) <FA1C8744-8E24-32FC-BFD4-8E2710C259F3> /usr/local/Cellar/python at 3.9/3.9.1_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/grp.cpython-39-darwin.so
       0x101ea0000 -        0x101ea3fff +_posixsubprocess.cpython-39-darwin.so (0) <72040909-A8B8-31A4-BB34-FCEEBE259B10> /usr/local/Cellar/python at 3.9/3.9.1_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/_posixsubprocess.cpython-39-darwin.so
       0x101eb0000 -        0x101eb7fff +select.cpython-39-darwin.so (0) <8E448349-CA8B-33AA-8CA1-0EC7B8263EBD> /usr/local/Cellar/python at 3.9/3.9.1_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/select.cpython-39-darwin.so
       0x101ec4000 -        0x101ecbfff +math.cpython-39-darwin.so (0) <0100A69F-B468-3D6C-B4F9-B2A29E275750> /usr/local/Cellar/python at 3.9/3.9.1_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/math.cpython-39-darwin.so
       0x101f18000 -        0x101f27fff +_socket.cpython-39-darwin.so (0) <65641E29-D67A-34BC-9C5C-5AAF7218FB2D> /usr/local/Cellar/python at 3.9/3.9.1_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/_socket.cpython-39-darwin.so
       0x101f34000 -        0x101f3bfff +array.cpython-39-darwin.so (0) <4832969C-4CAD-38DD-BAB8-57B700B67BA8> /usr/local/Cellar/python at 3.9/3.9.1_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/array.cpython-39-darwin.so
       0x101fc8000 -        0x101fcbfff +_opcode.cpython-39-darwin.so (0) <D68FA559-72C5-3925-8FFA-5C967D0D49C8> /usr/local/Cellar/python at 3.9/3.9.1_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/_opcode.cpython-39-darwin.so
       0x101fd8000 -        0x101fdffff +binascii.cpython-39-darwin.so (0) <1089A30F-88D2-398C-91DC-481A4FC355E9> /usr/local/Cellar/python at 3.9/3.9.1_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/binascii.cpython-39-darwin.so
       0x101fec000 -        0x101ff3fff +_struct.cpython-39-darwin.so (0) <A13D09EB-5580-30B9-92DB-D9DC8FFAE4A4> /usr/local/Cellar/python at 3.9/3.9.1_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/_struct.cpython-39-darwin.so
       0x104100000 -        0x10410ffff +_datetime.cpython-39-darwin.so (0) <9829C364-CE52-31D9-AF5F-A07924B8C04E> /usr/local/Cellar/python at 3.9/3.9.1_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/_datetime.cpython-39-darwin.so
       0x104120000 -        0x104143fff +pyexpat.cpython-39-darwin.so (0) <260AD849-DC46-3255-8EEB-FB72BA56A081> /usr/local/Cellar/python at 3.9/3.9.1_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/pyexpat.cpython-39-darwin.so
       0x1041d4000 -        0x1041dbfff +zlib.cpython-39-darwin.so (0) <21AB7C8C-37F8-3307-B9E3-678F62551826> /usr/local/Cellar/python at 3.9/3.9.1_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/zlib.cpython-39-darwin.so
       0x1041e8000 -        0x1041ebfff +_bz2.cpython-39-darwin.so (0) <1B3842B8-378B-3616-A0BA-0BDC38B59005> /usr/local/Cellar/python at 3.9/3.9.1_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/_bz2.cpython-39-darwin.so
       0x1041f8000 -        0x1041fffff +_lzma.cpython-39-darwin.so (0) <BDEEAA25-D32B-3D23-A73A-4611DF13E5D3> /usr/local/Cellar/python at 3.9/3.9.1_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/_lzma.cpython-39-darwin.so
       0x10420c000 -        0x104227fff +liblzma.5.dylib (0) <BA131191-0687-3D90-B9C4-1CCD399AC11F> /usr/local/opt/xz/lib/liblzma.5.dylib
       0x1043b4000 -        0x1043b7fff +_bisect.cpython-39-darwin.so (0) <4B2DACBB-2688-3B15-964F-199DE11351C0> /usr/local/Cellar/python at 3.9/3.9.1_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/_bisect.cpython-39-darwin.so
       0x1043c4000 -        0x1043c7fff +_random.cpython-39-darwin.so (0) <1D4681A8-C095-3EBC-98CE-D95EC276FA83> /usr/local/Cellar/python at 3.9/3.9.1_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/_random.cpython-39-darwin.so
       0x1043d4000 -        0x1043dbfff +_sha512.cpython-39-darwin.so (0) <E478A935-9C0B-3F7F-9C9E-32DE3CD9AD58> /usr/local/Cellar/python at 3.9/3.9.1_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/_sha512.cpython-39-darwin.so
       0x104428000 -        0x104437fff +_pickle.cpython-39-darwin.so (0) <ACF32FA3-223F-39A8-90CF-DADF38060103> /usr/local/Cellar/python at 3.9/3.9.1_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/_pickle.cpython-39-darwin.so
       0x104448000 -        0x10444bfff +_queue.cpython-39-darwin.so (0) <D7CDB18E-1B25-3132-81B2-D62BC08C7D85> /usr/local/Cellar/python at 3.9/3.9.1_1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload/_queue.cpython-39-darwin.so
       0x10a82e000 -        0x10a8c9fff  dyld (832.7.1) <DEA51514-B4E8-3368-979B-89D0F8397ABC> /usr/lib/dyld
    0x7fff2006b000 -     0x7fff2006cfff  libsystem_blocks.dylib (78) <9CF131C6-16FB-3DD0-B046-9E0B6AB99935> /usr/lib/system/libsystem_blocks.dylib
    0x7fff2006d000 -     0x7fff200a2fff  libxpc.dylib (2038.40.38) <003A027D-9CE3-3794-A319-88495844662D> /usr/lib/system/libxpc.dylib
    0x7fff200a3000 -     0x7fff200bafff  libsystem_trace.dylib (1277.50.1) <48C14376-626E-3C81-B0F5-7416E64580C7> /usr/lib/system/libsystem_trace.dylib
    0x7fff200bb000 -     0x7fff20159fff  libcorecrypto.dylib (1000.60.19) <92F0211E-506E-3760-A3C2-808BF3905C07> /usr/lib/system/libcorecrypto.dylib
    0x7fff2015a000 -     0x7fff20186fff  libsystem_malloc.dylib (317.40.8) <2EF43B96-90FB-3C50-B73E-035238504E33> /usr/lib/system/libsystem_malloc.dylib
    0x7fff20187000 -     0x7fff201cbfff  libdispatch.dylib (1271.40.12) <CEF1460B-1362-381A-AE69-6BCE2D8C215B> /usr/lib/system/libdispatch.dylib
    0x7fff201cc000 -     0x7fff20204fff  libobjc.A.dylib (818.2) <45EA2DE2-B612-3486-B156-2359CE279159> /usr/lib/libobjc.A.dylib
    0x7fff20205000 -     0x7fff20207fff  libsystem_featureflags.dylib (28.60.1) <7B4EBDDB-244E-3F78-8895-566FE22288F3> /usr/lib/system/libsystem_featureflags.dylib
    0x7fff20208000 -     0x7fff20290fff  libsystem_c.dylib (1439.40.11) <06D9F593-C815-385D-957F-2B5BCC223A8A> /usr/lib/system/libsystem_c.dylib
    0x7fff20291000 -     0x7fff202e6fff  libc++.1.dylib (904.4) <AE3A940A-7A9C-3F99-B175-3511528D8DFE> /usr/lib/libc++.1.dylib
    0x7fff202e7000 -     0x7fff202fffff  libc++abi.dylib (904.4) <DDFCBF9C-432D-3B8A-8641-578D2EDDCAD8> /usr/lib/libc++abi.dylib
    0x7fff20300000 -     0x7fff2032efff  libsystem_kernel.dylib (7195.60.75) <4BD61365-29AF-3234-8002-D989D295FDBB> /usr/lib/system/libsystem_kernel.dylib
    0x7fff2032f000 -     0x7fff2033afff  libsystem_pthread.dylib (454.60.1) <8DD3A0BC-2C92-31E3-BBAB-CE923A4342E4> /usr/lib/system/libsystem_pthread.dylib
    0x7fff2033b000 -     0x7fff20375fff  libdyld.dylib (832.7.1) <2F8A14F5-7CB8-3EDD-85EA-7FA960BBC04E> /usr/lib/system/libdyld.dylib
    0x7fff20376000 -     0x7fff2037ffff  libsystem_platform.dylib (254.60.1) <3F7F6461-7B5C-3197-ACD7-C8A0CFCC6F55> /usr/lib/system/libsystem_platform.dylib
    0x7fff20380000 -     0x7fff203abfff  libsystem_info.dylib (542.40.3) <0979757C-5F0D-3F5A-9E0E-EBF234B310AF> /usr/lib/system/libsystem_info.dylib
    0x7fff203ac000 -     0x7fff20847fff  com.apple.CoreFoundation (6.9 - 1770.300) <EAC298C4-CE3E-3551-A832-42ED9A13EF74> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
    0x7fff20848000 -     0x7fff20a77fff  com.apple.LaunchServices (1122.11 - 1122.11) <CAEEC254-68AE-39B5-8452-EC3E1EE8577B> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
    0x7fff20a78000 -     0x7fff20b4bfff  com.apple.gpusw.MetalTools (1.0 - 1) <C235D5FA-0B9D-3E72-A8CE-67174E1B9E7C> /System/Library/PrivateFrameworks/MetalTools.framework/Versions/A/MetalTools
    0x7fff20b4c000 -     0x7fff20daffff  libBLAS.dylib (1336.40.1) <AD2D155C-1294-3D10-817A-F6A581E6ACF1> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
    0x7fff20db0000 -     0x7fff20dfdfff  com.apple.Lexicon-framework (1.0 - 86.1) <D54364A6-1C4C-33D7-8B24-C753777B3654> /System/Library/PrivateFrameworks/Lexicon.framework/Versions/A/Lexicon
    0x7fff20dfe000 -     0x7fff20e6cfff  libSparse.dylib (106) <60559226-6E4B-3601-B6CA-E3B85B5EB27B> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libSparse.dylib
    0x7fff20e6d000 -     0x7fff20eeafff  com.apple.SystemConfiguration (1.20 - 1.20) <8524EE4C-628F-315A-9531-44DD83CE275E> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
    0x7fff20eeb000 -     0x7fff20f20fff  libCRFSuite.dylib (50) <6CA29EAA-0585-3682-9AD2-DFD3D87A74D4> /usr/lib/libCRFSuite.dylib
    0x7fff20f21000 -     0x7fff21158fff  libmecabra.dylib (929.1.1) <39F5AD50-3AF2-3CFB-BD21-2DC45AA92A91> /usr/lib/libmecabra.dylib
    0x7fff21159000 -     0x7fff214bcfff  com.apple.Foundation (6.9 - 1770.300) <44A7115B-7FF0-3300-B61B-0FA71B63C715> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
    0x7fff214bd000 -     0x7fff215a9fff  com.apple.LanguageModeling (1.0 - 247.1) <BCB1F8A7-54B9-36D1-B742-70DF7657BF0B> /System/Library/PrivateFrameworks/LanguageModeling.framework/Versions/A/LanguageModeling
    0x7fff215aa000 -     0x7fff216e0fff  com.apple.CoreDisplay (231.3 - 231.3) <229BF97A-1D56-3CB4-8338-E0D464F73A33> /System/Library/Frameworks/CoreDisplay.framework/Versions/A/CoreDisplay
    0x7fff216e1000 -     0x7fff21956fff  com.apple.audio.AudioToolboxCore (1.0 - 1180.23) <56821802-07B9-3FA9-AF73-D943BAE0DE57> /System/Library/PrivateFrameworks/AudioToolboxCore.framework/Versions/A/AudioToolboxCore
    0x7fff21957000 -     0x7fff21b3ffff  com.apple.CoreText (677.2.0.5 - 677.2.0.5) <B0B2A8DD-A6F1-3EF7-9351-1BA604353A11> /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText
    0x7fff21b40000 -     0x7fff221e3fff  com.apple.audio.CoreAudio (5.0 - 5.0) <DF623EC9-FC55-3B3C-94FF-6A5C50A981B3> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
    0x7fff221e4000 -     0x7fff22535fff  com.apple.security (7.0 - 59754.60.13) <A20AB68D-51DA-340B-B813-F2AFC81F7143> /System/Library/Frameworks/Security.framework/Versions/A/Security
    0x7fff22536000 -     0x7fff22797fff  libicucore.A.dylib (66109) <6C0A0196-2778-3035-81CE-7CA48D6C0628> /usr/lib/libicucore.A.dylib
    0x7fff22798000 -     0x7fff227a1fff  libsystem_darwin.dylib (1439.40.11) <BD269412-C9D0-32EE-B42B-B09A187A9B95> /usr/lib/system/libsystem_darwin.dylib
    0x7fff227a2000 -     0x7fff22a89fff  com.apple.CoreServices.CarbonCore (1307 - 1307) <9C615967-6D8E-307F-B028-6278A4FA7C8C> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
    0x7fff22a8a000 -     0x7fff22ac8fff  com.apple.CoreServicesInternal (476 - 476) <FD1692F7-A4B4-3FE5-B9C8-E0840D53C7D0> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal
    0x7fff22ac9000 -     0x7fff22b03fff  com.apple.CSStore (1122.11 - 1122.11) <088D0108-AA14-3610-86A0-89D0C605384F> /System/Library/PrivateFrameworks/CoreServicesStore.framework/Versions/A/CoreServicesStore
    0x7fff22b04000 -     0x7fff22bb1fff  com.apple.framework.IOKit (2.0.2 - 1845.60.2) <F2299682-5884-363F-9069-AA804E712C74> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
    0x7fff22bb2000 -     0x7fff22bbdfff  libsystem_notify.dylib (279.40.4) <98D74EEF-60D9-3665-B877-7BE1558BA83E> /usr/lib/system/libsystem_notify.dylib
    0x7fff22c0a000 -     0x7fff2396cfff  com.apple.AppKit (6.9 - 2022.20.119) <4CB42914-672D-3AF0-A0A5-2209088A3DA0> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
    0x7fff2396d000 -     0x7fff23bc0fff  com.apple.UIFoundation (1.0 - 726.11) <71C63CE5-094D-34AF-B538-8DCAB3B66DE9> /System/Library/PrivateFrameworks/UIFoundation.framework/Versions/A/UIFoundation
    0x7fff23bc1000 -     0x7fff23bd3fff  com.apple.UniformTypeIdentifiers (633.0.2 - 633.0.2) <7BEC7DDC-2B7A-3B5D-B994-5FA352FC485A> /System/Library/Frameworks/UniformTypeIdentifiers.framework/Versions/A/UniformTypeIdentifiers
    0x7fff2402b000 -     0x7fff2466efff  libnetwork.dylib (2288.60.5) <180FE916-8DD6-3385-B231-0C423B7D2BD3> /usr/lib/libnetwork.dylib
    0x7fff2466f000 -     0x7fff24b0cfff  com.apple.CFNetwork (1209.1 - 1209.1) <60DE4CD6-B5AF-3E0E-8AF1-39ECFC1B8C98> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
    0x7fff24b0d000 -     0x7fff24b1bfff  libsystem_networkextension.dylib (1295.60.5) <F476B1CB-3561-30C5-A78E-44E99B1720A3> /usr/lib/system/libsystem_networkextension.dylib
    0x7fff24b1c000 -     0x7fff24b1cfff  libenergytrace.dylib (22) <9BE5E51A-F531-3D59-BBBC-486FFF97BD30> /usr/lib/libenergytrace.dylib
    0x7fff24b1d000 -     0x7fff24b78fff  libMobileGestalt.dylib (978.60.2) <F721B185-0E6A-396B-A50F-0F55810D9A67> /usr/lib/libMobileGestalt.dylib
    0x7fff24b79000 -     0x7fff24b8ffff  libsystem_asl.dylib (385) <940C5BB9-4928-3A63-97F2-132797C8B7E5> /usr/lib/system/libsystem_asl.dylib
    0x7fff24b90000 -     0x7fff24ba7fff  com.apple.TCC (1.0 - 1) <457D5F24-A346-38FC-8FA1-43B0C835E035> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC
    0x7fff24ba8000 -     0x7fff24f0dfff  com.apple.SkyLight (1.600.0 - 569.6) <35876384-45F9-3C62-995B-38EC31BE75D7> /System/Library/PrivateFrameworks/SkyLight.framework/Versions/A/SkyLight
    0x7fff24f0e000 -     0x7fff255a1fff  com.apple.CoreGraphics (2.0 - 1463.2.2) <323F725F-CB03-3AAD-AFBC-37B430B3FD4E> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
    0x7fff255a2000 -     0x7fff25698fff  com.apple.ColorSync (4.13.0 - 3472) <7387EBC7-CBD9-34FE-B4A3-345E4750FD81> /System/Library/Frameworks/ColorSync.framework/Versions/A/ColorSync
    0x7fff25699000 -     0x7fff256f4fff  com.apple.HIServices (1.22 - 713) <9AF2CDD9-8B68-3606-8C9E-1842420ACDA7> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices
    0x7fff25aa0000 -     0x7fff25ebefff  com.apple.CoreData (120 - 1044.3) <76179A55-CA89-3967-A0A7-C419DB735983> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
    0x7fff25ebf000 -     0x7fff25ed5fff  com.apple.ProtocolBuffer (1 - 285.20.8.8.1) <8EE538E7-2BB1-3E29-8FC3-938335998B22> /System/Library/PrivateFrameworks/ProtocolBuffer.framework/Versions/A/ProtocolBuffer
    0x7fff25ed6000 -     0x7fff26095fff  libsqlite3.dylib (321.1) <D7017429-8D46-3ECB-8B70-4625C74918F3> /usr/lib/libsqlite3.dylib
    0x7fff26113000 -     0x7fff2612bfff  com.apple.commonutilities (8.0 - 900) <76711775-FF46-38CA-88F3-B4201C285C7F> /System/Library/PrivateFrameworks/CommonUtilities.framework/Versions/A/CommonUtilities
    0x7fff2612c000 -     0x7fff261adfff  com.apple.BaseBoard (526 - 526) <38C24B3A-8226-3FD5-8C28-B11D02747B56> /System/Library/PrivateFrameworks/BaseBoard.framework/Versions/A/BaseBoard
    0x7fff261ae000 -     0x7fff261f9fff  com.apple.RunningBoardServices (1.0 - 505.60.2) <F99A0D0C-D063-3E3F-8D1F-0E0B35E7CE2C> /System/Library/PrivateFrameworks/RunningBoardServices.framework/Versions/A/RunningBoardServices
    0x7fff261fa000 -     0x7fff2626ffff  com.apple.AE (918.0.1 - 918.0.1) <3A298716-A130-345E-B8FF-74194849015E> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
    0x7fff26270000 -     0x7fff26276fff  libdns_services.dylib (1310.60.4) <61EB26AD-C09E-3140-955E-16BF7DD2D6E3> /usr/lib/libdns_services.dylib
    0x7fff26277000 -     0x7fff2627efff  libsystem_symptoms.dylib (1431.60.1) <88F35AAC-746F-3176-81DF-49CE3D285636> /usr/lib/system/libsystem_symptoms.dylib
    0x7fff2627f000 -     0x7fff26403fff  com.apple.Network (1.0 - 1) <EED4099E-B17C-3E0B-AA8F-78A2D4F26CBF> /System/Library/Frameworks/Network.framework/Versions/A/Network
    0x7fff26404000 -     0x7fff26428fff  com.apple.analyticsd (1.0 - 1) <99FE0234-454F-36FF-9DE9-36B94D8753F9> /System/Library/PrivateFrameworks/CoreAnalytics.framework/Versions/A/CoreAnalytics
    0x7fff26429000 -     0x7fff2642bfff  libDiagnosticMessagesClient.dylib (112) <1014A32B-89EE-3ADD-971F-9CB973172F69> /usr/lib/libDiagnosticMessagesClient.dylib
    0x7fff2642c000 -     0x7fff26478fff  com.apple.spotlight.metadata.utilities (1.0 - 2150.7.2) <37A1E760-2006-366C-9FAC-FB70227393FB> /System/Library/PrivateFrameworks/MetadataUtilities.framework/Versions/A/MetadataUtilities
    0x7fff26479000 -     0x7fff26513fff  com.apple.Metadata (10.7.0 - 2150.7.2) <509C6597-ABB2-3B81-8E09-C51A755CCDA2> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
    0x7fff26514000 -     0x7fff2651afff  com.apple.DiskArbitration (2.7 - 2.7) <83DED679-BE65-3475-8AFF-D664BBAFA60A> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
    0x7fff2651b000 -     0x7fff26bc1fff  com.apple.vImage (8.1 - 544) <305D97CC-B47C-32FD-9EC5-43259A469A14> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
    0x7fff26bc2000 -     0x7fff26e8ffff  com.apple.QuartzCore (1.11 - 925.5) <D59138DC-10CD-3DF8-9F04-CCDB6102C370> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
    0x7fff26e90000 -     0x7fff26ed1fff  libFontRegistry.dylib (309) <790676A3-2B74-3239-A60D-429069933542> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib
    0x7fff26ed2000 -     0x7fff27013fff  com.apple.coreui (2.1 - 689.4) <0DA8F4E0-9473-374E-8B48-F0A40AEC63CE> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI
    0x7fff27100000 -     0x7fff2710bfff  com.apple.PerformanceAnalysis (1.275 - 275) <2F811EE6-D4D4-347E-B4A0-961F0DF050E5> /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis
    0x7fff2710c000 -     0x7fff2711bfff  com.apple.OpenDirectory (11.1 - 230.40.1) <7710743E-6F55-342E-88FA-18796CF83700> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory
    0x7fff2711c000 -     0x7fff2713bfff  com.apple.CFOpenDirectory (11.1 - 230.40.1) <32ECCB06-56D8-3704-935B-7D5363B2988E> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory
    0x7fff2713c000 -     0x7fff27144fff  com.apple.CoreServices.FSEvents (1290.40.2 - 1290.40.2) <FB18B8D7-C7F5-3CAB-B538-3F4B4E85D1F1> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/FSEvents.framework/Versions/A/FSEvents
    0x7fff27145000 -     0x7fff27169fff  com.apple.coreservices.SharedFileList (144 - 144) <93D2192D-7A27-3FD4-B3AB-A4DCBF8419B7> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SharedFileList.framework/Versions/A/SharedFileList
    0x7fff2716a000 -     0x7fff2716cfff  libapp_launch_measurement.dylib (14.1) <9E2700C3-E993-3695-988E-FEF798B75E34> /usr/lib/libapp_launch_measurement.dylib
    0x7fff2716d000 -     0x7fff271b5fff  com.apple.CoreAutoLayout (1.0 - 21.10.1) <998BC461-F4F5-396E-9798-1C8126AD61DA> /System/Library/PrivateFrameworks/CoreAutoLayout.framework/Versions/A/CoreAutoLayout
    0x7fff271b6000 -     0x7fff27298fff  libxml2.2.dylib (34.8) <68396181-8100-390C-8886-EFB79F5B484C> /usr/lib/libxml2.2.dylib
    0x7fff27299000 -     0x7fff272e5fff  com.apple.CoreVideo (1.8 - 408.4) <0D5AD16E-A871-3ACB-B910-39B87928E937> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
    0x7fff272e6000 -     0x7fff272e8fff  com.apple.loginsupport (1.0 - 1) <4F860927-F6F5-3A99-A103-744CF365634F> /System/Library/PrivateFrameworks/login.framework/Versions/A/Frameworks/loginsupport.framework/Versions/A/loginsupport
    0x7fff282c9000 -     0x7fff282d9fff  libsystem_containermanager.dylib (318.60.1) <4ED09A19-04CC-3464-9EFB-F674932020B5> /usr/lib/system/libsystem_containermanager.dylib
    0x7fff282da000 -     0x7fff282ebfff  com.apple.IOSurface (289.3 - 289.3) <A3B10665-5909-30EE-BE34-F3284D6D5975> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface
    0x7fff282ec000 -     0x7fff282f4fff  com.apple.IOAccelerator (439.52 - 439.52) <3944C92D-7838-3D2F-A453-9DB15C815D7B> /System/Library/PrivateFrameworks/IOAccelerator.framework/Versions/A/IOAccelerator
    0x7fff282f5000 -     0x7fff2841afff  com.apple.Metal (244.32.7 - 244.32.7) <413B81AE-653F-3CF7-B5A4-A4391436E6D1> /System/Library/Frameworks/Metal.framework/Versions/A/Metal
    0x7fff2841b000 -     0x7fff28437fff  com.apple.audio.caulk (1.0 - 70) <952BA9D4-BAD3-3319-8C17-F7BB2655F80C> /System/Library/PrivateFrameworks/caulk.framework/Versions/A/caulk
    0x7fff28438000 -     0x7fff28521fff  com.apple.CoreMedia (1.0 - 2760.6.4.6) <CBCD783B-B3C9-37B8-835C-A3BACEC35BB5> /System/Library/Frameworks/CoreMedia.framework/Versions/A/CoreMedia
    0x7fff28522000 -     0x7fff2867efff  libFontParser.dylib (305.2.0.6) <76C6C92A-1B16-3FB7-9EA2-7227D379C20F> /System/Library/PrivateFrameworks/FontServices.framework/libFontParser.dylib
    0x7fff2867f000 -     0x7fff2897efff  com.apple.HIToolbox (2.1.1 - 1060.4) <93518490-429F-3E31-8344-15D479C2F4CE> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
    0x7fff2897f000 -     0x7fff28992fff  com.apple.framework.DFRFoundation (1.0 - 265) <FB85651D-6221-38AF-BD6D-29BFF5830D36> /System/Library/PrivateFrameworks/DFRFoundation.framework/Versions/A/DFRFoundation
    0x7fff28993000 -     0x7fff28996fff  com.apple.dt.XCTTargetBootstrap (1.0 - 17500) <13ADD312-F6F5-3C03-BD3B-9331B3851285> /System/Library/PrivateFrameworks/XCTTargetBootstrap.framework/Versions/A/XCTTargetBootstrap
    0x7fff28997000 -     0x7fff289c0fff  com.apple.CoreSVG (1.0 - 149) <A0DAE6AE-9DDA-37B4-A087-545A242CF982> /System/Library/PrivateFrameworks/CoreSVG.framework/Versions/A/CoreSVG
    0x7fff289c1000 -     0x7fff28bfafff  com.apple.ImageIO (3.3.0 - 2130.2.7) <0FE3D51B-EC76-3558-BD56-7BFF61A6793D> /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
    0x7fff28bfb000 -     0x7fff28f78fff  com.apple.CoreImage (16.1.0 - 1120.10) <46F1E4F5-DF8F-32D4-8D0C-6FCF2C27A5CD> /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage
    0x7fff28f79000 -     0x7fff28fd4fff  com.apple.MetalPerformanceShaders.MPSCore (1.0 - 1) <E2377275-53D7-31A0-AEAF-0A0273B99B92> /System/Library/Frameworks/MetalPerformanceShaders.framework/Versions/A/Frameworks/MPSCore.framework/Versions/A/MPSCore
    0x7fff28fd5000 -     0x7fff28fd8fff  libsystem_configuration.dylib (1109.60.2) <C57B346B-0A03-3F87-BCAC-87B702FA0719> /usr/lib/system/libsystem_configuration.dylib
    0x7fff28fd9000 -     0x7fff28fddfff  libsystem_sandbox.dylib (1441.60.4) <8CE27199-D633-31D2-AB08-56380A1DA9FB> /usr/lib/system/libsystem_sandbox.dylib
    0x7fff28fde000 -     0x7fff28fdffff  com.apple.AggregateDictionary (1.0 - 1) <7F2AFEBB-FF06-3194-B691-B411F3456962> /System/Library/PrivateFrameworks/AggregateDictionary.framework/Versions/A/AggregateDictionary
    0x7fff28fe0000 -     0x7fff28fe3fff  com.apple.AppleSystemInfo (3.1.5 - 3.1.5) <250CD2CA-E796-3CB0-9ADD-054998903B1D> /System/Library/PrivateFrameworks/AppleSystemInfo.framework/Versions/A/AppleSystemInfo
    0x7fff28fe4000 -     0x7fff28fe5fff  liblangid.dylib (136) <224DC045-2B60-39AF-B89E-E524175667F5> /usr/lib/liblangid.dylib
    0x7fff28fe6000 -     0x7fff29086fff  com.apple.CoreNLP (1.0 - 245) <F876FD71-F077-3CF7-B94D-9E05A17E03D7> /System/Library/PrivateFrameworks/CoreNLP.framework/Versions/A/CoreNLP
    0x7fff29087000 -     0x7fff2908dfff  com.apple.LinguisticData (1.0 - 399) <D1B7F1D5-EB9E-3555-BA57-3611FA153C44> /System/Library/PrivateFrameworks/LinguisticData.framework/Versions/A/LinguisticData
    0x7fff2908e000 -     0x7fff2974afff  libBNNS.dylib (288.60.2) <E3FF47D5-7DD9-3A9E-A819-C79B0CC17C03> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBNNS.dylib
    0x7fff2974b000 -     0x7fff2991efff  libvDSP.dylib (760.40.6) <9434101D-E001-357F-9503-9896C6011F52> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
    0x7fff2991f000 -     0x7fff29931fff  com.apple.CoreEmoji (1.0 - 128) <7CCFC59A-8746-3E52-AF1D-1B67798E940C> /System/Library/PrivateFrameworks/CoreEmoji.framework/Versions/A/CoreEmoji
    0x7fff29932000 -     0x7fff2993cfff  com.apple.IOMobileFramebuffer (343.0.0 - 343.0.0) <9A6F913C-EC79-3FC1-A92C-3A1BA96D8DFB> /System/Library/PrivateFrameworks/IOMobileFramebuffer.framework/Versions/A/IOMobileFramebuffer
    0x7fff29c33000 -     0x7fff29c43fff  com.apple.AssertionServices (1.0 - 505.60.2) <9F8620BD-A58D-3A42-9B9E-DEC21517EF1A> /System/Library/PrivateFrameworks/AssertionServices.framework/Versions/A/AssertionServices
    0x7fff29c44000 -     0x7fff29cd0fff  com.apple.securityfoundation (6.0 - 55240.40.4) <5F06D141-62F4-3405-BA72-24673B170A16> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
    0x7fff29cd1000 -     0x7fff29cdafff  com.apple.coreservices.BackgroundTaskManagement (1.0 - 104) <C5E4B35C-FFDA-3423-890F-06DAD1F684F5> /System/Library/PrivateFrameworks/BackgroundTaskManagement.framework/Versions/A/BackgroundTaskManagement
    0x7fff29cdb000 -     0x7fff29cdffff  com.apple.xpc.ServiceManagement (1.0 - 1) <2C03BEB7-915C-3A3A-A44F-A77775E1BFD5> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement
    0x7fff29ce0000 -     0x7fff29ce2fff  libquarantine.dylib (119.40.2) <19D42B9D-3336-3543-AF75-6E605EA31599> /usr/lib/system/libquarantine.dylib
    0x7fff29ce3000 -     0x7fff29ceefff  libCheckFix.dylib (31) <3381FC93-F188-348C-9345-5567A7116CEF> /usr/lib/libCheckFix.dylib
    0x7fff29cef000 -     0x7fff29d06fff  libcoretls.dylib (169) <9C244029-6B45-3583-B27F-BB7BBF84D814> /usr/lib/libcoretls.dylib
    0x7fff29d07000 -     0x7fff29d17fff  libbsm.0.dylib (68.40.1) <DC652D50-FA69-3801-9361-004D4D6832D0> /usr/lib/libbsm.0.dylib
    0x7fff29d18000 -     0x7fff29d61fff  libmecab.dylib (929.1.1) <B5D8C96C-D3B8-32F8-84F9-A432CEAD4E5C> /usr/lib/libmecab.dylib
    0x7fff29d62000 -     0x7fff29d67fff  libgermantok.dylib (24) <F9772A76-7AFA-3E0B-A02C-A61FC6CA8D8B> /usr/lib/libgermantok.dylib
    0x7fff29d68000 -     0x7fff29d7dfff  libLinearAlgebra.dylib (1336.40.1) <D2826FAB-174C-3CD6-A765-06D83A9A0EDB> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLinearAlgebra.dylib
    0x7fff29d7e000 -     0x7fff29fa5fff  com.apple.MetalPerformanceShaders.MPSNeuralNetwork (1.0 - 1) <231CF580-952A-32BC-A423-9B9756AC9744> /System/Library/Frameworks/MetalPerformanceShaders.framework/Versions/A/Frameworks/MPSNeuralNetwork.framework/Versions/A/MPSNeuralNetwork
    0x7fff29fa6000 -     0x7fff29ff5fff  com.apple.MetalPerformanceShaders.MPSRayIntersector (1.0 - 1) <65A993E4-3DC2-3152-98D5-A1DF3DB4573F> /System/Library/Frameworks/MetalPerformanceShaders.framework/Versions/A/Frameworks/MPSRayIntersector.framework/Versions/A/MPSRayIntersector
    0x7fff29ff6000 -     0x7fff2a13cfff  com.apple.MLCompute (1.0 - 1) <BCEA1149-197E-398F-9424-E29B0AD0829F> /System/Library/Frameworks/MLCompute.framework/Versions/A/MLCompute
    0x7fff2a13d000 -     0x7fff2a173fff  com.apple.MetalPerformanceShaders.MPSMatrix (1.0 - 1) <F719DA57-EAAA-3527-B859-21025722932F> /System/Library/Frameworks/MetalPerformanceShaders.framework/Versions/A/Frameworks/MPSMatrix.framework/Versions/A/MPSMatrix
    0x7fff2a174000 -     0x7fff2a1b1fff  com.apple.MetalPerformanceShaders.MPSNDArray (1.0 - 1) <FCCC0D3F-74D2-3107-82B3-E2B500E36AAE> /System/Library/Frameworks/MetalPerformanceShaders.framework/Versions/A/Frameworks/MPSNDArray.framework/Versions/A/MPSNDArray
    0x7fff2a1b2000 -     0x7fff2a242fff  com.apple.MetalPerformanceShaders.MPSImage (1.0 - 1) <21527A17-2D6F-3BDF-9A74-F90FA6E26BB3> /System/Library/Frameworks/MetalPerformanceShaders.framework/Versions/A/Frameworks/MPSImage.framework/Versions/A/MPSImage
    0x7fff2a243000 -     0x7fff2a252fff  com.apple.AppleFSCompression (125 - 1.0) <D1E7DC71-1929-30A8-B73E-268387110608> /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression
    0x7fff2a253000 -     0x7fff2a260fff  libbz2.1.0.dylib (44) <0575C0D0-B107-3E53-857F-DEC55998197B> /usr/lib/libbz2.1.0.dylib
    0x7fff2a261000 -     0x7fff2a265fff  libsystem_coreservices.dylib (127) <A2D875B9-8BA8-33AD-BE92-ADAB915A8D5B> /usr/lib/system/libsystem_coreservices.dylib
    0x7fff2a266000 -     0x7fff2a293fff  com.apple.CoreServices.OSServices (1122.11 - 1122.11) <870F34BE-C0ED-318B-858D-5F1E4757D552> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
    0x7fff2a469000 -     0x7fff2a47bfff  libz.1.dylib (76) <9F89FD60-03F7-3175-AB34-5112B99E2B8A> /usr/lib/libz.1.dylib
    0x7fff2a47c000 -     0x7fff2a4c3fff  libsystem_m.dylib (3186.40.2) <79820D9E-0FF1-3F20-AF4F-F87EE20CE8C9> /usr/lib/system/libsystem_m.dylib
    0x7fff2a4c4000 -     0x7fff2a4c4fff  libcharset.1.dylib (59) <414F6A1C-1EBC-3956-AC2D-CCB0458F31AF> /usr/lib/libcharset.1.dylib
    0x7fff2a4c5000 -     0x7fff2a4cafff  libmacho.dylib (973.4) <28AE1649-22ED-3C4D-A232-29D37F821C39> /usr/lib/system/libmacho.dylib
    0x7fff2a4cb000 -     0x7fff2a4e6fff  libkxld.dylib (7195.60.75) <3600A314-332A-343D-B45D-D9D8B302545D> /usr/lib/system/libkxld.dylib
    0x7fff2a4e7000 -     0x7fff2a4f2fff  libcommonCrypto.dylib (60178.40.2) <1D0A75A5-DEC5-39C6-AB3D-E789B8866712> /usr/lib/system/libcommonCrypto.dylib
    0x7fff2a4f3000 -     0x7fff2a4fdfff  libunwind.dylib (200.10) <C5792A9C-DF0F-3821-BC14-238A78462E8A> /usr/lib/system/libunwind.dylib
    0x7fff2a4fe000 -     0x7fff2a505fff  liboah.dylib (203.13.2) <FF72E19B-3B02-34D4-A821-3397BB28AC02> /usr/lib/liboah.dylib
    0x7fff2a506000 -     0x7fff2a510fff  libcopyfile.dylib (173.40.2) <89483CD4-DA46-3AF2-AE78-FC37CED05ACC> /usr/lib/system/libcopyfile.dylib
    0x7fff2a511000 -     0x7fff2a518fff  libcompiler_rt.dylib (102.2) <0DB26EC8-B4CD-3268-B865-C2FC07E4D2AA> /usr/lib/system/libcompiler_rt.dylib
    0x7fff2a519000 -     0x7fff2a51bfff  libsystem_collections.dylib (1439.40.11) <D40D8097-0ABF-3645-B065-168F43ACFF4C> /usr/lib/system/libsystem_collections.dylib
    0x7fff2a51c000 -     0x7fff2a51efff  libsystem_secinit.dylib (87.60.1) <99B5FD99-1A8B-37C1-BD70-04990FA33B1C> /usr/lib/system/libsystem_secinit.dylib
    0x7fff2a51f000 -     0x7fff2a521fff  libremovefile.dylib (49.40.3) <750012C2-7097-33C3-B796-2766E6CDE8C1> /usr/lib/system/libremovefile.dylib
    0x7fff2a522000 -     0x7fff2a522fff  libkeymgr.dylib (31) <2C7B58B0-BE54-3A50-B399-AA49C19083A9> /usr/lib/system/libkeymgr.dylib
    0x7fff2a523000 -     0x7fff2a52afff  libsystem_dnssd.dylib (1310.60.4) <81EFC44D-450E-3AA3-AC8F-D7EF68F464B4> /usr/lib/system/libsystem_dnssd.dylib
    0x7fff2a52b000 -     0x7fff2a530fff  libcache.dylib (83) <2F7F7303-DB23-359E-85CD-8B2F93223E2A> /usr/lib/system/libcache.dylib
    0x7fff2a531000 -     0x7fff2a532fff  libSystem.B.dylib (1292.60.1) <A7FB4899-9E04-37ED-9DD8-8FFF0400879C> /usr/lib/libSystem.B.dylib
    0x7fff2a533000 -     0x7fff2a536fff  libfakelink.dylib (3) <34B6DC95-E19A-37C0-B9D0-558F692D85F5> /usr/lib/libfakelink.dylib
    0x7fff2a537000 -     0x7fff2a537fff  com.apple.SoftLinking (1.0 - 1) <90D679B3-DFFD-3604-B89F-1BCF70B3EBA4> /System/Library/PrivateFrameworks/SoftLinking.framework/Versions/A/SoftLinking
    0x7fff2a538000 -     0x7fff2a56ffff  libpcap.A.dylib (98.40.1) <E1995A1C-7EEB-3340-B1E1-DD45FA625C12> /usr/lib/libpcap.A.dylib
    0x7fff2a570000 -     0x7fff2a660fff  libiconv.2.dylib (59) <3E53F735-1D7E-3ABB-BC45-AAA37F535830> /usr/lib/libiconv.2.dylib
    0x7fff2a661000 -     0x7fff2a672fff  libcmph.dylib (8) <865FA425-831D-3E49-BD1B-14188D2A98AA> /usr/lib/libcmph.dylib
    0x7fff2a673000 -     0x7fff2a6e4fff  libarchive.2.dylib (83.40.4) <76B2F421-5335-37FB-9CD5-1018878B9E74> /usr/lib/libarchive.2.dylib
    0x7fff2a6e5000 -     0x7fff2a74cfff  com.apple.SearchKit (1.4.1 - 1.4.1) <7BDD2800-BDDC-3DE0-A4A8-B1E855130E3B> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
    0x7fff2a74d000 -     0x7fff2a74efff  libThaiTokenizer.dylib (3) <513547CD-5C7F-37BE-A2AD-55A22F279588> /usr/lib/libThaiTokenizer.dylib
    0x7fff2a74f000 -     0x7fff2a776fff  com.apple.applesauce (1.0 - 16.26) <AE525243-2CE7-373E-994E-C2457611EB3C> /System/Library/PrivateFrameworks/AppleSauce.framework/Versions/A/AppleSauce
    0x7fff2a777000 -     0x7fff2a78efff  libapple_nghttp2.dylib (1.41) <CC004768-6E3B-3D80-9431-61149EBE2E10> /usr/lib/libapple_nghttp2.dylib
    0x7fff2a78f000 -     0x7fff2a7a1fff  libSparseBLAS.dylib (1336.40.1) <CEBD7B0F-A54D-3A43-BD7E-E8BC2C7B7F0C> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libSparseBLAS.dylib
    0x7fff2a7a2000 -     0x7fff2a7a3fff  com.apple.MetalPerformanceShaders.MetalPerformanceShaders (1.0 - 1) <1BFEB124-CF05-342F-BC65-B233EAB661D9> /System/Library/Frameworks/MetalPerformanceShaders.framework/Versions/A/MetalPerformanceShaders
    0x7fff2a7a4000 -     0x7fff2a7a8fff  libpam.2.dylib (28.40.1) <AE84F5FA-DDB0-3028-AF25-D6B6A12DBA6A> /usr/lib/libpam.2.dylib
    0x7fff2a7a9000 -     0x7fff2a7c1fff  libcompression.dylib (96.40.6) <45B8B821-8EB6-34FE-92E9-5CBA474499E2> /usr/lib/libcompression.dylib
    0x7fff2a7c2000 -     0x7fff2a7c7fff  libQuadrature.dylib (7) <FB21F53D-4A40-327F-BD3B-C7C8D08C6A86> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libQuadrature.dylib
    0x7fff2a7c8000 -     0x7fff2ab64fff  libLAPACK.dylib (1336.40.1) <509FBCC6-4ECB-3192-98A6-D0C030E4E9D8> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
    0x7fff2ab65000 -     0x7fff2abb3fff  com.apple.DictionaryServices (1.2 - 341) <83CDCE83-6B48-35F1-BACF-83240D940777> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
    0x7fff2abb4000 -     0x7fff2abccfff  liblzma.5.dylib (16) <A45348BC-AA9C-39D6-A7C3-2246A3EFA34C> /usr/lib/liblzma.5.dylib
    0x7fff2abcd000 -     0x7fff2abcefff  libcoretls_cfhelpers.dylib (169) <C0F19E92-DACB-3100-8610-62DEC5E5FB81> /usr/lib/libcoretls_cfhelpers.dylib
    0x7fff2abcf000 -     0x7fff2acc8fff  com.apple.APFS (1677.60.23 - 1677.60.23) <8271EE40-CDF5-3E0B-9F42-B49DC7C46C98> /System/Library/PrivateFrameworks/APFS.framework/Versions/A/APFS
    0x7fff2acc9000 -     0x7fff2acd6fff  libxar.1.dylib (452) <3F3DA942-DC7B-31EF-BCF1-38F99F59A660> /usr/lib/libxar.1.dylib
    0x7fff2acd7000 -     0x7fff2acdafff  libutil.dylib (58.40.2) <85CF2B3B-6BEB-381D-8683-1DE2B0167ECC> /usr/lib/libutil.dylib
    0x7fff2acdb000 -     0x7fff2ad03fff  libxslt.1.dylib (17.2) <2C881E82-6E2C-3E92-8DC5-3C2D05FE7C95> /usr/lib/libxslt.1.dylib
    0x7fff2ad04000 -     0x7fff2ad0efff  libChineseTokenizer.dylib (37) <36891BB5-4A83-33A3-9995-CC5DB2AB53CE> /usr/lib/libChineseTokenizer.dylib
    0x7fff2ad0f000 -     0x7fff2adcdfff  libvMisc.dylib (760.40.6) <219319E1-BDBD-34D1-97B7-E46256785D3C> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
    0x7fff2adce000 -     0x7fff2ae66fff  libate.dylib (3.0.4) <51D50D08-F614-3929-AFB1-BF4ED9BE4751> /usr/lib/libate.dylib
    0x7fff2ae67000 -     0x7fff2ae6efff  libIOReport.dylib (64) <3C26FBDC-931E-3318-8225-C10849CF1D60> /usr/lib/libIOReport.dylib
    0x7fff2b01e000 -     0x7fff2b071fff  com.apple.AppleVAFramework (6.1.3 - 6.1.3) <8A5B1C42-DD83-303B-85DE-754FB6C10E1A> /System/Library/PrivateFrameworks/AppleVA.framework/Versions/A/AppleVA
    0x7fff2b072000 -     0x7fff2b08bfff  libexpat.1.dylib (26) <4408FC72-BDAA-33AE-BE14-4008642794ED> /usr/lib/libexpat.1.dylib
    0x7fff2b08c000 -     0x7fff2b095fff  libheimdal-asn1.dylib (597.40.10) <032931C8-B042-3B3D-93D3-5B3E27431FEA> /usr/lib/libheimdal-asn1.dylib
    0x7fff2b096000 -     0x7fff2b0aafff  com.apple.IconFoundation (479.3 - 479.3) <650C91C9-D6A1-3FF7-964B-DE1065F2243C> /System/Library/PrivateFrameworks/IconFoundation.framework/Versions/A/IconFoundation
    0x7fff2b0ab000 -     0x7fff2b118fff  com.apple.IconServices (479.3 - 479.3) <63CAB1AB-C485-382A-9088-F6E3937BB8E9> /System/Library/PrivateFrameworks/IconServices.framework/Versions/A/IconServices
    0x7fff2b119000 -     0x7fff2b1b6fff  com.apple.MediaExperience (1.0 - 1) <A7A754CE-61AB-39B8-AA31-3AEB14695F55> /System/Library/PrivateFrameworks/MediaExperience.framework/Versions/A/MediaExperience
    0x7fff2b1b7000 -     0x7fff2b1e0fff  com.apple.persistentconnection (1.0 - 1.0) <C3F975D3-A87C-353C-BA1F-072825E60E8C> /System/Library/PrivateFrameworks/PersistentConnection.framework/Versions/A/PersistentConnection
    0x7fff2b1e1000 -     0x7fff2b1effff  com.apple.GraphVisualizer (1.0 - 100.1) <7035CCDF-5B9D-365C-A1FA-1D961EBEE44D> /System/Library/PrivateFrameworks/GraphVisualizer.framework/Versions/A/GraphVisualizer
    0x7fff2b1f0000 -     0x7fff2b60bfff  com.apple.vision.FaceCore (4.3.2 - 4.3.2) <E0518821-B65D-31A4-8C37-DF3569CF8867> /System/Library/PrivateFrameworks/FaceCore.framework/Versions/A/FaceCore
    0x7fff2b60c000 -     0x7fff2b656fff  com.apple.OTSVG (1.0 - 677.2.0.5) <D2722431-6C71-3144-A024-6ED06334AEE0> /System/Library/PrivateFrameworks/OTSVG.framework/Versions/A/OTSVG
    0x7fff2b657000 -     0x7fff2b65dfff  com.apple.xpc.AppServerSupport (1.0 - 2038.40.38) <27B96AA0-421E-3E5A-B9D8-9BA3F0D133E9> /System/Library/PrivateFrameworks/AppServerSupport.framework/Versions/A/AppServerSupport
    0x7fff2b65e000 -     0x7fff2b66ffff  libhvf.dylib (1.0 - $[CURRENT_PROJECT_VERSION]) <CAD78803-0F56-316E-A7F1-D2BF26CA2DD6> /System/Library/PrivateFrameworks/FontServices.framework/libhvf.dylib
    0x7fff2b670000 -     0x7fff2b672fff  libspindump.dylib (295) <C6F804A3-5682-3766-A324-76667364873D> /usr/lib/libspindump.dylib
    0x7fff2b673000 -     0x7fff2b733fff  com.apple.Heimdal (4.0 - 2.0) <8BB18335-5DD3-3154-85C8-0145C64556A2> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal
    0x7fff2b8d2000 -     0x7fff2b93cfff  com.apple.bom (14.0 - 233) <A62EEEE5-3027-3F25-BCD9-32D36922106E> /System/Library/PrivateFrameworks/Bom.framework/Versions/A/Bom
    0x7fff2b93d000 -     0x7fff2b987fff  com.apple.AppleJPEG (1.0 - 1) <A2E9E2A4-AEDC-3481-BDC9-05D9AD84FC25> /System/Library/PrivateFrameworks/AppleJPEG.framework/Versions/A/AppleJPEG
    0x7fff2b988000 -     0x7fff2ba66fff  libJP2.dylib (2130.2.7) <9D837C01-3D6C-3D71-8E92-3673CE06A21F> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib
    0x7fff2ba67000 -     0x7fff2ba6afff  com.apple.WatchdogClient.framework (1.0 - 98.60.1) <8374BBBB-65CB-3D46-9AD6-0DD1FB99AD88> /System/Library/PrivateFrameworks/WatchdogClient.framework/Versions/A/WatchdogClient
    0x7fff2ba6b000 -     0x7fff2ba9efff  com.apple.MultitouchSupport.framework (4400.28 - 4400.28) <E9A95272-5E84-3B64-8263-8C7F84456269> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport
    0x7fff2ba9f000 -     0x7fff2bbf1fff  com.apple.VideoToolbox (1.0 - 2760.6.4.6) <35098775-A188-3BE0-B0B1-7CE0027BA295> /System/Library/Frameworks/VideoToolbox.framework/Versions/A/VideoToolbox
    0x7fff2bbf2000 -     0x7fff2bc24fff  libAudioToolboxUtility.dylib (1180.23) <58B4505B-F0EA-37FC-9F5A-6F9F05B0F2A5> /usr/lib/libAudioToolboxUtility.dylib
    0x7fff2bc25000 -     0x7fff2bc4bfff  libPng.dylib (2130.2.7) <1F3FED3B-FB07-3F43-8EAD-6100017FBAB5> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
    0x7fff2bc4c000 -     0x7fff2bca9fff  libTIFF.dylib (2130.2.7) <27E9A2D3-003D-3D97-AD85-BE595EA0516F> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
    0x7fff2bcaa000 -     0x7fff2bcc4fff  com.apple.IOPresentment (53 - 37) <070919DC-978E-3DB3-80FD-FB0C1BAAE80A> /System/Library/PrivateFrameworks/IOPresentment.framework/Versions/A/IOPresentment
    0x7fff2bcc5000 -     0x7fff2bccbfff  com.apple.GPUWrangler (6.2.2 - 6.2.2) <F4B3905F-C024-33C1-82C8-F1744AF8516E> /System/Library/PrivateFrameworks/GPUWrangler.framework/Versions/A/GPUWrangler
    0x7fff2bccc000 -     0x7fff2bccffff  libRadiance.dylib (2130.2.7) <7ABF94D2-5281-363F-A613-9C945D77AAE8> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib
    0x7fff2bcd0000 -     0x7fff2bcd5fff  com.apple.DSExternalDisplay (3.1 - 380) <BA802582-F1EB-35B8-902F-3D0F426124E0> /System/Library/PrivateFrameworks/DSExternalDisplay.framework/Versions/A/DSExternalDisplay
    0x7fff2bcd6000 -     0x7fff2bcfafff  libJPEG.dylib (2130.2.7) <FDD55379-6673-31E4-B916-7949459B60AE> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
    0x7fff2bcfb000 -     0x7fff2bd2afff  com.apple.ATSUI (1.0 - 1) <B82D099B-4F53-3B60-8BAA-975C41EFD356> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATSUI.framework/Versions/A/ATSUI
    0x7fff2bd2b000 -     0x7fff2bd2ffff  libGIF.dylib (2130.2.7) <C51FB0BA-E5C0-335B-9C64-185B1DDC9166> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib
    0x7fff2bd30000 -     0x7fff2bd39fff  com.apple.CMCaptureCore (1.0 - 80.17.1.1) <A0D43E58-B960-3A80-8807-4115F0E1EF74> /System/Library/PrivateFrameworks/CMCaptureCore.framework/Versions/A/CMCaptureCore
    0x7fff2bd3a000 -     0x7fff2bd81fff  com.apple.print.framework.PrintCore (16 - 531) <FC56A643-F502-3578-9EFF-375BE6B87691> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
    0x7fff2bd82000 -     0x7fff2be4efff  com.apple.TextureIO (3.10.9 - 3.10.9) <0AC15003-4B6A-3FB3-9B41-3EF61A2BD430> /System/Library/PrivateFrameworks/TextureIO.framework/Versions/A/TextureIO
    0x7fff2be4f000 -     0x7fff2be57fff  com.apple.InternationalSupport (1.0 - 60) <5485FFDC-CE44-37F4-865F-91B2EFBC6CAF> /System/Library/PrivateFrameworks/InternationalSupport.framework/Versions/A/InternationalSupport
    0x7fff2be58000 -     0x7fff2bed3fff  com.apple.datadetectorscore (8.0 - 674) <A2DEEF63-7643-37AA-9420-ED875629D1B2> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore
    0x7fff2bed4000 -     0x7fff2bf32fff  com.apple.UserActivity (435 - 435) <075FD354-28FD-3A13-881C-955FA9106D5C> /System/Library/PrivateFrameworks/UserActivity.framework/Versions/A/UserActivity
    0x7fff2cb80000 -     0x7fff2cbb1fff  libSessionUtility.dylib (76.7) <95615EDE-46B9-32AE-96EC-7F6E5EB6A932> /System/Library/PrivateFrameworks/AudioSession.framework/libSessionUtility.dylib
    0x7fff2cbb2000 -     0x7fff2cce2fff  com.apple.audio.toolbox.AudioToolbox (1.14 - 1.14) <D0F9F628-F241-3FA2-A785-7B9DCBB2FEC4> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
    0x7fff2cce3000 -     0x7fff2cd4afff  com.apple.audio.AudioSession (1.0 - 76.7) <C0B1C9EB-A594-31E3-ADDF-118583840E6F> /System/Library/PrivateFrameworks/AudioSession.framework/Versions/A/AudioSession
    0x7fff2cd4b000 -     0x7fff2cd5dfff  libAudioStatistics.dylib (25.1) <1D07EA54-BE7C-37C4-AA73-5224D402F0C3> /usr/lib/libAudioStatistics.dylib
    0x7fff2cd5e000 -     0x7fff2cd6dfff  com.apple.speech.synthesis.framework (9.0.51 - 9.0.51) <B86A2136-8DD7-395D-BB9F-9416C56DD2D6> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis
    0x7fff2cd6e000 -     0x7fff2cdd9fff  com.apple.ApplicationServices.ATS (377 - 516) <3A435648-CC5F-387E-AB37-391AAEABE314> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS
    0x7fff2cdda000 -     0x7fff2cdf2fff  libresolv.9.dylib (68) <9957A6F4-8B66-3429-86CD-6DF4993EB6F5> /usr/lib/libresolv.9.dylib
    0x7fff2cf25000 -     0x7fff2d004fff  libSMC.dylib (20) <CE5162B7-379E-3DF0-9D1E-44BC98BD2422> /usr/lib/libSMC.dylib
    0x7fff2d005000 -     0x7fff2d064fff  libcups.2.dylib (494.1) <04A4801E-E1B5-3919-9F14-100F0C2D049B> /usr/lib/libcups.2.dylib
    0x7fff2d065000 -     0x7fff2d074fff  com.apple.LangAnalysis (1.7.0 - 254) <120945D9-B74D-3A6F-B160-2678E6B6481D> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis
    0x7fff2d075000 -     0x7fff2d07ffff  com.apple.NetAuth (6.2 - 6.2) <C65B2F54-67EA-3E4D-B84A-BBA94998BD6B> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth
    0x7fff2d080000 -     0x7fff2d087fff  com.apple.ColorSyncLegacy (4.13.0 - 1) <33DA9348-EADF-36D2-B999-56854481D272> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSyncLegacy.framework/Versions/A/ColorSyncLegacy
    0x7fff2d088000 -     0x7fff2d093fff  com.apple.QD (4.0 - 416) <7FFC9049-7E42-372B-9105-1C4C94DE0110> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD
    0x7fff2d094000 -     0x7fff2d702fff  com.apple.audio.AudioResourceArbitration (1.0 - 1) <098FD431-D302-3DD5-9AD1-453615A73E68> /System/Library/PrivateFrameworks/AudioResourceArbitration.framework/Versions/A/AudioResourceArbitration
    0x7fff2d703000 -     0x7fff2d70ffff  com.apple.perfdata (1.0 - 67.40.1) <85A57A67-8721-3035-BCEE-D4AC98332D2C> /System/Library/PrivateFrameworks/perfdata.framework/Versions/A/perfdata
    0x7fff2d710000 -     0x7fff2d71efff  libperfcheck.dylib (41) <67113817-A463-360A-B321-9286DC50FEDA> /usr/lib/libperfcheck.dylib
    0x7fff2d71f000 -     0x7fff2d72efff  com.apple.Kerberos (3.0 - 1) <2E872705-0841-3695-AF79-4160D2A436AB> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
    0x7fff2d72f000 -     0x7fff2d77efff  com.apple.GSS (4.0 - 2.0) <2A38D59F-5F3A-3779-A421-2F8128F22B95> /System/Library/Frameworks/GSS.framework/Versions/A/GSS
    0x7fff2d77f000 -     0x7fff2d78ffff  com.apple.CommonAuth (4.0 - 2.0) <D9431F22-A16B-3237-9676-B6159B36F5EA> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth
    0x7fff2d964000 -     0x7fff2d964fff  liblaunch.dylib (2038.40.38) <05A7EFDD-4111-3E4D-B668-239B69DE3D0F> /usr/lib/system/liblaunch.dylib
    0x7fff2fb8a000 -     0x7fff2fbb5fff  com.apple.RemoteViewServices (2.0 - 163) <AC6E2D2F-8131-3A40-97D7-E24E2A45CD66> /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices
    0x7fff2fbb6000 -     0x7fff2fbc5fff  com.apple.SpeechRecognitionCore (6.1.12 - 6.1.12) <F2A0E41A-7976-3175-959A-98DC24AAFFCC> /System/Library/PrivateFrameworks/SpeechRecognitionCore.framework/Versions/A/SpeechRecognitionCore
    0x7fff2fbc6000 -     0x7fff2fbcdfff  com.apple.speech.recognition.framework (6.0.3 - 6.0.3) <9C14FA0A-D905-375B-8C32-E311ED59B6AD> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition
    0x7fff2fe11000 -     0x7fff2fe11fff  libsystem_product_info_filter.dylib (8.40.1) <7CCAF1A8-F570-341E-B275-0C80B092F8E0> /usr/lib/system/libsystem_product_info_filter.dylib
    0x7fff2feec000 -     0x7fff2feecfff  com.apple.Accelerate.vecLib (3.11 - vecLib 3.11) <510A463F-5CA5-3585-969F-2D44583B71C8> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
    0x7fff2ff13000 -     0x7fff2ff13fff  com.apple.CoreServices (1122.11 - 1122.11) <5DDB040C-6E92-3DBE-9049-873F510F26E2> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
    0x7fff301e1000 -     0x7fff301e1fff  com.apple.Accelerate (1.11 - Accelerate 1.11) <F2FFCC7B-EE3D-3768-A73B-342851B53741> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
    0x7fff32f61000 -     0x7fff32f64fff  com.apple.help (1.3.8 - 71) <599F7E42-DEF1-3B70-83AB-C3BDF727CF93> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help
    0x7fff331a6000 -     0x7fff331a6fff  com.apple.ApplicationServices (48 - 50) <7B536871-3F10-3138-B06B-9C2A3C07EC1E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
    0x7fff334a6000 -     0x7fff334a6fff  libHeimdalProxy.dylib (79) <1BD94BF6-8E63-3B21-95DC-E5EEEBFB8AE8> /System/Library/Frameworks/Kerberos.framework/Versions/A/Libraries/libHeimdalProxy.dylib
    0x7fff34fa7000 -     0x7fff34faafff  com.apple.Cocoa (6.11 - 23) <E44AC98B-5BEA-3087-AB41-C73CEB8A98C8> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
    0x7fff363ea000 -     0x7fff36405fff  com.apple.openscripting (1.7 - 190) <D0B98DF9-7A61-3810-AE81-2F870DCC2AC0> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting
    0x7fff36406000 -     0x7fff36409fff  com.apple.securityhi (9.0 - 55008) <DD7770F7-661C-363B-A1F4-8B69EB0FFB6A> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI
    0x7fff3640a000 -     0x7fff3640dfff  com.apple.ink.framework (10.15 - 227) <E10C40B6-2656-36D1-882C-2091CE02883A> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink
    0x7fff3640e000 -     0x7fff36411fff  com.apple.CommonPanels (1.2.6 - 101) <101582BA-E64F-391A-BD23-50DCC3CF8939> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels
    0x7fff36412000 -     0x7fff36419fff  com.apple.ImageCapture (1708 - 1708) <FE9D13DD-D733-3B2A-B4A6-D3C8313005F5> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture
    0x7fff3d104000 -     0x7fff3d107fff  com.apple.print.framework.Print (15 - 271) <8411879F-7E3E-3882-BD06-68E797A3B9D6> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print
    0x7fff3d108000 -     0x7fff3d10bfff  com.apple.Carbon (160 - 164) <5683716A-5610-3B97-B473-B4652067E7A6> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
    0x7fff3d390000 -     0x7fff3d3affff  com.apple.private.SystemPolicy (1.0 - 1) <CFE0B0C6-DF5B-31EB-9D79-B23E00A80B05> /System/Library/PrivateFrameworks/SystemPolicy.framework/Versions/A/SystemPolicy
    0x7fff3dcfa000 -     0x7fff3dd0cfff  libmis.dylib (274.60.2) <54387457-A60B-3390-AD6D-3B380792CD79> /usr/lib/libmis.dylib
    0x7fff6c804000 -     0x7fff6c80afff  libCoreFSCache.dylib (177.22) <4ECE128D-5E79-3ADF-8FE7-4FE8F565F8AA> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreFSCache.dylib
    0x7fff6c80b000 -     0x7fff6c80ffff  libCoreVMClient.dylib (177.22) <E0DBED1D-39B4-3E51-9EA8-D1ECAED93EAB> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib
    0x7fff6c810000 -     0x7fff6c81ffff  com.apple.opengl (18.1.1 - 18.1.1) <D8EE3AD0-C0D0-32F7-9C6D-39341099EB55> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
    0x7fff6c820000 -     0x7fff6c822fff  libCVMSPluginSupport.dylib (18.1.1) <5F020D32-8663-3CB8-A50C-F939D4D4C31F> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib
    0x7fff6c823000 -     0x7fff6c82bfff  libGFXShared.dylib (18.1.1) <2271532D-E2B3-3D4D-ADF0-0935F8DCE89B> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib
    0x7fff6c82c000 -     0x7fff6c85ffff  libGLImage.dylib (18.1.1) <528E53A3-33E1-34C7-8EE3-C42AE5255553> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
    0x7fff6c860000 -     0x7fff6c89cfff  libGLU.dylib (18.1.1) <15CBDF20-8A87-3D84-90F8-D19F4A2B06E2> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib
    0x7fff6ca32000 -     0x7fff6ca3cfff  libGL.dylib (18.1.1) <157B74E1-F30D-3F9D-9AF8-AAA333D2812D> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
    0x7fff6de73000 -     0x7fff6decbfff  com.apple.opencl (4.5 - 4.5) <8A3D06D5-4E82-355C-AE1B-E2C91DB58233> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
    0x7fff6fd89000 -     0x7fff6fe54fff  Tcl (8.5.9 - 8.5.9) <51600BFF-7BDA-3446-9BAA-5800C815A91E> /System/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl
    0x7fff6fe55000 -     0x7fff6ff39fff  Tk (8.5.9 - 8.5.9) <DA21CF89-6AE9-3430-8085-83522AA426A7> /System/Library/Frameworks/Tk.framework/Versions/8.5/Tk

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: 790
    thread_create: 0
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=664.8M resident=0K(0%) swapped_out_or_unallocated=664.8M(100%)
Writable regions: Total=96.8M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=96.8M(100%)
 
                                VIRTUAL   REGION 
REGION TYPE                        SIZE    COUNT (non-coalesced) 
===========                     =======  ======= 
Activity Tracing                   256K        1 
Dispatch continuations            32.0M        1 
Kernel Alloc Once                    8K        1 
MALLOC                            37.6M       21 
MALLOC guard page                   16K        4 
MALLOC_LARGE (reserved)            384K        1         reserved VM address space (unallocated)
STACK GUARD                         24K        6 
Stack                             18.5M        6 
VM_ALLOCATE                       8404K       43 
__DATA                            11.2M      281 
__DATA_CONST                      11.3M      175 
__DATA_DIRTY                       509K       86 
__FONT_DATA                          4K        1 
__LINKEDIT                       490.1M       48 
__OBJC_RO                         60.5M        1 
__OBJC_RW                         2452K        2 
__TEXT                           174.9M      289 
__UNICODE                          588K        1 
mapped file                       48.8M        9 
shared memory                       40K        4 
===========                     =======  ======= 
TOTAL                            897.3M      981 
TOTAL, minus reserved VM space   896.9M      981 

Model: MacBookAir9,1, BootROM 1554.60.15.0.0 (iBridge: 18.16.13030.0.0,0), 2 processors, Dual-Core Intel Core i3, 1,1 GHz, 8 GB, SMC 
Graphics: kHW_IntelIrisPlusGraphicsItem, Intel Iris Plus Graphics, spdisplays_builtin
Memory Module: BANK 0/ChannelA-DIMM0, 4 GB, LPDDR4X, 3733 MHz, SK Hynix, H9HCNNNCRMALPR-NEE
Memory Module: BANK 2/ChannelB-DIMM0, 4 GB, LPDDR4X, 3733 MHz, SK Hynix, H9HCNNNCRMALPR-NEE
AirPort: spairport_wireless_card_type_airport_extreme, wl0: Sep 11 2020 17:38:16 version 16.20.293.5.3.6.95 FWID 01-e5bd2163
Bluetooth: Version 8.0.2f9, 3 services, 27 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
USB Device: USB 3.1 Bus
USB Device: USB 3.1 Bus
USB Device: Apple T2 Bus
USB Device: Touch Bar Backlight
USB Device: Apple Internal Keyboard / Trackpad
USB Device: Headset
USB Device: Ambient Light Sensor
USB Device: FaceTime HD Camera (Built-in)
USB Device: Apple T2 Controller
Thunderbolt Bus: MacBook Air, Apple Inc., 85.0

----------
assignee: terry.reedy
components: IDLE
messages: 383436
nosy: p.sirenko.94, terry.reedy
priority: normal
severity: normal
status: open
title: macOS 11.1 + Homebrew 2.6.2 + python 3.9.1 = idle crash
type: crash
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42691>
_______________________________________

From report at bugs.python.org  Sun Dec 20 16:18:24 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 20 Dec 2020 21:18:24 +0000
Subject: [issue42669] "except" documentation still suggests nested tuples are
 allowed
In-Reply-To: <1608211677.22.0.0507603390583.issue42669@roundup.psfhosted.org>
Message-ID: <1608499104.49.0.0476542126472.issue42669@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset 409ce4a09e4f96ca9b251c19f5819205aae9ae34 by Miss Islington (bot) in branch '3.9':
bpo-42669: Document that `except` rejects nested tuples (GH-23822) (GH-23870)
https://github.com/python/cpython/commit/409ce4a09e4f96ca9b251c19f5819205aae9ae34


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42669>
_______________________________________

From report at bugs.python.org  Sun Dec 20 16:18:45 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 20 Dec 2020 21:18:45 +0000
Subject: [issue42669] "except" documentation still suggests nested tuples are
 allowed
In-Reply-To: <1608211677.22.0.0507603390583.issue42669@roundup.psfhosted.org>
Message-ID: <1608499125.09.0.235440765293.issue42669@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:


New changeset 81f706d2db0f57c4fdd747df6e0a4cffcbc54704 by Miss Islington (bot) in branch '3.8':
bpo-42669: Document that `except` rejects nested tuples (GH-23822) (GH-23871)
https://github.com/python/cpython/commit/81f706d2db0f57c4fdd747df6e0a4cffcbc54704


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42669>
_______________________________________

From report at bugs.python.org  Sun Dec 20 16:20:03 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 20 Dec 2020 21:20:03 +0000
Subject: [issue42669] "except" documentation still suggests nested tuples are
 allowed
In-Reply-To: <1608211677.22.0.0507603390583.issue42669@roundup.psfhosted.org>
Message-ID: <1608499203.44.0.852021693459.issue42669@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42669>
_______________________________________

From report at bugs.python.org  Sun Dec 20 16:22:53 2020
From: report at bugs.python.org (Justin)
Date: Sun, 20 Dec 2020 21:22:53 +0000
Subject: [issue42695] tkinter keysym_num value is incorrect
Message-ID: <1608499373.07.0.718041853104.issue42695@roundup.psfhosted.org>


New submission from Justin <justin.a.black at gmail.com>:

Hi there.
On my MacOS 10.14.16 laptop with a qwerty keyboard I was testing tkinter keyboard listening for an azerty keyboard layout by switching the layout to `French - PC`
When I press qwerty keys Shift + \ I expect to see '?' printed.
When looking at the tkinter events for that key press we see:
```
down {'keysym': 'Shift_L', 'keysym_num': 65505, 'keycode': 131072, 'char': ''}
down {'keysym': 'tslash', 'keysym_num': 956, 'keycode': 956, 'char': '?'}
up {'keysym': 'asterisk', 'keysym_num': 42, 'keycode': 2753468, 'char': '?'}
up {'keysym': 'Shift_L', 'keysym_num': 65505, 'keycode': 131072, 'char': ''}
```
So the char value is correct but the keysym_num is not the expected 181 for mu.
Comparing this to pressing Shift + / to generate the section symbol (?) we see:
```
down {'keysym': 'Shift_L', 'keysym_num': 65505, 'keycode': 131072, 'char': ''}
down {'keysym': 'section', 'keysym_num': 167, 'keycode': 167, 'char': '?'}
up {'keysym': 'section', 'keysym_num': 167, 'keycode': 2883751, 'char': '?'}
up {'keysym': 'Shift_L', 'keysym_num': 65505, 'keycode': 131072, 'char': ''}
```
Which produces the expected keysym_num of 167.

TLDR: the kysym_num value when writing the mu character is incorrect. It should be 181 and logging shows values of 956 and 42. Can this be fixed?

Here is the keyboard listener program which can be used for verification:
```
from tkinter import *

params = ['keysym', 'keysym_num', 'keycode', 'char']

def keyup(e):
    d = {p: getattr(e, p) for p in params}
    print('up', d)
    # print('up', e.__dict__)
def keydown(e):
    d = {p: getattr(e, p) for p in params}
    print('down', d)
    # print('down', e.__dict__)
    pass

root = Tk()
frame = Frame(root, width=100, height=100)
frame.bind("<KeyPress>", keydown)
frame.bind("<KeyRelease>", keyup)
frame.pack()
frame.focus_set()
root.mainloop()
```
Note: my python version was installed from python.org and is:
```
Python 3.9.1 (v3.9.1:1e5d33e9b9, Dec  7 2020, 12:44:01) 
[Clang 12.0.0 (clang-1200.0.32.27)] on darwin
```

----------
messages: 383458
nosy: spacether
priority: normal
severity: normal
status: open
title: tkinter keysym_num value is incorrect

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42695>
_______________________________________

From report at bugs.python.org  Sun Dec 20 16:25:46 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 20 Dec 2020 21:25:46 +0000
Subject: [issue42693] "if 0:" lines are traced; they didn't use to be
In-Reply-To: <1608498368.47.0.692310939381.issue42693@roundup.psfhosted.org>
Message-ID: <1608499546.34.0.509380732611.issue42693@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Confirmed.  There is bogus NOP in the code.

=======================================================================

Python 3.10.0a3+ (heads/master:17ef4319a3, Dec 18 2020, 09:35:26)
[Clang 12.0.0 (clang-1200.0.32.28)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from textwrap import dedent
>>> from dis import dis
>>> s = '''
        x = 10
        if 0:
                print('hello')
        y = 20
'''
>>> code = compile(dedent(s), '', 'exec')
>>> list(code.co_code)
[100, 0, 90, 0, 9, 0, 100, 3, 90, 2, 100, 4, 83, 0]
>>> dis(code)
  2           0 LOAD_CONST               0 (10)
              2 STORE_NAME               0 (x)

  3           4 NOP

  5           6 LOAD_CONST               3 (20)
              8 STORE_NAME               2 (y)
             10 LOAD_CONST               4 (None)
             12 RETURN_VALUE

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42693>
_______________________________________

From report at bugs.python.org  Sun Dec 20 16:29:18 2020
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 20 Dec 2020 21:29:18 +0000
Subject: [issue42696] Duplicated unused bytecodes at end of function
Message-ID: <1608499758.44.0.239199538725.issue42696@roundup.psfhosted.org>


New submission from Ned Batchelder <ned at nedbatchelder.com>:

(Using CPython commit c95f8bc270.)

This program has extra bytecodes:

    def f():
        for i in range(10):
            break
        return 17

The dis output is:

      1           0 LOAD_CONST               0 (<code object f at 0x109cf7450, file "afterbreak.py", line 1>)
                  2 LOAD_CONST               1 ('f')
                  4 MAKE_FUNCTION            0
                  6 STORE_NAME               0 (f)
                  8 LOAD_CONST               2 (None)
                 10 RETURN_VALUE

    Disassembly of <code object f at 0x109cf7450, file "afterbreak.py", line 1>:
      2           0 LOAD_GLOBAL              0 (range)
                  2 LOAD_CONST               1 (10)
                  4 CALL_FUNCTION            1
                  6 GET_ITER
                  8 FOR_ITER                 8 (to 18)
                 10 STORE_FAST               0 (i)

      3          12 POP_TOP

      4          14 LOAD_CONST               2 (17)
                 16 RETURN_VALUE
            >>   18 LOAD_CONST               2 (17)
                 20 RETURN_VALUE

The break has something to do with it, because if I change the Python to:

    def f():
        for i in range(10):
            a = 1
        return 17

then the dis output is:

      1           0 LOAD_CONST               0 (<code object f at 0x10bf8f450, file "afterbreak.py", line 1>)
                  2 LOAD_CONST               1 ('f')
                  4 MAKE_FUNCTION            0
                  6 STORE_NAME               0 (f)
                  8 LOAD_CONST               2 (None)
                 10 RETURN_VALUE

    Disassembly of <code object f at 0x10bf8f450, file "afterbreak.py", line 1>:
      2           0 LOAD_GLOBAL              0 (range)
                  2 LOAD_CONST               1 (10)
                  4 CALL_FUNCTION            1
                  6 GET_ITER
            >>    8 FOR_ITER                 8 (to 18)
                 10 STORE_FAST               0 (i)

      3          12 LOAD_CONST               2 (1)
                 14 STORE_FAST               1 (a)
                 16 JUMP_ABSOLUTE            8

      4     >>   18 LOAD_CONST               3 (17)
                 20 RETURN_VALUE

----------
messages: 383460
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: Duplicated unused bytecodes at end of function
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42696>
_______________________________________

From report at bugs.python.org  Sun Dec 20 16:33:13 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Dec 2020 21:33:13 +0000
Subject: [issue42695] tkinter keysym_num value is incorrect
In-Reply-To: <1608499373.07.0.718041853104.issue42695@roundup.psfhosted.org>
Message-ID: <1608499993.68.0.736846097984.issue42695@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Tkinter is just a wrapper around Tcl/Tk. Please report a bug in Tk on the corresponding bug tracker.

https://wiki.tcl-lang.org/page/How+do+I+report+a+bug+in+Tcl%2C+Tk%2C+...

----------
nosy: +serhiy.storchaka
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42695>
_______________________________________

From report at bugs.python.org  Sun Dec 20 16:35:03 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 20 Dec 2020 21:35:03 +0000
Subject: [issue42681] mistake in curses documentation
In-Reply-To: <1608339537.48.0.496910027234.issue42681@roundup.psfhosted.org>
Message-ID: <1608500103.92.0.231759399484.issue42681@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +22736
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23874

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42681>
_______________________________________

From report at bugs.python.org  Sun Dec 20 16:48:01 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 20 Dec 2020 21:48:01 +0000
Subject: [issue42680] unicode identifiers not accessible or assignable through
 globals()
In-Reply-To: <1608337638.31.0.282266859185.issue42680@roundup.psfhosted.org>
Message-ID: <1608500881.93.0.756527236515.issue42680@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I think documenting this with globals() and locals() is a good idea. That's the place this is most likely to trip someone up.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42680>
_______________________________________

From report at bugs.python.org  Sun Dec 20 16:53:52 2020
From: report at bugs.python.org (Justin)
Date: Sun, 20 Dec 2020 21:53:52 +0000
Subject: [issue42695] tkinter keysym_num value is incorrect
In-Reply-To: <1608499373.07.0.718041853104.issue42695@roundup.psfhosted.org>
Message-ID: <1608501232.28.0.00227350470747.issue42695@roundup.psfhosted.org>


Justin <justin.a.black at gmail.com> added the comment:

TK bug ticket has been created at https://core.tcl-lang.org/tk/tktview/ffe6925b916caac02acae53f745e95dd1c557019

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42695>
_______________________________________

From report at bugs.python.org  Sun Dec 20 16:56:08 2020
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Sun, 20 Dec 2020 21:56:08 +0000
Subject: [issue42697] 3.8.7rc1 regression: 'free(): invalid pointer' after
 running backports-zoneinfo test suite
Message-ID: <1608501368.18.0.633201368751.issue42697@roundup.psfhosted.org>


New submission from Micha? G?rny <mgorny at gentoo.org>:

I'm still investigating the problem and I will include more information shortly.  However, I'm filing the bug early, as I'd like to prevent this regression from hitting 3.8.7 release.

When running backports-zoneinfo-0.2.1 test suite using cpython 3.8.7rc1, all tests pass, then python segfaults:

```
----------------------------------------------------------------------
Ran 233 tests in 2.200s

OK (skipped=27)
free(): invalid pointer
/var/tmp/portage/dev-python/backports-zoneinfo-0.2.1/temp/environment: line 3054:   167 Aborted                 (core dumped) "${EPYTHON}" -m unittest discover -v
```


The backtrace I got doesn't seem very useful:

#0  __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1  0x00007fd4b6c79536 in __GI_abort () at abort.c:79
#2  0x00007fd4b6cd2bf7 in __libc_message (action=action at entry=do_abort, fmt=fmt at entry=0x7fd4b6de53b5 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x00007fd4b6cdaa7a in malloc_printerr (str=str at entry=0x7fd4b6de3593 "free(): invalid pointer") at malloc.c:5389
#4  0x00007fd4b6cdbe5c in _int_free (av=<optimized out>, p=<optimized out>, have_lock=0) at malloc.c:4201
#5  0x00007fd4b6f00aaa in ?? () from /usr/lib64/libpython3.8.so.1.0
#6  0x00007fd4b6eb8745 in ?? () from /usr/lib64/libpython3.8.so.1.0
#7  0x00007fd4b6ece115 in ?? () from /usr/lib64/libpython3.8.so.1.0
#8  0x00007fd4b6ece2f2 in ?? () from /usr/lib64/libpython3.8.so.1.0
#9  0x0000562239cd1a60 in ?? ()
#10 0x00007fd4b7086967 in ?? () from /usr/lib64/libpython3.8.so.1.0
#11 0x00007fd4b7167e20 in ?? () from /usr/lib64/libpython3.8.so.1.0
#12 0x0000562239cd1a60 in ?? ()
#13 0x00007fd4b6f05d26 in ?? () from /usr/lib64/libpython3.8.so.1.0
#14 0x00007fd4b6fccf0d in ?? () from /usr/lib64/libpython3.8.so.1.0
#15 0x00007fd4b6fcdc1d in PyGC_Collect () from /usr/lib64/libpython3.8.so.1.0
#16 0x000056223996c670 in ?? ()
#17 0x00007fd4b6f93e8a in PyImport_Cleanup () from /usr/lib64/libpython3.8.so.1.0
#18 0x00007fd4b6faa55c in Py_NewInterpreter () from /usr/lib64/libpython3.8.so.1.0
#19 0x0000000000000000 in ?? ()


I'm going to start by trying to bisect this, and let you know the results when I manage them.

----------
components: Interpreter Core
messages: 383464
nosy: mgorny
priority: normal
severity: normal
status: open
title: 3.8.7rc1 regression: 'free(): invalid pointer' after running backports-zoneinfo test suite
type: crash
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42697>
_______________________________________

From report at bugs.python.org  Sun Dec 20 16:59:00 2020
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 20 Dec 2020 21:59:00 +0000
Subject: [issue42697] 3.8.7rc1 regression: 'free(): invalid pointer' after
 running backports-zoneinfo test suite
In-Reply-To: <1608501368.18.0.633201368751.issue42697@roundup.psfhosted.org>
Message-ID: <1608501540.61.0.288930711385.issue42697@roundup.psfhosted.org>


Change by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42697>
_______________________________________

From report at bugs.python.org  Sun Dec 20 17:17:07 2020
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Sun, 20 Dec 2020 22:17:07 +0000
Subject: [issue42697] 3.8.7rc1 regression: 'free(): invalid pointer' after
 running backports-zoneinfo test suite
In-Reply-To: <1608501368.18.0.633201368751.issue42697@roundup.psfhosted.org>
Message-ID: <1608502627.87.0.471760416794.issue42697@roundup.psfhosted.org>


Micha? G?rny <mgorny at gentoo.org> added the comment:

aeb66c1abbf4ec214e2e80eb972546996d1a1571 is the first bad commit
commit aeb66c1abbf4ec214e2e80eb972546996d1a1571
Author: Miss Skeleton (bot) <31488909+miss-islington at users.noreply.github.com>
Date:   Thu Oct 15 08:51:48 2020 -0700

    bpo-41984: GC track all user classes (GH-22701/GH-22707)
    
    (cherry picked from commit c13b847a6f913b72eeb71651ff626390b738d973)

 Lib/test/test_finalization.py                      | 23 ++++++++++++++++++++--
 Lib/test/test_gc.py                                |  6 +++---
 .../2020-10-14-16-19-43.bpo-41984.SEtKMr.rst       |  2 ++
 Modules/_testcapimodule.c                          | 20 +++++++++++++++++++
 Objects/typeobject.c                               | 22 ++++++---------------
 5 files changed, 52 insertions(+), 21 deletions(-)
 create mode 100644 Misc/NEWS.d/next/Core and Builtins/2020-10-14-16-19-43.bpo-41984.SEtKMr.rst

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42697>
_______________________________________

From report at bugs.python.org  Sun Dec 20 17:23:40 2020
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Sun, 20 Dec 2020 22:23:40 +0000
Subject: [issue42697] 3.8.7rc1 regression: 'free(): invalid pointer' after
 running backports-zoneinfo test suite
In-Reply-To: <1608501368.18.0.633201368751.issue42697@roundup.psfhosted.org>
Message-ID: <1608503020.39.0.718541258665.issue42697@roundup.psfhosted.org>


Micha? G?rny <mgorny at gentoo.org> added the comment:

A more complete backtrace:

#0  __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1  0x00007fa633b20536 in __GI_abort () at abort.c:79
#2  0x00007fa633b79bf7 in __libc_message (action=action at entry=do_abort, fmt=fmt at entry=0x7fa633c8c3b5 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x00007fa633b81a7a in malloc_printerr (str=str at entry=0x7fa633c8a593 "free(): invalid pointer") at malloc.c:5389
#4  0x00007fa633b82e5c in _int_free (av=<optimized out>, p=<optimized out>, have_lock=0) at malloc.c:4201
#5  0x000055ea845c6170 in _PyMem_RawFree (ctx=0x0, ptr=0x55ea848c1a60 <small_ints+192>) at Objects/obmalloc.c:127
#6  0x000055ea845c6f46 in PyMem_RawFree (ptr=0x55ea848c1a60 <small_ints+192>) at Objects/obmalloc.c:595
#7  0x000055ea845c7fa0 in _PyObject_Free (ctx=0x0, p=0x55ea848c1a60 <small_ints+192>) at Objects/obmalloc.c:1898
#8  0x000055ea845c726e in PyObject_Free (ptr=0x55ea848c1a60 <small_ints+192>) at Objects/obmalloc.c:709
#9  0x000055ea845dda33 in object_dealloc (self=0x55ea848c1a60 <small_ints+192>) at Objects/typeobject.c:3784
#10 0x000055ea845c60a5 in _Py_Dealloc (op=0x55ea848c1a60 <small_ints+192>) at Objects/object.c:2215
#11 0x000055ea845d3b55 in _Py_DECREF (filename=0x55ea847a8de0 "./Include/object.h", lineno=541, op=0x55ea848c1a60 <small_ints+192>)
    at ./Include/object.h:478
#12 0x000055ea845d3b83 in _Py_XDECREF (op=0x55ea848c1a60 <small_ints+192>) at ./Include/object.h:541
#13 0x000055ea845d4627 in tupledealloc (op=0x7fa63195d6c0) at Objects/tupleobject.c:247
#14 0x000055ea845c60a5 in _Py_Dealloc (op=0x7fa63195d6c0) at Objects/object.c:2215
#15 0x000055ea84743afb in _Py_DECREF (filename=0x55ea8482b9a0 "./Include/object.h", lineno=541, op=0x7fa63195d6c0) at ./Include/object.h:478
#16 0x000055ea84743b29 in _Py_XDECREF (op=0x7fa63195d6c0) at ./Include/object.h:541
#17 0x000055ea84745b5a in code_dealloc (co=0x7fa631b68450) at Objects/codeobject.c:552
#18 0x000055ea845c60a5 in _Py_Dealloc (op=0x7fa631b68450) at Objects/object.c:2215
#19 0x000055ea847525d2 in _Py_DECREF (filename=0x55ea8482e47c "Objects/funcobject.c", lineno=576, op=0x7fa631b68450) at ./Include/object.h:478
#20 0x000055ea84753b6a in func_clear (op=0x7fa631b768b0) at Objects/funcobject.c:576
#21 0x000055ea84753de0 in func_dealloc (op=0x7fa631b768b0) at Objects/funcobject.c:597
#22 0x000055ea845c60a5 in _Py_Dealloc (op=0x7fa631b768b0) at Objects/object.c:2215
#23 0x000055ea845addff in _Py_DECREF (filename=0x55ea847a3320 "./Include/object.h", lineno=541, op=0x7fa631b768b0) at ./Include/object.h:478
#24 0x000055ea845ade4f in _Py_XDECREF (op=0x7fa631b768b0) at ./Include/object.h:541
#25 0x000055ea845aeed8 in free_keys_object (keys=0x55ea84e72580) at Objects/dictobject.c:584
#26 0x000055ea845ae524 in dictkeys_decref (dk=0x55ea84e72580) at Objects/dictobject.c:324
#27 0x000055ea845b1c9c in PyDict_Clear (op=0x7fa63198b740) at Objects/dictobject.c:1729
#28 0x000055ea845dd683 in type_clear (type=0x55ea84e12ba0) at Objects/typeobject.c:3594
#29 0x000055ea845d8720 in subtype_clear (self=0x55ea84e12ba0) at Objects/typeobject.c:1147
#30 0x000055ea846ac4aa in delete_garbage (state=0x55ea848dd6f8 <_PyRuntime+344>, collectable=0x7fff13eb2e10, old=0x55ea848dd740 <_PyRuntime+416>)
    at Modules/gcmodule.c:948
#31 0x000055ea846aca23 in collect (state=0x55ea848dd6f8 <_PyRuntime+344>, generation=2, n_collected=0x0, n_uncollectable=0x0, nofail=1)
    at Modules/gcmodule.c:1123
#32 0x000055ea846ae0da in _PyGC_CollectNoFail () at Modules/gcmodule.c:1866
#33 0x000055ea846616da in PyImport_Cleanup () at Python/import.c:599
#34 0x000055ea8467df93 in Py_FinalizeEx () at Python/pylifecycle.c:1233
#35 0x000055ea84577e8a in Py_RunMain () at Modules/main.c:691
#36 0x000055ea84577f22 in pymain_main (args=0x7fff13eb2ff0) at Modules/main.c:719
#37 0x000055ea84577fe2 in Py_BytesMain (argc=6, argv=0x7fff13eb3138) at Modules/main.c:743
#38 0x000055ea84576785 in main (argc=6, argv=0x7fff13eb3138) at ./Programs/python.c:16

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42697>
_______________________________________

From report at bugs.python.org  Sun Dec 20 17:28:12 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 20 Dec 2020 22:28:12 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1608503292.2.0.220664615969.issue31904@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset ab74c014ae514fde7487542ec96ef45235aa86b0 by pxinwr in branch 'master':
bpo-31904: Fix site and sysconfig modules for VxWorks RTOS (GH-21821)
https://github.com/python/cpython/commit/ab74c014ae514fde7487542ec96ef45235aa86b0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Sun Dec 20 18:45:32 2020
From: report at bugs.python.org (mike bayer)
Date: Sun, 20 Dec 2020 23:45:32 +0000
Subject: [issue16535] json encoder unable to handle decimal
In-Reply-To: <1353624338.46.0.574343718645.issue16535@psf.upfronthosting.co.za>
Message-ID: <1608507932.03.0.518516833991.issue16535@roundup.psfhosted.org>


Change by mike bayer <mike_mp at zzzcomputing.com>:


----------
nosy: +zzzeek

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16535>
_______________________________________

From report at bugs.python.org  Sun Dec 20 18:49:14 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Sun, 20 Dec 2020 23:49:14 +0000
Subject: [issue42584] Upgrade macOS and Windows installers to use SQLite 3.34.0
In-Reply-To: <1607337382.55.0.591359272905.issue42584@roundup.psfhosted.org>
Message-ID: <1608508154.55.0.390574146862.issue42584@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

See attached proof-of-concept CI check. This GitHub Workflow extracts the SQLite version information, downloads the amalgamation source code, and does a simple `cmp` on each file.

Example run: https://github.com/erlend-aasland/cpython-source-deps/runs/1586069119?check_suite_focus=true

----------
Added file: https://bugs.python.org/file49694/0001-Add-simple-validation-CI.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42584>
_______________________________________

From report at bugs.python.org  Sun Dec 20 19:02:38 2020
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 21 Dec 2020 00:02:38 +0000
Subject: [issue42697] 3.8.7rc1 regression: 'free(): invalid pointer' after
 running backports-zoneinfo test suite
In-Reply-To: <1608501368.18.0.633201368751.issue42697@roundup.psfhosted.org>
Message-ID: <1608508958.2.0.67904026568.issue42697@roundup.psfhosted.org>


Change by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +brandtbucher, nascheme, pablogsal, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42697>
_______________________________________

From report at bugs.python.org  Sun Dec 20 19:30:54 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 21 Dec 2020 00:30:54 +0000
Subject: [issue42697] 3.8.7rc1 regression: 'free(): invalid pointer' after
 running backports-zoneinfo test suite
In-Reply-To: <1608501368.18.0.633201368751.issue42697@roundup.psfhosted.org>
Message-ID: <1608510654.7.0.535858890561.issue42697@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Raising this to a release blocker

----------
priority: normal -> release blocker
versions: +Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42697>
_______________________________________

From report at bugs.python.org  Sun Dec 20 19:41:21 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 21 Dec 2020 00:41:21 +0000
Subject: [issue42697] 3.8.7rc1 regression: 'free(): invalid pointer' after
 running backports-zoneinfo test suite
In-Reply-To: <1608501368.18.0.633201368751.issue42697@roundup.psfhosted.org>
Message-ID: <1608511281.07.0.319695276393.issue42697@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

The symptom is that we are now trying to free something in the small integer cache that we shouldn't. Running this under the address sanitizer shows a bit more of the problem:

==190303==ERROR: AddressSanitizer: attempting free on address which was not malloc()-ed: 0x564456357fe0 in thread T0
    #0 0x7f18ad2200e9 in __interceptor_free /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cpp:123
    #1 0x564455b03283 in _PyMem_RawFree Objects/obmalloc.c:127
    #2 0x564455b0538d in PyObject_Free Objects/obmalloc.c:709
    #3 0x564455b3b820 in object_dealloc Objects/typeobject.c:3797
    #4 0x564455b03180 in _Py_Dealloc Objects/object.c:2215
    #5 0x564455b21308 in _Py_DECREF Include/object.h:478
    #6 0x564455b21336 in _Py_XDECREF Include/object.h:541
    #7 0x564455b2305f in tupledealloc Objects/tupleobject.c:247
    #8 0x564455b03180 in _Py_Dealloc Objects/object.c:2215
    #9 0x564455f1ef6b in _Py_DECREF Include/object.h:478
    #10 0x564455f1ef99 in _Py_XDECREF Include/object.h:541
    #11 0x564455f24ed4 in code_dealloc Objects/codeobject.c:552
    #12 0x564455b03180 in _Py_Dealloc Objects/object.c:2215
    #13 0x564455a85e3c in _Py_DECREF Include/object.h:478
    #14 0x564455a892f7 in func_clear Objects/funcobject.c:579
    #15 0x564455a89704 in func_dealloc Objects/funcobject.c:600
    #16 0x564455b03180 in _Py_Dealloc Objects/object.c:2215
    #17 0x564455ac025d in _Py_DECREF Include/object.h:478
    #18 0x564455ac02ad in _Py_XDECREF Include/object.h:541
    #19 0x564455ac3178 in free_keys_object Objects/dictobject.c:584
    #20 0x564455ac1f41 in dictkeys_decref Objects/dictobject.c:324
    #21 0x564455acb293 in PyDict_Clear Objects/dictobject.c:1729
    #22 0x564455b3b00b in type_clear Objects/typeobject.c:3607
    #23 0x564455d9afa6 in delete_garbage Modules/gcmodule.c:948
    #24 0x564455d9b9c3 in collect Modules/gcmodule.c:1123
    #25 0x564455d9ee3a in _PyGC_CollectNoFail Modules/gcmodule.c:1866
    #26 0x564455ce0fe3 in PyImport_Cleanup Python/import.c:599
    #27 0x564455d29245 in Py_FinalizeEx Python/pylifecycle.c:1229
    #28 0x564455a29e99 in Py_RunMain Modules/main.c:691
    #29 0x564455a2a236 in pymain_main Modules/main.c:719
    #30 0x564455a2a5e5 in Py_BytesMain Modules/main.c:743
    #31 0x564455a269b8 in main Programs/python.c:16
    #32 0x7f18ace5a151 in __libc_start_main (/usr/lib/libc.so.6+0x28151)
    #33 0x564455a268cd in _start (/home/pablogsal/github/python/3.8/python+0x1d48cd)

0x564456357fe0 is located 192 bytes inside of global variable 'small_ints' defined in 'Objects/longobject.c:43:21' (0x564456357f20) of size 8384
SUMMARY: AddressSanitizer

Still unclear how we have reached this situation

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42697>
_______________________________________

From report at bugs.python.org  Sun Dec 20 19:44:44 2020
From: report at bugs.python.org (hydroflask)
Date: Mon, 21 Dec 2020 00:44:44 +0000
Subject: [issue42698] Deadlock in pysqlite_connection_dealloc()
Message-ID: <1608511484.37.0.765804145287.issue42698@roundup.psfhosted.org>


New submission from hydroflask <hydroflask at yqxmail.com>:

pysqlite_connection_dealloc() calls sqlite3_close{,_v2}(). This can cause a deadlock if sqlite3_close() tries to acquire a lock that another thread  holds, due to a deadlock between the GIL and an internal sqlite3 lock.

This is especially common with sqlite3's "shared cache mode."

Since the GIL should not be released during a tp_dealloc function and python has no control over the behavior of sqlite3_close(), it is incorrect to call sqlite3_close() in pysqlite_connection_dealloc().

----------
components: Library (Lib)
messages: 383471
nosy: hydroflask
priority: normal
severity: normal
status: open
title: Deadlock in pysqlite_connection_dealloc()
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42698>
_______________________________________

From report at bugs.python.org  Sun Dec 20 19:46:20 2020
From: report at bugs.python.org (hydroflask)
Date: Mon, 21 Dec 2020 00:46:20 +0000
Subject: [issue42698] Deadlock in pysqlite_connection_dealloc()
In-Reply-To: <1608511484.37.0.765804145287.issue42698@roundup.psfhosted.org>
Message-ID: <1608511580.24.0.911383612092.issue42698@roundup.psfhosted.org>


Change by hydroflask <hydroflask at yqxmail.com>:


----------
components: +Extension Modules

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42698>
_______________________________________

From report at bugs.python.org  Sun Dec 20 20:32:19 2020
From: report at bugs.python.org (hydroflask)
Date: Mon, 21 Dec 2020 01:32:19 +0000
Subject: [issue42698] Deadlock in pysqlite_connection_dealloc()
In-Reply-To: <1608511484.37.0.765804145287.issue42698@roundup.psfhosted.org>
Message-ID: <1608514339.52.0.438271844731.issue42698@roundup.psfhosted.org>


hydroflask <hydroflask at yqxmail.com> added the comment:

This is also a problem in pysqlite_connection_close() as currently implemented.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42698>
_______________________________________

From report at bugs.python.org  Sun Dec 20 20:34:08 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Mon, 21 Dec 2020 01:34:08 +0000
Subject: [issue42697] 3.8.7rc1 regression: 'free(): invalid pointer' after
 running backports-zoneinfo test suite
In-Reply-To: <1608501368.18.0.633201368751.issue42697@roundup.psfhosted.org>
Message-ID: <1608514448.21.0.848335377156.issue42697@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

On my phone right now, but this looks a tad suspicious:

https://github.com/pganssle/zoneinfo/blob/07ec80ad5dc7e7e4b4f861ddbb61a9b71e9f27c7/lib/zoneinfo_module.c#L596-L600

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42697>
_______________________________________

From report at bugs.python.org  Sun Dec 20 20:39:34 2020
From: report at bugs.python.org (Samuel Marks)
Date: Mon, 21 Dec 2020 01:39:34 +0000
Subject: [issue42699] Use `.join(k for k in g)` instead of `.join([k for k in
 g])`
Message-ID: <1608514774.35.0.908581836458.issue42699@roundup.psfhosted.org>


New submission from Samuel Marks <samuelmarks at gmail.com>:

This is an extremely minor improvement. Rather than create a `list`?using a comprehension?then have it consumed by `.join`, one can skip the list construction entirely.

(I remember this working from at least Python 2.7? probably earlier also)

----------
messages: 383474
nosy: samuelmarks
priority: normal
pull_requests: 22737
severity: normal
status: open
title: Use `.join(k for k in g)` instead of `.join([k for k in g])`
type: performance
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42699>
_______________________________________

From report at bugs.python.org  Sun Dec 20 20:41:50 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 21 Dec 2020 01:41:50 +0000
Subject: [issue42699] Use `.join(k for k in g)` instead of `.join([k for k in
 g])`
In-Reply-To: <1608514774.35.0.908581836458.issue42699@roundup.psfhosted.org>
Message-ID: <1608514910.25.0.50020534125.issue42699@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Do you have any benchmarks to show this is an actual improvement? Often times it is not.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42699>
_______________________________________

From report at bugs.python.org  Sun Dec 20 20:47:08 2020
From: report at bugs.python.org (Samuel Marks)
Date: Mon, 21 Dec 2020 01:47:08 +0000
Subject: [issue42699] Use `.join(k for k in g)` instead of `.join([k for k in
 g])`
In-Reply-To: <1608514774.35.0.908581836458.issue42699@roundup.psfhosted.org>
Message-ID: <1608515228.69.0.713239046107.issue42699@roundup.psfhosted.org>


Samuel Marks <samuelmarks at gmail.com> added the comment:

@eric.smith No benchmarks offhand, but I'd expect it to be a very minor improvement (if detectable).

If this gets accepted I'll probably do a bunch of little changes like this, to improve things, e.g., replace '%' with '.format' (or f-strings, whatever you prefer), ensure `.iterkeys()`/`.iteritems()` validity, and collapse some obvious `.append` cases with list comprehensions.

The idea I'm going off is that when one is debugging their Python code, and it goes across to the Python source, that that Python source code quality is better or equal to the one the higher-level Python developer is creating.

Constructing unnecessary lists is one such code quality issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42699>
_______________________________________

From report at bugs.python.org  Sun Dec 20 20:49:21 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 21 Dec 2020 01:49:21 +0000
Subject: [issue42697] 3.8.7rc1 regression: 'free(): invalid pointer' after
 running backports-zoneinfo test suite
In-Reply-To: <1608501368.18.0.633201368751.issue42697@roundup.psfhosted.org>
Message-ID: <1608515361.98.0.591324425024.issue42697@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Indeed. The module in the std lib is actually different:

https://github.com/python/cpython/blob/master/Modules/_zoneinfo.c#L570-L589

and uses _PyLong_GetOne() instead of _PyLong_One

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42697>
_______________________________________

From report at bugs.python.org  Sun Dec 20 20:52:47 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 21 Dec 2020 01:52:47 +0000
Subject: [issue42697] 3.8.7rc1 regression: 'free(): invalid pointer' after
 running backports-zoneinfo test suite
In-Reply-To: <1608501368.18.0.633201368751.issue42697@roundup.psfhosted.org>
Message-ID: <1608515567.6.0.653720058355.issue42697@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

The version in 3.9 is also different but also uses _PyLong_One:

https://github.com/python/cpython/blob/3.9/Modules/_zoneinfo.c#L571-L590

Although that is passed directly to PyDict_SetItemString so the refcount should be correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42697>
_______________________________________

From report at bugs.python.org  Sun Dec 20 21:00:09 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 21 Dec 2020 02:00:09 +0000
Subject: [issue42697] 3.8.7rc1 regression: 'free(): invalid pointer' after
 running backports-zoneinfo test suite
In-Reply-To: <1608501368.18.0.633201368751.issue42697@roundup.psfhosted.org>
Message-ID: <1608516009.26.0.757443768018.issue42697@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Oh, wait. This looks incorrect:

https://github.com/pganssle/zoneinfo/blob/07ec80ad5dc7e7e4b4f861ddbb61a9b71e9f27c7/lib/zoneinfo_module.c#L619-L621

That

#ifndef ATLEAST_37

should be

#ifdef ATLEAST_37

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42697>
_______________________________________

From report at bugs.python.org  Sun Dec 20 21:00:22 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 21 Dec 2020 02:00:22 +0000
Subject: [issue42697] 3.8.7rc1 regression: 'free(): invalid pointer' after
 running backports-zoneinfo test suite
In-Reply-To: <1608501368.18.0.633201368751.issue42697@roundup.psfhosted.org>
Message-ID: <1608516022.99.0.247371460447.issue42697@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy: +p-ganssle

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42697>
_______________________________________

From report at bugs.python.org  Sun Dec 20 21:04:20 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 21 Dec 2020 02:04:20 +0000
Subject: [issue42697] 3.8.7rc1 regression: 'free(): invalid pointer' after
 running backports-zoneinfo test suite
In-Reply-To: <1608501368.18.0.633201368751.issue42697@roundup.psfhosted.org>
Message-ID: <1608516260.87.0.33937677456.issue42697@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I am quite sure that is the problem. I opened https://github.com/pganssle/zoneinfo/pull/97 to correct this in the backport.

The standard library versions are ok.

Brandt, if you agree that this is indeed the problem, let's close this as "not a bug".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42697>
_______________________________________

From report at bugs.python.org  Sun Dec 20 21:11:48 2020
From: report at bugs.python.org (Michael Wayne Goodman)
Date: Mon, 21 Dec 2020 02:11:48 +0000
Subject: [issue42700] xml.parsers.expat.errors description of codes/messages
 is flipped
Message-ID: <1608516708.54.0.399014748226.issue42700@roundup.psfhosted.org>


New submission from Michael Wayne Goodman <goodman.m.w at gmail.com>:

The documentation for xml.parsers.expat.errors.codes says:

   A dictionary mapping numeric error codes to their string descriptions.

But this is backwards. It should say it maps the string descriptions to the error codes. Likewise, the docs for xml.parsers.expat.errors.messages is backwards.

The other references to these dictionaries appear correct. For instance, under ExpatError.code:

   The :mod:`~xml.parsers.expat.errors` module also provides error message
   constants and a dictionary :data:`~xml.parsers.expat.errors.codes` mapping
   these messages back to the error codes, see below.

This issue appears to be present in the docs for all available versions.

----------
assignee: docs at python
components: Documentation
messages: 383481
nosy: docs at python, goodmami
priority: normal
severity: normal
status: open
title: xml.parsers.expat.errors description of codes/messages is flipped
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42700>
_______________________________________

From report at bugs.python.org  Sun Dec 20 21:15:00 2020
From: report at bugs.python.org (hydroflask)
Date: Mon, 21 Dec 2020 02:15:00 +0000
Subject: [issue42698] Deadlock in pysqlite_connection_dealloc()
In-Reply-To: <1608511484.37.0.765804145287.issue42698@roundup.psfhosted.org>
Message-ID: <1608516900.81.0.964779766093.issue42698@roundup.psfhosted.org>


hydroflask <hydroflask at yqxmail.com> added the comment:

Nevermind it seems that it's legal to call Py_BEGIN_ALLOW_THREADS in tp_dealloc. The fix is then to allow threads around sqlite3_close().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42698>
_______________________________________

From report at bugs.python.org  Sun Dec 20 21:39:30 2020
From: report at bugs.python.org (Michael Wayne Goodman)
Date: Mon, 21 Dec 2020 02:39:30 +0000
Subject: [issue42700] xml.parsers.expat.errors description of codes/messages
 is flipped
In-Reply-To: <1608516708.54.0.399014748226.issue42700@roundup.psfhosted.org>
Message-ID: <1608518370.36.0.946473564952.issue42700@roundup.psfhosted.org>


Change by Michael Wayne Goodman <goodman.m.w at gmail.com>:


----------
keywords: +patch
pull_requests: +22738
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23876

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42700>
_______________________________________

From report at bugs.python.org  Sun Dec 20 22:14:09 2020
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 21 Dec 2020 03:14:09 +0000
Subject: [issue42699] Use `.join(k for k in g)` instead of `.join([k for k in
 g])`
In-Reply-To: <1608514774.35.0.908581836458.issue42699@roundup.psfhosted.org>
Message-ID: <1608520449.34.0.581793062132.issue42699@roundup.psfhosted.org>


Josh Rosenberg <shadowranger+python at gmail.com> added the comment:

This is a pessimization given the current implementation of str.join; it calls PySequence_Fast as the very first step, which is effectively free for a tuple or list input (just reference count manipulation), but must convert a generator expression to a list (which is slower than building the list with a listcomp in the first place).

It does this so it can do two passes, one to compute the final length (and max ordinal) of the string, allowing it to allocate just once, and one to build the new string.

In theory, it might be rewritten to use PyUnicodeWriter under-the-hood for single-pass operation, but as is, a generator expression is slower than a listcomp for this task.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42699>
_______________________________________

From report at bugs.python.org  Sun Dec 20 22:27:56 2020
From: report at bugs.python.org (Brandt Bucher)
Date: Mon, 21 Dec 2020 03:27:56 +0000
Subject: [issue42697] 3.8.7rc1 regression: 'free(): invalid pointer' after
 running backports-zoneinfo test suite
In-Reply-To: <1608501368.18.0.633201368751.issue42697@roundup.psfhosted.org>
Message-ID: <1608521276.05.0.788023237751.issue42697@roundup.psfhosted.org>


Brandt Bucher <brandtbucher at gmail.com> added the comment:

Almost certain. The number one is offset 192 bytes in small_ints on 3.8, which matches both of your backtraces:

>>> id(1) - id(-5)                                                                                                                                                                                                                            
192

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42697>
_______________________________________

From report at bugs.python.org  Sun Dec 20 22:50:30 2020
From: report at bugs.python.org (Ken Jin)
Date: Mon, 21 Dec 2020 03:50:30 +0000
Subject: [issue42699] Use `.join(k for k in g)` instead of `.join([k for k in
 g])`
In-Reply-To: <1608514774.35.0.908581836458.issue42699@roundup.psfhosted.org>
Message-ID: <1608522630.73.0.842939124155.issue42699@roundup.psfhosted.org>


Ken Jin <kenjin4096 at gmail.com> added the comment:

Sorry for intruding, but I thought I'd offer some rudimentary, non-scientific benchmarks for this:

[MSC v.1928 32 bit (Intel)] on win32  # a debug build of python, no compiler optimizations

import timeit
# gen comp
timeit.timeit("''.join(str(_) for _ in range(1000))", number=10000)
11.154560299999957

# list comp
timeit.timeit("''.join([str(_) for _ in range(1000)])", number=10000)
9.987510899999961

The list comp is slightly faster than the gen comp. Interestingly, if one were to use python -m timeit instead, the gen comp would show better results since it has a better 'best of 5' timing. IMO, total time is a more accurate representation than best of 5 since the latter gets skewed by outliers.

----------
nosy: +kj

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42699>
_______________________________________

From report at bugs.python.org  Sun Dec 20 23:15:32 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 21 Dec 2020 04:15:32 +0000
Subject: [issue42697] 3.8.7rc1 regression: 'free(): invalid pointer' after
 running backports-zoneinfo test suite
In-Reply-To: <1608501368.18.0.633201368751.issue42697@roundup.psfhosted.org>
Message-ID: <1608524132.23.0.00483753831384.issue42697@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
assignee:  -> pablogsal
priority: release blocker -> 
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42697>
_______________________________________

From report at bugs.python.org  Sun Dec 20 23:37:54 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Dec 2020 04:37:54 +0000
Subject: [issue42699] Use `.join(k for k in g)` instead of `.join([k for k in
 g])`
In-Reply-To: <1608514774.35.0.908581836458.issue42699@roundup.psfhosted.org>
Message-ID: <1608525474.16.0.949033979745.issue42699@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Sorry Samuel, but this would be a performance degradation.  The reason is that the algorithm of str.join makes two passes over the input, so it runs faster when the input is already a list; otherwise, it would have to do the additional work of creating a list.

----------
nosy: +rhettinger
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42699>
_______________________________________

From report at bugs.python.org  Sun Dec 20 23:39:22 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Dec 2020 04:39:22 +0000
Subject: [issue42696] Duplicated unused bytecodes at end of function
In-Reply-To: <1608499758.44.0.239199538725.issue42696@roundup.psfhosted.org>
Message-ID: <1608525562.11.0.204167620981.issue42696@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42696>
_______________________________________

From report at bugs.python.org  Mon Dec 21 00:10:25 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Dec 2020 05:10:25 +0000
Subject: [issue42480] Python Tkinter crashes on macOS 11.1 beta
In-Reply-To: <1606468409.23.0.371615995189.issue42480@roundup.psfhosted.org>
Message-ID: <1608527425.57.0.949861418536.issue42480@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

@fxcoudert: If you are trying to link with the Apple-provided system Tcl and Tk frameworks, don't.  They have been seriously broken since macOS 10.7 and stuck at Tk 8.5.9. The only visible Apple action has been to deprecate them. Any Python on macOS that claims to support tkinter (and, hence, IDLE) *must* be able to link with, and preferably supply, newer versions of Tcl and Tk. And for use on current versions of macOS, that also means Tcl/Tk 8.6.x, not 8.5.x.

https://www.python.org/download/mac/tcltk/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42480>
_______________________________________

From report at bugs.python.org  Mon Dec 21 00:18:33 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Dec 2020 05:18:33 +0000
Subject: [issue42691] macOS 11.1 + Homebrew 2.6.2 + Python 3.9.1 = "IDLE" crash
In-Reply-To: <1608488832.09.0.347546053982.issue42691@roundup.psfhosted.org>
Message-ID: <1608527913.56.0.585148469833.issue42691@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

This is the same sort of crash of a Homebrew Python as reported in Issue42480 and the root cause is the same: the Homebrew recipe is allowing building and linking with the known faulty and deprecated Apple-provided system Tcl and Tk 8.5.9 frameworks. It needs to be modified to use a newer (8.6.x) version of Tcl and Tk.

----------
nosy: +fxcoudert
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Python Tkinter crashes on macOS 11.1 beta

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42691>
_______________________________________

From report at bugs.python.org  Mon Dec 21 00:26:15 2020
From: report at bugs.python.org (hydroflask)
Date: Mon, 21 Dec 2020 05:26:15 +0000
Subject: [issue42698] Deadlock in pysqlite_connection_dealloc()
In-Reply-To: <1608511484.37.0.765804145287.issue42698@roundup.psfhosted.org>
Message-ID: <1608528375.65.0.258454397377.issue42698@roundup.psfhosted.org>


hydroflask <hydroflask at yqxmail.com> added the comment:

Another comment: if calling sqlite3_close() outside of GIL, then the associated SQL function destructors must take the GIL before calling Py_DECREF

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42698>
_______________________________________

From report at bugs.python.org  Mon Dec 21 01:38:38 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 21 Dec 2020 06:38:38 +0000
Subject: [issue15872] shutil.rmtree(...,
 ignore_errors=True) doesn't ignore all errors
In-Reply-To: <1346962035.48.0.664042204164.issue15872@psf.upfronthosting.co.za>
Message-ID: <1608532718.11.0.60194690392.issue15872@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 37a6d5f8027f969418fe53d0a73a21003a8e370d by Daniel Hahler in branch 'master':
[WIP/RFC] bpo-15872: tests: remove oddity from test_rmtree_errors (GH-22967)
https://github.com/python/cpython/commit/37a6d5f8027f969418fe53d0a73a21003a8e370d


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15872>
_______________________________________

From report at bugs.python.org  Mon Dec 21 01:42:42 2020
From: report at bugs.python.org (=?utf-8?b?0J/RkdGC0YAg0KHQuNGA0LXQvdC60L4=?=)
Date: Mon, 21 Dec 2020 06:42:42 +0000
Subject: [issue42691] macOS 11.1 + Homebrew 2.6.2 + Python 3.9.1 = "IDLE" crash
In-Reply-To: <1608488832.09.0.347546053982.issue42691@roundup.psfhosted.org>
Message-ID: <1608532962.34.0.509837115488.issue42691@roundup.psfhosted.org>


???? ??????? <p.sirenko.94 at gmail.com> added the comment:

petr at air-anastasia ~ % python3 -c "import tkinter; tkinter.Tk()"   
macOS 11 or later required !
zsh: abort      python3 -c "import tkinter; tkinter.Tk()"

>>> tkinter.TclVersion
8.5
>>> tkinter.TkVersion
8.5

petr at air-anastasia ~ % brew install tcl-tk
Updating Homebrew...
==> Auto-updated Homebrew!
Updated Homebrew from f47c1eae3 to 1eff47766.
Updated 2 taps (homebrew/core and homebrew/cask).
==> New Formulae
xcb-util-image             xcb-util-renderutil        xcb-util-wm
==> Updated Formulae
Updated 29 formulae.
==> Updated Casks
Updated 18 casks.

==> Downloading https://homebrew.bintray.com/bottles/tcl-tk-8.6.10.big_sur.bottl
==> Downloading from https://d29vzk4ow07wi7.cloudfront.net/b7c942f7fc15b6a402bf4
######################################################################## 100.0%
==> Pouring tcl-tk-8.6.10.big_sur.bottle.1.tar.gz
==> Caveats
tcl-tk is keg-only, which means it was not symlinked into /usr/local,
because macOS already provides this software and installing another version in
parallel can cause all kinds of trouble.

If you need to have tcl-tk first in your PATH run:
  echo 'export PATH="/usr/local/opt/tcl-tk/bin:$PATH"' >> ~/.zshrc

For compilers to find tcl-tk you may need to set:
  export LDFLAGS="-L/usr/local/opt/tcl-tk/lib"
  export CPPFLAGS="-I/usr/local/opt/tcl-tk/include"

==> Summary
?  /usr/local/Cellar/tcl-tk/8.6.10: 3,037 files, 51.4MB

I have tried to update tcl-tk with the homebrew, but in command line I see 8.5
Could you please help me to fix this tcl-tk problem?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42691>
_______________________________________

From report at bugs.python.org  Mon Dec 21 02:49:44 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 21 Dec 2020 07:49:44 +0000
Subject: [issue42699] Use `.join(k for k in g)` instead of `.join([k for k in
 g])`
In-Reply-To: <1608514774.35.0.908581836458.issue42699@roundup.psfhosted.org>
Message-ID: <1608536984.15.0.71838839952.issue42699@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

By the way, it is almost always wrong to write "k for k in iterable" when you can just write "iterable" or "list(iterable)".

Here are some micro-benchmarks:


[steve ~]$ python3.9 -m timeit -s "from string import ascii_letters" "''.join(k for k in ascii_letters)"
100000 loops, best of 5: 2.3 usec per loop

[steve ~]$ python3.9 -m timeit -s "from string import ascii_letters" "''.join([k for k in ascii_letters])"
200000 loops, best of 5: 1.57 usec per loop

[steve ~]$ python3.9 -m timeit -s "from string import ascii_letters" "''.join(list(ascii_letters))"
500000 loops, best of 5: 749 nsec per loop

[steve ~]$ python3.9 -m timeit -s "from string import ascii_letters" "''.join(ascii_letters)"
500000 loops, best of 5: 737 nsec per loop

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42699>
_______________________________________

From report at bugs.python.org  Mon Dec 21 03:24:49 2020
From: report at bugs.python.org (mattip)
Date: Mon, 21 Dec 2020 08:24:49 +0000
Subject: [issue42151] Pure Python xml.etree.ElementTree is missing default
 attribute values
In-Reply-To: <1603684290.04.0.0149631860455.issue42151@roundup.psfhosted.org>
Message-ID: <1608539089.95.0.144350356451.issue42151@roundup.psfhosted.org>


mattip <matti.picus at gmail.com> added the comment:

Is there an owner for the XML module that can make a decision? The PR has a test that shows this fix brings the python implementation into sync with the C implementation, which is, unintuitively, the "reference implementation".

----------
nosy: +mattip

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42151>
_______________________________________

From report at bugs.python.org  Mon Dec 21 03:37:14 2020
From: report at bugs.python.org (Jakub Kulik)
Date: Mon, 21 Dec 2020 08:37:14 +0000
Subject: [issue42277] Solaris & PEP 3149: start using ABI version tagged .so
 files
In-Reply-To: <1604673019.95.0.76532678004.issue42277@roundup.psfhosted.org>
Message-ID: <1608539834.37.0.0290253877982.issue42277@roundup.psfhosted.org>


Jakub Kulik <kulikjak at gmail.com> added the comment:

This was resolved with issue 42604 and PR 23708.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42277>
_______________________________________

From report at bugs.python.org  Mon Dec 21 03:37:40 2020
From: report at bugs.python.org (Jakub Kulik)
Date: Mon, 21 Dec 2020 08:37:40 +0000
Subject: [issue42277] Solaris & PEP 3149: start using ABI version tagged .so
 files
In-Reply-To: <1604673019.95.0.76532678004.issue42277@roundup.psfhosted.org>
Message-ID: <1608539860.91.0.362630043581.issue42277@roundup.psfhosted.org>


Change by Jakub Kulik <kulikjak at gmail.com>:


----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42277>
_______________________________________

From report at bugs.python.org  Mon Dec 21 04:13:31 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 Dec 2020 09:13:31 +0000
Subject: [issue18131] Tkinter Variables require a proper master
In-Reply-To: <1370308379.98.0.744218229266.issue18131@psf.upfronthosting.co.za>
Message-ID: <1608542011.38.0.711036172593.issue18131@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

And the first issue was fixed in issue42630.

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18131>
_______________________________________

From report at bugs.python.org  Mon Dec 21 04:18:29 2020
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Mon, 21 Dec 2020 09:18:29 +0000
Subject: [issue42697] 3.8.7rc1 regression: 'free(): invalid pointer' after
 running backports-zoneinfo test suite
In-Reply-To: <1608501368.18.0.633201368751.issue42697@roundup.psfhosted.org>
Message-ID: <1608542309.57.0.0520240615897.issue42697@roundup.psfhosted.org>


Micha? G?rny <mgorny at gentoo.org> added the comment:

Thank you for debugging this.  I can confirm that this patch resolves my issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42697>
_______________________________________

From report at bugs.python.org  Mon Dec 21 04:19:56 2020
From: report at bugs.python.org (Samuel Marks)
Date: Mon, 21 Dec 2020 09:19:56 +0000
Subject: [issue42699] Use `.join(k for k in g)` instead of `.join([k for k in
 g])`
In-Reply-To: <1608514774.35.0.908581836458.issue42699@roundup.psfhosted.org>
Message-ID: <1608542396.64.0.995713479884.issue42699@roundup.psfhosted.org>


Samuel Marks <samuelmarks at gmail.com> added the comment:

Yeah I hear ya, was just trying for the most concise issue title. I tend to [over]use `map`, `filter`, `filterfalse` and other `itertools` and `operator` methods in my own codebase.

Surprised with that result, that using an explicit list is actually faster. Seems like an obvious* micro-optimisation. *But don't want to say that unless I'm actually maintaining/contributing-to your C code.

It's also surprising?last time I checked?that lists are faster to construct than tuples. When I create codebases or maintain other peoples, I try and:
- remove all unnecessary mutability (incl. replacing lists with tuples);
- flatten `.append` occurrences into generator comprehensions or map;
- remove all indentation creating for-loops, replacing with comprehensions or map and functions or lambdas
- combine generators rather than concatenate lists;

The general idea here is to evaluate at the time of computation, and be lazy everywhere else. So searching the whole codebase for lists and other mutable structures is a good first step.

But maybe with efficiency losses, like shown here, means that this would only aid [maybe] in readability, understandability, traceability & whatever other functional -ility; but not performance?

:(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42699>
_______________________________________

From report at bugs.python.org  Mon Dec 21 04:22:57 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 Dec 2020 09:22:57 +0000
Subject: [issue4343] tkinter: add _get_master() and use it consistently
In-Reply-To: <1227011959.0.0.968897886388.issue4343@psf.upfronthosting.co.za>
Message-ID: <1608542577.18.0.460614068391.issue4343@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I do not think that popping up a root window on first call of Variable() or getboolean() is a good idea. Issue42630 fixed errors in other way. A root window is not automatically created for non-graphic objects (like Variable), instead a RuntimeError with relevant error message is raised.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue4343>
_______________________________________

From report at bugs.python.org  Mon Dec 21 04:25:23 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 Dec 2020 09:25:23 +0000
Subject: [issue35728] Tkinter font nametofont requires default root
In-Reply-To: <1547328812.09.0.281453810047.issue35728@roundup.psfhosted.org>
Message-ID: <1608542723.13.0.0995111206237.issue35728@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +easy
versions: +Python 3.10 -Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35728>
_______________________________________

From report at bugs.python.org  Mon Dec 21 04:32:24 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 21 Dec 2020 09:32:24 +0000
Subject: [issue42699] Use `.join(k for k in g)` instead of `.join([k for k in
 g])`
In-Reply-To: <1608514774.35.0.908581836458.issue42699@roundup.psfhosted.org>
Message-ID: <1608543144.54.0.520400111886.issue42699@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

@samuelmarks:

A place where there it is possible to improve performance is with f-strings replacing %-formatting or str.format. This does move significant work to compile time.

However, we'd be unlikely to accept a wholesale stdlib change that swaps in f-strings. Instead, if there were specific places where benchmarks showed real world improvements, we should look at those on a case-by-case basis.

Also note that replacing %-formatting with .format() is almost always a performance pessimization.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42699>
_______________________________________

From report at bugs.python.org  Mon Dec 21 04:38:03 2020
From: report at bugs.python.org (Samuel Marks)
Date: Mon, 21 Dec 2020 09:38:03 +0000
Subject: [issue42699] Use `.join(k for k in g)` instead of `.join([k for k in
 g])`
In-Reply-To: <1608514774.35.0.908581836458.issue42699@roundup.psfhosted.org>
Message-ID: <1608543483.73.0.165068805848.issue42699@roundup.psfhosted.org>


Samuel Marks <samuelmarks at gmail.com> added the comment:

Wait I don't understand why you wouldn't accept a wholesale replacement of all `%` and `format` with f-strings through the entire CPython codebase [master branch]?

BTW: Kinda unrelated, but would be great to have perspective on this little project - https://github.com/SamuelMarks/doctrans - I'm interested in wholesale enforcement of code consistency and translating between constructs (e.g., dataclass to/fro argparse to/fro class method; ReST to/fro Google to/fro NumPy dostrings; inline types to/fro types in docstrings; with more planned)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42699>
_______________________________________

From report at bugs.python.org  Mon Dec 21 04:39:23 2020
From: report at bugs.python.org (Jakub Kulik)
Date: Mon, 21 Dec 2020 09:39:23 +0000
Subject: [issue37232] Parallel compilation fails because of low ulimit.
In-Reply-To: <1560258604.43.0.910483303566.issue37232@roundup.psfhosted.org>
Message-ID: <1608543563.86.0.185372912417.issue37232@roundup.psfhosted.org>


Jakub Kulik <kulikjak at gmail.com> added the comment:

I am closing this as it is true that the limit on files of 256 is pretty low, and no matter how robust you make it, arbitrarily low ulimits will crash it anyway.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37232>
_______________________________________

From report at bugs.python.org  Mon Dec 21 04:40:32 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 Dec 2020 09:40:32 +0000
Subject: [issue34550] UnicodeDecodeError when invoke method configure() of
 Menu instance
In-Reply-To: <1535644548.51.0.56676864532.issue34550@psf.upfronthosting.co.za>
Message-ID: <1608543632.02.0.828172649303.issue34550@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

There should no be any UnicodeDecodeError now. Tkinter on Windows uses now the UTF-16 encoding with the surrogatepass error handler which should never fail.

Could you please confirm that the issue is gone?

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34550>
_______________________________________

From report at bugs.python.org  Mon Dec 21 04:50:58 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 21 Dec 2020 09:50:58 +0000
Subject: [issue42686] include built-in Math functions in SQLite to 3.35.0 of
 march 2021
In-Reply-To: <1608391961.58.0.717857253057.issue42686@roundup.psfhosted.org>
Message-ID: <1608544258.45.0.77512241008.issue42686@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

I see no reason not to build SQLite with -DSQLITE_ENABLE_MATH_FUNCTIONS for the Windows and macOS builds. Why take the detour through the Python library when you can use the built-in SQLite functions?

The change is trivial: Add -DSQLITE_ENABLE_MATH_FUNCTIONS to PCbuild/sqlite3.vcxproj and Mac/BuildScript/build-installer.py.

----------
nosy: +erlendaasland

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42686>
_______________________________________

From report at bugs.python.org  Mon Dec 21 05:04:06 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 Dec 2020 10:04:06 +0000
Subject: [issue31483] ButtonPress event not firing until button release Python
 3.6.1
In-Reply-To: <1505481451.72.0.943425151923.issue31483@psf.upfronthosting.co.za>
Message-ID: <1608545046.37.0.289361548675.issue31483@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

And in any case Tkinter is just a wrapper around Tk. If there is a bug it should be reported on the Tk bug tracker.

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31483>
_______________________________________

From report at bugs.python.org  Mon Dec 21 05:06:17 2020
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 21 Dec 2020 10:06:17 +0000
Subject: [issue42693] "if 0:" lines are traced; they didn't use to be
In-Reply-To: <1608498368.47.0.692310939381.issue42693@roundup.psfhosted.org>
Message-ID: <1608545177.34.0.495752828959.issue42693@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Yes, this is change is deliberate.

PEP 626 states that *all* executed code gets traced.
Occasionally that will result in NOPs in the code, that are necessary 
for correctness, but cannot be removed by the optimizer.
Is this a problem in practice?

In fact this NOP can be removed by rewriting the bytecode to:

  2           0 LOAD_CONST               0 (10)
              2 STORE_NAME               0 (x)

  3           4 LOAD_CONST               3 (20)

  5           6 STORE_NAME               2 (y)
              8 LOAD_CONST               4 (None)
             10 RETURN_VALUE

but that is a relatively rare case where the proceeding or following instruction has no observable side-effects.
It is also non-trivial to implement, as the NOP and LOAD_CONST are in different basic blocks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42693>
_______________________________________

From report at bugs.python.org  Mon Dec 21 05:07:11 2020
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 21 Dec 2020 10:07:11 +0000
Subject: [issue42634] Incorrect line number in bytecode for try-except-finally
In-Reply-To: <1607930696.05.0.974303425196.issue42634@roundup.psfhosted.org>
Message-ID: <1608545231.48.0.649126526555.issue42634@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
resolution: fixed -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42634>
_______________________________________

From report at bugs.python.org  Mon Dec 21 05:12:32 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 21 Dec 2020 10:12:32 +0000
Subject: [issue42686] include built-in Math functions in SQLite to 3.35.0 of
 march 2021
In-Reply-To: <1608391961.58.0.717857253057.issue42686@roundup.psfhosted.org>
Message-ID: <1608545552.91.0.817144976913.issue42686@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Seems like the math functions will be included by default anyways, so we'll have to explicitly exclude them if we don't want them.

https://www.sqlite.org/draft/compile.html#enable_math_functions:
"This option?[SQLITE_ENABLE_MATH_FUNCTIONS] is automatically added to the Makefile by the configure script on unix platforms, unless the --disable-math option is used."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42686>
_______________________________________

From report at bugs.python.org  Mon Dec 21 05:16:14 2020
From: report at bugs.python.org (Ned Batchelder)
Date: Mon, 21 Dec 2020 10:16:14 +0000
Subject: [issue42693] "if 0:" lines are traced; they didn't use to be
In-Reply-To: <1608498368.47.0.692310939381.issue42693@roundup.psfhosted.org>
Message-ID: <1608545774.08.0.450920450183.issue42693@roundup.psfhosted.org>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

Previous versions of Python completely removed the "if 0:" statement, because it would have no effect.  The condition was checked at compile time, effectively.  It seems odd for 3.10 to add it back in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42693>
_______________________________________

From report at bugs.python.org  Mon Dec 21 05:30:13 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 21 Dec 2020 10:30:13 +0000
Subject: [issue42699] Use `.join(k for k in g)` instead of `.join([k for k in
 g])`
In-Reply-To: <1608514774.35.0.908581836458.issue42699@roundup.psfhosted.org>
Message-ID: <1608546613.19.0.346938167084.issue42699@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

> Wait I don't understand why you wouldn't accept a wholesale replacement of all `%` and `format` with f-strings through the entire CPython codebase [master branch]?

For such a large change it's difficult to review every single change and ensure it's correct. I'm guessing there are thousands of occurrences.

In addition, it runs the risk of breaking any existing pull requests.

And in the vast majority of cases it wouldn't make any noticeable performance difference. So why risk the breakage and endure the hassle?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42699>
_______________________________________

From report at bugs.python.org  Mon Dec 21 06:01:26 2020
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 21 Dec 2020 11:01:26 +0000
Subject: [issue42693] "if 0:" lines are traced; they didn't use to be
In-Reply-To: <1608498368.47.0.692310939381.issue42693@roundup.psfhosted.org>
Message-ID: <1608548486.12.0.495004807609.issue42693@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

But why remove it? It is in the source code.

Do we want tracing and profiling to depend on what transformations the optimizer does or does not make?

What lines are to be traced here? What is the last line executed?

def no_code():
    if 0:
        some_code


Consider the code:

def one():
    return 1

def two():
    return one() + 1

def const_test():
    if two() != 2:
       lots_of_code_here

What lines should be traced here?
If the runtime does speculatively inlining, should it change what code is to be traced?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42693>
_______________________________________

From report at bugs.python.org  Mon Dec 21 06:09:32 2020
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 21 Dec 2020 11:09:32 +0000
Subject: [issue42696] Duplicated unused bytecodes at end of function
In-Reply-To: <1608499758.44.0.239199538725.issue42696@roundup.psfhosted.org>
Message-ID: <1608548972.46.0.262900837402.issue42696@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

My guess is that we are changing the CFG after computing reachability leaving unreachable blocks marked as reachable.

----------
assignee:  -> Mark.Shannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42696>
_______________________________________

From report at bugs.python.org  Mon Dec 21 06:27:52 2020
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 21 Dec 2020 11:27:52 +0000
Subject: [issue42634] Incorrect line number in bytecode for try-except-finally
In-Reply-To: <1607930696.05.0.974303425196.issue42634@roundup.psfhosted.org>
Message-ID: <1608550072.29.0.838290169225.issue42634@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +22740
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/23877

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42634>
_______________________________________

From report at bugs.python.org  Mon Dec 21 06:44:02 2020
From: report at bugs.python.org (Ned Batchelder)
Date: Mon, 21 Dec 2020 11:44:02 +0000
Subject: [issue42693] "if 0:" lines are traced; they didn't use to be
In-Reply-To: <1608498368.47.0.692310939381.issue42693@roundup.psfhosted.org>
Message-ID: <1608551042.37.0.200319737606.issue42693@roundup.psfhosted.org>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

> PEP 626 states that *all* executed code gets traced.

Yes, but reading the PEP now, it's not clear what "executed" means. Do we mean "conceptually executed", or, "executed as compiled by the optimizing compiler"?

> In fact this NOP can be removed by rewriting the bytecode to:

That change looks both difficult and confusing.  If we want to keep an "if 0:" line in the bytecode, NOP is the best way to do it.

> But why remove it? It is in the source code.

I think the reason you are keeping it now isn't because it is in the source code.  Lines after returns are in the source code, but are now removed because they aren't in the path of execution.  "if 0:" is in the path of execution, so now you are keeping it. (I guess: I don't mean to put words in your mouth.)

As I mentioned, this is a change from previous versions, which removed the "if 0:" as uninteresting code.

> Do we want tracing and profiling to depend on what transformations the optimizer does or does not make?

Tracing has long depended on the optimizer's transformations.  When the optimizer removes a jump to a jump, the tracing never sees the removed intermediate jump.

The reason I am writing these bug reports is because coverage.py tries to track CPython's optimizations.  Coverage.py "knows" that "if 0:" lines won't appear in the trace, because previous versions removed them.

Unfortunately, it's not possible to make the match perfect. See bug 2506 for the original debate about this point.  As it stands now, CPython will keep statements in the byte code that are "conceptually" executed, but because of optimization, are never executed.  This creates a gap between the developer's mental model and the data produced by tools.

I can adjust coverage.py to reflect the decision either way from this bug report. Mostly I raise the issues to point out differences and to get a clear decision about whether it's desired behavior.

> If the runtime does speculatively inlining, should it change what code is to be traced?

I hope this is purely hypothetical. If CPython gets to that point we are going to have to revisit what kinds of controls there are to disable optimizations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42693>
_______________________________________

From report at bugs.python.org  Mon Dec 21 06:45:14 2020
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 21 Dec 2020 11:45:14 +0000
Subject: [issue42696] Duplicated unused bytecodes at end of function
In-Reply-To: <1608499758.44.0.239199538725.issue42696@roundup.psfhosted.org>
Message-ID: <1608551114.73.0.834864457564.issue42696@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Our reachability analysis is correct (in this case at least).
There is no unreachable code here.

In theory we could merge the two basic blocks at the end, but searching for identical blocks and merging them is potentially quite expensive (and fiddly).

What might be better is to be change the order of optimizations, so that we duplicate BBs after we have performed jump-to-jump elimination.

Is this a problem in practice?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42696>
_______________________________________

From report at bugs.python.org  Mon Dec 21 06:51:02 2020
From: report at bugs.python.org (Samuel Marks)
Date: Mon, 21 Dec 2020 11:51:02 +0000
Subject: [issue42699] Use `.join(k for k in g)` instead of `.join([k for k in
 g])`
In-Reply-To: <1608514774.35.0.908581836458.issue42699@roundup.psfhosted.org>
Message-ID: <1608551462.23.0.982786602704.issue42699@roundup.psfhosted.org>


Samuel Marks <samuelmarks at gmail.com> added the comment:

I suppose that's a good justification to never improve/upgrade the syntax and quality of the codebase.

In terms of automatic upgrades of the codebase, one could always replicate the approach I use in doctrans?i.e., use of `ast` and/or `inspect`?to automatically upgrade syntax from `%` and `.format` to use f-strings.

Would that be acceptable?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42699>
_______________________________________

From report at bugs.python.org  Mon Dec 21 06:52:43 2020
From: report at bugs.python.org (Samuel Marks)
Date: Mon, 21 Dec 2020 11:52:43 +0000
Subject: [issue42699] Use `.join(k for k in g)` instead of `.join([k for k in
 g])`
In-Reply-To: <1608514774.35.0.908581836458.issue42699@roundup.psfhosted.org>
Message-ID: <1608551563.74.0.537443363677.issue42699@roundup.psfhosted.org>


Samuel Marks <samuelmarks at gmail.com> added the comment:

EDIT: Just found https://github.com/ikamensh/flynt

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42699>
_______________________________________

From report at bugs.python.org  Mon Dec 21 08:07:57 2020
From: report at bugs.python.org (Michael Felt)
Date: Mon, 21 Dec 2020 13:07:57 +0000
Subject: [issue42701] Discrepency between configure.ac and configure
Message-ID: <1608556077.87.0.922310073391.issue42701@roundup.psfhosted.org>


New submission from Michael Felt <aixtools at felt.demon.nl>:

While working on a PR for issue42323 I get an error with the generated ./configure even without my patch.

Working from commit 37a6d5f8027f969418fe53d0a73a21003a8e370d

aixtools at gcc119:[/home/aixtools/cpython/cpython-master]git log --oneline | head
37a6d5f (HEAD -> master, upstream/master, upstream/HEAD, bpo-42323) [WIP/RFC] bpo-15872: tests: remove oddity from test_rmtree_errors (GH-22967)
ab74c01 bpo-31904: Fix site and sysconfig modules for VxWorks RTOS (GH-21821)
c95f8bc bpo-42669: Document that `except` rejects nested tuples (GH-23822)
b0398a4 bpo-42572:  Improve argparse docs for the type parameter. (GH-23849)
a44ce6c bpo-42604: always set EXT_SUFFIX=${SOABI}${SHLIB_SUFFIX} when using configure (GH-23708)

aixtools at gcc119:[/home/aixtools/cpython/cpython-master]rpm -qa autoconf
autoconf-2.69-2.noarch

aixtools at gcc119:[/home/aixtools/cpython/cpython-master]autoreconf -v
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /opt/freeware/bin/autoconf
autoreconf: running: /opt/freeware/bin/autoheader
autoreconf: configure.ac: not using Automake
autoreconf: Leaving directory `.'

Your branch is up-to-date with 'upstream/master'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   aclocal.m4
        modified:   configure
        modified:   pyconfig.h.in

aixtools at gcc119:[/home/aixtools/cpython/cpython-master]git diff configure
diff --git a/configure b/configure
index f07edff..6f0d51f 100755
--- a/configure
+++ b/configure
@@ -6471,44 +6471,10 @@ if test "$Py_OPT" = 'true' ; then
   DEF_MAKE_RULE="build_all"
   case $CC in
     *gcc*)
-      { $as_echo "$as_me:${as_lineno-$LINENO}: checking whether C compiler accepts -fno-semantic-interposition" >&5
-$as_echo_n "checking whether C compiler accepts -fno-semantic-interposition... " >&6; }
-if ${ax_cv_check_cflags___fno_semantic_interposition+:} false; then :
-  $as_echo_n "(cached) " >&6
-else
-
-  ax_check_save_flags=$CFLAGS
-  CFLAGS="$CFLAGS  -fno-semantic-interposition"
-  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
-/* end confdefs.h.  */
-
-int
-main ()
-{
-
-  ;
-  return 0;
-}
-_ACEOF
-if ac_fn_c_try_compile "$LINENO"; then :
-  ax_cv_check_cflags___fno_semantic_interposition=yes
-else
-  ax_cv_check_cflags___fno_semantic_interposition=no
-fi
-rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
-  CFLAGS=$ax_check_save_flags
-fi
-{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ax_cv_check_cflags___fno_semantic_interposition" >&5
-$as_echo "$ax_cv_check_cflags___fno_semantic_interposition" >&6; }
-if test "x$ax_cv_check_cflags___fno_semantic_interposition" = xyes; then :
-
+      AX_CHECK_COMPILE_FLAG(-fno-semantic-interposition,
       CFLAGS_NODIST="$CFLAGS_NODIST -fno-semantic-interposition"

aixtools at gcc119:[/home/aixtools/cpython/cpython-master]./configure
checking for git... found
checking build system type... powerpc-ibm-aix7.2.4.0
checking host system type... powerpc-ibm-aix7.2.4.0
checking for python3.10... no
checking for python3... python3
checking for --enable-universalsdk... no
checking for --with-universal-archs... no
checking MACHDEP... "aix"
checking for gcc... gcc
checking whether the C compiler works... yes
...
checking for --with-pydebug... no
checking for --with-trace-refs... no
checking for --with-assertions... no
checking for --enable-optimizations... no
./configure[6464]: syntax error at line 6475 : `(' unexpected
aixtools at gcc119:[/home/aixtools/cpython/cpython-master]

Unclear - to me - what is wrong with configure.ac or autoconf that is installed.

aixtools at gcc119:[/home/aixtools/cpython/cpython-master]autoconf --version
autoconf (GNU Autoconf) 2.69
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>, <http://gnu.org/licenses/exceptions.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.

----------
components: Build
messages: 383515
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: Discrepency between configure.ac and configure
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42701>
_______________________________________

From report at bugs.python.org  Mon Dec 21 08:13:39 2020
From: report at bugs.python.org (Julien Palard)
Date: Mon, 21 Dec 2020 13:13:39 +0000
Subject: [issue35790] Correct the description of sys.exc_info() and add a code
 example
In-Reply-To: <1548002384.27.0.286179066843.issue35790@roundup.psfhosted.org>
Message-ID: <1608556419.08.0.669835715616.issue35790@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:


New changeset d515c610c61b9a8c40c037a3dc3bfc8d67563658 by G?ry Ogam in branch 'master':
bpo-35790: Correct the description of sys.exc_info() and add a code example (GH-11625)
https://github.com/python/cpython/commit/d515c610c61b9a8c40c037a3dc3bfc8d67563658


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35790>
_______________________________________

From report at bugs.python.org  Mon Dec 21 08:14:44 2020
From: report at bugs.python.org (Julien Palard)
Date: Mon, 21 Dec 2020 13:14:44 +0000
Subject: [issue35790] Correct the description of sys.exc_info() and add a code
 example
In-Reply-To: <1548002384.27.0.286179066843.issue35790@roundup.psfhosted.org>
Message-ID: <1608556484.05.0.589525833078.issue35790@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/issue35790>
_______________________________________

From report at bugs.python.org  Mon Dec 21 08:14:59 2020
From: report at bugs.python.org (agbaroni)
Date: Mon, 21 Dec 2020 13:14:59 +0000
Subject: [issue42702] Inconsistent state after autoreconf
Message-ID: <1608556499.13.0.313130118619.issue42702@roundup.psfhosted.org>


New submission from agbaroni <alessiogiovanni.baroni at gmail.com>:

git clone https://github.com/python/cpython && cd cpython && autoreconf && ./configure --with-pydebug gives the following error:

checking for --enable-optimizations... no
./configure: line 6443: syntax error near unexpected token `-fno-semantic-interposition,'
./configure: line 6443: `      AX_CHECK_COMPILE_FLAG(-fno-semantic-interposition,'

Here (section 1.5): https://cpython-devguide.readthedocs.io/setup/ speaks about only autoreconf.

----------
messages: 383517
nosy: agbaroni
priority: normal
severity: normal
status: open
title: Inconsistent state after autoreconf
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42702>
_______________________________________

From report at bugs.python.org  Mon Dec 21 08:22:09 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 21 Dec 2020 13:22:09 +0000
Subject: [issue42699] Use `.join(k for k in g)` instead of `.join([k for k in
 g])`
In-Reply-To: <1608514774.35.0.908581836458.issue42699@roundup.psfhosted.org>
Message-ID: <1608556929.35.0.674148912108.issue42699@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

See https://github.com/ikamensh/flynt#dangers-of-conversion for reasons.

Would I like to see all string literal formatting done with f-strings? Yes!

Would I accept the risk and hassle of doing it blindly? No.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42699>
_______________________________________

From report at bugs.python.org  Mon Dec 21 08:45:46 2020
From: report at bugs.python.org (Michael Felt)
Date: Mon, 21 Dec 2020 13:45:46 +0000
Subject: [issue42701] Discrepency between configure.ac and configure
In-Reply-To: <1608556077.87.0.922310073391.issue42701@roundup.psfhosted.org>
Message-ID: <1608558346.49.0.208018886739.issue42701@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

This is what I find via bisect:

aixtools at gcc119:[/home/aixtools/cpython/cpython-master]git checkout . && git bisect bad
c6d7e82d19c091af698d4e4b3623648e259843e3 is the first bad commit
commit c6d7e82d19c091af698d4e4b3623648e259843e3
Author: Petr Viktorin <encukou at gmail.com>
Date:   Thu Oct 22 18:11:53 2020 +0200

    bpo-38980: Only apply -fno-semantic-interposition if available (GH-22892)

:100644 100644 b5f9cb0e8da44fb378e7e082f23025901cb06c6c 99913e7f3b85cf9ebba261073883c50b3f9a9ecd M      aclocal.m4
:100755 100755 df7118f68d3bb484148f8b719b1550676c029493 29f33b543ecc02c8eaae7cfd66c442a4bd60d44a M      configure
:100644 100644 c63c1e88a2302f7a60e9c2319f9965c1d7830d47 9698c3c888a6b7f74f2458df94bf21e51b6793d7 M      configure.ac

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42701>
_______________________________________

From report at bugs.python.org  Mon Dec 21 08:53:57 2020
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 21 Dec 2020 13:53:57 +0000
Subject: [issue42634] Incorrect line number in bytecode for try-except-finally
In-Reply-To: <1607930696.05.0.974303425196.issue42634@roundup.psfhosted.org>
Message-ID: <1608558837.47.0.468791098394.issue42634@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset f2dbfd7e20431f0bcf2b655aa876afec7fe03c6f by Mark Shannon in branch 'master':
bpo-42634: Mark reraise after except blocks as artificial. (GH-23877)
https://github.com/python/cpython/commit/f2dbfd7e20431f0bcf2b655aa876afec7fe03c6f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42634>
_______________________________________

From report at bugs.python.org  Mon Dec 21 08:55:22 2020
From: report at bugs.python.org (Mark Shannon)
Date: Mon, 21 Dec 2020 13:55:22 +0000
Subject: [issue42693] "if 0:" lines are traced; they didn't use to be
In-Reply-To: <1608498368.47.0.692310939381.issue42693@roundup.psfhosted.org>
Message-ID: <1608558922.78.0.231281591851.issue42693@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

You should never have to disable optimizations.

Let's be clear about what an optimization is.

An optimization (CS not math) is a change to the program such that it has the same effect, according to the language spec, but improves some aspect of the behavior, such as run time or memory use.

Any transformation that changes the effect of the program is not an optimization.

You shouldn't be able to tell, without timing the program (or measuring memory use, observing race conditions, etc.) whether optimizations are turned on or not.

Removing bytecodes for dead code is a legal optimization. It can never run, so we can't tell by observation whether it is there or not.

PEP 626 makes the lines number traced part of the language specification.
So the optimizer *must* respect line numbers.

Thus, removing all trace of `if 0:` is not legal since we could observe that change.
Hypothetically, we could change the line number table to allow multiple lines per bytecode and remove the NOP. The important point is that is coverage.py shouldn't care, or even know, if we do so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42693>
_______________________________________

From report at bugs.python.org  Mon Dec 21 08:58:45 2020
From: report at bugs.python.org (Michael Felt)
Date: Mon, 21 Dec 2020 13:58:45 +0000
Subject: [issue42701] Discrepency between configure.ac and configure
In-Reply-To: <1608556077.87.0.922310073391.issue42701@roundup.psfhosted.org>
Message-ID: <1608559125.26.0.194959622196.issue42701@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

This is beginning to look like it is an issue with the version of automake installed: 

aixtools at gcc119:[/home/aixtools/cpython/cpython-master]automake --version
Unescaped left brace in regex is deprecated, passed through in regex; marked by <-- HERE in m/\${ <-- HERE ([^ \t=:+{}]+)}/ at /usr/bin/automake line 3936.
automake (GNU automake) 1.15
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl-2.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Tom Tromey <tromey at redhat.com>
       and Alexandre Duret-Lutz <adl at gnu.org>.


Will test on a system where I can install the latest automake.

Assuming an updated version of automake fixes that - but not knowing autotools well enough - is there a simple addition to ensure that automake-1.16 is used?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42701>
_______________________________________

From report at bugs.python.org  Mon Dec 21 09:05:35 2020
From: report at bugs.python.org (Kurochan)
Date: Mon, 21 Dec 2020 14:05:35 +0000
Subject: [issue42257] platform.libc_ver() doesn't consider in case of
 executable is empty string
In-Reply-To: <1604469715.55.0.889552705694.issue42257@roundup.psfhosted.org>
Message-ID: <1608559535.22.0.471495275085.issue42257@roundup.psfhosted.org>


Kurochan <kuro at kurochan.org> added the comment:

Can anyone review this PR?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42257>
_______________________________________

From report at bugs.python.org  Mon Dec 21 09:30:35 2020
From: report at bugs.python.org (Matt Fowler)
Date: Mon, 21 Dec 2020 14:30:35 +0000
Subject: [issue42703] Asyncio Event Documentation Links Incorrect
Message-ID: <1608561035.31.0.374875188875.issue42703@roundup.psfhosted.org>


New submission from Matt Fowler <matt.fow at gmail.com>:

The documentation for `asyncio.Event` has incorrect links. The `wait` coroutine incorrectly links to the docs for the `asyncio.wait` waiting primitive, and the `set` method incorrectly links to the docs for the `set` class constructor.

----------
assignee: docs at python
components: Documentation
messages: 383524
nosy: docs at python, mattfowler
priority: normal
severity: normal
status: open
title: Asyncio Event Documentation Links Incorrect
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42703>
_______________________________________

From report at bugs.python.org  Mon Dec 21 09:33:43 2020
From: report at bugs.python.org (Malay Shah)
Date: Mon, 21 Dec 2020 14:33:43 +0000
Subject: [issue42704] [macOS] [python3.7] : platform.machine() returns x86_64
 on ARM machine
Message-ID: <1608561223.52.0.215688337013.issue42704@roundup.psfhosted.org>


New submission from Malay Shah <shah.malay04 at gmail.com>:

there is a discrepancy in platform.machine() behaviour on mac ARM:

In python2.7.16 ,  platform.machine() returns : "arm64"
In python3.7.9 , platform.machine() returns : "x86_64"

----------
components: macOS
messages: 383525
nosy: ned.deily, ronaldoussoren, shah.malay04
priority: normal
severity: normal
status: open
title: [macOS] [python3.7] : platform.machine() returns x86_64 on ARM machine
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42704>
_______________________________________

From report at bugs.python.org  Mon Dec 21 09:38:29 2020
From: report at bugs.python.org (Michael Felt)
Date: Mon, 21 Dec 2020 14:38:29 +0000
Subject: [issue42701] Discrepency between configure.ac and configure
In-Reply-To: <1608556077.87.0.922310073391.issue42701@roundup.psfhosted.org>
Message-ID: <1608561509.34.0.355390975869.issue42701@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

The 'issue' is that a package known as autoconf-archive must ALSO be installed - so that aclocal has a definition for ax_check_compile_flag.

Guessing that resolution is `third_party` - If not, please explain what the resolution flag is used for.

----------
resolution:  -> third party

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42701>
_______________________________________

From report at bugs.python.org  Mon Dec 21 09:40:48 2020
From: report at bugs.python.org (Matt Fowler)
Date: Mon, 21 Dec 2020 14:40:48 +0000
Subject: [issue42703] Asyncio Event Documentation Links Incorrect
In-Reply-To: <1608561035.31.0.374875188875.issue42703@roundup.psfhosted.org>
Message-ID: <1608561648.86.0.39667935081.issue42703@roundup.psfhosted.org>


Change by Matt Fowler <matt.fow at gmail.com>:


----------
keywords: +patch
pull_requests: +22741
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23881

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42703>
_______________________________________

From report at bugs.python.org  Mon Dec 21 09:53:37 2020
From: report at bugs.python.org (Ned Batchelder)
Date: Mon, 21 Dec 2020 14:53:37 +0000
Subject: [issue42693] "if 0:" lines are traced; they didn't use to be
In-Reply-To: <1608498368.47.0.692310939381.issue42693@roundup.psfhosted.org>
Message-ID: <1608562417.45.0.0727959776476.issue42693@roundup.psfhosted.org>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

This feels like a recurring debate.  I will need some time to lay out my case.  Perhaps it needs a wider audience than a bpo issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42693>
_______________________________________

From report at bugs.python.org  Mon Dec 21 10:04:08 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 21 Dec 2020 15:04:08 +0000
Subject: [issue42704] [macOS] [python3.7] : platform.machine() returns x86_64
 on ARM machine
In-Reply-To: <1608561223.52.0.215688337013.issue42704@roundup.psfhosted.org>
Message-ID: <1608563048.18.0.234351340442.issue42704@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

How did you install python3.7?

Platform.machine() will return "x86_64" when running in Rosetta 3. That is, when python itself is an x86_64 binary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42704>
_______________________________________

From report at bugs.python.org  Mon Dec 21 10:08:38 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 Dec 2020 15:08:38 +0000
Subject: [issue36968] Top level transient modal windows stopping deiconify on
 windows 10
In-Reply-To: <1558301146.73.0.73309397079.issue36968@roundup.psfhosted.org>
Message-ID: <1608563318.31.0.00210315608779.issue36968@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Tkinter is a wrapper around the Tk library. This seems a bug in Tk itself. Please file report on the corresponding bug tracker.

----------
nosy: +serhiy.storchaka
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36968>
_______________________________________

From report at bugs.python.org  Mon Dec 21 10:11:17 2020
From: report at bugs.python.org (Mohamad Kanj)
Date: Mon, 21 Dec 2020 15:11:17 +0000
Subject: [issue42705] Intercepting thread lock objects not working under
 context managers
Message-ID: <1608563477.42.0.0709881246927.issue42705@roundup.psfhosted.org>


Change by Mohamad Kanj <mhmd.kanj at gmail.com>:


----------
assignee: docs at python
components: C API, Demos and Tools, Distutils, Documentation
files: tracing-locking-mechanisms.py
nosy: docs at python, dstufft, eric.araujo, mhmdkanj
priority: normal
severity: normal
status: open
title: Intercepting thread lock objects not working under context managers
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49695/tracing-locking-mechanisms.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42705>
_______________________________________

From report at bugs.python.org  Mon Dec 21 10:14:43 2020
From: report at bugs.python.org (Mohamad Kanj)
Date: Mon, 21 Dec 2020 15:14:43 +0000
Subject: [issue42705] Intercepting thread lock objects not working under
 context managers
Message-ID: <1608563683.89.0.442233562977.issue42705@roundup.psfhosted.org>


New submission from Mohamad Kanj <mhmd.kanj at gmail.com>:

The interception of Python and C functions is achieved through the `sys` module - however, when using thread locks from `threading` module for instance under context managers, the calls on the lock to `acquire()` and `release()` cannot be witnessed. If these methods were to be called explicitly then this is no problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42705>
_______________________________________

From report at bugs.python.org  Mon Dec 21 10:21:26 2020
From: report at bugs.python.org (Malay Shah)
Date: Mon, 21 Dec 2020 15:21:26 +0000
Subject: [issue42704] [macOS] [python3.7] : platform.machine() returns x86_64
 on ARM machine
In-Reply-To: <1608561223.52.0.215688337013.issue42704@roundup.psfhosted.org>
Message-ID: <1608564086.02.0.826897560877.issue42704@roundup.psfhosted.org>


Malay Shah <shah.malay04 at gmail.com> added the comment:

I downloaded it from : 
www.python.org/ftp/python/3.7.9/python-3.7.9-macosx10.9.pkg

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42704>
_______________________________________

From report at bugs.python.org  Mon Dec 21 10:25:39 2020
From: report at bugs.python.org (Scott Norton)
Date: Mon, 21 Dec 2020 15:25:39 +0000
Subject: [issue42706] random.uniform 2x slower than inline implementation
Message-ID: <1608564339.76.0.67705848453.issue42706@roundup.psfhosted.org>


New submission from Scott Norton <pikalaxalt at gmail.com>:

The library function random.uniform takes about twice as long as a manual inline implementation (Python 3.9.1).

>>> import timeit
>>> timeit.timeit('3 + (8 - 3) * random.random()', 'import random')
0.1540887290000228
>>> timeit.timeit('a + (b - a) * random.random()', 'import random\na = 3\nb = 8')
0.17950458899986188
>>> timeit.timeit('random.uniform(3, 8)', 'import random')  # does the call/return really add that much overhead?
0.31145418699999894

----------
components: C API
messages: 383532
nosy: Scott Norton
priority: normal
severity: normal
status: open
title: random.uniform 2x slower than inline implementation
type: performance
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42706>
_______________________________________

From report at bugs.python.org  Mon Dec 21 10:28:58 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 21 Dec 2020 15:28:58 +0000
Subject: [issue42704] [macOS] [python3.7] : platform.machine() returns x86_64
 on ARM machine
In-Reply-To: <1608561223.52.0.215688337013.issue42704@roundup.psfhosted.org>
Message-ID: <1608564538.79.0.0438601859808.issue42704@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

That installer contains intel (x86_64) binaries. The behaviour of platform.machine() and platform.processor() is expected, due to Rosetta the binary runs as if it is running on an Intel Mac.

There is a "universal2" installer for Python 3.9.1 which will run natively on Arm systems.  The experience with 3th-party packages ("pip install ...") might be a bit rough though: this installer variant is quite new and I expect that most packages with C extensions do not yet have binary wheels for this variant.

----------
resolution:  -> not a bug
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42704>
_______________________________________

From report at bugs.python.org  Mon Dec 21 10:39:26 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 21 Dec 2020 15:39:26 +0000
Subject: [issue42706] random.uniform 2x slower than inline implementation
In-Reply-To: <1608564339.76.0.67705848453.issue42706@roundup.psfhosted.org>
Message-ID: <1608565166.66.0.0209150142824.issue42706@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Yes, calling functions in Python has some overhead. It is not specific to random.uniform().

----------
nosy: +rhettinger, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42706>
_______________________________________

From report at bugs.python.org  Mon Dec 21 10:53:31 2020
From: report at bugs.python.org (Michael Felt)
Date: Mon, 21 Dec 2020 15:53:31 +0000
Subject: [issue42323] [AIX] test_math: test_nextafter(float('nan'),
 1.0) does not return a NaN on AIX
In-Reply-To: <1605094498.01.0.809514320528.issue42323@roundup.psfhosted.org>
Message-ID: <1608566011.35.0.35917627866.issue42323@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

I have been doing a lot of research on this. Wish I had thought do start the way I finished.

Basically, when math.nextafter() was added all the AIX bots were on systems running AIX earlier than AIX 7.2 TL2.

When AIX 7.2 TL2 was released (roughly Q3 2017) a (major?) change was made to the nextafter() function.

root at gcc119:[/home2/root]instfix -k IV95512 -a
IV95512 Abstract: nextafter(+0.0, -0.0) returns +0.0 instead of -0.0.

IV95512 Symptom Text:
 If(x==y) nextafter returns x instead of y.

At first glance - it appears the CPython code is reversing the arguments:

The lines in test_math.py are currently:
 +2026          # NaN
 +2027          self.assertIsNaN(math.nextafter(NAN, 1.0))
 +2028          self.assertIsNaN(math.nextafter(1.0, NAN))
 +2029          self.assertIsNaN(math.nextafter(NAN, NAN))

Moving line 2027 (which is what is failing) to 2029 - the other two lines pass on an AIX system with IV95512 applied. 

As IEEE754 says (and seems to have always said):

https://pubs.opengroup.org/onlinepubs/9699919799: 

If x or y is NaN, a NaN shall be returned.

The current test in Modules/mathmodule.c might be too simple.

I am working on a PR where I check for presence of APAR IV95512 - with the nextafter() changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42323>
_______________________________________

From report at bugs.python.org  Mon Dec 21 11:10:06 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Dec 2020 16:10:06 +0000
Subject: [issue42704] [macOS] [python3.7] : platform.machine() returns x86_64
 on ARM machine
In-Reply-To: <1608561223.52.0.215688337013.issue42704@roundup.psfhosted.org>
Message-ID: <1608567006.25.0.124949998604.issue42704@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

Note also that Python 3.7 is now in the security-fix-only phase of its lifecycle meaning it no longer receives non-security bug fixes and binary installers for it will no longer be produced.  In particular, Pygthon 3.7 has not been updated for macOS 11 and Apple Silicon Macs and, as Ronald notes, it will run on Apple Silicon Macs using Rosetta 2 translation, there are some things that do not work correctly on Big Sur, like find_library functions.  If at all possible, you should upgrade to Python 3.9.1 which is supported on macOS 11 Big Sur.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42704>
_______________________________________

From report at bugs.python.org  Mon Dec 21 11:10:32 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Dec 2020 16:10:32 +0000
Subject: [issue42704] [macOS] [python3.7] : platform.machine() returns x86_64
 on ARM machine
In-Reply-To: <1608561223.52.0.215688337013.issue42704@roundup.psfhosted.org>
Message-ID: <1608567032.89.0.907513468817.issue42704@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42704>
_______________________________________

From report at bugs.python.org  Mon Dec 21 11:12:16 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Dec 2020 16:12:16 +0000
Subject: [issue42701] Discrepency between configure.ac and configure
In-Reply-To: <1608556077.87.0.922310073391.issue42701@roundup.psfhosted.org>
Message-ID: <1608567136.36.0.675799759622.issue42701@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42701>
_______________________________________

From report at bugs.python.org  Mon Dec 21 11:20:26 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Dec 2020 16:20:26 +0000
Subject: [issue42691] macOS 11.1 + Homebrew 2.6.2 + Python 3.9.1 = "IDLE" crash
In-Reply-To: <1608488832.09.0.347546053982.issue42691@roundup.psfhosted.org>
Message-ID: <1608567626.16.0.784924652892.issue42691@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

> I have tried to update tcl-tk with the homebrew, but in command line I see 8.5
> Could you please help me to fix this tcl-tk problem?

You should check with the Homebrew project; we have no insight into or control over their packaging choices.  Good luck!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42691>
_______________________________________

From report at bugs.python.org  Mon Dec 21 11:41:30 2020
From: report at bugs.python.org (Paul Ganssle)
Date: Mon, 21 Dec 2020 16:41:30 +0000
Subject: [issue42697] 3.8.7rc1 regression: 'free(): invalid pointer' after
 running backports-zoneinfo test suite
In-Reply-To: <1608501368.18.0.633201368751.issue42697@roundup.psfhosted.org>
Message-ID: <1608568890.23.0.536608367395.issue42697@roundup.psfhosted.org>


Paul Ganssle <p.ganssle at gmail.com> added the comment:

For future reference, this bug is triggered only when `.fromutc` is called on a subclass of `datetime` and the resulting date is the second ambiguous time (e.g. if there's a DST transition from 02:00 ? 01:00, and the result of the `.fromutc` call is the *second* 01:30, you will trigger this issue).

Here's an MWE:

```
from backports.zoneinfo import ZoneInfo
from datetime import datetime, timezone

class SubDT(datetime):
    pass

LON = ZoneInfo("Europe/London")
d = SubDT(2020, 10, 25, 1, 30, tzinfo=timezone.utc)

# Each pass through the loop inappropriately reduces the reference count on the
# `1` object by 1. Since there are usually a large number of live references to
# `1`, this won't have any immediate noticeable effect unless you do it a lot.
for i in range(10000):
    d.astimezone(LON)
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42697>
_______________________________________

From report at bugs.python.org  Mon Dec 21 12:11:36 2020
From: report at bugs.python.org (FX Coudert)
Date: Mon, 21 Dec 2020 17:11:36 +0000
Subject: [issue42691] macOS 11.1 + Homebrew 2.6.2 + Python 3.9.1 = "IDLE" crash
In-Reply-To: <1608488832.09.0.347546053982.issue42691@roundup.psfhosted.org>
Message-ID: <1608570696.43.0.618710369643.issue42691@roundup.psfhosted.org>


FX Coudert <fxcoudert at gmail.com> added the comment:

Hi Ned,

FX from Homebrew here. One of the reasons we a couple of years ago to stick with macOS system tcl-tk was that cpython's configure does not currently allow to build against our tcl-tk, which is not a framework but a simple Unix-style library build. We can definitely reconsider if you recommend a newer tcl-tk, but do you know if the build issues with non-framework tcl-tk have been fixed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42691>
_______________________________________

From report at bugs.python.org  Mon Dec 21 12:35:04 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Dec 2020 17:35:04 +0000
Subject: [issue42706] random.uniform 2x slower than inline implementation
In-Reply-To: <1608564339.76.0.67705848453.issue42706@roundup.psfhosted.org>
Message-ID: <1608572104.9.0.903923938403.issue42706@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> does the call/return really add that much overhead?

Yes, it does.

$ python3.9 -m timeit -s 'x=3.5' 'x**2'
5000000 loops, best of 5: 63.5 nsec per loop
$ python3.9 -m timeit -s 'x=3.5' -s 'f=lambda x: x**2' 'f(x)'
2000000 loops, best of 5: 136 nsec per loop

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42706>
_______________________________________

From report at bugs.python.org  Mon Dec 21 12:36:36 2020
From: report at bugs.python.org (FX Coudert)
Date: Mon, 21 Dec 2020 17:36:36 +0000
Subject: [issue42691] macOS 11.1 + Homebrew 2.6.2 + Python 3.9.1 = "IDLE" crash
In-Reply-To: <1608488832.09.0.347546053982.issue42691@roundup.psfhosted.org>
Message-ID: <1608572196.88.0.315031957753.issue42691@roundup.psfhosted.org>


FX Coudert <fxcoudert at gmail.com> added the comment:

After checking, I can see the code in cpython's setup.py is still there. detect_tkinter_darwin will prefer the system's version over anything we can specific in our cflags or ldflags. This seems contrary to the advice above not to use macOS system Tcl/Tk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42691>
_______________________________________

From report at bugs.python.org  Mon Dec 21 12:48:17 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Dec 2020 17:48:17 +0000
Subject: [issue42691] macOS 11.1 + Homebrew 2.6.2 + Python 3.9.1 = "IDLE" crash
In-Reply-To: <1608488832.09.0.347546053982.issue42691@roundup.psfhosted.org>
Message-ID: <1608572897.34.0.911312964261.issue42691@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

If you are not using Tcl and Tk framework builds installed in /Library, you use the configure or make options:

  --with-tcltk-includes='-I...'
                          override search for Tcl and Tk include files
  --with-tcltk-libs='-L...'
                          override search for Tcl and Tk libs

to specify exactly where to find your versions of Tcl and Tk. See the comments in setup.py:

    def detect_tkinter_explicitly(self):
        # Build _tkinter using explicit locations for Tcl/Tk.
        #
        # This is enabled when both arguments are given to ./configure:
        #
        #     --with-tcltk-includes="-I/path/to/tclincludes \
        #                            -I/path/to/tkincludes"
        #     --with-tcltk-libs="-L/path/to/tcllibs -ltclm.n \
        #                        -L/path/to/tklibs -ltkm.n"
        #
        # These values can also be specified or overridden via make:
        #    make TCLTK_INCLUDES="..." TCLTK_LIBS="..."
        #
        # This can be useful for building and testing tkinter with multiple
        # versions of Tcl/Tk.  Note that a build of Tk depends on a particular
        # build of Tcl so you need to specify both arguments and use care when
        # overriding.

        # The _TCLTK variables are created in the Makefile sharedmods target.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42691>
_______________________________________

From report at bugs.python.org  Mon Dec 21 12:51:52 2020
From: report at bugs.python.org (FX Coudert)
Date: Mon, 21 Dec 2020 17:51:52 +0000
Subject: [issue42691] macOS 11.1 + Homebrew 2.6.2 + Python 3.9.1 = "IDLE" crash
In-Reply-To: <1608488832.09.0.347546053982.issue42691@roundup.psfhosted.org>
Message-ID: <1608573112.74.0.108248663616.issue42691@roundup.psfhosted.org>


FX Coudert <fxcoudert at gmail.com> added the comment:

But we can override with --with-tcltk-includes and --with-tcltk-libs
I've opened a pull request for Homebrew to switch to recent tcl-tk: https://github.com/Homebrew/homebrew-core/pull/67378

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42691>
_______________________________________

From report at bugs.python.org  Mon Dec 21 12:58:23 2020
From: report at bugs.python.org (FX Coudert)
Date: Mon, 21 Dec 2020 17:58:23 +0000
Subject: [issue42691] macOS 11.1 + Homebrew 2.6.2 + Python 3.9.1 = "IDLE" crash
In-Reply-To: <1608488832.09.0.347546053982.issue42691@roundup.psfhosted.org>
Message-ID: <1608573503.15.0.53603744494.issue42691@roundup.psfhosted.org>


FX Coudert <fxcoudert at gmail.com> added the comment:

Our messages crossed, thanks Ned for the help. Hopefully we'll be solving this in a way that benefit most users.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42691>
_______________________________________

From report at bugs.python.org  Mon Dec 21 13:03:57 2020
From: report at bugs.python.org (=?utf-8?b?0J/RkdGC0YAg0KHQuNGA0LXQvdC60L4=?=)
Date: Mon, 21 Dec 2020 18:03:57 +0000
Subject: [issue42691] macOS 11.1 + Homebrew 2.6.2 + Python 3.9.1 = "IDLE" crash
In-Reply-To: <1608488832.09.0.347546053982.issue42691@roundup.psfhosted.org>
Message-ID: <1608573837.84.0.162167440766.issue42691@roundup.psfhosted.org>


???? ??????? <p.sirenko.94 at gmail.com> added the comment:

Guys, thank you all for joining the conversation!

I don't understand what exactly should I do to fix this, but I have a lot to study through py4u and plenty of time before I will really need Python fixed.
Should I do something with this now or just wait for updates?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42691>
_______________________________________

From report at bugs.python.org  Mon Dec 21 13:09:21 2020
From: report at bugs.python.org (Brad Warren)
Date: Mon, 21 Dec 2020 18:09:21 +0000
Subject: [issue42650] Can people use dest=argparse.SUPPRESS in custom Action
 classes?
In-Reply-To: <1608058165.01.0.505230302489.issue42650@roundup.psfhosted.org>
Message-ID: <1608574161.98.0.0793352821044.issue42650@roundup.psfhosted.org>


Brad Warren <bradmwarren at gmail.com> added the comment:

Thanks for the help! I was mistaken here.

The behavior I want is to not add the option to the namespace regardless of whether or not the user set it. I was initially under the impression that dest=SUPPRESS caused this behavior, however, it seems to have the same behavior as default=SUPPRESS due to the code at https://github.com/python/cpython/blob/711381dfb09fbd434cc3b404656f7fd306161a64/Lib/argparse.py#L1838-L1841. By using default=SUPPRESS which is documented and a custom __call__ method on an Action class, I can get the behavior I want so I'm closing this issue.

Thanks again and sorry for the noise!

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42650>
_______________________________________

From report at bugs.python.org  Mon Dec 21 13:29:19 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 21 Dec 2020 18:29:19 +0000
Subject: [issue42691] macOS 11.1 + Homebrew 2.6.2 + Python 3.9.1 = "IDLE" crash
In-Reply-To: <1608488832.09.0.347546053982.issue42691@roundup.psfhosted.org>
Message-ID: <1608575359.35.0.741722377123.issue42691@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

To use tkinter and hence IDLE and turtle on macOS, get the Mac Python installer on python.org.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42691>
_______________________________________

From report at bugs.python.org  Mon Dec 21 13:37:22 2020
From: report at bugs.python.org (Michael Felt)
Date: Mon, 21 Dec 2020 18:37:22 +0000
Subject: [issue42323] [AIX] test_math: test_nextafter(float('nan'),
 1.0) does not return a NaN on AIX
In-Reply-To: <1605094498.01.0.809514320528.issue42323@roundup.psfhosted.org>
Message-ID: <1608575842.49.0.813265616063.issue42323@roundup.psfhosted.org>


Michael Felt <aixtools at felt.demon.nl> added the comment:

While my patch in working - was successful in what it attempted to do, it did not fix this test issue.

Instead - I reinstalled the `bos.adt.libm-7.2.0.0` fileset, to backout of the so-called bugfix/APAR IV95512.

@David - can you take this up with AIX support - IV95112 (and more) do not seem to return NaN when one of the arguments is NaN.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42323>
_______________________________________

From report at bugs.python.org  Mon Dec 21 13:44:39 2020
From: report at bugs.python.org (Ned Deily)
Date: Mon, 21 Dec 2020 18:44:39 +0000
Subject: [issue42691] macOS 11.1 + Homebrew 2.6.2 + Python 3.9.1 = "IDLE" crash
In-Reply-To: <1608488832.09.0.347546053982.issue42691@roundup.psfhosted.org>
Message-ID: <1608576279.37.0.608462416736.issue42691@roundup.psfhosted.org>


Ned Deily <nad at python.org> added the comment:

> Should I do something with this now or just wait for updates?

I'd wait for a Homebrew recipe update.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42691>
_______________________________________

From report at bugs.python.org  Mon Dec 21 13:59:31 2020
From: report at bugs.python.org (Alexandre)
Date: Mon, 21 Dec 2020 18:59:31 +0000
Subject: [issue42707] Python uses ANSI CP for stdio on Windows console instead
 of using console or OEM CP
Message-ID: <1608577171.81.0.55180678487.issue42707@roundup.psfhosted.org>


New submission from Alexandre <alexandre+python at 13x.fr>:

Hello, 

first of all, I hope this was not already discussed (I searched the bugs but it might have been discussed elsewhere) and it's really a bug.

I've been struggling to understand today why a simple file redirection couldn't work properly today (encoding issues) and I think I finally understand the whole thing.

There's an IO codepage set on Windows consoles (`chcp` for cmd, `[Console]::InputEncoding; [Console]::OutputEncoding` for PowerShell ; chcp will not work on Powershell while it displays it set the CP), 850 for my locale.
When there's no redirection / piping, PyWindowsConsoleIO take cares of the encoding (utf-8 is seems), but when there's redirection or piping, encoding falls back to ANSI CP (from config_get_locale_encoding).

This behavior seems to be incorrect / breaking things, an example:
* testcp.py (file encoded as utf-8)
```
#!/usr/bin/env python3
# -*- coding: utf-8

print('?')
```

* using cmd:
```
# Test condition
L:\Cop>chcp
Page de codes active?: 850

# We're fine here
L:\Cop>py testcp.py
?
L:\Cop>py -c "import sys; print(sys.stdout.encoding)"
utf-8

# Now with piping
L:\Cop>py -c "import sys; print(sys.stdout.encoding)" | more
cp1252

L:\Cop>py testcp.py | more
?
L:\Cop>py testcp.py > lol && type lol
?

# If we adjust cmd CP, it's fine too:
L:\Cop>chcp 1252
Page de codes active?: 1252
L:\Cop>py testcp.py | more
?
```

* with pwsh:
```
PS L:\Cop> ([Console]::InputEncoding, [Console]::OutputEncoding) | select CodePage

CodePage
--------
     850
     850

# Fine without redirection
PS L:\Cop> py .\testcp.py
?

# Here, write-host expect cp850
PS L:\Cop> py .\testcp.py | write-output
?
# Same with Out-file (used by ">")
PS L:\Cop> py .\testcp.py > lol; Get-Content lol
?

# 
PS L:\Cop> py .\testcp.py | more
??
```

By reading some sources today to solve my issue, I found many solutions:
* in PS `[Console]::OutputEncoding = [Text.Utf8Encoding]::new($false); $env:PYTHONIOENCODING="utf8"` or `[Console]::OutputEncoding = [Text.Encoding]::GetEncoding(1252)`
* in CMD `chcp 65001 && set PYTHONIOENCODING=utf8` (but this seems to break more) or `chcp 1252`

But reading (and trusting) https://serverfault.com/questions/80635/how-can-i-manually-determine-the-codepage-and-locale-of-the-current-os (https://docs.microsoft.com/en-us/windows/win32/intl/locale-idefault-constants), I understand Python should be using reading the current CP (from GetConsoleOutputCP, like https://github.com/python/cpython/blob/3.9/Python/fileutils.c:) or using the default OEM CP, and not assuming ANSI CP for stdio : 
> * the OEM code page for use by legacy console applications,
> * the ANSI code page for use by legacy GUI applications.

The init path I could trace : 
> https://github.com/python/cpython/blob/3.9/Python/pylifecycle.c
> init_sys_streams
>> create_stdio (https://github.com/python/cpython/blob/3.9/Python/pylifecycle.c#L1774)
>>> open.raw : https://github.com/python/cpython/blob/3.9/Modules/_io/_iomodule.c#L374
>>>> https://github.com/python/cpython/blob/3.9/Modules/_io/winconsoleio.c
>> fallback to ini_sys_stream encoding
> https://github.com/python/cpython/blob/3.9/Python/initconfig.c
> config_init_stdio_encoding
> config_get_locale_encoding
> GetACP()

Some test with GetConsoleCP:
```
L:\Cop>py -c "import os; print(os.device_encoding(0), os.device_encoding(1))" | more
cp850 None

L:\Cop>type nul | py -c "import os; print(os.device_encoding(0), os.device_encoding(1))"
None cp850

L:\Cop>type nul | py -c "import ctypes; print(ctypes.windll.kernel32.GetConsoleCP(), ctypes.windll.kernel32.GetConsoleOutputCP())"
850 850

L:\Cop>py -c "import ctypes; print(ctypes.windll.kernel32.GetConsoleCP(), ctypes.windll.kernel32.GetConsoleOutputCP())" | more
850 850
```

Some links / documentations, if useful:
* https://serverfault.com/questions/80635/how-can-i-manually-determine-the-codepage-and-locale-of-the-current-os
* https://docs.microsoft.com/en-us/windows/win32/intl/locale-idefault-constants
* https://docs.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-getoemcp
* https://docs.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-getacp
* https://docs.microsoft.com/en-us/windows/console/getconsoleoutputcp
* https://stackoverflow.com/questions/56944301/why-does-powershell-redirection-change-the-formatting-of-the-text-content
* https://stackoverflow.com/questions/19122755/output-echo-a-variable-to-a-text-file
* https://stackoverflow.com/questions/40098771/changing-powershells-default-output-encoding-to-utf-8
* Maybe related: https://github.com/PowerShell/PowerShell/issues/10907
* https://stackoverflow.com/questions/57131654/using-utf-8-encoding-chcp-65001-in-command-prompt-windows-powershell-window (will probably break things :) )
* https://stackoverflow.com/questions/49476326/displaying-unicode-in-powershell/49481797#49481797
* https://stackoverflow.com/questions/25642746/how-do-i-pipe-unicode-into-a-native-application-in-powershell

Please note I took time to write this issue as best as I could, I hope it won't be closed without explaining why the current behavior is normal (not that I suppose this will happen, I just don't know how people react here :) ).

Thanks a lot for Python, I really enjoy using it, 
Best, 
Alexandre

----------
components: Windows
messages: 383550
nosy: paul.moore, steve.dower, tim.golden, u36959, zach.ware
priority: normal
severity: normal
status: open
title: Python uses ANSI CP for stdio on Windows console instead of using console or OEM CP
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42707>
_______________________________________

From report at bugs.python.org  Mon Dec 21 15:28:21 2020
From: report at bugs.python.org (agbaroni)
Date: Mon, 21 Dec 2020 20:28:21 +0000
Subject: [issue42702] Inconsistent state after autoreconf
In-Reply-To: <1608556499.13.0.313130118619.issue42702@roundup.psfhosted.org>
Message-ID: <1608582501.85.0.529853343038.issue42702@roundup.psfhosted.org>


agbaroni <alessiogiovanni.baroni at gmail.com> added the comment:

I'm closing the issue: I hadn't the autoconf-archive package on Fedora 33.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42702>
_______________________________________

From report at bugs.python.org  Mon Dec 21 15:59:43 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 21 Dec 2020 20:59:43 +0000
Subject: [issue42686] include built-in Math functions in SQLite to 3.35.0 of
 march 2021
In-Reply-To: <1608544258.45.0.77512241008.issue42686@roundup.psfhosted.org>
Message-ID: <20201221205849.GS28254@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

It is probably harmless to enable the option, especially if it will be 
the SQLite default, but why would you do your maths computations in sql, 
using the limited set of functions available, when you could do them in 
Python, with a much larger set of available functions and better 
debugging facilities?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42686>
_______________________________________

From report at bugs.python.org  Mon Dec 21 16:11:48 2020
From: report at bugs.python.org (Samuel Marks)
Date: Mon, 21 Dec 2020 21:11:48 +0000
Subject: [issue42699] Use `.join(k for k in g)` instead of `.join([k for k in
 g])`
In-Reply-To: <1608556929.35.0.674148912108.issue42699@roundup.psfhosted.org>
Message-ID: <CAMfPbcZAMMEtgp_giHRcs5KPiay=pHxn_pRX5VSF_VCmBeUTTg@mail.gmail.com>


Samuel Marks <samuelmarks at gmail.com> added the comment:

There were only 12k occurrences, I'm sure I could manually go through that
in an afternoon. Would you accept it then?

On Tue, 22 Dec 2020, 12:22 am Eric V. Smith, <report at bugs.python.org> wrote:

>
> Eric V. Smith <eric at trueblade.com> added the comment:
>
> See https://github.com/ikamensh/flynt#dangers-of-conversion for reasons.
>
> Would I like to see all string literal formatting done with f-strings? Yes!
>
> Would I accept the risk and hassle of doing it blindly? No.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue42699>
> _______________________________________
>

----------
nosy: +SamuelMarks

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42699>
_______________________________________

From report at bugs.python.org  Mon Dec 21 16:20:33 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 21 Dec 2020 21:20:33 +0000
Subject: [issue42699] Use `.join(k for k in g)` instead of `.join([k for k in
 g])`
In-Reply-To: <CAMfPbcZAMMEtgp_giHRcs5KPiay=pHxn_pRX5VSF_VCmBeUTTg@mail.gmail.com>
Message-ID: <20201221211911.GV28254@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

On Mon, Dec 21, 2020 at 09:11:48PM +0000, Samuel Marks wrote:

> There were only 12k occurrences, I'm sure I could manually go through that
> in an afternoon. Would you accept it then?

Assuming "an afternoon" is half a work day, so 4 hours, that's 1.2 
seconds per occurrence. So no, not even if you were a trusted core 
developer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42699>
_______________________________________

From report at bugs.python.org  Mon Dec 21 16:22:35 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Dec 2020 21:22:35 +0000
Subject: [issue42686] include built-in Math functions in SQLite to 3.35.0 of
 march 2021
In-Reply-To: <1608391961.58.0.717857253057.issue42686@roundup.psfhosted.org>
Message-ID: <1608585755.15.0.71282521745.issue42686@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> but why would you do your maths computations in sql?

There are number of reasons it might be more convenient in SQL.  For example, it could be handy to create views measured in degrees instead of radians.  That might make where clauses in queries a little easier to read.


> Seems like the math functions will be included by default anyways

So, can this be closed?

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42686>
_______________________________________

From report at bugs.python.org  Mon Dec 21 16:33:34 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 21 Dec 2020 21:33:34 +0000
Subject: [issue42686] include built-in Math functions in SQLite to 3.35.0 of
 march 2021
In-Reply-To: <1608391961.58.0.717857253057.issue42686@roundup.psfhosted.org>
Message-ID: <1608586414.9.0.558648394938.issue42686@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

> So, can this be closed?

For macOS, the SQLITE_ENABLE_MATH_FUNCTIONS option is enabled by default, but I'm not sure about the Windows build. The SQLite docs says: 
"This option is also included on Windows builds using the "Makefile.msc" makefile for nmake."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42686>
_______________________________________

From report at bugs.python.org  Mon Dec 21 16:43:02 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Dec 2020 21:43:02 +0000
Subject: [issue42705] Intercepting thread lock objects not working under
 context managers
In-Reply-To: <1608563683.89.0.442233562977.issue42705@roundup.psfhosted.org>
Message-ID: <1608586982.3.0.839620065897.issue42705@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The sys.setprofile() doc don't make it clear whether the __enter__ and __exit__ call were intended to be traceable events.  The docs do state, "there is no way for the profiler to know about context switches between threads, so it does not make sense to use this in the presence of multiple threads."

----------
nosy: +rhettinger, vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42705>
_______________________________________

From report at bugs.python.org  Mon Dec 21 16:46:05 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Dec 2020 21:46:05 +0000
Subject: [issue42151] Pure Python xml.etree.ElementTree is missing default
 attribute values
In-Reply-To: <1603684290.04.0.0149631860455.issue42151@roundup.psfhosted.org>
Message-ID: <1608587165.08.0.0533150726628.issue42151@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Changing the behaviour of the C implementation would 
> certainly break a lot more code than changing the Python
> implementation.

+1 for changing only the Python implementation.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42151>
_______________________________________

From report at bugs.python.org  Mon Dec 21 16:50:19 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Dec 2020 21:50:19 +0000
Subject: [issue16535] json encoder unable to handle decimal
In-Reply-To: <1353624338.46.0.574343718645.issue16535@psf.upfronthosting.co.za>
Message-ID: <1608587419.56.0.0571498349217.issue16535@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> I wonder if adding something similar to what `simplejson` uses 
> (i.e. explicitly specifying in `json.dump(s)` how to
> serialize `decimal.Decimal`) could be acceptable.

+1 for this approach.  For financial applications, we need the recommended solution to be simple.

----------
nosy: +bob.ippolito
versions: +Python 3.10 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16535>
_______________________________________

From report at bugs.python.org  Mon Dec 21 16:51:51 2020
From: report at bugs.python.org (Mohamad Kanj)
Date: Mon, 21 Dec 2020 21:51:51 +0000
Subject: [issue42705] Intercepting thread lock objects not working under
 context managers
In-Reply-To: <1608563683.89.0.442233562977.issue42705@roundup.psfhosted.org>
Message-ID: <1608587511.69.0.0641060569121.issue42705@roundup.psfhosted.org>


Mohamad Kanj <mhmd.kanj at gmail.com> added the comment:

Thanks Raymond for the input.
So with some experimentation, the __enter__() & __exit__() functions could be traceable when other kinds of objects are used with the context manager (i.e with statement using file IO or custom class objects). However, just when the object is a Lock object, then this is not the case anymore - which basically shows an unusual behavior if we were to think that such statements are executed for a specific thread. Also please mind that the threading module already implements settrace() and setprofile() methods like the sys module to extend tracing capabilities.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42705>
_______________________________________

From report at bugs.python.org  Mon Dec 21 18:26:32 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Dec 2020 23:26:32 +0000
Subject: [issue29030] argparse: choices override metavar
In-Reply-To: <1482281546.0.0.613026945443.issue29030@psf.upfronthosting.co.za>
Message-ID: <1608593192.74.0.363849455668.issue29030@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
pull_requests: +22743
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23884

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29030>
_______________________________________

From report at bugs.python.org  Mon Dec 21 18:36:46 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Dec 2020 23:36:46 +0000
Subject: [issue9625] argparse: Problem with defaults for variable nargs when
 using choices
In-Reply-To: <1282036744.37.0.964764969496.issue9625@psf.upfronthosting.co.za>
Message-ID: <1608593806.14.0.840171338965.issue9625@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/issue9625>
_______________________________________

From report at bugs.python.org  Mon Dec 21 18:38:08 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Dec 2020 23:38:08 +0000
Subject: [issue29030] argparse: choices override default metavar
In-Reply-To: <1482281546.0.0.613026945443.issue29030@psf.upfronthosting.co.za>
Message-ID: <1608593888.3.0.849584578158.issue29030@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
title: argparse: choices override metavar -> argparse: choices override default metavar

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29030>
_______________________________________

From report at bugs.python.org  Mon Dec 21 18:45:59 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Dec 2020 23:45:59 +0000
Subject: [issue42008] Internal Random class calling seed() with incorrect
 argument
In-Reply-To: <1602453161.68.0.0739681342621.issue42008@roundup.psfhosted.org>
Message-ID: <1608594359.3.0.326378908839.issue42008@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset b8fde8b5418b75d2935d0ff93b20d45d5350f206 by AMIR in branch 'master':
bpo-42008: Fix internal _random.Random() seeding for the one argument case (GH-22668)
https://github.com/python/cpython/commit/b8fde8b5418b75d2935d0ff93b20d45d5350f206


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42008>
_______________________________________

From report at bugs.python.org  Mon Dec 21 18:46:42 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 21 Dec 2020 23:46:42 +0000
Subject: [issue42008] Internal Random class calling seed() with incorrect
 argument
In-Reply-To: <1602453161.68.0.0739681342621.issue42008@roundup.psfhosted.org>
Message-ID: <1608594402.23.0.190157558449.issue42008@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for the PR :-)

----------
assignee:  -> rhettinger
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42008>
_______________________________________

From report at bugs.python.org  Mon Dec 21 19:15:54 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Dec 2020 00:15:54 +0000
Subject: [issue39159] Ideas for making ast.literal_eval() usable
In-Reply-To: <1577658169.97.0.393062022698.issue39159@roundup.psfhosted.org>
Message-ID: <1608596154.29.0.366685810083.issue39159@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset fbc7723778be01b8f3bb72d2dcac15ab9fbb9923 by Batuhan Taskaya in branch 'master':
bpo-39159: Declare error that might be raised from literal_eval (GH-19899)
https://github.com/python/cpython/commit/fbc7723778be01b8f3bb72d2dcac15ab9fbb9923


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39159>
_______________________________________

From report at bugs.python.org  Mon Dec 21 19:54:50 2020
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 22 Dec 2020 00:54:50 +0000
Subject: [issue42246] Implement PEP 626 -- Precise line numbers for debugging
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1608598490.93.0.237824884611.issue42246@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
nosy: +methane

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42246>
_______________________________________

From report at bugs.python.org  Mon Dec 21 20:39:34 2020
From: report at bugs.python.org (Karl Fogel)
Date: Tue, 22 Dec 2020 01:39:34 +0000
Subject: [issue30988] Exception parsing invalid email address headers starting
 or ending with dot
In-Reply-To: <1500699002.76.0.343337119039.issue30988@psf.upfronthosting.co.za>
Message-ID: <1608601174.25.0.312200063799.issue30988@roundup.psfhosted.org>


Karl Fogel <kfogel at red-bean.com> added the comment:

I can also confirm this bug, with Python 3.9.1 on Debian GNU/Linux ('testing' distro up-to-date as of 2020-12-21).

1) Create a parser `p` with `p = email.parser.HeaderParser(policy=email.policy.default)`.

2) Parse a single problematic (as described below) message: `msg_headers = p.parsestr(msg_str)`

3) Try to get the To field: `msg_headers.get_all('to', [ ])` and get an exception raised: `AttributeError: 'str' object has no attribute 'token_type'` (with the same stack trace as OP shows).

Here is a minimal problematic message you can reproduce this with (i.e., just make `msg_str` have this string value):

```
>From nobody Mon Dec 21 12:00:00  2020
From: sender at example.com
To: . <jrandom at example.com>
Date: Mon, 21 Dec 2020 12:00:00 -0000
Message-ID: <87ab5rvds7.fsf at example.com>
Subject: This is the Subject header.

Here is the body of the message.
```

Note that *any* number of dots for the recipient's name would also result in an error.  The above example uses just ".", but it could be "..", "...", ".................", etc.

----------
nosy: +kfogel

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30988>
_______________________________________

From report at bugs.python.org  Mon Dec 21 21:00:48 2020
From: report at bugs.python.org (Reeyarn Li)
Date: Tue, 22 Dec 2020 02:00:48 +0000
Subject: [issue42708] AttributeError when running multiprocessing on MacOS 11
 with Apple Silicon (M1)
Message-ID: <1608602448.28.0.20225447007.issue42708@roundup.psfhosted.org>


New submission from Reeyarn Li <reeyarn at gmail.com>:

I just run the sample code from multiprocessing's documentation page:

#https://docs.python.org/3/library/multiprocessing.html

from multiprocessing import Pool

def f(x):
    return x*x


with Pool(5) as p:
    print(p.map(f, [1, 2, 3]))

## end of code

And it cannot run, with the following error messages:
Process SpawnPoolWorker-2:
Traceback (most recent call last):
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/multiprocessing/process.py", line 315, in _bootstrap
    self.run()
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/multiprocessing/process.py", line 108, in run
    self._target(*self._args, **self._kwargs)
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/multiprocessing/pool.py", line 114, in worker
    task = get()
  File "/Library/Developer/CommandLineTools/Library/Frameworks/Python3.framework/Versions/3.8/lib/python3.8/multiprocessing/queues.py", line 358, in get
    return _ForkingPickler.loads(res)
AttributeError: Can't get attribute 'f' on <module '__main__' (built-in)>

----------
components: macOS
messages: 383565
nosy: ned.deily, reeyarn, ronaldoussoren
priority: normal
severity: normal
status: open
title: AttributeError when running multiprocessing on MacOS 11 with Apple Silicon (M1)
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42708>
_______________________________________

From report at bugs.python.org  Mon Dec 21 21:02:17 2020
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 22 Dec 2020 02:02:17 +0000
Subject: [issue42707] Python uses ANSI CP for stdio on Windows console instead
 of using console or OEM CP
In-Reply-To: <1608577171.81.0.55180678487.issue42707@roundup.psfhosted.org>
Message-ID: <1608602537.95.0.715463893662.issue42707@roundup.psfhosted.org>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

> I've been struggling to understand today why a simple file redirection couldn't work properly today (encoding issues)

The core issue is that "working properly" is not defined in general when we're talking about piping/redirection, as opposed to the console. Different programs that consume Python's output (or produce its input) can have different expectations wrt. data encoding, and there is no way for Python to know it in advance. In your examples, you use programs like "more" and "type" to print the Python's output back to the console, so in this case using the OEM code page would produce the result that you expect. But, for example, in case Python's output was to be consumed by a C program that uses simple `fopen()/wscanf()/wprintf()` to work with text files, the ANSI code page would be appropriate because that's what the Microsoft C runtime library defaults to for wide character operations.

Python has traditionally used the ANSI code page as the default IO encoding for non-console cases (note that Python makes no distinction between non-console `sys.std*` and the builtin `open()` wrt. encoding), and this behavior can't be changed. You can use `PYTHONIOENCODING` or enable the UTF-8 mode[1] to change the default encoding.

Note that in your example you could simply use `PYTHONIOENCODING=cp850`, which would remove the need to use `chcp`.

[1] https://docs.python.org/3/using/cmdline.html#envvar-PYTHONUTF8

----------
nosy: +izbyshev, vstinner
versions: +Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42707>
_______________________________________

From report at bugs.python.org  Mon Dec 21 21:27:31 2020
From: report at bugs.python.org (Reeyarn Li)
Date: Tue, 22 Dec 2020 02:27:31 +0000
Subject: [issue42708] AttributeError when running multiprocessing on MacOS 11
 with Apple Silicon (M1)
In-Reply-To: <1608602448.28.0.20225447007.issue42708@roundup.psfhosted.org>
Message-ID: <1608604051.65.0.530063618833.issue42708@roundup.psfhosted.org>


Reeyarn Li <reeyarn at gmail.com> added the comment:

There is already a solution: https://stackoverflow.com/questions/41385708/multiprocessing-example-giving-attributeerror

When putting the function into a separate file and import it in the main file, there is no error at all.

##File: defs.py

def f(x):
    return x*x


##File: run.py

from multiprocessing import Pool
import defs

if __name__ == '__main__':
    with Pool(5) as p:
        print(p.map(defs.f, [1, 2, 3]))

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42708>
_______________________________________

From report at bugs.python.org  Mon Dec 21 21:41:55 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Dec 2020 02:41:55 +0000
Subject: [issue39159] Ideas for making ast.literal_eval() usable
In-Reply-To: <1577658169.97.0.393062022698.issue39159@roundup.psfhosted.org>
Message-ID: <1608604915.19.0.761893560968.issue39159@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Can you explain it a bit more detailed, 
> how does this standalone expression compiler should work?

Aim for something like JSON parser but for the supported Python constant expressions and with the existing tokenize module to feed a hand-rolled on-recursive parser

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39159>
_______________________________________

From report at bugs.python.org  Mon Dec 21 21:42:30 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Dec 2020 02:42:30 +0000
Subject: [issue40284] Add mapping methods to types.SimpleNamespace
In-Reply-To: <1586898649.19.0.221456344176.issue40284@roundup.psfhosted.org>
Message-ID: <1608604950.03.0.819024213697.issue40284@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> rejected

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40284>
_______________________________________

From report at bugs.python.org  Mon Dec 21 21:45:54 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Dec 2020 02:45:54 +0000
Subject: [issue1818] Add named tuple reader to CSV module
In-Reply-To: <1200263236.24.0.0303258184569.issue1818@psf.upfronthosting.co.za>
Message-ID: <1608605154.56.0.966445361495.issue1818@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1818>
_______________________________________

From report at bugs.python.org  Mon Dec 21 21:53:57 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Dec 2020 02:53:57 +0000
Subject: [issue38381] Possible wordcode optimization for STORE/LOAD pairs
In-Reply-To: <1570314235.55.0.575306260981.issue38381@roundup.psfhosted.org>
Message-ID: <1608605637.84.0.648622600559.issue38381@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38381>
_______________________________________

From report at bugs.python.org  Mon Dec 21 21:54:50 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Dec 2020 02:54:50 +0000
Subject: [issue40284] Add mapping methods to types.SimpleNamespace
In-Reply-To: <1586898649.19.0.221456344176.issue40284@roundup.psfhosted.org>
Message-ID: <1608605690.08.0.679651695463.issue40284@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40284>
_______________________________________

From report at bugs.python.org  Mon Dec 21 22:04:50 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Dec 2020 03:04:50 +0000
Subject: [issue42693] "if 0:" lines are traced; they didn't use to be
In-Reply-To: <1608498368.47.0.692310939381.issue42693@roundup.psfhosted.org>
Message-ID: <1608606290.23.0.197311525507.issue42693@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> But why remove it? It is in the source code.

Because traditionally, "if 0: <suite>" has been used as a way to comment out code while leaving syntax highlighting in place.  The expectation is all the code effectively ceases to exist, just like a comment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42693>
_______________________________________

From report at bugs.python.org  Mon Dec 21 22:59:18 2020
From: report at bugs.python.org (James B Wilkinson)
Date: Tue, 22 Dec 2020 03:59:18 +0000
Subject: [issue42709] I
Message-ID: <1608609558.65.0.94290684892.issue42709@roundup.psfhosted.org>


Change by James B Wilkinson <the.doc at twc.com>:


----------
nosy: the.doc
priority: normal
severity: normal
status: open
title: I

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42709>
_______________________________________

From report at bugs.python.org  Mon Dec 21 23:11:20 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Dec 2020 04:11:20 +0000
Subject: [issue42709] I
Message-ID: <1608610280.42.0.0395707592732.issue42709@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42709>
_______________________________________

From report at bugs.python.org  Mon Dec 21 23:26:31 2020
From: report at bugs.python.org (Faris Chugthai)
Date: Tue, 22 Dec 2020 04:26:31 +0000
Subject: [issue42710] Viewing pydoc API documentation
Message-ID: <1608611191.07.0.553217513358.issue42710@roundup.psfhosted.org>


New submission from Faris Chugthai <farischugthai at gmail.com>:

I'm sure that this has been observed before, but I was unable to find the original issue where this was discussed so I'm going to apologize in advance for what is probably a duplicate issue.

But why is there no documentation available on the classes and functions available in the pydoc module?

There are a large number of well documented classes, methods and functions and I could easily imagine legitimate motivations to want to import some of the functionality provided and use it in a project.

No information on the 2000 lines of code in pydoc.py are provided at https://docs.python.org/3/library/pydoc.html

Running:

`python -m pydoc -w pydoc`

Generates a similarly sparse file.

In addition, running in the interactive interpreter:

>>> help(pydoc)

shows almost no real information. I'm genuinely unsure of why this happens. Even if this is an intentional design decision for how the Helper class is supposed to work, why isn't there corresponding information for the different classes at `Doc/library/pydoc.rst`?

Searching for something like `pydoc.TextRepr` in the search bar of docs.python.org doesn't return anything at all.

Sorry if there's something horrifically obvious I'm missing here guys but I'd appreciate any clarification on this matter.

----------
assignee: docs at python
components: Documentation
messages: 383570
nosy: Faris Chugthai, docs at python
priority: normal
severity: normal
status: open
title: Viewing pydoc API documentation

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42710>
_______________________________________

From report at bugs.python.org  Mon Dec 21 23:43:55 2020
From: report at bugs.python.org (James B Wilkinson)
Date: Tue, 22 Dec 2020 04:43:55 +0000
Subject: [issue42709] I
In-Reply-To: <1608610280.45.0.0927871104429.issue42709@roundup.psfhosted.org>
Message-ID: <7545B6BF-D18B-459A-97C3-2A2C4219666A@twc.com>


New submission from James B Wilkinson <the.doc at twc.com>:

> On Dec 21, 2020, at 11:11 PM, Raymond Hettinger <report at bugs.python.org> wrote:
> 
> 
> Change by Raymond Hettinger <raymond.hettinger at gmail.com>:
> 
> 
> ----------
> stage:  -> resolved
> status: open -> closed

I see that this has been marked ?resolved? and closed with no hint as to what the problem is.

Did I do something wrong by submitting this? If so I apologize.

thanks

James B. Wilkinson
Professor Emeritus
Department of Computer Science
The College of Charleston

the.doc at twc.com

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42709>
_______________________________________

From report at bugs.python.org  Tue Dec 22 00:13:01 2020
From: report at bugs.python.org (Tim Peters)
Date: Tue, 22 Dec 2020 05:13:01 +0000
Subject: [issue42709] I
In-Reply-To: <7545B6BF-D18B-459A-97C3-2A2C4219666A@twc.com>
Message-ID: <1608613981.52.0.725600766782.issue42709@roundup.psfhosted.org>


Tim Peters <tim at python.org> added the comment:

It appears to be spam: the title is the single letter "I", and there's not a single word of text. There was nothing sensible to be done _except_ to close it :-)

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42709>
_______________________________________

From report at bugs.python.org  Tue Dec 22 00:36:13 2020
From: report at bugs.python.org (Desmond Cheong)
Date: Tue, 22 Dec 2020 05:36:13 +0000
Subject: [issue35728] Tkinter font nametofont requires default root
In-Reply-To: <1547328812.09.0.281453810047.issue35728@roundup.psfhosted.org>
Message-ID: <1608615373.21.0.717029346283.issue35728@roundup.psfhosted.org>


Change by Desmond Cheong <desmondcheongzx at gmail.com>:


----------
keywords: +patch
nosy: +desmondcheongzx
nosy_count: 2.0 -> 3.0
pull_requests: +22744
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/23885

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35728>
_______________________________________

From report at bugs.python.org  Tue Dec 22 01:40:07 2020
From: report at bugs.python.org (Kaleb Barrett)
Date: Tue, 22 Dec 2020 06:40:07 +0000
Subject: [issue42711] lru_cache and NotImplemented
Message-ID: <1608619207.84.0.36165935347.issue42711@roundup.psfhosted.org>


New submission from Kaleb Barrett <dev.ktbarrett at gmail.com>:

Having to return `NotImplemented` (which counts as a successful function call) in `functools.lru_cache` and `functools.cache` decorated binary dunder methods has the potential to fill the LRU cache with calls that will in ultimately result in errors (read "garbage").

There are a few ways to avoid this IMO:

1. Change `functools.lru_cache` not cache calls that result in `NotImplemented`.
2. Allow a user to easily extend `functools.lru_cache` (the implementation is not extensible right now) to do the previously mentioned operation.
3. Add the ability to *throw* `NotImplemented` in binary dunder methods so the function call does not complete. This would work exactly like returning `NotImplemented` and be handled by the runtime.

And my current solution...

4. Copy-paste `functools.lru_cache` and add in changes for solution 1 :)

----------
components: Library (Lib)
messages: 383573
nosy: ktbarrett
priority: normal
severity: normal
status: open
title: lru_cache and NotImplemented
type: performance
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42711>
_______________________________________

From report at bugs.python.org  Tue Dec 22 03:24:55 2020
From: report at bugs.python.org (Xinmeng Xia)
Date: Tue, 22 Dec 2020 08:24:55 +0000
Subject: [issue42652] recursive in finally clause cause Python interpreter
 crash.
In-Reply-To: <1608108499.51.0.334108279167.issue42652@roundup.psfhosted.org>
Message-ID: <1608625495.97.0.290480149186.issue42652@roundup.psfhosted.org>


Xinmeng Xia <xiaxm at smail.nju.edu.cn> added the comment:

Thanks for fixing this, looking forward to the new version.

Could you please kindly change the resolution into fixed and close this report?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42652>
_______________________________________

From report at bugs.python.org  Tue Dec 22 03:26:36 2020
From: report at bugs.python.org (Xinmeng Xia)
Date: Tue, 22 Dec 2020 08:26:36 +0000
Subject: [issue42651] Recursive traceback crashes  Python Interpreter
In-Reply-To: <1608105735.03.0.523665122471.issue42651@roundup.psfhosted.org>
Message-ID: <1608625596.08.0.878392973034.issue42651@roundup.psfhosted.org>


Xinmeng Xia <xiaxm at smail.nju.edu.cn> added the comment:

Thank you very much, looking forward to the new Python version.

Could you please kindly change the resolution into fixed and close this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42651>
_______________________________________

From report at bugs.python.org  Tue Dec 22 03:32:24 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Dec 2020 08:32:24 +0000
Subject: [issue42651] Recursive traceback crashes  Python Interpreter
In-Reply-To: <1608105735.03.0.523665122471.issue42651@roundup.psfhosted.org>
Message-ID: <1608625944.49.0.126360462032.issue42651@roundup.psfhosted.org>


Change by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
superseder:  -> crash with unbounded recursion in except statement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42651>
_______________________________________

From report at bugs.python.org  Tue Dec 22 03:32:50 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Dec 2020 08:32:50 +0000
Subject: [issue42652] recursive in finally clause cause Python interpreter
 crash.
In-Reply-To: <1608108499.51.0.334108279167.issue42652@roundup.psfhosted.org>
Message-ID: <1608625970.24.0.310155387479.issue42652@roundup.psfhosted.org>


Change by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
superseder:  -> crash with unbounded recursion in except statement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42652>
_______________________________________

From report at bugs.python.org  Tue Dec 22 03:39:45 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Dec 2020 08:39:45 +0000
Subject: [issue42693] "if 0:" lines are traced; they didn't use to be
In-Reply-To: <1608498368.47.0.692310939381.issue42693@roundup.psfhosted.org>
Message-ID: <1608626385.14.0.161658202878.issue42693@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I just noticed that "while True:" is now compiled to NOP. It is clearly a regression which affects performance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42693>
_______________________________________

From report at bugs.python.org  Tue Dec 22 04:12:18 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 22 Dec 2020 09:12:18 +0000
Subject: [issue19733] Setting image parameter of a button crashes with Cocoa Tk
In-Reply-To: <1385212186.78.0.599244063108.issue19733@psf.upfronthosting.co.za>
Message-ID: <1608628338.34.0.507153381114.issue19733@roundup.psfhosted.org>


Change by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19733>
_______________________________________

From report at bugs.python.org  Tue Dec 22 05:10:54 2020
From: report at bugs.python.org (Peixing Xin)
Date: Tue, 22 Dec 2020 10:10:54 +0000
Subject: [issue41443] some test cases in test_posix.py fail if some os
 attributes are not supported
In-Reply-To: <1596106142.56.0.534494527465.issue41443@roundup.psfhosted.org>
Message-ID: <1608631854.12.0.706552171749.issue41443@roundup.psfhosted.org>


Change by Peixing Xin <peixing.xin at windriver.com>:


----------
pull_requests: +22745
pull_request: https://github.com/python/cpython/pull/23886

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41443>
_______________________________________

From report at bugs.python.org  Tue Dec 22 05:13:09 2020
From: report at bugs.python.org (Peixing Xin)
Date: Tue, 22 Dec 2020 10:13:09 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1608631989.49.0.743978699198.issue31904@roundup.psfhosted.org>


Change by Peixing Xin <peixing.xin at windriver.com>:


----------
pull_requests: +22746
pull_request: https://github.com/python/cpython/pull/23886

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Tue Dec 22 05:17:25 2020
From: report at bugs.python.org (Xinmeng Xia)
Date: Tue, 22 Dec 2020 10:17:25 +0000
Subject: [issue42712] Segmentation fault in running ast.literal_eval() with
 large expression size.
Message-ID: <1608632245.06.0.0184110305677.issue42712@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

Calling function ast.literal_eval() with large size can cause a segmentation fault in Python 3.5 -3.10. Please check the following two examples. The example 1 works as expected, while the second one triggers segmentation fault on Python 3.5,3.6,3.7,3.8,3.9,3.10. The primary difference between these two examples lay on the value of "n".


Example 1: 
========================================= 
import ast
mylist = []
n = 100000
print(ast.literal_eval("mylist"+"+mylist"*n))
==========================================

The actual output: value Error on Python 3.5,3.7,3.8,3.9,3.10, Recursive Error on Python 3.6 (as expected)



Example 2:
===================================
import ast
mylist = []
n = 1000000
print(ast.literal_eval("mylist"+"+mylist"*n))
===================================

The actual output: segmentation fault on Python 3.5 - 3.10 (not as expected)


My system information:

>> python3.10 -V
Python 3.10.0a2

>> python3.9 -V
Python 3.9.0rc1

>> python3.8 -V
Python 3.8.0

>> python3.7 -V
Python 3.7.3

>> python3.6 -V
Python 3.6.12

>> uname -v
#73~16.04.1-Ubuntu

----------
components: Interpreter Core
messages: 383577
nosy: xxm
priority: normal
severity: normal
status: open
title: Segmentation fault in running ast.literal_eval() with large expression size.
type: crash
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42712>
_______________________________________

From report at bugs.python.org  Tue Dec 22 05:18:43 2020
From: report at bugs.python.org (Xinmeng Xia)
Date: Tue, 22 Dec 2020 10:18:43 +0000
Subject: [issue42713] Segmentation fault in running eval() with large
 expression size.
Message-ID: <1608632323.64.0.924637507568.issue42713@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

Calling function eval() with large size can cause a segmentation fault in Python 3.7 -3.10. Please check the following two examples. The example 1 works as expected, while the second one triggers segmentation fault on Python 3.7,3.8,3.9,3.10. The primary difference between these two examples lay on the value of "n".

Example 1:
=========================================
mylist = []
n = 100000
print(eval("mylist"+"+mylist"*n))
==========================================

The actual output: Recursion Error on Python 3.5-3.10 (as expected)




Example 2:
===================================
mylist = []
n = 1000000
print(eval("mylist"+"+mylist"*n))
===================================

The actual output: Recursive Error on Python 3.5, 3.6 (as expected),  segmentation fault on Python 3.7, 3.8, 3.9, 3.10 (not as expected)



My system information:

>> python3.10 -V
Python 3.10.0a2

>> python3.9 -V
Python 3.9.0rc1

>> python3.8 -V
Python 3.8.0

>> python3.7 -V
Python 3.7.3

>> python3.6 -V
Python 3.6.12

>> uname -v
#73~16.04.1-Ubuntu

----------
components: Interpreter Core
messages: 383578
nosy: xxm
priority: normal
severity: normal
status: open
title: Segmentation fault in running eval() with large expression size.
type: crash
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42713>
_______________________________________

From report at bugs.python.org  Tue Dec 22 05:19:47 2020
From: report at bugs.python.org (Xinmeng Xia)
Date: Tue, 22 Dec 2020 10:19:47 +0000
Subject: [issue42714] Segmentation fault in running compile() with large
 expression size.
Message-ID: <1608632387.72.0.614247098104.issue42714@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

Calling function compile() with large size can cause a segmentation fault in Python 3.7 -3.10. Please check the following two examples. The example 1 works as expected, while the second one triggers segmentation fault on Python 3.7,3.8,3.9,3.10. The primary difference between these two examples lay on the value of "n".   


Example 1:
=========================================
mylist = []
n = 100000
print(compile("mylist"+"+mylist"*n,'','single'))
==========================================

The actual output: Recursion Error on Python 3.5-3.10 (as expected)




Example 2:
=========================================
mylist = []
n = 1000000
print(compile("mylist"+"+mylist"*n,'','single'))
===================================

The actual output: Recursive Error on Python 3.5, 3.6 (as expected),  segmentation fault on Python 3.7, 3.8, 3.9, 3.10 (not as expected)




My system information:

>> python3.10 -V
Python 3.10.0a2

>> python3.9 -V
Python 3.9.0rc1

>> python3.8 -V
Python 3.8.0

>> python3.7 -V
Python 3.7.3

>> python3.6 -V
Python 3.6.12

>> uname -v
#73~16.04.1-Ubuntu

----------
components: Interpreter Core
messages: 383579
nosy: xxm
priority: normal
severity: normal
status: open
title: Segmentation fault in running compile() with large expression size.
type: crash
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42714>
_______________________________________

From report at bugs.python.org  Tue Dec 22 05:20:37 2020
From: report at bugs.python.org (Xinmeng Xia)
Date: Tue, 22 Dec 2020 10:20:37 +0000
Subject: [issue42715] Segmentation fault in running exec() with large
 expression size.
Message-ID: <1608632437.39.0.152674435504.issue42715@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

Calling function exec() with large size can cause a segmentation fault in Python 3.7 -3.10. Please check the following two examples. The example 1 works as expected, while the second one triggers segmentation fault on Python 3.7,3.8,3.9,3.10. The primary difference between these two examples lay on the value of "n".   




Example 1:
=========================================
mylist = []
n = 100000
print(exec("mylist"+"+mylist"*n))
==========================================

The actual output: Recursion Error on Python 3.5-3.10 (as expected)



Example 2:
===================================
mylist = []
n = 1000000
print(exec("mylist"+"+mylist"*n))
===================================

The actual output: Recursive Error on Python 3.5, 3.6 (as expected),  segmentation fault on Python 3.7, 3.8, 3.9, 3.10 (not as expected)


My system information:

>> python3.10 -V
Python 3.10.0a2

>> python3.9 -V
Python 3.9.0rc1

>> python3.8 -V
Python 3.8.0

>> python3.7 -V
Python 3.7.3

>> python3.6 -V
Python 3.6.12

>> uname -v
#73~16.04.1-Ubuntu

----------
components: Interpreter Core
messages: 383580
nosy: xxm
priority: normal
severity: normal
status: open
title: Segmentation fault in running exec() with large expression size.
type: crash
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42715>
_______________________________________

From report at bugs.python.org  Tue Dec 22 05:21:33 2020
From: report at bugs.python.org (Xinmeng Xia)
Date: Tue, 22 Dec 2020 10:21:33 +0000
Subject: [issue42716] Segmentation fault in running ast.parse() with large
 expression size.
Message-ID: <1608632493.48.0.125975965886.issue42716@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

Calling function ast.parse() with large size can cause a segmentation fault in Python 3.5 -3.10. Please check the following two examples. The example 1 works as expected, while the second one triggers segmentation fault on Python 3.5,3.6,3.7,3.8,3.9,3.10. The primary difference between these two examples lay on the value of "n".



Example 1:
=========================================
import ast
mylist = []
n = 100000
print(ast.parse("mylist"+"+mylist"*n))
==========================================

The actual output: AST nodes on Python 3.5-3.10 (as expected)
# <_ast.Module object at 0x7f78d7b672e8>
 


Example 2:
===================================
import ast
mylist = []
n = 1000000
print(ast.parse("mylist"+"+mylist"*n))
# <_ast.Module object at 0x7f78d7b672e8>
===================================

The actual output: segmentation fault on Python 3.5 - 3.10 (not as expected)




My system information:

>> python3.10 -V
Python 3.10.0a2

>> python3.9 -V
Python 3.9.0rc1

>> python3.8 -V
Python 3.8.0

>> python3.7 -V
Python 3.7.3

>> python3.6 -V
Python 3.6.12

>> uname -v
#73~16.04.1-Ubuntu

----------
components: Interpreter Core
messages: 383581
nosy: xxm
priority: normal
severity: normal
status: open
title: Segmentation fault in running ast.parse() with large expression size.
type: crash
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42716>
_______________________________________

From report at bugs.python.org  Tue Dec 22 05:25:03 2020
From: report at bugs.python.org (Xinmeng Xia)
Date: Tue, 22 Dec 2020 10:25:03 +0000
Subject: [issue42717] The python interpreter crashed with
 "_enter_buffered_busy"
Message-ID: <1608632703.27.0.708410911987.issue42717@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

The following program can work well in Python 2. However it crashes in Python 3( 3.6-3.10 ) with the following error messages.
Program:
============================================
import sys,time, threading

class test:
    def test(self):
        pass


class test1:
    def run(self):
        for i in range(0,10000000):
            connection = test()
            sys.stderr.write(' =_= ')


def testrun():
    client = test1()
    thread = threading.Thread(target=client.run, args=())
    thread.setDaemon(True)
    thread.start()

    time.sleep(0.1)

testrun()
============================================

Error message:
------------------------------------------------------------------------------

=_=  =_=  =_=  =_=  =_=  ......  =_=  =_=  =_=  =_= 
Fatal Python error: _enter_buffered_busy: could not acquire lock for <_io.BufferedWriter name='<stderr>'> at interpreter shutdown, possibly due to daemon threads
Python runtime state: finalizing (tstate=0xd0c180)

Current thread 0x00007f08a638f700 (most recent call first):
<no Python frame>
Aborted (core dumped)
------------------------------------------------------------------------------

When I remove "time.sleep(0.1)" or  "thread.setDaemon(True)" or "sys.stderr.write(' =_= ')" or "for i in range(0,10000000)":, the python interpreter seems to work well.

----------
components: Interpreter Core
messages: 383582
nosy: xxm
priority: normal
severity: normal
status: open
title: The python interpreter crashed with "_enter_buffered_busy"
type: crash
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42717>
_______________________________________

From report at bugs.python.org  Tue Dec 22 06:12:40 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 22 Dec 2020 11:12:40 +0000
Subject: [issue42688] ctypes memory error on Apple Silicon with external libffi
In-Reply-To: <1608443574.61.0.0166938419217.issue42688@roundup.psfhosted.org>
Message-ID: <1608635560.01.0.558484070977.issue42688@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b3c77ecbbe0ad3e3cc6dbd885792203e9e6ec858 by erykoff in branch 'master':
bpo-42688: Fix ffi alloc/free when using external libffi on macos (GH-23868)
https://github.com/python/cpython/commit/b3c77ecbbe0ad3e3cc6dbd885792203e9e6ec858


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42688>
_______________________________________

From report at bugs.python.org  Tue Dec 22 06:13:00 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 22 Dec 2020 11:13:00 +0000
Subject: [issue42688] ctypes memory error on Apple Silicon with external libffi
In-Reply-To: <1608443574.61.0.0166938419217.issue42688@roundup.psfhosted.org>
Message-ID: <1608635580.53.0.997562519523.issue42688@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22747
pull_request: https://github.com/python/cpython/pull/23888

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42688>
_______________________________________

From report at bugs.python.org  Tue Dec 22 06:41:53 2020
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 22 Dec 2020 11:41:53 +0000
Subject: [issue42693] "if 0:" lines are traced; they didn't use to be
In-Reply-To: <1608498368.47.0.692310939381.issue42693@roundup.psfhosted.org>
Message-ID: <1608637313.53.0.133081929271.issue42693@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

What is the problem with NOPs?
If there are performance regressions in real code, then that needs to be addressed. 
If only in a few toy examples, then that is (IMO) a price worth paying for predictable debugging and profiling.

Raymond:
   Effectively it does cease to exist. A NOP in the bytecode, except maybe in the tightest of loops, is going to be impossible to detect without inspecting the bytecode.

Serhiy:
   The NOP is outside of the loop, so won't slow down the loop.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42693>
_______________________________________

From report at bugs.python.org  Tue Dec 22 07:02:51 2020
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 22 Dec 2020 12:02:51 +0000
Subject: [issue42718] Allow zero-width entries in code.co_lines()
Message-ID: <1608638571.52.0.00224943237142.issue42718@roundup.psfhosted.org>


New submission from Mark Shannon <mark at hotpy.org>:

While the impact of making `if 0` and `while True` appear when tracing can be mitigated, the impact of `continue` is more of a concern.

The following loop:

while True:
    if test:
        continue
    rest

PEP 626 requires that the `continue` is traced, and continue can occur once per iteration. So inserting a NOP for a continue will have a measurable impact on performance.

In some cases the NOP can be folded into the preceding or following bytecode, but often it cannot because the code is both branchy and spread across several lines.

If PEP 626 allowed zero-width entries in the line number table, then any remaining NOPs could be eliminated in the assembler, at the cost of a little additional complexity in `maybe_call_line_trace()`

----------
assignee: Mark.Shannon
components: Interpreter Core
messages: 383585
nosy: Mark.Shannon, pablogsal, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Allow zero-width entries in code.co_lines()
type: performance
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42718>
_______________________________________

From report at bugs.python.org  Tue Dec 22 07:21:49 2020
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 22 Dec 2020 12:21:49 +0000
Subject: [issue42693] "if 0:" lines are traced; they didn't use to be
In-Reply-To: <1608498368.47.0.692310939381.issue42693@roundup.psfhosted.org>
Message-ID: <1608639709.41.0.162468277729.issue42693@roundup.psfhosted.org>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

Mark said:

> An optimization (CS not math) is a change to the program such that it has the same effect, according to the language spec, but improves some aspect of the behavior, such as run time or memory use.
> 
> Any transformation that changes the effect of the program is not an optimization.
> 
> You shouldn't be able to tell, without timing the program (or measuring memory use, observing race conditions, etc.) whether optimizations are turned on or not.

It's not that simple. Many aspects of the program can be observed, and coverage.py observes them and reports on them.

Coverage.py reports on branch coverage by tracking pairs of line numbers: in the trace function, the last line number is remembered, then paired with the current line number to note how execution moved from line to line.  This is an observable behavior of the program.  The optimization of removing jumps to jumps changes this observable behavior.

Here is a bug report against coverage.py that relates to this: https://github.com/nedbat/coveragepy/issues/1025

To reproduce this in the small, here is bug1025.py:

    nums = [1,2,3,4,5,6,7,8]        # line 1
    for num in nums:                # line 2
        if num % 2 == 0:            # line 3
            if num % 4 == 0:        # line 4
                print(num)          # line 5
            continue                # line 6
        print(-num)                 # line 7

Here is branch_trace.py:

    import sys

    pairs = set()
    last = -1

    def trace(frame, event, arg):
        global last
        if event == "line":
            this = frame.f_lineno
            pairs.add((last, this))
            last = this
        return trace

    code = open(sys.argv[1]).read()
    sys.settrace(trace)
    exec(code)
    print(sorted(pairs))

Running "python branch_trace.py bug1025.py" produces:

    -1
    -3
    4
    -5
    -7
    8
    [(-1, 1), (1, 2), (2, 3), (3, 4), (3, 7), (4, 2), (4, 5), (5, 6), (6, 2), (7, 2)]

Conceptually, executing bug1025.py should sometimes jump from line 4 to line 6. When line 4 is false, execution moves to the continue and then to the top of the for loop.  But CPython optimizes away the jump to a jump, so the pair (4, 6) never appears in our trace output.  The result is that coverage.py thinks there is a branch that could have occurred, but was never observed during the run.  It reports this as a missed branch.

Coverage.py currently deals with these sorts of issues by understanding the kinds of optimizations that can occur, and taking them into account when figuring "what could have happened during execution". Currently, it does not understand the jump-to-jump optimizations, which is why bug 1025 happens.

This pairing of line numbers doesn't relate specifically to the  "if 0:" optimizations that this issue is about, but this is where the observability point was raised, so I thought I would discuss it here.  As I said earlier, this probably should be worked out in a better forum.

This is already long, so I'm not sure what else to say.  Optimizations complicate things for tools that want to analyze code and help people reason about code.  You can't simply say, "optimizations should not be observable."  They are observable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42693>
_______________________________________

From report at bugs.python.org  Tue Dec 22 07:25:56 2020
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 22 Dec 2020 12:25:56 +0000
Subject: [issue42693] "if 0:" lines are traced; they didn't use to be
In-Reply-To: <1608498368.47.0.692310939381.issue42693@roundup.psfhosted.org>
Message-ID: <1608639956.62.0.129550375755.issue42693@roundup.psfhosted.org>


Change by Ned Batchelder <ned at nedbatchelder.com>:


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42693>
_______________________________________

From report at bugs.python.org  Tue Dec 22 07:44:30 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 22 Dec 2020 12:44:30 +0000
Subject: [issue28964] AST literal_eval exceptions provide no information about
 line number
In-Reply-To: <1481665664.26.0.256194535172.issue28964@psf.upfronthosting.co.za>
Message-ID: <1608641070.93.0.432293506904.issue28964@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

I'm +0 on this (even though we only had 2 users wanting this, the implementation seems very trivial). @serhiy.storchaka, @pablogsal any opinions?

----------
keywords: +gsoc -patch
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28964>
_______________________________________

From report at bugs.python.org  Tue Dec 22 07:44:49 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 22 Dec 2020 12:44:49 +0000
Subject: [issue28964] AST literal_eval exceptions provide no information about
 line number
In-Reply-To: <1481665664.26.0.256194535172.issue28964@psf.upfronthosting.co.za>
Message-ID: <1608641089.08.0.0312423764733.issue28964@roundup.psfhosted.org>


Change by Batuhan Taskaya <isidentical at gmail.com>:


----------
keywords: +patch -gsoc

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28964>
_______________________________________

From report at bugs.python.org  Tue Dec 22 08:45:18 2020
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 22 Dec 2020 13:45:18 +0000
Subject: [issue42707] Python uses ANSI CP for stdio on Windows console instead
 of using console or OEM CP
In-Reply-To: <1608577171.81.0.55180678487.issue42707@roundup.psfhosted.org>
Message-ID: <1608644718.35.0.827277601212.issue42707@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> I understand Python should be using reading the current CP (from 
> GetConsoleOutputCP
> or using the default OEM CP, and not assuming ANSI CP for stdio

A while ago I analyzed text encodings used by many of the legacy CLI programs in Windows. Some programs hard code using either the ANSI or OEM code page, and others use either the console's current input code page or its current output code page. In light of the inconsistencies, I think defaulting to ANSI for non-console standard I/O is fine.

> There's an IO codepage set on Windows consoles (`chcp` for cmd, 
> `[Console]::InputEncoding; [Console]::OutputEncoding` for PowerShell ;

The CMD shell is a Unicode (UTF-16) application, i.e. it calls wide-character system and console I/O functions such as ReadConsoleW() and WriteConsoleW(). It still uses the console output code page, but as a kind of locale encoding. For example, CMD uses the *output* code page when reading a batch file as well as when reading output from an external command in a `FOR /F` loop. If Python were only concerned with satisfying a `FOR /F` loop in CMD, then it would be reasonable to make stdout default to the console output code page. But "more.com" and "find.exe" are commonly used as well, and they decode piped input using the console *input* code page. Other commands such as "findstr.exe" use OEM.

PowerShell adds a spin to this problem. In CMD, piping bytes between two processes doesn't actively involve the shell. It just creates an anonymous pipe, with each process connected to either end. In contrast, PowerShell injects itself as a middle man. For example, piping between "python.exe" and "more.com" is implemented as a pipe from "python.exe" to PowerShell and a separate pipe from PowerShell to "more.com". In between, PowerShell decodes the output from "python.exe" using its current output encoding and then re-encodes it using its current input encoding before writing to "more.com".

> # If we adjust cmd CP, it's fine too:
> L:\Cop>chcp 1252
> Page de codes active : 1252
> L:\Cop>py testcp.py | more
> ?

In this case, the ANSI code-page encoded output from Python is written to a pipe that's read directly by "more.com". In turn, "more.com" decodes the input bytes using the console input code page before writing UTF-16 text to the console via WriteConsoleW(). 

To make Python use the console input code page for standard I/O, query the code page via "chcp.com", and set PYTHONIOENCODING. For example:

    C:\>chcp
    Active code page: 437
    C:\>set PYTHONIOENCODING=cp437
    C:\>py -c "print('?')" | more
    ?

It would be convenient to support encodings that are based on the current console code pages, maybe named "conin" and "conout", based on GetConsoleCP() and GetConsoleOutputCP(). For example:

    C:\>set PYTHONIOENCODING=conin

They could default to the process active code page from GetACP() when there's no console. "ansi" and "oem" are already supported, so all four of the common encoding abstractions would be supported.

> when there's redirection or piping, encoding falls back to ANSI CP 
> (from config_get_locale_encoding).

The default encoding for files is locale.getpreferredencoding(), unless UTF-8 mode is enabled. In Windows, this is the process active code page, as returned by WinAPI GetACP(). By default, this is the system ANSI code page.

Standard I/O isn't excepted from this, unless either PYTHONIOENCODING is set or it's a console device file. The default, non-legacy behavior for console files is to use UTF-8 at the buffer and raw I/O level. Internally, Python uses the wide-character console I/O functions ReadConsoleW() and WriteConsoleW(), with UTF-16 encoded text.

Windows 10 allows setting the system ANSI code page to UTF-8. It also allows an application to override its active code page to UTF-8, but that's not easy to change. It requires adding an "activeCodePage" setting to the manifest that's embedded in the executable, which can be done using the manifest tool, "mt.exe".

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42707>
_______________________________________

From report at bugs.python.org  Tue Dec 22 09:00:23 2020
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 22 Dec 2020 14:00:23 +0000
Subject: [issue42718] Allow zero-width entries in code.co_lines()
In-Reply-To: <1608638571.52.0.00224943237142.issue42718@roundup.psfhosted.org>
Message-ID: <1608645623.5.0.883775541774.issue42718@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42718>
_______________________________________

From report at bugs.python.org  Tue Dec 22 09:02:47 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 22 Dec 2020 14:02:47 +0000
Subject: [issue28964] AST literal_eval exceptions provide no information about
 line number
In-Reply-To: <1481665664.26.0.256194535172.issue28964@psf.upfronthosting.co.za>
Message-ID: <1608645767.25.0.743439580317.issue28964@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

This is a recurring feature request (I have heard people asking for this a couple of times) and is simple enough to do, so I am fine with this. Unless Serhiy has some concern, I would go forward :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28964>
_______________________________________

From report at bugs.python.org  Tue Dec 22 09:08:13 2020
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 22 Dec 2020 14:08:13 +0000
Subject: [issue42719] Eliminate NOPs in the assembler,
 by emitting zero-width entries in the line number table
Message-ID: <1608646093.23.0.458945572076.issue42719@roundup.psfhosted.org>


New submission from Mark Shannon <mark at hotpy.org>:

This will require a change to the internal line number table format.

PEP 626 requires all lines are traced, which makes handling of 'continue' and other jump-to-jumps inefficient if spread across multiple lines.

In 3.9 many jump-to-jumps were eliminated, but PEP 626 requires that many are converted to a NOP. Zero-width line number table entries will allow us to eliminate most, if not all, remaining NOPs in the assembler.

----------
assignee: Mark.Shannon
components: Interpreter Core
messages: 383590
nosy: Mark.Shannon
priority: normal
severity: normal
stage: needs patch
status: open
title: Eliminate NOPs in the assembler, by emitting zero-width entries in the line number table
type: performance
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42719>
_______________________________________

From report at bugs.python.org  Tue Dec 22 09:20:13 2020
From: report at bugs.python.org (Alfie Stoppani)
Date: Tue, 22 Dec 2020 14:20:13 +0000
Subject: [issue38946] IDLE on macOS 10.15 Catalina does not open
 double-clicked files if app already launched
In-Reply-To: <1575141041.2.0.751349559914.issue38946@roundup.psfhosted.org>
Message-ID: <1608646813.45.0.41289507963.issue38946@roundup.psfhosted.org>


Alfie Stoppani <alfiestoppani at hotmail.com> added the comment:

Yep, me too. It's very annoying indeed.

----------
nosy: +alftheelf

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38946>
_______________________________________

From report at bugs.python.org  Tue Dec 22 09:22:32 2020
From: report at bugs.python.org (Steve Stagg)
Date: Tue, 22 Dec 2020 14:22:32 +0000
Subject: [issue42712] Segmentation fault in running ast.literal_eval() with
 large expression size.
In-Reply-To: <1608632245.06.0.0184110305677.issue42712@roundup.psfhosted.org>
Message-ID: <1608646952.55.0.393567209866.issue42712@roundup.psfhosted.org>


Steve Stagg <stestagg at gmail.com> added the comment:

Likely duplicate of Issue42609, Probably fixed by bpo-42609

----------
nosy: +stestagg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42712>
_______________________________________

From report at bugs.python.org  Tue Dec 22 09:23:46 2020
From: report at bugs.python.org (Rahul Kumaresan)
Date: Tue, 22 Dec 2020 14:23:46 +0000
Subject: [issue27820] Possible bug in smtplib when initial_response_ok=False
In-Reply-To: <1471739698.94.0.271523306415.issue27820@psf.upfronthosting.co.za>
Message-ID: <1608647026.46.0.895816624075.issue27820@roundup.psfhosted.org>


Change by Rahul Kumaresan <kayrahul at gmail.com>:


----------
nosy: +rahul-kumi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27820>
_______________________________________

From report at bugs.python.org  Tue Dec 22 10:24:00 2020
From: report at bugs.python.org (Rahul Kumaresan)
Date: Tue, 22 Dec 2020 15:24:00 +0000
Subject: [issue29860] smtplib.py doesn't capitalize EHLO.
In-Reply-To: <1490020373.29.0.308540627587.issue29860@psf.upfronthosting.co.za>
Message-ID: <1608650640.5.0.0616967126447.issue29860@roundup.psfhosted.org>


Change by Rahul Kumaresan <kayrahul at gmail.com>:


----------
nosy: +rahul-kumi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29860>
_______________________________________

From report at bugs.python.org  Tue Dec 22 11:04:16 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 22 Dec 2020 16:04:16 +0000
Subject: [issue38946] IDLE on macOS 10.15 Catalina does not open
 double-clicked files if app already launched
In-Reply-To: <1575141041.2.0.751349559914.issue38946@roundup.psfhosted.org>
Message-ID: <1608653056.68.0.93517854769.issue38946@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +Tkinter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38946>
_______________________________________

From report at bugs.python.org  Tue Dec 22 11:14:23 2020
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 22 Dec 2020 16:14:23 +0000
Subject: [issue42693] "if 0:" lines are traced; they didn't use to be
In-Reply-To: <1608498368.47.0.692310939381.issue42693@roundup.psfhosted.org>
Message-ID: <1608653663.91.0.377499933253.issue42693@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Ned, I agree that up until 3.9, it is wasn't that simple.
But from 3.10 onward, it should be that simple.
That's the point of PEP 626.

If a transformation changes observable behavior within the scope of language specification, then it is not an optimization but a bug.

Up to 3.9, the language did not specify the behavior of sys.settrace w.r.t. line numbers, so coverage.py had to second guess what the bytecode optimizer was doing. 

In 3.10 onwards, the behavior of sys.settrace w.r.t. line numbers is part of the language spec. The optimizer cannot change it, and coverage.py should not need care what the optimizer does.

If you can observe the effect of the optimizer, w.r.t. line numbers, then it's a bug.

(According to that definition, there are still bugs in the optimizer relating to jumps-to-jumps. I plan to fix them)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42693>
_______________________________________

From report at bugs.python.org  Tue Dec 22 11:16:47 2020
From: report at bugs.python.org (Rahul Kumaresan)
Date: Tue, 22 Dec 2020 16:16:47 +0000
Subject: [issue35783] incorrect example of fetching messages in imaplib
 documentation
In-Reply-To: <1547887217.4.0.578077466695.issue35783@roundup.psfhosted.org>
Message-ID: <1608653807.34.0.553226702189.issue35783@roundup.psfhosted.org>


Change by Rahul Kumaresan <kayrahul at gmail.com>:


----------
nosy: +rahul-kumi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35783>
_______________________________________

From report at bugs.python.org  Tue Dec 22 11:24:09 2020
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 22 Dec 2020 16:24:09 +0000
Subject: [issue42693] "if 0:" lines are traced; they didn't use to be
In-Reply-To: <1608498368.47.0.692310939381.issue42693@roundup.psfhosted.org>
Message-ID: <1608654249.54.0.852828820542.issue42693@roundup.psfhosted.org>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

> According to that definition, there are still bugs in the optimizer relating to jumps-to-jumps. I plan to fix them

Can you say more about that? What is the bug? How will you fix it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42693>
_______________________________________

From report at bugs.python.org  Tue Dec 22 11:36:14 2020
From: report at bugs.python.org (Jakub Kulik)
Date: Tue, 22 Dec 2020 16:36:14 +0000
Subject: [issue19561] request to reopen Issue837046 - pyport.h redeclares
 gethostname() if SOLARIS is defined
In-Reply-To: <1384267181.39.0.791538142123.issue19561@psf.upfronthosting.co.za>
Message-ID: <1608654974.79.0.378596884158.issue19561@roundup.psfhosted.org>


Change by Jakub Kulik <kulikjak at gmail.com>:


----------
versions: +Python 3.10, Python 3.8, Python 3.9 -Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19561>
_______________________________________

From report at bugs.python.org  Tue Dec 22 12:19:09 2020
From: report at bugs.python.org (Jakub Kulik)
Date: Tue, 22 Dec 2020 17:19:09 +0000
Subject: [issue41843] Reenable sendfile in shutil.copyfile() on Solaris
In-Reply-To: <1600867452.06.0.35884925988.issue41843@roundup.psfhosted.org>
Message-ID: <1608657549.04.0.669664833812.issue41843@roundup.psfhosted.org>


Change by Jakub Kulik <kulikjak at gmail.com>:


----------
keywords: +patch
pull_requests: +22748
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23893

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41843>
_______________________________________

From report at bugs.python.org  Tue Dec 22 12:24:45 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 22 Dec 2020 17:24:45 +0000
Subject: [issue29030] argparse: choices override default metavar
In-Reply-To: <1482281546.0.0.613026945443.issue29030@psf.upfronthosting.co.za>
Message-ID: <1608657885.04.0.134134271937.issue29030@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 6.0 -> 7.0
pull_requests: +22749
pull_request: https://github.com/python/cpython/pull/23894

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29030>
_______________________________________

From report at bugs.python.org  Tue Dec 22 12:24:45 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Dec 2020 17:24:45 +0000
Subject: [issue29030] argparse: choices override default metavar
In-Reply-To: <1482281546.0.0.613026945443.issue29030@psf.upfronthosting.co.za>
Message-ID: <1608657885.24.0.750659313354.issue29030@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 6afb730e2a8bf0b472b4c3157bcf5b44aa7e6d56 by Raymond Hettinger in branch 'master':
bpo-29030: Document interaction between *choices* and *metavar*. (GH-23884)
https://github.com/python/cpython/commit/6afb730e2a8bf0b472b4c3157bcf5b44aa7e6d56


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29030>
_______________________________________

From report at bugs.python.org  Tue Dec 22 13:12:58 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Dec 2020 18:12:58 +0000
Subject: [issue42711] lru_cache and NotImplemented
In-Reply-To: <1608619207.84.0.36165935347.issue42711@roundup.psfhosted.org>
Message-ID: <1608660778.12.0.055351976573.issue42711@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> has the potential to fill the LRU cache with calls that
> will in ultimately result in errors

How would a call result in an error?  The worst that can happen is a cache miss and the underlying function gets called.


> Change `functools.lru_cache` not cache calls that 
> result in `NotImplemented`.

That would be a backwards incompatible change.


> Allow a user to easily extend `functools.lru_cache`

The implementation is intentionally closed off to support thread-safety, having a C implementation, ease of use, and making it performant.  

We've provided OrderedDict to make it relatively easy to roll your own cache variants.  Essentially the only algorithmically interesting part of the lru_cache is the linked list. OrderedDict has that logic already built in (the move_to_end() method does the equivalent of the linked list update).


> Add the ability to *throw* `NotImplemented` in binary dunder
> methods so the function call does not complete. This would 
> work exactly like returning `NotImplemented` and be handled 
> by the runtime.

Deep changes to the language would require a PEP.

> And my current solution...
> 4. Copy-paste `functools.lru_cache` 

The usual technique is to cache only what you want cached.  

Consider factoring-out the expensive logic rather than caching the NotImplemented logic:

    def __add__(self, other):
        if not isinstance(other, type(self)):
            return NotImplemented
        self._expensive_method(other)

    @lru_cache
    def _expensive_method(self, other):
        ...

----------
assignee:  -> rhettinger
nosy: +rhettinger
priority: normal -> low
type: performance -> behavior
versions:  -Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42711>
_______________________________________

From report at bugs.python.org  Tue Dec 22 13:19:42 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Dec 2020 18:19:42 +0000
Subject: [issue29030] argparse: choices override default metavar
In-Reply-To: <1482281546.0.0.613026945443.issue29030@psf.upfronthosting.co.za>
Message-ID: <1608661182.92.0.943020485924.issue29030@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 4ec2149708c7c06ebeccc27e28e2bbc51c4abeca by Miss Islington (bot) in branch '3.9':
bpo-29030: Document interaction between *choices* and *metavar*. (GH-23884) (GH-23894)
https://github.com/python/cpython/commit/4ec2149708c7c06ebeccc27e28e2bbc51c4abeca


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29030>
_______________________________________

From report at bugs.python.org  Tue Dec 22 13:19:56 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Dec 2020 18:19:56 +0000
Subject: [issue29030] argparse: choices override default metavar
In-Reply-To: <1482281546.0.0.613026945443.issue29030@psf.upfronthosting.co.za>
Message-ID: <1608661196.96.0.326868700836.issue29030@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/issue29030>
_______________________________________

From report at bugs.python.org  Tue Dec 22 13:50:35 2020
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 22 Dec 2020 18:50:35 +0000
Subject: [issue42696] Duplicated unused bytecodes at end of function
In-Reply-To: <1608499758.44.0.239199538725.issue42696@roundup.psfhosted.org>
Message-ID: <1608663035.96.0.650723661167.issue42696@roundup.psfhosted.org>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

This isn't a problem for me.  I noticed it and figured I'd mention it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42696>
_______________________________________

From report at bugs.python.org  Tue Dec 22 14:00:23 2020
From: report at bugs.python.org (Nandish)
Date: Tue, 22 Dec 2020 19:00:23 +0000
Subject: [issue42720] << operator has a bug
Message-ID: <1608663622.99.0.883125192536.issue42720@roundup.psfhosted.org>


New submission from Nandish <lbnandish at gmail.com>:

I verified the following on both Python 2.7 and Python 3.8

I did print(100<<3) Converting 100 to Binary gives 1100100. What I did is I droped the first 3 bits and added 3 bits with the value '0' at the end. So it should result as 0100000, and I converted this to Decimal and the answer was 32.

For my suprise when I executed print(100<<3) the answer was 800. I was puzzled. I converted 800 to Binary to check whats going on. And this is what I got 1100100000.

If you see how 800 was Python answer, they did not shift or drop the first 3 bits but they added value '0' to last 3 bits.

Where as print(100>>3) , worked perfect. I did manual calculation and cheked the print result from python. It worked correctly. Dropped last 3 bits and added value '0' to first 3 bits.

Looks like (100<<3) , left shift operator has a bug on Python.

----------
messages: 383599
nosy: Nandish
priority: normal
severity: normal
status: open
title: << operator has a bug
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42720>
_______________________________________

From report at bugs.python.org  Tue Dec 22 14:02:56 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Dec 2020 19:02:56 +0000
Subject: [issue25246] Alternative algorithm for deque_remove()
In-Reply-To: <1443343421.14.0.18683145075.issue25246@psf.upfronthosting.co.za>
Message-ID: <1608663776.23.0.27614435725.issue25246@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Am closing this one because it isn't worth an API change.  The remove() method is little used and to the extent people do use it, they expect it to work like list.remove().  The latter never raises a RuntimeError.

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25246>
_______________________________________

From report at bugs.python.org  Tue Dec 22 14:11:18 2020
From: report at bugs.python.org (Steve Stagg)
Date: Tue, 22 Dec 2020 19:11:18 +0000
Subject: [issue42712] Segmentation fault in running ast.literal_eval() with
 large expression size.
In-Reply-To: <1608632245.06.0.0184110305677.issue42712@roundup.psfhosted.org>
Message-ID: <1608664278.6.0.750932967106.issue42712@roundup.psfhosted.org>


Steve Stagg <stestagg at gmail.com> added the comment:

Confirmed fixed by https://github.com/python/cpython/pull/23744:

Traceback (most recent call last):
  File "/home/sstagg/tmp/fuzztest/cpython/../test.py", line 4, in <module>
    print(ast.literal_eval("mylist"+"+mylist"*n))
  File "/home/sstagg/tmp/fuzztest/prefix/lib/python3.10/ast.py", line 62, in literal_eval
    node_or_string = parse(node_or_string.lstrip(" \t"), mode='eval')
  File "/home/sstagg/tmp/fuzztest/prefix/lib/python3.10/ast.py", line 50, in parse
    return compile(source, filename, mode, flags,
RecursionError: maximum recursion depth exceeded during compilation

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42712>
_______________________________________

From report at bugs.python.org  Tue Dec 22 14:16:28 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Dec 2020 19:16:28 +0000
Subject: [issue42696] Duplicated unused bytecodes at end of function
In-Reply-To: <1608499758.44.0.239199538725.issue42696@roundup.psfhosted.org>
Message-ID: <1608664588.99.0.732555639585.issue42696@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Is this a problem in practice?

It's just a hint that code generation has imperfections.

>From a teacher's or author's point of view, it is something we have to explain away when demonstrating dis().  It leaves the impression that Python is kludgy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42696>
_______________________________________

From report at bugs.python.org  Tue Dec 22 14:18:39 2020
From: report at bugs.python.org (Steve Stagg)
Date: Tue, 22 Dec 2020 19:18:39 +0000
Subject: [issue42716] Segmentation fault in running ast.parse() with large
 expression size.
In-Reply-To: <1608632493.48.0.125975965886.issue42716@roundup.psfhosted.org>
Message-ID: <1608664719.51.0.863758716727.issue42716@roundup.psfhosted.org>


Steve Stagg <stestagg at gmail.com> added the comment:

PR: https://github.com/python/cpython/pull/23744 stops this from segfaulting.  It does however raise a RecursionError:

RecursionError: maximum recursion depth exceeded during compilation

As per https://bugs.python.org/issue42609#msg382910, Serhiy implies that the new recursion error is probably expected and acceptable.

----------
nosy: +serhiy.storchaka, stestagg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42716>
_______________________________________

From report at bugs.python.org  Tue Dec 22 14:22:42 2020
From: report at bugs.python.org (Steve Stagg)
Date: Tue, 22 Dec 2020 19:22:42 +0000
Subject: [issue42715] Segmentation fault in running exec() with large
 expression size.
In-Reply-To: <1608632437.39.0.152674435504.issue42715@roundup.psfhosted.org>
Message-ID: <1608664962.92.0.671957645673.issue42715@roundup.psfhosted.org>


Steve Stagg <stestagg at gmail.com> added the comment:

As with the other issues, the underlying segfault is fixed in
PR: https://github.com/python/cpython/pull/23744. It does however raise a RecursionError:

RecursionError: maximum recursion depth exceeded during compilation

As per https://bugs.python.org/issue42609#msg382910, Serhiy implies that the new recursion error is probably expected and acceptable.

----------
nosy: +stestagg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42715>
_______________________________________

From report at bugs.python.org  Tue Dec 22 14:24:28 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 22 Dec 2020 19:24:28 +0000
Subject: [issue42720] << operator has a bug
In-Reply-To: <1608663622.99.0.883125192536.issue42720@roundup.psfhosted.org>
Message-ID: <1608665068.87.0.46619029504.issue42720@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Why do you think the first 3 bits should be dropped? That's not the documented behavior of <<.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42720>
_______________________________________

From report at bugs.python.org  Tue Dec 22 14:25:15 2020
From: report at bugs.python.org (Steve Stagg)
Date: Tue, 22 Dec 2020 19:25:15 +0000
Subject: [issue42714] Segmentation fault in running compile() with large
 expression size.
In-Reply-To: <1608632387.72.0.614247098104.issue42714@roundup.psfhosted.org>
Message-ID: <1608665115.17.0.279761984019.issue42714@roundup.psfhosted.org>


Steve Stagg <stestagg at gmail.com> added the comment:

As with the other ones, 
PR: https://github.com/python/cpython/pull/23744 stops this from segfaulting.  It does however raise a RecursionError:

RecursionError: maximum recursion depth exceeded during compilation

As per https://bugs.python.org/issue42609#msg382910, Serhiy implies that the new recursion error is probably expected and acceptable.

----------
nosy: +stestagg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42714>
_______________________________________

From report at bugs.python.org  Tue Dec 22 14:35:07 2020
From: report at bugs.python.org (Nandish)
Date: Tue, 22 Dec 2020 19:35:07 +0000
Subject: [issue42720] << operator has a bug
In-Reply-To: <1608665068.87.0.46619029504.issue42720@roundup.psfhosted.org>
Message-ID: <CANiJTZSei5OvmSobK3AomOEQMruaDXTsSUQttVq8ox4GBNsDzg@mail.gmail.com>


Nandish <lbnandish at gmail.com> added the comment:

I took print(100>>3), I dropped last 3 bits and added value ?0? to first 3
bits. Both manual calculation and python result was correct.

How can << shit operator and >> shit operator work differently , with
different logic ?

Thanks
Nandish

On Wed, Dec 23, 2020 at 12:54 AM Eric V. Smith <report at bugs.python.org>
wrote:

>
> Eric V. Smith <eric at trueblade.com> added the comment:
>
> Why do you think the first 3 bits should be dropped? That's not the
> documented behavior of <<.
>
> ----------
> nosy: +eric.smith
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue42720>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42720>
_______________________________________

From report at bugs.python.org  Tue Dec 22 14:40:54 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 22 Dec 2020 19:40:54 +0000
Subject: [issue42720] << operator has a bug
In-Reply-To: <1608663622.99.0.883125192536.issue42720@roundup.psfhosted.org>
Message-ID: <1608666054.25.0.242081495838.issue42720@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

That's not how they're defined. From https://docs.python.org/3/reference/expressions.html?highlight=left%20shift#shifting-operations

"A right shift by n bits is defined as floor division by pow(2,n). A left shift by n bits is defined as multiplication with pow(2,n)."

Perhaps you are assuming that Python operates on fixed width integers, such as 8 bit bytes? That's not true. You can think of Python integers as infinitely large, up to the limit of how memory you have.

Since it's working as documented, I'm going to close this.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42720>
_______________________________________

From report at bugs.python.org  Tue Dec 22 14:49:15 2020
From: report at bugs.python.org (Steve Stagg)
Date: Tue, 22 Dec 2020 19:49:15 +0000
Subject: [issue42717] The python interpreter crashed with
 "_enter_buffered_busy"
In-Reply-To: <1608632703.27.0.708410911987.issue42717@roundup.psfhosted.org>
Message-ID: <1608666555.1.0.884406845558.issue42717@roundup.psfhosted.org>


Steve Stagg <stestagg at gmail.com> added the comment:

Minimal test case:

====
import sys, threading

def run():
    for i in range(10000000):
        sys.stderr.write(' =.= ')

if __name__ == '__main__':
    threading.Thread(target=run, daemon=True).start()
===

I think this is expected behaviour.  My knowledge isn't complete here, but something similar to:

* During shutdown, the daemon threads are aborted
* In your example, the thread is very likely to be busy doing IO, so holding the io lock.
* The abort you're seeing is an explicit check/abort to avoid a deadlock (https://bugs.python.org/issue23309).

----------
nosy: +stestagg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42717>
_______________________________________

From report at bugs.python.org  Tue Dec 22 14:53:19 2020
From: report at bugs.python.org (Tal Einat)
Date: Tue, 22 Dec 2020 19:53:19 +0000
Subject: [issue34463] Discrepancy between traceback.print_exception and
 sys.__excepthook__
In-Reply-To: <1534964466.61.0.56676864532.issue34463@psf.upfronthosting.co.za>
Message-ID: <1608666799.13.0.147583894205.issue34463@roundup.psfhosted.org>


Tal Einat <taleinat+python at gmail.com> added the comment:


New changeset 069560b1171eb6385121ff3b6331e8814a4e7454 by Irit Katriel in branch 'master':
bpo-34463: Make python tracebacks identical to C tracebacks for SyntaxErrors without a lineno (GH-23427)
https://github.com/python/cpython/commit/069560b1171eb6385121ff3b6331e8814a4e7454


----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34463>
_______________________________________

From report at bugs.python.org  Tue Dec 22 14:53:27 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 22 Dec 2020 19:53:27 +0000
Subject: [issue34463] Discrepancy between traceback.print_exception and
 sys.__excepthook__
In-Reply-To: <1534964466.61.0.56676864532.issue34463@psf.upfronthosting.co.za>
Message-ID: <1608666807.0.0.119454737415.issue34463@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +22750
pull_request: https://github.com/python/cpython/pull/23895

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34463>
_______________________________________

From report at bugs.python.org  Tue Dec 22 15:07:19 2020
From: report at bugs.python.org (Steve Stagg)
Date: Tue, 22 Dec 2020 20:07:19 +0000
Subject: [issue42716] Segmentation fault in running ast.parse() with large
 expression size.
In-Reply-To: <1608632493.48.0.125975965886.issue42716@roundup.psfhosted.org>
Message-ID: <1608667639.58.0.722186164175.issue42716@roundup.psfhosted.org>


Steve Stagg <stestagg at gmail.com> added the comment:

fyi, Issue42712, Issue42712, Issue42714, Issue42715, Issue42716 all seem to be variants of the same underlying problem

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42716>
_______________________________________

From report at bugs.python.org  Tue Dec 22 15:32:21 2020
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 22 Dec 2020 20:32:21 +0000
Subject: [issue42246] Implement PEP 626 -- Precise line numbers for debugging
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1608669141.89.0.757001202196.issue42246@roundup.psfhosted.org>


Change by Mark Shannon <mark at hotpy.org>:


----------
pull_requests: +22751
pull_request: https://github.com/python/cpython/pull/23896

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42246>
_______________________________________

From report at bugs.python.org  Tue Dec 22 15:35:41 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Dec 2020 20:35:41 +0000
Subject: [issue42721] Using of simple dialogs without default root window
Message-ID: <1608669340.97.0.219315442285.issue42721@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Currently, standard message boxes in tkinter.messagebox (like showinfo() or askyesnocancel()) can be called without master or default root window. If arguments master or parent are not specified and there is no default root window is still created, the root window is created and set as the default root window. It is kept visible after closing a message box. It was done for testing from REPL. It affects also tkinter.colorchooser.askcolor().

The drawback is that the root window is kept visible and that it is set as the default root window (so following explicit calls of Tk(), with possible different arguments does not set the default root window).

Simple query dialogs in tkinter (like askinteger()) initially had the same behavior. But later it was broken, and currently they do not work if master and parent are not specified and the default root window is not set.

Proposed PR improves behavior of message boxes and colorchooser and restore the lost feature for query dialogs. Now if master and parent are not specified and the default root window is not set, the new temporary hidden root window is created, but is not set as the default root window. It will be destroyed right after closing the dialog, so it will not affect other widgets.

----------
components: Tkinter
messages: 383612
nosy: gpolo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Using of simple dialogs without default root window
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42721>
_______________________________________

From report at bugs.python.org  Tue Dec 22 15:46:01 2020
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 22 Dec 2020 20:46:01 +0000
Subject: [issue42696] Duplicated unused bytecodes at end of function
In-Reply-To: <1608499758.44.0.239199538725.issue42696@roundup.psfhosted.org>
Message-ID: <1608669961.21.0.502202364344.issue42696@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

In what way is it "kludgy"?
There is a mathematical theorem that states that generated code will be imperfect, 
so we will have to live with that :)
https://en.wikipedia.org/wiki/Full_employment_theorem

3.10a produces more efficient bytecode than 3.9.

3.9:

  2           0 LOAD_GLOBAL              0 (range)
              2 LOAD_CONST               1 (10)
              4 CALL_FUNCTION            1
              6 GET_ITER
        >>    8 FOR_ITER                 8 (to 18)
             10 STORE_FAST               0 (i)

  3          12 POP_TOP
             14 JUMP_ABSOLUTE           18
             16 JUMP_ABSOLUTE            8

  4     >>   18 LOAD_CONST               2 (17)
             20 RETURN_VALUE

3.10a:

  2           0 LOAD_GLOBAL              0 (range)
              2 LOAD_CONST               1 (10)
              4 CALL_FUNCTION            1
              6 GET_ITER
              8 FOR_ITER                 8 (to 18)
             10 STORE_FAST               0 (i)

  3          12 POP_TOP

  4          14 LOAD_CONST               2 (17)
             16 RETURN_VALUE
        >>   18 LOAD_CONST               2 (17)
             20 RETURN_VALUE

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42696>
_______________________________________

From report at bugs.python.org  Tue Dec 22 15:55:05 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 22 Dec 2020 20:55:05 +0000
Subject: [issue42721] Using of simple dialogs without default root window
In-Reply-To: <1608669340.97.0.219315442285.issue42721@roundup.psfhosted.org>
Message-ID: <1608670505.1.0.0296561367229.issue42721@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +22752
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23897

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42721>
_______________________________________

From report at bugs.python.org  Tue Dec 22 16:00:05 2020
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 22 Dec 2020 21:00:05 +0000
Subject: [issue42693] "if 0:" lines are traced; they didn't use to be
In-Reply-To: <1608498368.47.0.692310939381.issue42693@roundup.psfhosted.org>
Message-ID: <1608670805.39.0.069443032303.issue42693@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

The fix, which explains the bug:
https://github.com/python/cpython/pull/23896

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42693>
_______________________________________

From report at bugs.python.org  Tue Dec 22 16:15:24 2020
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 22 Dec 2020 21:15:24 +0000
Subject: [issue2506] Add mechanism to disable optimizations
In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za>
Message-ID: <1608671724.67.0.196720289963.issue2506@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

I think this can finally be closed.
A mere 12 years after it was opened :)

PEP 626 specifies what the correct behavior is, regardless of whether optimizations are turned on or off, so there is no point in a no-optimize option.
The compiler is fast enough that it is never worth turning off, even for iterate development.

If the bytecode optimizer produces incorrect or inefficient code for a particular example, please file a bug report for that case, and assign me.

----------
nosy: +Mark.Shannon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue2506>
_______________________________________

From report at bugs.python.org  Tue Dec 22 16:21:30 2020
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 22 Dec 2020 21:21:30 +0000
Subject: [issue42693] "if 0:" lines are traced; they didn't use to be
In-Reply-To: <1608498368.47.0.692310939381.issue42693@roundup.psfhosted.org>
Message-ID: <1608672090.3.0.211981016208.issue42693@roundup.psfhosted.org>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

Mark, I'm trying to follow along with your ideas, but it's hard to piece together the implications.  Is there a way to have a discussion about where you are headed?

https://github.com/python/cpython/pull/23896 "fixes" the jump to jump problems by no longer optimizing away jumps to jumps.  https://bugs.python.org/issue42719 mentions creating zero-width entries in the line number table.  Does that let us get rid of jumps to jumps but still produce two trace events?  I'd like to understand more.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42693>
_______________________________________

From report at bugs.python.org  Tue Dec 22 16:23:25 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Dec 2020 21:23:25 +0000
Subject: [issue25246] Alternative algorithm for deque_remove()
In-Reply-To: <1443343421.14.0.18683145075.issue25246@psf.upfronthosting.co.za>
Message-ID: <1608672205.27.0.959304792436.issue25246@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
pull_requests: +22753
pull_request: https://github.com/python/cpython/pull/23898

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25246>
_______________________________________

From report at bugs.python.org  Tue Dec 22 16:39:12 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Dec 2020 21:39:12 +0000
Subject: [issue9694] argparse required arguments displayed under "optional
 arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1608673152.65.0.863858383141.issue9694@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Since this change will break tests that rely matching help output exactly, I  would like to hear if there are any objections to replacing "optional arguments" with "options".

The words "switch" or "flag" don't work as well because they imply on/off and don't encompass option that take arguments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9694>
_______________________________________

From report at bugs.python.org  Tue Dec 22 16:53:49 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 22 Dec 2020 21:53:49 +0000
Subject: [issue42693] "if 0:" lines are traced; they didn't use to be
In-Reply-To: <1608498368.47.0.692310939381.issue42693@roundup.psfhosted.org>
Message-ID: <1608674029.29.0.731506451009.issue42693@roundup.psfhosted.org>


Change by Batuhan Taskaya <isidentical at gmail.com>:


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42693>
_______________________________________

From report at bugs.python.org  Tue Dec 22 16:57:34 2020
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 22 Dec 2020 21:57:34 +0000
Subject: [issue42693] "if 0:" lines are traced; they didn't use to be
In-Reply-To: <1608498368.47.0.692310939381.issue42693@roundup.psfhosted.org>
Message-ID: <1608674254.36.0.991886779305.issue42693@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

Are you interested in the "what" or the "how"?

The "what":
    PEP 626 defines what CPython must do in terms of tracing lines executed.

The "how":
    Obviously, we want to execute Python as efficiently as possible.
To do so, we use a series of "peephole" optimizations that make the bytecode more efficient but preserve PEP 626 semantics.

The front-end of the compiler produces code that conforms to PEP 626.
The optimizer should make the bytecode faster, while still conforming to PEP 626. Since the optimizer is inherited from 3.9, it doesn't always respect PEP 626. I am in the process of fixing that.

If you need to know what the optimizer does, in order to correctly implement coverage.py, then that is a bug in the optimizer.

Zero-width entries will, in theory, allow some additional optimizations.
But probably not that much, in practice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42693>
_______________________________________

From report at bugs.python.org  Tue Dec 22 17:01:29 2020
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 22 Dec 2020 22:01:29 +0000
Subject: [issue42693] "if 0:" lines are traced; they didn't use to be
In-Reply-To: <1608498368.47.0.692310939381.issue42693@roundup.psfhosted.org>
Message-ID: <1608674489.19.0.626297872203.issue42693@roundup.psfhosted.org>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

Specifically, for jumps to jumps, what is the plan?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42693>
_______________________________________

From report at bugs.python.org  Tue Dec 22 17:12:38 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 22 Dec 2020 22:12:38 +0000
Subject: [issue34463] Discrepancy between traceback.print_exception and
 sys.__excepthook__
In-Reply-To: <1534964466.61.0.56676864532.issue34463@psf.upfronthosting.co.za>
Message-ID: <1608675158.98.0.377969411308.issue34463@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 8e5c61a075f3a60272a7dcdc48db200090d76309 by Miss Islington (bot) in branch '3.9':
bpo-34463: Make python tracebacks identical to C tracebacks for SyntaxErrors without a lineno (GH-23427)
https://github.com/python/cpython/commit/8e5c61a075f3a60272a7dcdc48db200090d76309


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34463>
_______________________________________

From report at bugs.python.org  Tue Dec 22 17:25:24 2020
From: report at bugs.python.org (Mark Shannon)
Date: Tue, 22 Dec 2020 22:25:24 +0000
Subject: [issue42693] "if 0:" lines are traced; they didn't use to be
In-Reply-To: <1608498368.47.0.692310939381.issue42693@roundup.psfhosted.org>
Message-ID: <1608675924.24.0.44224552274.issue42693@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

There isn't much of a plan.

https://github.com/python/cpython/pull/23896 makes the optimizer respect PEP 626 w.r.t. jumps-to-jumps. 

>From the point of view of optimization, there is nothing special about jumps-to-jumps.
Any optimization that offers a speed up is good, regardless of which language feature it relates to.

To be honest, bytecode optimizations are going to win us a few percent max, whereas speeding up the interpreter could gain us 50-100%. So I'm not going to worry about trivial differences.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42693>
_______________________________________

From report at bugs.python.org  Tue Dec 22 17:37:30 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Tue, 22 Dec 2020 22:37:30 +0000
Subject: [issue42246] Implement PEP 626 -- Precise line numbers for debugging
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1608676650.56.0.993476599349.issue42246@roundup.psfhosted.org>


Change by Batuhan Taskaya <isidentical at gmail.com>:


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42246>
_______________________________________

From report at bugs.python.org  Tue Dec 22 17:42:00 2020
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 22 Dec 2020 22:42:00 +0000
Subject: [issue42693] "if 0:" lines are traced; they didn't use to be
In-Reply-To: <1608498368.47.0.692310939381.issue42693@roundup.psfhosted.org>
Message-ID: <1608676920.93.0.112442074826.issue42693@roundup.psfhosted.org>


Ned Batchelder <ned at nedbatchelder.com> added the comment:

This seems like a perspective that needs a wider audience.  PEP 626 says there will be no performance slowdown:

> Performance Implications
> 
> In general, there should be no change in performance. When tracing,
> programs should run a little faster as the new table format can be
> designed with line number calculation speed in mind. Code with long
> sequences of pass statements will probably become a bit slower.

Now you are saying that is fine to take a small performance hit in order to conform to PEP 626.  

I am usually on the side of good tracing, but I imagine other people feel differently, that it is unacceptable to slow down all execution for sake of accurate tracing.  I would love to have a clear agreement before moving forward so that we don't have to backtrack.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42693>
_______________________________________

From report at bugs.python.org  Tue Dec 22 17:48:55 2020
From: report at bugs.python.org (Irit Katriel)
Date: Tue, 22 Dec 2020 22:48:55 +0000
Subject: [issue34463] Discrepancy between traceback.print_exception and
 sys.__excepthook__
In-Reply-To: <1534964466.61.0.56676864532.issue34463@psf.upfronthosting.co.za>
Message-ID: <1608677335.05.0.238613149997.issue34463@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
pull_requests: +22754
pull_request: https://github.com/python/cpython/pull/23899

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue34463>
_______________________________________

From report at bugs.python.org  Tue Dec 22 18:32:20 2020
From: report at bugs.python.org (Inada Naoki)
Date: Tue, 22 Dec 2020 23:32:20 +0000
Subject: [issue42707] Python uses ANSI CP for stdio on Windows console instead
 of using console or OEM CP
In-Reply-To: <1608577171.81.0.55180678487.issue42707@roundup.psfhosted.org>
Message-ID: <1608679940.47.0.11166462956.issue42707@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

I think using Console codepage for stdio is better. But I am afraid about breaking existing code.
How about treating only UTF-8 and leave legacy environment as-is?

* When GetConsoleCP() returns CP_UTF8, use UTF-8 for stdin. Otherwise, use ANSI.
* When GetConsoleOutputCP() returns CP_UTF8, use UTF-8 for stdout. Otherwise, use ANSI.

This will work nice with PowerShell or cmd with `chcp 65001` in most simple cases.

----------
nosy: +methane

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42707>
_______________________________________

From report at bugs.python.org  Tue Dec 22 18:46:51 2020
From: report at bugs.python.org (Dominik V.)
Date: Tue, 22 Dec 2020 23:46:51 +0000
Subject: [issue42722] Add --debug command line option to unittest to enable
 post-mortem debugging
Message-ID: <1608680811.32.0.033035519481.issue42722@roundup.psfhosted.org>


New submission from Dominik V. <dominik.vilsmeier1123 at gmail.com>:

Currently there is no option to use post-mortem debugging via `pdb`
on a `unittest` test case which fails due to an exception being leaked.

Consider the following example:

```
import unittest

def foo():
    for x in [1, 2, 'oops', 4]:
        print(x + 100)

class TestFoo(unittest.TestCase):
    def test_foo(self):
        self.assertIs(foo(), None)

if __name__ == '__main__':
    unittest.main()
```

If we were calling `foo` directly we could enter post-mortem debugging via
`python -m pdb test.py`.
However since `foo` is wrapped in a test case, `unittest` eats the
exception and thus prevents post-mortem debugging.

So I propose adding a
command-line option `--debug` to unittest for running
test cases in debug mode so that post-mortem debugging can be used.

I see that some third-party distributions enable this, but since both
`unittest` and `pdb` are part of the standard library, it would
be nice if they played well together.
Plus the required methods are already in place (`TestCase.debug`
and `TestSuite.debug`).

There is also a popular StackOverflow question on this topic:
https://stackoverflow.com/questions/4398967/python-unit-testing-automatically-running-the-debugger-when-a-test-fails

----------
messages: 383624
nosy: Dominik V.
priority: normal
severity: normal
status: open
title: Add --debug command line option to unittest to enable post-mortem debugging
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42722>
_______________________________________

From report at bugs.python.org  Tue Dec 22 18:52:55 2020
From: report at bugs.python.org (Dominik V.)
Date: Tue, 22 Dec 2020 23:52:55 +0000
Subject: [issue42722] Add --debug command line option to unittest to enable
 post-mortem debugging
In-Reply-To: <1608680811.32.0.033035519481.issue42722@roundup.psfhosted.org>
Message-ID: <1608681175.73.0.204127616487.issue42722@roundup.psfhosted.org>


Change by Dominik V. <dominik.vilsmeier1123 at gmail.com>:


----------
keywords: +patch
pull_requests: +22755
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23900

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42722>
_______________________________________

From report at bugs.python.org  Tue Dec 22 18:58:03 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Tue, 22 Dec 2020 23:58:03 +0000
Subject: [issue42367] Restore os.makedirs ability to apply mode to all
 directories created
In-Reply-To: <1605520451.51.0.153670810596.issue42367@roundup.psfhosted.org>
Message-ID: <1608681483.48.0.00916275418986.issue42367@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 3.0 -> 4.0
pull_requests: +22756
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/23901

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42367>
_______________________________________

From report at bugs.python.org  Tue Dec 22 19:50:37 2020
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 23 Dec 2020 00:50:37 +0000
Subject: [issue42707] Python uses ANSI CP for stdio on Windows console instead
 of using console or OEM CP
In-Reply-To: <1608577171.81.0.55180678487.issue42707@roundup.psfhosted.org>
Message-ID: <1608684637.74.0.800451087403.issue42707@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> How about treating only UTF-8 and leave legacy environment as-is?
> * When GetConsoleCP() returns CP_UTF8, use UTF-8 for stdin. 
> Otherwise, use ANSI.

Okay, and also when GetConsoleCP() fails because there's no console (e.g. python.exe w/ DETACHED_PROCESS creation flag, or pythonw.exe). 

However, using UTF-8 for the input code page is currently broken in many cases, so it should not be promoted as a recommended solution until Microsoft fixes their broken code (which should have been fixed 20 years ago; it's ridiculous). Legacy console applications rely on ReadFile and ReadConsoleA. Setting the input code page to UTF-8 is limited to reading 7-bit ASCII (ordinals 0-127). Other characters get converted to null bytes. For example:

    >>> kernel32.SetConsoleCP(65001)
    1
    >>> os.read(0, 10)
    ab????cd
    b'ab\x00\x00\x00\x00cd\r\n'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42707>
_______________________________________

From report at bugs.python.org  Tue Dec 22 20:22:55 2020
From: report at bugs.python.org (Inada Naoki)
Date: Wed, 23 Dec 2020 01:22:55 +0000
Subject: [issue42707] Python uses ANSI CP for stdio on Windows console instead
 of using console or OEM CP
In-Reply-To: <1608577171.81.0.55180678487.issue42707@roundup.psfhosted.org>
Message-ID: <1608686575.9.0.343159710397.issue42707@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

> Okay, and also when GetConsoleCP() fails because there's no console (e.g. python.exe w/ DETACHED_PROCESS creation flag, or pythonw.exe). 

When there is no console, stdio should use the default textio encoding that is ANSI for now.

> However, using UTF-8 for the input code page is currently broken in many cases, so it should not be promoted as a recommended solution until Microsoft fixes their broken code (which should have been fixed 20 years ago; it's ridiculous). Legacy console applications rely on ReadFile and ReadConsoleA. Setting the input code page to UTF-8 is limited to reading 7-bit ASCII (ordinals 0-127). Other characters get converted to null bytes.

Regardless when we promote it, people use `chcp 65001` in cmd and `[Console]::OutputEncoding = [Text.Encoding]::UTF8` in Power Shell.
In such situation, UTF-8 is the best encoding for pipes and redirected files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42707>
_______________________________________

From report at bugs.python.org  Tue Dec 22 20:45:29 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 23 Dec 2020 01:45:29 +0000
Subject: [issue9694] argparse required arguments displayed under "optional
 arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1608687929.49.0.851738278059.issue9694@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I wouldn't let breaking these tests deter you from improving the output. I think using "options" is an improvement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9694>
_______________________________________

From report at bugs.python.org  Tue Dec 22 21:05:22 2020
From: report at bugs.python.org (Xinmeng Xia)
Date: Wed, 23 Dec 2020 02:05:22 +0000
Subject: [issue42717] The python interpreter crashed with
 "_enter_buffered_busy"
In-Reply-To: <1608632703.27.0.708410911987.issue42717@roundup.psfhosted.org>
Message-ID: <1608689122.51.0.790097111759.issue42717@roundup.psfhosted.org>


Xinmeng Xia <xiaxm at smail.nju.edu.cn> added the comment:

Thanks for your kind explanation! Now, I have understand the causes of this core dump. Considering it will not cause core dump in Python 2.x, I am wondering should we suggest an exception to catch it rather than "core dump"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42717>
_______________________________________

From report at bugs.python.org  Tue Dec 22 21:41:11 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Dec 2020 02:41:11 +0000
Subject: [issue39465] [subinterpreters] Design a subinterpreter friendly
 alternative to _Py_IDENTIFIER
In-Reply-To: <1580135310.72.0.978238650594.issue39465@roundup.psfhosted.org>
Message-ID: <1608691271.49.0.846419890055.issue39465@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 52a327c1cbb86c7f2f5c460645889b23615261bf by Victor Stinner in branch 'master':
bpo-39465: Add pycore_atomic_funcs.h header (GH-20766)
https://github.com/python/cpython/commit/52a327c1cbb86c7f2f5c460645889b23615261bf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39465>
_______________________________________

From report at bugs.python.org  Tue Dec 22 21:50:45 2020
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 23 Dec 2020 02:50:45 +0000
Subject: [issue42707] Python uses ANSI CP for stdio on Windows console instead
 of using console or OEM CP
In-Reply-To: <1608577171.81.0.55180678487.issue42707@roundup.psfhosted.org>
Message-ID: <1608691845.23.0.286820757202.issue42707@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> When there is no console, stdio should use the default textio 
> encoding that is ANSI for now.

stdin, stdout, and stderr are special and can be special cased because they're used implicitly for IPC. They've always been acknowledged as special by the existence of PYTHONIOENCODING. I think if Python is going to change its policy for standard I/O, along the lines of what I think you've been arguing in favor of for months now, it should commit to (almost) consistently using the console input and output code pages for the standard I/O encoding in Windows, with UTF-8 as the default when there is no console session, and with the exception that UTF-8 is used for console files. To get legacy behavior, set PYTHONLEGACYWINDOWSSTDIO, which will use the console code pages for console standard I/O and otherwise use the process active code page for standard I/O.

The default encoding for open() would still be the process active code page from GetACP(), and the recommendation should be for scripts to use an explicit `encoding`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42707>
_______________________________________

From report at bugs.python.org  Tue Dec 22 22:42:04 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 23 Dec 2020 03:42:04 +0000
Subject: [issue42693] "if 0:" lines are traced; they didn't use to be
In-Reply-To: <1608498368.47.0.692310939381.issue42693@roundup.psfhosted.org>
Message-ID: <1608694924.5.0.427484925268.issue42693@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

Maybe sys.settrace() is not ultimately the best tool for coverage reporting? If the bytecode compiler natively supported coverage instrumentation, source semantics would be easier to respect. A nice implementation could use Knuth & Stevenson "Optimal measurement of points for program frequency counts".

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42693>
_______________________________________

From report at bugs.python.org  Wed Dec 23 00:03:52 2020
From: report at bugs.python.org (hai shi)
Date: Wed, 23 Dec 2020 05:03:52 +0000
Subject: [issue42035] [C API] PyType_GetSlot cannot get tp_name
In-Reply-To: <1602683525.08.0.938781399322.issue42035@roundup.psfhosted.org>
Message-ID: <1608699832.6.0.272887005831.issue42035@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
keywords: +patch
pull_requests: +22757
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23903

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42035>
_______________________________________

From report at bugs.python.org  Wed Dec 23 01:02:26 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 23 Dec 2020 06:02:26 +0000
Subject: [issue42693] "if 0:" lines are traced; they didn't use to be
In-Reply-To: <1608498368.47.0.692310939381.issue42693@roundup.psfhosted.org>
Message-ID: <1608703346.32.0.320826427834.issue42693@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

If the NOP is outside of the loop, then what is the reason of adding it? You cannot set a breakpoint on "while True:" which stops on every iteration.

The goal "tracing every line of code" is incompatible with code optimization. It would be better to add a special option to produce slower bytecode for tracing if you want to trace every line.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42693>
_______________________________________

From report at bugs.python.org  Wed Dec 23 01:09:00 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 23 Dec 2020 06:09:00 +0000
Subject: [issue15303] Minor revision to the <BaseWidget._setup> method in
 Tkinter
In-Reply-To: <1341822350.55.0.995662615633.issue15303@psf.upfronthosting.co.za>
Message-ID: <1608703740.36.0.511285580293.issue15303@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +22758
pull_request: https://github.com/python/cpython/pull/23904

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15303>
_______________________________________

From report at bugs.python.org  Wed Dec 23 02:26:00 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Dec 2020 07:26:00 +0000
Subject: [issue42620] documentation on `getsockname()` wrong for AF_INET6
In-Reply-To: <1607687399.41.0.179840129913.issue42620@roundup.psfhosted.org>
Message-ID: <1608708360.88.0.156577217176.issue42620@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset cf3565ca9a7ed0f7decd000e41fa3de400986e4d by Christian Heimes in branch 'master':
bpo-42620: Improve socket.getsockname doc string (GH-23742)
https://github.com/python/cpython/commit/cf3565ca9a7ed0f7decd000e41fa3de400986e4d


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42620>
_______________________________________

From report at bugs.python.org  Wed Dec 23 02:26:21 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Dec 2020 07:26:21 +0000
Subject: [issue42620] documentation on `getsockname()` wrong for AF_INET6
In-Reply-To: <1607687399.41.0.179840129913.issue42620@roundup.psfhosted.org>
Message-ID: <1608708381.08.0.00668461958913.issue42620@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22759
pull_request: https://github.com/python/cpython/pull/23906

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42620>
_______________________________________

From report at bugs.python.org  Wed Dec 23 02:26:29 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Dec 2020 07:26:29 +0000
Subject: [issue42620] documentation on `getsockname()` wrong for AF_INET6
In-Reply-To: <1607687399.41.0.179840129913.issue42620@roundup.psfhosted.org>
Message-ID: <1608708389.31.0.451588976843.issue42620@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22760
pull_request: https://github.com/python/cpython/pull/23907

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42620>
_______________________________________

From report at bugs.python.org  Wed Dec 23 02:44:25 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Dec 2020 07:44:25 +0000
Subject: [issue42620] documentation on `getsockname()` wrong for AF_INET6
In-Reply-To: <1607687399.41.0.179840129913.issue42620@roundup.psfhosted.org>
Message-ID: <1608709465.63.0.962519087549.issue42620@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b20494618c6ac6ebcd354e0b16a6645fe47acbee by Miss Islington (bot) in branch '3.8':
bpo-42620: Improve socket.getsockname doc string (GH-23742)
https://github.com/python/cpython/commit/b20494618c6ac6ebcd354e0b16a6645fe47acbee


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42620>
_______________________________________

From report at bugs.python.org  Wed Dec 23 02:48:14 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Dec 2020 07:48:14 +0000
Subject: [issue42620] documentation on `getsockname()` wrong for AF_INET6
In-Reply-To: <1607687399.41.0.179840129913.issue42620@roundup.psfhosted.org>
Message-ID: <1608709694.58.0.36029682104.issue42620@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 7fe7d83c26b02c8a65c8a9633cc4251f5cd97ebf by Miss Islington (bot) in branch '3.9':
bpo-42620: Improve socket.getsockname doc string (GH-23742)
https://github.com/python/cpython/commit/7fe7d83c26b02c8a65c8a9633cc4251f5cd97ebf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42620>
_______________________________________

From report at bugs.python.org  Wed Dec 23 02:55:41 2020
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 23 Dec 2020 07:55:41 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1608710141.06.0.0109866595496.issue1635741@roundup.psfhosted.org>


Christian Heimes <lists at cheimes.de> added the comment:


New changeset 6d9ec8bbfa07161431dc6190dd0772a6fbaf7ebd by Christian Heimes in branch 'master':
bpo-1635741: Port resource extension module to module state (GH-23462)
https://github.com/python/cpython/commit/6d9ec8bbfa07161431dc6190dd0772a6fbaf7ebd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Wed Dec 23 05:40:52 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 23 Dec 2020 10:40:52 +0000
Subject: [issue42682] awaiting a wrapped asyncio.Task multiple times gives
 long, repeative tracebacks
In-Reply-To: <1608365364.67.0.620283086401.issue42682@roundup.psfhosted.org>
Message-ID: <1608720052.59.0.281253810036.issue42682@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:

The traceback contains frames from asyncio internal machinery, that's why the traceback is long.

IFIAK Python standard library never filters such calls, asyncio is not an exception.

On the other hand, well-known pytest library supports `__tracebackhide__ = True` for skipping pytest internals in test failure reports.
I'm not sure if we want to do such black magic though.

Plus, sometimes an information about internals is helpful to detect the actual source of the problem,

I have no clear vision of how to skip internal frames easily. 

Yuri, maybe you have an idea?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42682>
_______________________________________

From report at bugs.python.org  Wed Dec 23 05:45:02 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 23 Dec 2020 10:45:02 +0000
Subject: [issue42703] Asyncio Event Documentation Links Incorrect
In-Reply-To: <1608561035.31.0.374875188875.issue42703@roundup.psfhosted.org>
Message-ID: <1608720302.65.0.841071815126.issue42703@roundup.psfhosted.org>


Andrew Svetlov <andrew.svetlov at gmail.com> added the comment:


New changeset d90ff376813843310a6f9ccc96551fa1521e8fef by Matt Fowler in branch 'master':
BPO-42703: Fix incorrect documentation links for asyncio.Event (GH-23881)
https://github.com/python/cpython/commit/d90ff376813843310a6f9ccc96551fa1521e8fef


----------
nosy: +asvetlov

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42703>
_______________________________________

From report at bugs.python.org  Wed Dec 23 05:45:07 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Dec 2020 10:45:07 +0000
Subject: [issue42703] Asyncio Event Documentation Links Incorrect
In-Reply-To: <1608561035.31.0.374875188875.issue42703@roundup.psfhosted.org>
Message-ID: <1608720307.94.0.403100446897.issue42703@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +22761
pull_request: https://github.com/python/cpython/pull/23908

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42703>
_______________________________________

From report at bugs.python.org  Wed Dec 23 05:45:15 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Dec 2020 10:45:15 +0000
Subject: [issue42703] Asyncio Event Documentation Links Incorrect
In-Reply-To: <1608561035.31.0.374875188875.issue42703@roundup.psfhosted.org>
Message-ID: <1608720315.11.0.300162122033.issue42703@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22762
pull_request: https://github.com/python/cpython/pull/23909

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42703>
_______________________________________

From report at bugs.python.org  Wed Dec 23 06:14:16 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Dec 2020 11:14:16 +0000
Subject: [issue42703] Asyncio Event Documentation Links Incorrect
In-Reply-To: <1608561035.31.0.374875188875.issue42703@roundup.psfhosted.org>
Message-ID: <1608722056.4.0.990126900231.issue42703@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 1e1bacf9e61143e7b0f78de9dcb578983bea8f81 by Miss Islington (bot) in branch '3.9':
BPO-42703: Fix incorrect documentation links for asyncio.Event (GH-23881)
https://github.com/python/cpython/commit/1e1bacf9e61143e7b0f78de9dcb578983bea8f81


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42703>
_______________________________________

From report at bugs.python.org  Wed Dec 23 06:14:30 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Dec 2020 11:14:30 +0000
Subject: [issue42703] Asyncio Event Documentation Links Incorrect
In-Reply-To: <1608561035.31.0.374875188875.issue42703@roundup.psfhosted.org>
Message-ID: <1608722070.83.0.478384517364.issue42703@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 412c935a37eb8fe290b684c44c80cf361f6b814b by Miss Islington (bot) in branch '3.8':
BPO-42703: Fix incorrect documentation links for asyncio.Event (GH-23881)
https://github.com/python/cpython/commit/412c935a37eb8fe290b684c44c80cf361f6b814b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42703>
_______________________________________

From report at bugs.python.org  Wed Dec 23 06:14:51 2020
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 23 Dec 2020 11:14:51 +0000
Subject: [issue42703] Asyncio Event Documentation Links Incorrect
In-Reply-To: <1608561035.31.0.374875188875.issue42703@roundup.psfhosted.org>
Message-ID: <1608722091.85.0.621939850331.issue42703@roundup.psfhosted.org>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42703>
_______________________________________

From report at bugs.python.org  Wed Dec 23 06:21:19 2020
From: report at bugs.python.org (Luke Davis)
Date: Wed, 23 Dec 2020 11:21:19 +0000
Subject: [issue42723] Unclear why dict unpacking cannot be used in dict
 comprehension
Message-ID: <1608722479.78.0.847759478082.issue42723@roundup.psfhosted.org>


New submission from Luke Davis <lukedavis at live.com>:

Why am I unable to do:

dict = { **sub_dict for sub_dict in super_dict.values() }

which throws: "dict unpacking cannot be used in dict comprehension"

Whereas the equivalent code below doesn't throw any errors?:

dict = {}
for sub_dict in super_dict.values():
    dict = { **dict, **sub_dict }

Am I wrong in thinking the first and second block of code should do the same thing behind the scenes?

----------
messages: 383641
nosy: PartlyFluked
priority: normal
severity: normal
status: open
title: Unclear why dict unpacking cannot be used in dict comprehension
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42723>
_______________________________________

From report at bugs.python.org  Wed Dec 23 06:30:33 2020
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 23 Dec 2020 11:30:33 +0000
Subject: [issue42693] "if 0:" lines are traced; they didn't use to be
In-Reply-To: <1608498368.47.0.692310939381.issue42693@roundup.psfhosted.org>
Message-ID: <1608723033.41.0.41127899889.issue42693@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:

I'll briefly answer the above questions, but we could we close this issue?

If there are specific issues regarding PEP 626, please make a new issue. Feel free to +nosy me on those issues.

I intend to review all the recent changes to the compiler in the new year,
in case there are any obvious inefficiencies.

Ned,
The bytecode for 3.10a should be more efficient than 3.9.
IMO, it is not worth spending too much time on making the bytecode look pretty, and that if we care about performance it would be better to spend our time elsewhere.

Serhiy,
The bytecode for the test in the while statement is duplicated; one in the loop header, one in the body. Try it under pdb, you'll see that it breaks at two different places in the bytecode. 
See https://github.com/python/cpython/pull/23743

Benjamin,
Eventually, yes we will want to implement something like the JVMTI for the JVM. However, for that to be useful we still need precise line number tracing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42693>
_______________________________________

From report at bugs.python.org  Wed Dec 23 06:43:19 2020
From: report at bugs.python.org (Mark Shannon)
Date: Wed, 23 Dec 2020 11:43:19 +0000
Subject: [issue42246] Implement PEP 626 -- Precise line numbers for debugging
In-Reply-To: <1604331162.26.0.596873070589.issue42246@roundup.psfhosted.org>
Message-ID: <1608723799.31.0.115570288646.issue42246@roundup.psfhosted.org>


Mark Shannon <mark at hotpy.org> added the comment:


New changeset 28b75c80dcc1e17ed3ac1c69362bf8dc164b760a by Mark Shannon in branch 'master':
bpo-42246: Don't eliminate jumps to jumps, if it will break PEP 626. (GH-23896)
https://github.com/python/cpython/commit/28b75c80dcc1e17ed3ac1c69362bf8dc164b760a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42246>
_______________________________________

From report at bugs.python.org  Wed Dec 23 06:51:42 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 23 Dec 2020 11:51:42 +0000
Subject: [issue42723] Unclear why dict unpacking cannot be used in dict
 comprehension
In-Reply-To: <1608722479.78.0.847759478082.issue42723@roundup.psfhosted.org>
Message-ID: <1608724302.38.0.797074521154.issue42723@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

They don't do the same thing.

The dict comprehension requires a single key:value pair per loop. It accumulates values into a single dict. Try this:

    d = {}
    for key, value in items:
        print(id(d))
        d[key] = value

The ID doesn't change because it is the same dict each time.

Unpacking a dict doesn't produce a single key:value pair, except maybe by accident, so it is not usable in a dict comprehension.

Your second example doesn't modify a single dict, it **replaces** it with a new dict each time.

    d = {}
    for sub_dict in super_dict.values():
        print(id(d))
        d = { **d, **sub_dict }

The IDs will change through the loop as d gets replaced with a new dict each time. So this is not equivalent to a comprehension.

Also, the second would also be very inefficient. It unpacks the existing dict, then packs the values into a new dict, then unpacks it again, then repacks it into yet another dict, and so on.

Better:

    d = {}
    for sub_dict in super_dict.values():
        d.update(sub_dict)

But that's not equivalent to a dict comprehension either.

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42723>
_______________________________________

From report at bugs.python.org  Wed Dec 23 07:17:15 2020
From: report at bugs.python.org (Brian Costlow)
Date: Wed, 23 Dec 2020 12:17:15 +0000
Subject: [issue36702] test_dtrace failed
In-Reply-To: <1556002133.06.0.696794109378.issue36702@roundup.psfhosted.org>
Message-ID: <1608725835.41.0.243844211975.issue36702@roundup.psfhosted.org>


Brian Costlow <brian.costlow at gmail.com> added the comment:

There are actually two different issues here.

dtrace -q will not work on Fedora-based linux (haven't tried elsewhere) and that probably should be corrected, but that is NOT what causes the test fail. 

The tests' setup checks whether dtrace is usuable, and since it is not, those tests are skipped. 

However, stap IS usable, so those tests run.

test.test_dtrace.SystemTapOptimizedTests.test_line will always fail because it expects files in dtracedata (line.stp and line.stp.expected) that are not there.

I've attached a file showing isolated runs of test_dtrace on a newly built Python 3.8.6 on two Centos 7 systems.

The first is against the official Centos 7 Docker container, and stap fails because Linuxkit kernel modules are not installed. The test_dtrace check for a working stap fails, and all 4 tests are skipped.

The second is against a virtualized Centos 7 where the kernel modules are properly installed and stap works.

I don't see how test_dtrace ever passes on a system with a working /bin/stap command.

----------
nosy: +brian.costlow
Added file: https://bugs.python.org/file49696/test_dtrace_stap_bug.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36702>
_______________________________________

From report at bugs.python.org  Wed Dec 23 07:56:35 2020
From: report at bugs.python.org (Corentin Bolou)
Date: Wed, 23 Dec 2020 12:56:35 +0000
Subject: [issue42724] Change library name when building.
Message-ID: <1608728195.78.0.130143828179.issue42724@roundup.psfhosted.org>


New submission from Corentin Bolou <corentin.bolou27 at gmail.com>:

Hello python community.
I use python in a software I develop.
I succeed the standard build into lib/dll on windows.
However, I have difficulties when I want to change the name of the lib. And used them with the new name in my project.
I follow the Readme that tell to change the name, we have to change in PCbuild the python.props. So I did that and I had the right name I wanted after building python. But when I compile my project, when I reached the link step,my project search for the old library name. And I have nothing in my code that try to search for this library. I add the include python.lib in my project settings, but it said that it cannot open file python38.lib. I think some compile C code may reference to his name. And if it's the case. I want to know if it's possible to build python with a different name than  python38 and python38_d.lib/dll on Windows. 
Sincerely,
Corentin

----------
components: Build
messages: 383646
nosy: corentin.bolou27
priority: normal
severity: normal
status: open
title: Change library name when building.
type: compile error
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42724>
_______________________________________

From report at bugs.python.org  Wed Dec 23 08:28:51 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 23 Dec 2020 13:28:51 +0000
Subject: [issue42725] PEP 563: Should the behavior change for yield/yield
 from's
Message-ID: <1608730131.08.0.595189962302.issue42725@roundup.psfhosted.org>


New submission from Batuhan Taskaya <isidentical at gmail.com>:

Since the annotations are processed just like all other expressions in the symbol table, the generated entries for functions etc. This would result with 

def foo():
    for number in range(5):
        foo: (yield number)
    return number

foo()

returning a generator / coroutine (depending on yield/yield from/await usage). Is this something we want to keep or maybe tweak the symbol table generator to not to handle annotations (since there are also more subtle issues regarding analysis of cell / free vars).

----------
messages: 383647
nosy: BTaskaya, gvanrossum
priority: normal
severity: normal
status: open
title: PEP 563: Should the behavior change for yield/yield from's

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42725>
_______________________________________

From report at bugs.python.org  Wed Dec 23 08:33:58 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 23 Dec 2020 13:33:58 +0000
Subject: [issue41960] Add globalns and localns to the inspect.signature and
 inspect.Signature.from_callable
In-Reply-To: <1602016741.16.0.216443843373.issue41960@roundup.psfhosted.org>
Message-ID: <1608730438.02.0.643840163874.issue41960@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

> It's been a while, I've lost context for this idea. What problem are you trying to solve here? Are there issues where people have reported problems that this would allow them to solve?

Context: https://github.com/python/cpython/pull/20434#discussion_r499289645

tl;dr: 
import inspect

def foo():
    class F: ...
    def foo(bar: F): ...
    print(inspect.signature(foo))

foo()

Normally, if inspect.signature is able to resolve annotations with the current globals()/locals() it will give the resolved version, if not the string version. So adding this would allow people to choose which namespace inspect.signature will pass to the typing.get_type_hints. (inspect.signature(foo, localns=locals()) would give directly the F object instead of 'F', etc.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41960>
_______________________________________

From report at bugs.python.org  Wed Dec 23 11:14:23 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Dec 2020 16:14:23 +0000
Subject: [issue28468] Add platform.freedesktop_os_release()
In-Reply-To: <1476780458.76.0.0265588591799.issue28468@psf.upfronthosting.co.za>
Message-ID: <1608740063.29.0.839066794366.issue28468@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22763
pull_request: https://github.com/python/cpython/pull/23913

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28468>
_______________________________________

From report at bugs.python.org  Wed Dec 23 11:36:03 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 23 Dec 2020 16:36:03 +0000
Subject: [issue28468] Add platform.freedesktop_os_release()
In-Reply-To: <1476780458.76.0.0265588591799.issue28468@psf.upfronthosting.co.za>
Message-ID: <1608741363.12.0.667764967863.issue28468@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset bfda4f5776fd20f92b441c8a88ee7a9d44dc8777 by Victor Stinner in branch 'master':
bpo-28468: Fix typo in _os_release_candidates (GH-23913)
https://github.com/python/cpython/commit/bfda4f5776fd20f92b441c8a88ee7a9d44dc8777


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28468>
_______________________________________

From report at bugs.python.org  Wed Dec 23 11:40:12 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 23 Dec 2020 16:40:12 +0000
Subject: [issue38655] ipaddress.ip_network('0.0.0.0/0').is_private == True
In-Reply-To: <1572530691.84.0.462430681921.issue38655@roundup.psfhosted.org>
Message-ID: <1608741612.32.0.0940176824609.issue38655@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38655>
_______________________________________

From report at bugs.python.org  Wed Dec 23 12:41:06 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 23 Dec 2020 17:41:06 +0000
Subject: [issue9694] argparse required arguments displayed under "optional
 arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1608745266.78.0.539471018538.issue9694@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 41b223d29cdfeb1f222c12c3abaccc3bc128f5e7 by Raymond Hettinger in branch 'master':
bpo-9694: Fix misleading phrase "optional arguments" (GH-23858)
https://github.com/python/cpython/commit/41b223d29cdfeb1f222c12c3abaccc3bc128f5e7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue9694>
_______________________________________

From report at bugs.python.org  Wed Dec 23 12:41:40 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 23 Dec 2020 17:41:40 +0000
Subject: [issue9694] argparse required arguments displayed under "optional
 arguments"
In-Reply-To: <1282846759.11.0.900867962743.issue9694@psf.upfronthosting.co.za>
Message-ID: <1608745300.13.0.655948976951.issue9694@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/issue9694>
_______________________________________

From report at bugs.python.org  Wed Dec 23 12:44:51 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 23 Dec 2020 17:44:51 +0000
Subject: [issue42711] lru_cache and NotImplemented
In-Reply-To: <1608619207.84.0.36165935347.issue42711@roundup.psfhosted.org>
Message-ID: <1608745491.62.0.262143540972.issue42711@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for the suggestion, but I think it is better to use the tool as designed without any special cases.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42711>
_______________________________________

From report at bugs.python.org  Wed Dec 23 13:16:44 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 23 Dec 2020 18:16:44 +0000
Subject: [issue42724] Change library name when building.
In-Reply-To: <1608728195.78.0.130143828179.issue42724@roundup.psfhosted.org>
Message-ID: <1608747404.6.0.424596255428.issue42724@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

This tracker is for reporting bugs in python. I think you'd have better luck asking this question on Stack Overflow, or maybe the python-list mailing list: https://mail.python.org/mailman/listinfo/python-list

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42724>
_______________________________________

From report at bugs.python.org  Wed Dec 23 13:17:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 23 Dec 2020 18:17:04 +0000
Subject: [issue32381] Python 3.6 cannot reopen .pyc file with non-ASCII path
In-Reply-To: <1513750045.01.0.213398074469.issue32381@psf.upfronthosting.co.za>
Message-ID: <1608747424.24.0.789303039185.issue32381@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset a12491681f08a33abcca843f5150330740c91111 by Victor Stinner in branch 'master':
bpo-32381: pymain_run_command() uses PyCF_IGNORE_COOKIE (GH-23724)
https://github.com/python/cpython/commit/a12491681f08a33abcca843f5150330740c91111


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32381>
_______________________________________

From report at bugs.python.org  Wed Dec 23 13:30:18 2020
From: report at bugs.python.org (Augusto Hack)
Date: Wed, 23 Dec 2020 18:30:18 +0000
Subject: [issue42726] gdb/libpython.py InstanceProxy does not work with py3
Message-ID: <1608748218.63.0.956794347013.issue42726@roundup.psfhosted.org>


New submission from Augusto Hack <me at hak.cx>:

Calling `proxyval` on an instance of a user defined class fails.

minimally reproducible example:
```
from time import sleep

class A:
    def __init__(self):
        self.a = 1

a = A()
sleep(10)
```
Attach to process and run:
```
py-up
python-interactive
Frame.get_selected_python_frame().get_pyop().get_var_by_name('a')[0].proxyval(set())
```
Will result in the following error:
```
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/debug/usr/lib64/libpython3.7m.so.1.0-3.7.9-2.fc33.x86_64.debug-gdb.py", line 471, in __repr__
    for arg, val in self.attrdict.iteritems()])
AttributeError: 'dict' object has no attribute 'iteritems'
```
Tested on fedora 33 with python3.7 and debugsymbols

----------
components: Demos and Tools
messages: 383654
nosy: hack.augusto
priority: normal
pull_requests: 22764
severity: normal
status: open
title: gdb/libpython.py InstanceProxy does not work with py3
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42726>
_______________________________________

From report at bugs.python.org  Wed Dec 23 14:35:04 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 23 Dec 2020 19:35:04 +0000
Subject: [issue42725] PEP 563: Should the behavior change for yield/yield
 from's
In-Reply-To: <1608730131.08.0.595189962302.issue42725@roundup.psfhosted.org>
Message-ID: <1608752104.94.0.111342862195.issue42725@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Ouch.  I think we should generate a SyntaxError if yield [from] is used in an annotation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42725>
_______________________________________

From report at bugs.python.org  Wed Dec 23 14:35:14 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 23 Dec 2020 19:35:14 +0000
Subject: [issue42725] PEP 563: Should the behavior change for yield/yield
 from's
In-Reply-To: <1608730131.08.0.595189962302.issue42725@roundup.psfhosted.org>
Message-ID: <1608752114.55.0.273364870401.issue42725@roundup.psfhosted.org>


Change by Guido van Rossum <guido at python.org>:


----------
nosy: +lys.nikolaou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42725>
_______________________________________

From report at bugs.python.org  Wed Dec 23 14:44:46 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 23 Dec 2020 19:44:46 +0000
Subject: [issue25246] Alternative algorithm for deque_remove()
In-Reply-To: <1443343421.14.0.18683145075.issue25246@psf.upfronthosting.co.za>
Message-ID: <1608752686.82.0.553341009288.issue25246@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Created a new PR that gives a substantial speed-up while keeping the API unchanged and while closely matching the logic for list.remove().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25246>
_______________________________________

From report at bugs.python.org  Wed Dec 23 14:45:18 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 23 Dec 2020 19:45:18 +0000
Subject: [issue25246] Alternative algorithm for deque_remove()
In-Reply-To: <1443343421.14.0.18683145075.issue25246@psf.upfronthosting.co.za>
Message-ID: <1608752718.96.0.107234338948.issue25246@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 6b1ac809b9718a369aea67b99077cdd682be2238 by Raymond Hettinger in branch 'master':
bpo-25246: Optimize deque.remove() (GH-23898)
https://github.com/python/cpython/commit/6b1ac809b9718a369aea67b99077cdd682be2238


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25246>
_______________________________________

From report at bugs.python.org  Wed Dec 23 14:45:44 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 23 Dec 2020 19:45:44 +0000
Subject: [issue25246] Alternative algorithm for deque_remove()
In-Reply-To: <1443343421.14.0.18683145075.issue25246@psf.upfronthosting.co.za>
Message-ID: <1608752744.17.0.211686326828.issue25246@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution: rejected -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25246>
_______________________________________

From report at bugs.python.org  Wed Dec 23 14:55:46 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 23 Dec 2020 19:55:46 +0000
Subject: [issue18140] urlparse,
 urlsplit confused when password includes fragment (#), query (?)
In-Reply-To: <1370425503.35.0.436511643169.issue18140@psf.upfronthosting.co.za>
Message-ID: <1608753346.95.0.285242353309.issue18140@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Not a bug. The message #msg375109 explains how to quote and unquote the '#' in the password field, and demonstrates how urllib parses it correctly.

I guess, it was set to open as a mistake. Closing it again.

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue18140>
_______________________________________

From report at bugs.python.org  Wed Dec 23 15:41:34 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 23 Dec 2020 20:41:34 +0000
Subject: [issue42725] PEP 563: Should the behavior change for yield/yield
 from's
In-Reply-To: <1608730131.08.0.595189962302.issue42725@roundup.psfhosted.org>
Message-ID: <1608756094.7.0.944899403116.issue42725@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

This is another side effect of processing annotations (at the symbol table construction stage) (and I would assume there are a few more cases like this);

def foo():
    outer_var = 1

    def bar():
        inner_var: outer_var = T
    
    return bar

inner = foo()
print(inner.__closure__)

In theory, there shouldn't be any cells / references to the variables from outer scope, but since we process the entry for the annotation and record `outer_var` as a free var it is listed here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42725>
_______________________________________

From report at bugs.python.org  Wed Dec 23 15:45:23 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 23 Dec 2020 20:45:23 +0000
Subject: [issue42725] PEP 563: Should the behavior change for yield/yield
 from's
In-Reply-To: <1608730131.08.0.595189962302.issue42725@roundup.psfhosted.org>
Message-ID: <1608756323.59.0.515476036721.issue42725@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

The difference is that that just causes a slight inefficiency, while processing 'yield' makes the function a generator. So I don't feel as strongly about that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42725>
_______________________________________

From report at bugs.python.org  Wed Dec 23 16:06:16 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 23 Dec 2020 21:06:16 +0000
Subject: [issue23328] urllib.request fails for proxy credentials that contain
 a '/' character
In-Reply-To: <1422342235.17.0.905041944591.issue23328@psf.upfronthosting.co.za>
Message-ID: <1608757576.7.0.950532940544.issue23328@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
title: urllib2 fails for proxy credentials that contain a '/' character -> urllib.request fails for proxy credentials that contain a '/' character
versions: +Python 3.10 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23328>
_______________________________________

From report at bugs.python.org  Wed Dec 23 16:09:33 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 23 Dec 2020 21:09:33 +0000
Subject: [issue42725] PEP 563: Should the behavior change for yield/yield
 from's
In-Reply-To: <1608730131.08.0.595189962302.issue42725@roundup.psfhosted.org>
Message-ID: <1608757773.44.0.263946779087.issue42725@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

> So I don't feel as strongly about that.

Just to note, since I believe the solution for all this might be the same (not processing annotations at all, since they will be compiled to strings in the later stage). If we go down on that route, it will be simpler but we won't be able to raise SyntaxError's for "a: (yield)" / "b: (await/yield from x)". 

By the way, this is what happens if you try to use get_type_hints on a function where an argument is (yield):

>>> typing.get_type_hints(a)
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/typing.py", line 537, in __init__
    code = compile(arg, '<string>', 'eval')
  File "<string>", line 1
SyntaxError: 'yield' outside function

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.10/typing.py", line 1490, in get_type_hints
    value = ForwardRef(value)
  File "/usr/local/lib/python3.10/typing.py", line 539, in __init__
    raise SyntaxError(f"Forward reference must be an expression -- got {arg!r}")
SyntaxError: Forward reference must be an expression -- got '(yield)'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42725>
_______________________________________

From report at bugs.python.org  Wed Dec 23 16:19:59 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 23 Dec 2020 21:19:59 +0000
Subject: [issue42725] PEP 563: Should the behavior change for yield/yield
 from's
In-Reply-To: <1608730131.08.0.595189962302.issue42725@roundup.psfhosted.org>
Message-ID: <1608758399.74.0.699998617186.issue42725@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

If we simply ignored yield in the annotation, wouldn't we have the problem that

def f(a: (yield)): pass

silently changes from being a generator (in 3.9) to not being a generator (in 3.10)? That would be bad. I'd rather make this an error still. (But for nonlocals, not processing sounds fine.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42725>
_______________________________________

From report at bugs.python.org  Wed Dec 23 17:45:25 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 23 Dec 2020 22:45:25 +0000
Subject: [issue41960] Add globalns and localns to the inspect.signature and
 inspect.Signature.from_callable
In-Reply-To: <1602016741.16.0.216443843373.issue41960@roundup.psfhosted.org>
Message-ID: <1608763525.78.0.317032428215.issue41960@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:


New changeset eee1c7745ab4eb4f75153e71aaa2a62018b7625a by Batuhan Taskaya in branch 'master':
bpo-41960: Add globalns and localns parameters to inspect.signature and Signature.from_callable (GH-22583)
https://github.com/python/cpython/commit/eee1c7745ab4eb4f75153e71aaa2a62018b7625a


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41960>
_______________________________________

From report at bugs.python.org  Wed Dec 23 17:45:52 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Wed, 23 Dec 2020 22:45:52 +0000
Subject: [issue41960] Add globalns and localns to the inspect.signature and
 inspect.Signature.from_callable
In-Reply-To: <1602016741.16.0.216443843373.issue41960@roundup.psfhosted.org>
Message-ID: <1608763552.59.0.0184378250846.issue41960@roundup.psfhosted.org>


Change by Batuhan Taskaya <isidentical at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41960>
_______________________________________

From report at bugs.python.org  Wed Dec 23 18:14:45 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 23 Dec 2020 23:14:45 +0000
Subject: [issue38308] Add optional weighting to statistics.harmonic_mean()
In-Reply-To: <1569695295.83.0.838130885601.issue38308@roundup.psfhosted.org>
Message-ID: <1608765285.64.0.580649952632.issue38308@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
pull_requests: +22765
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23914

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38308>
_______________________________________

From report at bugs.python.org  Wed Dec 23 18:17:12 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 23 Dec 2020 23:17:12 +0000
Subject: [issue38308] Add optional weighting to statistics.harmonic_mean()
In-Reply-To: <1569695295.83.0.838130885601.issue38308@roundup.psfhosted.org>
Message-ID: <1608765432.59.0.0891423982285.issue38308@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: steven.daprano -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38308>
_______________________________________

From report at bugs.python.org  Wed Dec 23 19:53:32 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 24 Dec 2020 00:53:32 +0000
Subject: [issue38308] Add optional weighting to statistics.harmonic_mean()
In-Reply-To: <1569695295.83.0.838130885601.issue38308@roundup.psfhosted.org>
Message-ID: <1608771212.51.0.0861973691809.issue38308@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I like the addition but I'm not sure why you removed the price-earnings ratio example from the docs. I think that it's useful to have an example that shows that harmonic mean is not *just* for speed-related problems.

I'm not going to reject your change just on this documentation issue, but I would like to hear why you removed the P/E example instead of just adding additional examples.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38308>
_______________________________________

From report at bugs.python.org  Wed Dec 23 20:34:38 2020
From: report at bugs.python.org (Ken Jin)
Date: Thu, 24 Dec 2020 01:34:38 +0000
Subject: [issue42195] Inconsistent __args__ between typing.Callable and
 collections.abc.Callable
In-Reply-To: <1603974319.88.0.166786801787.issue42195@roundup.psfhosted.org>
Message-ID: <1608773678.0.0.140522823413.issue42195@roundup.psfhosted.org>


Change by Ken Jin <kenjin4096 at gmail.com>:


----------
pull_requests: +22766
pull_request: https://github.com/python/cpython/pull/23915

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42195>
_______________________________________

From report at bugs.python.org  Wed Dec 23 21:22:46 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 24 Dec 2020 02:22:46 +0000
Subject: [issue38308] Add optional weighting to statistics.harmonic_mean()
In-Reply-To: <1569695295.83.0.838130885601.issue38308@roundup.psfhosted.org>
Message-ID: <1608776566.61.0.987244134978.issue38308@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> I would like to hear why you removed the P/E example
> instead of just adding additional examples.

I tried out the existing P/E example in my Python courses and found that it had very little explanatory power ? in general, non-finance people know less about P/E ratios than they know about the harmonic mean :-)  

For people with a finance background who do already understand P/E ratios, the example is weak.  The current example only works mathematically if the portfolios are exactly the same market value at the time the ratios are combined ? this never happens.  Also P/E ratios in real portfolios include zero and negative values ? that won't work with our harmonic mean.  Also, combining P/Es for non-homogenous securities is a bit of dark art.  Given a utility stock, a healthcare stock, and a tech stock, the aggregate P/E is rarely comparable to anything else.

All that said, I would be happy to add the example back if you think it is necessary.  It's your module and it's important that you're happy with it :-)

> I think that it's useful to have an example that shows that 
> harmonic mean is not *just* for speed-related problems.

I considered using a resistors in parallel example, but that is somewhat specialized and isn't directly applicable because we normally don't want a mean at all, we just want the equivalent resistance.

I also thought about adding something like: "The harmonic mean is the smaller of the three Pythagorean means and tends to emphasize the impact of small outliers while minimizing the impact of large outliers."  But while this is true, I've never seen a data scientist switch from an arithmetic mean to a harmonic mean to achieve this effect.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38308>
_______________________________________

From report at bugs.python.org  Wed Dec 23 21:39:00 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 24 Dec 2020 02:39:00 +0000
Subject: [issue42721] Using of simple dialogs without default root window
In-Reply-To: <1608669340.97.0.219315442285.issue42721@roundup.psfhosted.org>
Message-ID: <1608777540.27.0.574880805577.issue42721@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The does not affect IDLE, as the two ask... calls pass parent.  (And I may someday replace them with query.Query subclasses.)  But I do prefer that tkinter act consistently and sensibly for others.  The PR's initial commit message adds this justification for the particular behavior: "It will help to use these simple dialog windows in programs which do
not need other GUI."  I agree with this goal.

Contrary to the message above, temporary root is set as _default_root and the latter is then set back to None.  Consequently, there can be no temporary if _default_root cannot be set.  Changing this would be messy enough that I think it reasonable to presume and require that people not otherwise needing a GUI will not call no_default_root, or learn to call Tk() if using an installation with patched tkinter.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42721>
_______________________________________

From report at bugs.python.org  Wed Dec 23 21:42:46 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 24 Dec 2020 02:42:46 +0000
Subject: [issue38308] Add optional weighting to statistics.harmonic_mean()
In-Reply-To: <1608776566.61.0.987244134978.issue38308@roundup.psfhosted.org>
Message-ID: <20201224024238.GI28254@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Okay, I'm satisfied with that reasoning, thanks Raymond.

Patch looks good to me. Go for it!

Have a good Christmas and stay safe.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38308>
_______________________________________

From report at bugs.python.org  Wed Dec 23 21:47:48 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 24 Dec 2020 02:47:48 +0000
Subject: [issue42195] Inconsistent __args__ between typing.Callable and
 collections.abc.Callable
In-Reply-To: <1603974319.88.0.166786801787.issue42195@roundup.psfhosted.org>
Message-ID: <1608778068.07.0.1392574387.issue42195@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 6dd3da3cf4a0d6cb62d9c2a155434c127183454d by kj in branch 'master':
bpo-42195: Override _CallableGenericAlias's __getitem__ (GH-23915)
https://github.com/python/cpython/commit/6dd3da3cf4a0d6cb62d9c2a155434c127183454d


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42195>
_______________________________________

From report at bugs.python.org  Wed Dec 23 21:48:06 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 24 Dec 2020 02:48:06 +0000
Subject: [issue42195] Inconsistent __args__ between typing.Callable and
 collections.abc.Callable
In-Reply-To: <1603974319.88.0.166786801787.issue42195@roundup.psfhosted.org>
Message-ID: <1608778086.95.0.281619746706.issue42195@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22767
pull_request: https://github.com/python/cpython/pull/23916

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42195>
_______________________________________

From report at bugs.python.org  Wed Dec 23 22:07:54 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 24 Dec 2020 03:07:54 +0000
Subject: [issue42195] Inconsistent __args__ between typing.Callable and
 collections.abc.Callable
In-Reply-To: <1603974319.88.0.166786801787.issue42195@roundup.psfhosted.org>
Message-ID: <1608779274.51.0.441518341365.issue42195@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset a1251980d20ee8aab8d887fc0d30a726247327af by Miss Islington (bot) in branch '3.9':
bpo-42195: Override _CallableGenericAlias's __getitem__ (GH-23915)
https://github.com/python/cpython/commit/a1251980d20ee8aab8d887fc0d30a726247327af


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42195>
_______________________________________

From report at bugs.python.org  Wed Dec 23 22:31:47 2020
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 24 Dec 2020 03:31:47 +0000
Subject: [issue35815] Able to instantiate a subclass with abstract methods
 from __init_subclass__ of the ABC
In-Reply-To: <1548316625.2.0.852101004839.issue35815@roundup.psfhosted.org>
Message-ID: <1608780707.39.0.439619381978.issue35815@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35815>
_______________________________________

From report at bugs.python.org  Wed Dec 23 22:41:22 2020
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 24 Dec 2020 03:41:22 +0000
Subject: [issue42727] [Enum] EnumMeta.__prepare__ needs to accept **kwds
Message-ID: <1608781282.89.0.997821175942.issue42727@roundup.psfhosted.org>


New submission from Ethan Furman <ethan at stoneleaf.us>:

**kwds are necessary to support __init_subclass__, but __prepare__ currently does not accept them.

----------
assignee: ethan.furman
messages: 383670
nosy: ethan.furman
priority: normal
severity: normal
status: open
title: [Enum] EnumMeta.__prepare__ needs to accept **kwds
type: behavior
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42727>
_______________________________________

From report at bugs.python.org  Wed Dec 23 22:45:35 2020
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 24 Dec 2020 03:45:35 +0000
Subject: [issue42727] [Enum] EnumMeta.__prepare__ needs to accept **kwds
In-Reply-To: <1608781282.89.0.997821175942.issue42727@roundup.psfhosted.org>
Message-ID: <1608781535.9.0.403830277753.issue42727@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
keywords: +patch
pull_requests: +22768
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23917

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42727>
_______________________________________

From report at bugs.python.org  Wed Dec 23 22:52:22 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 24 Dec 2020 03:52:22 +0000
Subject: [issue38308] Add optional weighting to statistics.harmonic_mean()
In-Reply-To: <1569695295.83.0.838130885601.issue38308@roundup.psfhosted.org>
Message-ID: <1608781942.15.0.0724582021914.issue38308@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset cc3467a57b61b0e7ef254b36790a1c44b13f2228 by Raymond Hettinger in branch 'master':
bpo-38308: Add optional weighting to statistics.harmonic_mean() (GH-23914)
https://github.com/python/cpython/commit/cc3467a57b61b0e7ef254b36790a1c44b13f2228


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38308>
_______________________________________

From report at bugs.python.org  Wed Dec 23 22:53:17 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 24 Dec 2020 03:53:17 +0000
Subject: [issue38308] Add optional weighting to statistics.harmonic_mean()
In-Reply-To: <1569695295.83.0.838130885601.issue38308@roundup.psfhosted.org>
Message-ID: <1608781997.41.0.314942654639.issue38308@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thank you and Merry Christmas.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38308>
_______________________________________

From report at bugs.python.org  Wed Dec 23 22:54:39 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 24 Dec 2020 03:54:39 +0000
Subject: [issue42685] Improve placing of simple query windows.
In-Reply-To: <1608391787.71.0.662938082611.issue42685@roundup.psfhosted.org>
Message-ID: <1608782079.83.0.377251808918.issue42685@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I took a look at the somewhat messy popup placement in IDLE.  The query.Query subclasses are centered over their parent.  Some others are over the window but up and to the left.  Maybe they have a custom geometry setting that I should delete.  Search and replace dialogs are at the upper left of the screen.  Bad if window is at the right edge.  Editor SyntaxError boxes, with no placement specified, are centered on the screen.  Centered on the text frame would be much better (as long as it did not cover the error).  Same would be true of most anything else currently centered.

> * If parent is specified and mapped, the query widget is centered at the center of parent.

I am not sure what 'mapped' means.  With patch, SyntaxError continues to  be centered on screen even with editor visible and focused.  Will say more on the PR.

> Its position and size can be corrected so that it fits in the virtual root window.
I don't understand this.  Will check the code.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42685>
_______________________________________

From report at bugs.python.org  Wed Dec 23 23:33:56 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 24 Dec 2020 04:33:56 +0000
Subject: [issue41559] Add support for PEP 612 (Parameter Specification
 Variables) to typing.py
In-Reply-To: <1597516564.62.0.520187732663.issue41559@roundup.psfhosted.org>
Message-ID: <1608784436.5.0.260648857911.issue41559@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset 73607be68668ab7f4bee53507c8dc7b5a46c9cb4 by kj in branch 'master':
bpo-41559: Implement PEP 612 - Add ParamSpec and Concatenate to typing (#23702)
https://github.com/python/cpython/commit/73607be68668ab7f4bee53507c8dc7b5a46c9cb4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41559>
_______________________________________

From report at bugs.python.org  Wed Dec 23 23:39:01 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 24 Dec 2020 04:39:01 +0000
Subject: [issue41559] Add support for PEP 612 (Parameter Specification
 Variables) to typing.py
In-Reply-To: <1597516564.62.0.520187732663.issue41559@roundup.psfhosted.org>
Message-ID: <1608784741.97.0.182789300552.issue41559@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Huge thanks!

I think the next step is to port the essence to typing_extensions, which has to work for anything from 3.5 up (or maybe 3.6), *including* 3.10 and above.

https://github.com/python/typing/tree/master/typing_extensions

Honestly maybe we could just make ParamSpec an alias for TypeVar there, and make Concatenate an alias for Tuple?  Because "work" just means that the syntax needs to be valid, the type checkers are responsible for using it. (We're still working on getting this to work for mypy.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41559>
_______________________________________

From report at bugs.python.org  Wed Dec 23 23:46:19 2020
From: report at bugs.python.org (Ken Jin)
Date: Thu, 24 Dec 2020 04:46:19 +0000
Subject: [issue41559] Add support for PEP 612 (Parameter Specification
 Variables) to typing.py
In-Reply-To: <1597516564.62.0.520187732663.issue41559@roundup.psfhosted.org>
Message-ID: <1608785179.17.0.679557865114.issue41559@roundup.psfhosted.org>


Ken Jin <kenjin4096 at gmail.com> added the comment:

Thanks for the extremely helpful reviews and help in this Guido!

Sure, I'll probably start work on that next week, slightly busy with life right now. After that I'll work on docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41559>
_______________________________________

From report at bugs.python.org  Thu Dec 24 00:30:08 2020
From: report at bugs.python.org (Eric Snow)
Date: Thu, 24 Dec 2020 05:30:08 +0000
Subject: [issue36876] [subinterpreters] Global C variables are a problem
In-Reply-To: <1557514902.13.0.853517754348.issue36876@roundup.psfhosted.org>
Message-ID: <1608787808.41.0.459389213936.issue36876@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
pull_requests: +22769
pull_request: https://github.com/python/cpython/pull/23918

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36876>
_______________________________________

From report at bugs.python.org  Thu Dec 24 01:43:41 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 24 Dec 2020 06:43:41 +0000
Subject: [issue38308] Add optional weighting to statistics.harmonic_mean()
In-Reply-To: <1569695295.83.0.838130885601.issue38308@roundup.psfhosted.org>
Message-ID: <1608792221.54.0.351937918415.issue38308@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
nosy: +ZackerySpytz
nosy_count: 4.0 -> 5.0
pull_requests: +22770
pull_request: https://github.com/python/cpython/pull/23919

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38308>
_______________________________________

From report at bugs.python.org  Thu Dec 24 02:11:59 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 24 Dec 2020 07:11:59 +0000
Subject: [issue38308] Add optional weighting to statistics.harmonic_mean()
In-Reply-To: <1569695295.83.0.838130885601.issue38308@roundup.psfhosted.org>
Message-ID: <1608793919.77.0.632556342139.issue38308@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

The "versionchanged" for *weights* should be 3.10, not 3.8.  I've created PR 23919 to fix this.

----------
versions: +Python 3.10 -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38308>
_______________________________________

From report at bugs.python.org  Thu Dec 24 02:24:53 2020
From: report at bugs.python.org (Tao He)
Date: Thu, 24 Dec 2020 07:24:53 +0000
Subject: [issue42728] Typo in documentation: importlib.metadata
Message-ID: <1608794693.94.0.363783921808.issue42728@roundup.psfhosted.org>


New submission from Tao He <sighingnow at gmail.com>:

There's a typo in importlib.metadata.rst:

In section: 

https://docs.python.org/3/library/importlib.metadata.html#distributions

----------
messages: 383678
nosy: sighingnow
priority: normal
severity: normal
status: open
title: Typo in documentation: importlib.metadata
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42728>
_______________________________________

From report at bugs.python.org  Thu Dec 24 02:26:16 2020
From: report at bugs.python.org (Peixing Xin)
Date: Thu, 24 Dec 2020 07:26:16 +0000
Subject: [issue31904] Python should support VxWorks RTOS
In-Reply-To: <1509393393.78.0.213398074469.issue31904@psf.upfronthosting.co.za>
Message-ID: <1608794776.24.0.935345845147.issue31904@roundup.psfhosted.org>


Change by Peixing Xin <peixing.xin at windriver.com>:


----------
pull_requests: +22771
pull_request: https://github.com/python/cpython/pull/23920

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue31904>
_______________________________________

From report at bugs.python.org  Thu Dec 24 02:28:49 2020
From: report at bugs.python.org (Tao He)
Date: Thu, 24 Dec 2020 07:28:49 +0000
Subject: [issue42728] Typo in documentation: importlib.metadata
In-Reply-To: <1608794693.94.0.363783921808.issue42728@roundup.psfhosted.org>
Message-ID: <1608794929.76.0.264350060227.issue42728@roundup.psfhosted.org>


Change by Tao He <sighingnow at gmail.com>:


----------
keywords: +patch
pull_requests: +22772
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23921

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42728>
_______________________________________

From report at bugs.python.org  Thu Dec 24 04:18:46 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 24 Dec 2020 09:18:46 +0000
Subject: [issue42222] Modernize integer test/conversion in randrange()
In-Reply-To: <1604165232.15.0.0916383458838.issue42222@roundup.psfhosted.org>
Message-ID: <1608801526.97.0.718523312234.issue42222@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/issue42222>
_______________________________________

From report at bugs.python.org  Thu Dec 24 05:12:16 2020
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Blondon?=)
Date: Thu, 24 Dec 2020 10:12:16 +0000
Subject: [issue37779] configparser: add documentation about several read()
 behaviour
In-Reply-To: <1565122960.66.0.217084239893.issue37779@roundup.psfhosted.org>
Message-ID: <1608804736.23.0.680946227204.issue37779@roundup.psfhosted.org>


St?phane Blondon <stephane.blondon at gmail.com> added the comment:

Merged by ?ukasz Langa in september 2020.
(Thanks ?ukasz)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37779>
_______________________________________

From report at bugs.python.org  Thu Dec 24 05:19:56 2020
From: report at bugs.python.org (Paul Sokolovsky)
Date: Thu, 24 Dec 2020 10:19:56 +0000
Subject: [issue42729] tokenize, ast: No direct way to parse tokens into AST,
 a gap in the language processing pipiline
Message-ID: <1608805195.98.0.835213865075.issue42729@roundup.psfhosted.org>


New submission from Paul Sokolovsky <pfalcon at users.sourceforge.net>:

Currently, it's possible:

* To get from stream-of-characters program representation to AST representation (AST.parse()).
* To get from AST to code object (compile()).
* To get from a code object to first-class function to the execute the program.

Python also offers "tokenize" module, but it stands as a disconnected island: the only things it allows to do is to get from stream-of-characters program representation to stream-of-tokens, and back. At the same time, conceptually, tokenization is not a disconnected feature, it's the first stage of language processing pipeline. The fact that "tokenize" is disconnected from the rest of the pipeline, as listed above, is more an artifact of CPython implementation: both "ast" module and compile() module are backed by the underlying bytecode compiler implementation written in C, and that's what connects them.

On the other hand, "tokenize" module is pure-Python, while the underlying compiler has its own tokenizer implementation (not exposed). That's the likely reason of such disconnection between "tokenize" and the rest of the infrastructure.

I propose to close that gap, and establish an API which would allow to parse token stream (iterable) into an AST. An initial implementation for CPython can (and likely should) be naive, making a loop thru surface program representation. That's ok, again, the idea is to establish a standard API to be able to go tokens -> AST, then individual Python implementation can make/optimize it based on their needs.

The proposed name is ast.parse_tokens(). It follows the signature of the existing ast.parse(), except that first parameter is "token_stream" instead of "source".

Another alternative would be to overload existing ast.parse() to accept token iterable. I guess, at the current stage, where we try to tighten up type strictness of API, and have clear typing signatures for API functions, this is not favored solution.

----------
components: Library (Lib)
messages: 383680
nosy: BTaskaya, pablogsal, pfalcon, serhiy.storchaka
priority: normal
severity: normal
status: open
title: tokenize, ast: No direct way to parse tokens into AST, a gap in the language processing pipiline
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42729>
_______________________________________

From report at bugs.python.org  Thu Dec 24 05:26:19 2020
From: report at bugs.python.org (Paul Sokolovsky)
Date: Thu, 24 Dec 2020 10:26:19 +0000
Subject: [issue42729] tokenize, ast: No direct way to parse tokens into AST,
 a gap in the language processing pipiline
In-Reply-To: <1608805195.98.0.835213865075.issue42729@roundup.psfhosted.org>
Message-ID: <1608805579.3.0.963337371483.issue42729@roundup.psfhosted.org>


Change by Paul Sokolovsky <pfalcon at users.sourceforge.net>:


----------
keywords: +patch
pull_requests: +22773
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23922

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42729>
_______________________________________

From report at bugs.python.org  Thu Dec 24 05:34:15 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 24 Dec 2020 10:34:15 +0000
Subject: [issue42729] tokenize, ast: No direct way to parse tokens into AST,
 a gap in the language processing pipiline
In-Reply-To: <1608805195.98.0.835213865075.issue42729@roundup.psfhosted.org>
Message-ID: <1608806055.68.0.139746238425.issue42729@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

> I propose to close that gap, and establish an API which would allow to parse token stream (iterable) into an AST. An initial implementation for CPython can (and likely should) be naive, making a loop thru surface program representation. 

There is different aspects of this problem (like maintenance cost of either exposing the underlying tokenizer, or building something like Python-ast.c to convert these 2 different token types back and forth which I'm big -1 on both of them.) but the thing I don't quite get is the use case. 

What prevents you from using ast.parse(tokenize.untokenize(token_stream))? It is guaranteed that you won't miss anything (in terms of the position of tokens) (since it almost roundtrips every case). 

Also, tokens -> AST is not the only disconnected part in the underlying compiler. Stuff like AST -> Symbol Table / AST -> Optimized AST etc. is also not available, and apparently not needed (since nobody else, maybe except me [about the AST -> ST conversion], complained about these being missing). 

I'd also suggest moving the discussion to the Python-ideas, for a much greater audience.

----------
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42729>
_______________________________________

From report at bugs.python.org  Thu Dec 24 05:54:42 2020
From: report at bugs.python.org (Paul Sokolovsky)
Date: Thu, 24 Dec 2020 10:54:42 +0000
Subject: [issue42729] tokenize, ast: No direct way to parse tokens into AST,
 a gap in the language processing pipiline
In-Reply-To: <1608805195.98.0.835213865075.issue42729@roundup.psfhosted.org>
Message-ID: <1608807282.91.0.352567736524.issue42729@roundup.psfhosted.org>


Paul Sokolovsky <pfalcon at users.sourceforge.net> added the comment:

> What prevents you from using ast.parse(tokenize.untokenize(token_stream))?

That's exactly the implementation in the patch now submitted against this issue. But that's the patch for CPython, the motive of the proposal here is to establish a standard API call for *Python*, which different implementation can implement how they like/can/need.

> Also, tokens -> AST is not the only disconnected part in the underlying compiler.

We should address them, one by one.

> Stuff like AST -> Symbol Table 

Kinda yes, again, based on CPython implementation history, we have only source -> Symbol table (https://docs.python.org/3/library/symtable.html). Would be nice to address that (separately of course).

> AST -> Optimized AST

Yes. PEP511 touched on that, but as it-as-a-whole was rejected, any useful sub-ideas from it don't seem to get further progress either (like, being able to disable some optimizations, and then maybe even exposing them as standalone passes).

> I'd also suggest moving the discussion to the Python-ideas, for a much greater audience.

That's how I usually do, but I posted too much there recently. I wanted to submit a patch right away, but noticed that standard commit message format is "bpo-XXXXX: ...", so I created a ticket here to reference in the commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42729>
_______________________________________

From report at bugs.python.org  Thu Dec 24 06:02:36 2020
From: report at bugs.python.org (Paul Sokolovsky)
Date: Thu, 24 Dec 2020 11:02:36 +0000
Subject: [issue42729] tokenize, ast: No direct way to parse tokens into AST,
 a gap in the language processing pipiline
In-Reply-To: <1608805195.98.0.835213865075.issue42729@roundup.psfhosted.org>
Message-ID: <1608807756.76.0.0510951810049.issue42729@roundup.psfhosted.org>


Paul Sokolovsky <pfalcon at users.sourceforge.net> added the comment:

> but the thing I don't quite get is the use case.

And if that went unanswered: the usecase, how I'd formulate it, is to not expose CPython historical implementation detail of "tokenize" being disconnected from the rest of the language processing infrastructure, and make them learn tricks like needing to go back to character program form if they ever start to use "tokenize", but let it all integrate well into single processing pipeline.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42729>
_______________________________________

From report at bugs.python.org  Thu Dec 24 06:05:30 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 24 Dec 2020 11:05:30 +0000
Subject: [issue42729] tokenize, ast: No direct way to parse tokens into AST,
 a gap in the language processing pipiline
In-Reply-To: <1608805195.98.0.835213865075.issue42729@roundup.psfhosted.org>
Message-ID: <1608807930.95.0.543244819028.issue42729@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

> That's exactly the implementation in the patch now submitted against this issue. But that's the patch for CPython, the motive of the proposal here is to establish a standard API call for *Python*, which different implementation can implement how they like/can/need.

I don't feel great about it, but if you are final motive is to address this issue for other implementations (like pycopy?), I still think that Python-ideas is the best place to discuss it rather than the bugtracker of CPython.

> We should address them, one by one.

I am not sure about that, IIRC @pablogsal and I talked these about a year ago and decided that there won't be any clear benefit (since nobody come with a need to it) and there will the downside of sometimes limiting ourselves for being backward-compatible for an API that ~almost no one will use.

> That's how I usually do, but I posted too much there recently. I wanted to submit a patch right away, but noticed that standard commit message format is "bpo-XXXXX: ...", so I created a ticket here to reference in the commit.

What people does in this cases is, they push to their branches with a random commit message (Implement blabla) and then share the link to the branch on their post in the Python-ideas.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42729>
_______________________________________

From report at bugs.python.org  Thu Dec 24 07:30:20 2020
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Blondon?=)
Date: Thu, 24 Dec 2020 12:30:20 +0000
Subject: [issue42643] http.server does not support HTTP range requests
In-Reply-To: <1607999046.16.0.658504644018.issue42643@roundup.psfhosted.org>
Message-ID: <1608813020.95.0.0649729726949.issue42643@roundup.psfhosted.org>


St?phane Blondon <stephane.blondon at gmail.com> added the comment:

RangeHTTPServer seems to support python3: there is a try-except clause to manage the different import of SimpleHTTPServer:
https://github.com/danvk/RangeHTTPServer/blob/master/RangeHTTPServer/__main__.py#L13

The code is under Apache 2.0 licence. I don't know if it can be integrated in codebase under the PSF licence.

Another question needs to be answered previously: does the maintainers want to add such feature to SimpleHTTPServer (which goal is to be very basic)? They could prefer to add a header refusing the Range header:
Accept-Ranges: none

https://tools.ietf.org/id/draft-ietf-httpbis-p5-range-09.html#header.accept-ranges

----------
nosy: +sblondon

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42643>
_______________________________________

From report at bugs.python.org  Thu Dec 24 07:44:42 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Thu, 24 Dec 2020 12:44:42 +0000
Subject: [issue42725] PEP 563: Should the behavior change for yield/yield
 from's
In-Reply-To: <1608730131.08.0.595189962302.issue42725@roundup.psfhosted.org>
Message-ID: <1608813882.73.0.155436787333.issue42725@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

I concur with Guido. I feel that making this an error is the best alternative we have.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42725>
_______________________________________

From report at bugs.python.org  Thu Dec 24 07:50:56 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Thu, 24 Dec 2020 12:50:56 +0000
Subject: [issue42729] tokenize, ast: No direct way to parse tokens into AST,
 a gap in the language processing pipiline
In-Reply-To: <1608805195.98.0.835213865075.issue42729@roundup.psfhosted.org>
Message-ID: <1608814256.45.0.0541593846694.issue42729@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

The thing is that the parser itself does not get a stream of tokens as input. It only accepts either a file or a string and it lazily converts its input to tokens.

As for the PR attached to this patch, I'm -1 on that. I don't think the usecase is common enough for us to have another public function, that we need to maintain and keep backwards-compatible. I concur with Batuhan that if people need this, they can use ast.parse with tokenize.untokenize.

----------
nosy: +lys.nikolaou

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42729>
_______________________________________

From report at bugs.python.org  Thu Dec 24 08:14:59 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 24 Dec 2020 13:14:59 +0000
Subject: [issue42729] tokenize, ast: No direct way to parse tokens into AST,
 a gap in the language processing pipiline
In-Reply-To: <1608805195.98.0.835213865075.issue42729@roundup.psfhosted.org>
Message-ID: <1608815699.4.0.477576677928.issue42729@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I am with Lysandros and Batuhan. The parser is considerably coupled with the C tokenizer and the only way to reuse *the parser* is to make flexible enough to receive a token stream of Python objects as input and that can not only have a performance impact on normal parsing but also raises the complexity of this task considerably, especially taking into account that the use case is quite restricted and is something that you can already achieve by transforming the token stream into text and using ast.parse.

There is a considerable tension on exposed parts of the compiler pipeline for introspection and other capabilities and our ability to do optimizations. Given how painful it has been in the past to deal with this, my view is to avoid exposing as much as possible anything in the compiler pipeline, so we don't shoot ourselves in the foot in the future if we need to change stuff around.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42729>
_______________________________________

From report at bugs.python.org  Thu Dec 24 08:30:34 2020
From: report at bugs.python.org (Paul Sokolovsky)
Date: Thu, 24 Dec 2020 13:30:34 +0000
Subject: [issue42729] tokenize, ast: No direct way to parse tokens into AST,
 a gap in the language processing pipiline
In-Reply-To: <1608805195.98.0.835213865075.issue42729@roundup.psfhosted.org>
Message-ID: <1608816634.37.0.266647739513.issue42729@roundup.psfhosted.org>


Paul Sokolovsky <pfalcon at users.sourceforge.net> added the comment:

> There is a considerable tension on exposed parts of the compiler pipeline for introspection and other capabilities and our ability to do optimizations. Given how painful it has been in the past to deal with this, my view is to avoid exposing as much as possible anything in the compiler pipeline, so we don't shoot ourselves in the foot in the future if we need to change stuff around.

That's somewhat extreme outcome when a problem is known and understood, but the best solution is deemed not doing anything.

But the problem of "doing it wrong" definitely known and exists. One known way to address it is to design generic interfaces and implement them. This ticket is exactly about that - defining a missing interface for a parser in Python. It's not about *the* CPython's C parser and its peculiarities. (But even it fits with the generic interface proposed.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42729>
_______________________________________

From report at bugs.python.org  Thu Dec 24 08:36:38 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 24 Dec 2020 13:36:38 +0000
Subject: [issue42729] tokenize, ast: No direct way to parse tokens into AST,
 a gap in the language processing pipiline
In-Reply-To: <1608805195.98.0.835213865075.issue42729@roundup.psfhosted.org>
Message-ID: <1608816998.43.0.823784503987.issue42729@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I concur with other core developers. Seems there is no real need for this feature and the idea was proposed purely to "close a gap". Taking into account significant cost of implementing and maintaining this feature, I think that it should not be added.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42729>
_______________________________________

From report at bugs.python.org  Thu Dec 24 08:55:12 2020
From: report at bugs.python.org (Paul Sokolovsky)
Date: Thu, 24 Dec 2020 13:55:12 +0000
Subject: [issue42729] tokenize, ast: No direct way to parse tokens into AST,
 a gap in the language processing pipiline
In-Reply-To: <1608805195.98.0.835213865075.issue42729@roundup.psfhosted.org>
Message-ID: <1608818112.27.0.262376205926.issue42729@roundup.psfhosted.org>


Paul Sokolovsky <pfalcon at users.sourceforge.net> added the comment:

> the idea was proposed purely to "close a gap"

That pinpoints it well. I was just writing a tutorial on implementing custom import hooks, with the idea to show people how easy it to do it in Python. As first step, I explained that it's bad idea to do any transformations on surface representation of a program. At the very least, it should be converted to token stream. But then I found that I need to explain that we need to convert it back, which sounds pretty weird and undermines the idea:

    def xform(token_stream):
        for t in token_stream:
            if t[0] == tokenize.NAME and t[1] == "function":
                yield (tokenize.NAME, "lambda") + t[2:]
            else:
                yield t

    with open(filename, "rb") as f:
        # Fairly speaking, tokenizing just to convert back to string form
        # isn't too efficient, but CPython doesn't offer us a way to parse
        # token stream so far, so we have no choice.
        source = tokenize.untokenize(xform(tokenize.tokenize(f.readline)))
    mod = type(imphook)("")
    exec(source, vars(mod))
    return mod

Having written that comment, I thought I could as well just make one more step and monkey-patch "ast" for parse_tokens() function - I'll need to explain that, but the explanation probably wouldn't sound worse than the explanation above. And then it was just one more step to actually submit patch for ast.parse_tokens(), and that's how this ticket was created!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42729>
_______________________________________

From report at bugs.python.org  Thu Dec 24 08:56:52 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 24 Dec 2020 13:56:52 +0000
Subject: [issue42729] tokenize, ast: No direct way to parse tokens into AST,
 a gap in the language processing pipiline
In-Reply-To: <1608805195.98.0.835213865075.issue42729@roundup.psfhosted.org>
Message-ID: <1608818212.39.0.53107861825.issue42729@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

Thank you for your patch though!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42729>
_______________________________________

From report at bugs.python.org  Thu Dec 24 11:59:15 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 24 Dec 2020 16:59:15 +0000
Subject: [issue42725] PEP 563: Should the behavior change for yield/yield
 from's
In-Reply-To: <1608730131.08.0.595189962302.issue42725@roundup.psfhosted.org>
Message-ID: <1608829155.69.0.24334630938.issue42725@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Okay, let's do it. It should probably a post-parse check (before we invoke the bytecode compiler but after we have the AST in hand).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42725>
_______________________________________

From report at bugs.python.org  Thu Dec 24 12:16:12 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 24 Dec 2020 17:16:12 +0000
Subject: [issue42726] gdb/libpython.py InstanceProxy does not work with py3
In-Reply-To: <1608748218.63.0.956794347013.issue42726@roundup.psfhosted.org>
Message-ID: <1608830172.66.0.434595945095.issue42726@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset b57ada98da0d5b0cf1ebc2c9c5502d04aa962042 by Augusto Hack in branch 'master':
closes bpo-42726: gdb libpython: InstanceProxy support for py3 (GH-23912)
https://github.com/python/cpython/commit/b57ada98da0d5b0cf1ebc2c9c5502d04aa962042


----------
nosy: +miss-islington
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42726>
_______________________________________

From report at bugs.python.org  Thu Dec 24 12:16:19 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 24 Dec 2020 17:16:19 +0000
Subject: [issue42726] gdb/libpython.py InstanceProxy does not work with py3
In-Reply-To: <1608748218.63.0.956794347013.issue42726@roundup.psfhosted.org>
Message-ID: <1608830179.97.0.204417792595.issue42726@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22775
pull_request: https://github.com/python/cpython/pull/23924

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42726>
_______________________________________

From report at bugs.python.org  Thu Dec 24 12:16:27 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 24 Dec 2020 17:16:27 +0000
Subject: [issue42726] gdb/libpython.py InstanceProxy does not work with py3
In-Reply-To: <1608748218.63.0.956794347013.issue42726@roundup.psfhosted.org>
Message-ID: <1608830187.3.0.106053361318.issue42726@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22776
pull_request: https://github.com/python/cpython/pull/23925

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42726>
_______________________________________

From report at bugs.python.org  Thu Dec 24 12:29:09 2020
From: report at bugs.python.org (Abdulrahman Alabdulkareem)
Date: Thu, 24 Dec 2020 17:29:09 +0000
Subject: [issue42730] TypeError in Time.Sleep when invoked from shell script
 background
Message-ID: <1608830949.51.0.513581784179.issue42730@roundup.psfhosted.org>


New submission from Abdulrahman Alabdulkareem <master3243 at gmail.com>:

I get a random TypeError exception thrown whenever I interrupt/kill a sleeping parent thread from a child thread but ONLY if the python script was invoked by a shell script with an & argument to make it run in the background. (this is in vanilla python)

This doesn't happen if invoked 

(1) in command line
(2) in command line with &
(3) in shell script (without &)

Only in shell script with &.

Here is the python script named psc.py https://pastebin.com/raw/KZQptCMr
And here is the shell script named ssc.sh https://pastebin.com/raw/QQzs4Tpz that when ran will run the python script and cause the strange behaviour

Here is the output I'm seeing: -------------------
parent looping
child interrupting parent
why would I ever catch a TypeError?
Traceback (most recent call last):
  File "m.py", line 17, in <module>
    time.sleep(1)
TypeError: 'int' object is not callable

Here is the output I'm expecting: --------------------
parent looping
child interrupting parent
caught interruption raised from user or child thread :)

Another unexpected behaviour might be that python suddenly hangs.

Here is a stackoverflow question raised on this issue with discussion in the comments https://stackoverflow.com/questions/65440353/python-time-sleep1-raises-typeerror?noredirect=1#comment115697237_65440353

----------
messages: 383695
nosy: master3243
priority: normal
severity: normal
status: open
title: TypeError in Time.Sleep when invoked from shell script background
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42730>
_______________________________________

From report at bugs.python.org  Thu Dec 24 12:34:36 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 24 Dec 2020 17:34:36 +0000
Subject: [issue42726] gdb/libpython.py InstanceProxy does not work with py3
In-Reply-To: <1608748218.63.0.956794347013.issue42726@roundup.psfhosted.org>
Message-ID: <1608831276.37.0.582877889072.issue42726@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset efd64c8ea0fed1c13839cec0feea450820da34f8 by Miss Islington (bot) in branch '3.8':
closes bpo-42726: gdb libpython: InstanceProxy support for py3 (GH-23912)
https://github.com/python/cpython/commit/efd64c8ea0fed1c13839cec0feea450820da34f8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42726>
_______________________________________

From report at bugs.python.org  Thu Dec 24 12:37:10 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 24 Dec 2020 17:37:10 +0000
Subject: [issue42726] gdb/libpython.py InstanceProxy does not work with py3
In-Reply-To: <1608748218.63.0.956794347013.issue42726@roundup.psfhosted.org>
Message-ID: <1608831430.86.0.55805900213.issue42726@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3bb85672bb894403a787a9c5afc0ca5987d28fe0 by Miss Islington (bot) in branch '3.9':
closes bpo-42726: gdb libpython: InstanceProxy support for py3 (GH-23912)
https://github.com/python/cpython/commit/3bb85672bb894403a787a9c5afc0ca5987d28fe0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42726>
_______________________________________

From report at bugs.python.org  Thu Dec 24 13:04:44 2020
From: report at bugs.python.org (Eric Snow)
Date: Thu, 24 Dec 2020 18:04:44 +0000
Subject: [issue36876] [subinterpreters] Global C variables are a problem
In-Reply-To: <1557514902.13.0.853517754348.issue36876@roundup.psfhosted.org>
Message-ID: <1608833084.66.0.447833662446.issue36876@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:


New changeset 7ec59d8861ef1104c3028678b2cacde4c5693e19 by Eric Snow in branch 'master':
bpo-36876: [c-analyzer tool] Add a "capi" subcommand to the c-analyzer tool. (gh-23918)
https://github.com/python/cpython/commit/7ec59d8861ef1104c3028678b2cacde4c5693e19


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36876>
_______________________________________

From report at bugs.python.org  Thu Dec 24 13:21:08 2020
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 24 Dec 2020 18:21:08 +0000
Subject: [issue42727] [Enum] EnumMeta.__prepare__ needs to accept **kwds
In-Reply-To: <1608781282.89.0.997821175942.issue42727@roundup.psfhosted.org>
Message-ID: <1608834068.74.0.504645334944.issue42727@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
pull_requests: +22777
pull_request: https://github.com/python/cpython/pull/23926

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42727>
_______________________________________

From report at bugs.python.org  Thu Dec 24 13:26:37 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 24 Dec 2020 18:26:37 +0000
Subject: [issue42685] Improve placing of simple query windows.
In-Reply-To: <1608391787.71.0.662938082611.issue42685@roundup.psfhosted.org>
Message-ID: <1608834397.0.0.868163631071.issue42685@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset c6c43b28746b0642cc3c49dd8138b896bed3028f by Serhiy Storchaka in branch 'master':
bpo-42685: Improve placing of simple query windows. (GH-23856)
https://github.com/python/cpython/commit/c6c43b28746b0642cc3c49dd8138b896bed3028f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42685>
_______________________________________

From report at bugs.python.org  Thu Dec 24 14:06:22 2020
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 24 Dec 2020 19:06:22 +0000
Subject: [issue35815] Able to instantiate a subclass with abstract methods
 from __init_subclass__ of the ABC
In-Reply-To: <1548316625.2.0.852101004839.issue35815@roundup.psfhosted.org>
Message-ID: <1608836782.72.0.723426921753.issue35815@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

I tried update `abc.py` with the same dance I have to use with `Enum`:

    def __new__(mcls, name, bases, namespace, **kwargs):
        # remove current __init_subclass__ so previous one can be found with getattr
        try:
            new_init_subclass = namespace.get('__init_subclass__')
            del namespace['__init_subclass__']
        except KeyError:
            pass
        # create our new ABC type
        if bases:
            bases = (_NoInitSubclass, ) + bases
            abc_cls = super().__new__(mcls, name, bases, namespace, **kwargs)
            abc_cls.__bases__ = abc_cls.__bases__[1:]
        else:
            abc_cls = super().__new__(mcls, name, bases, namespace, **kwargs)
        old_init_subclass = getattr(abc_cls, '__init_subclass__', None)
        # restore new __init_subclass__ (if there was one)
        if new_init_subclass is not None:
            abc_cls.__init_subclass__ = classmethod(new_init_subclass)
        _abc_init(abc_cls)
        # call parents' __init_subclass__
        if old_init_subclass is not None:
            old_init_subclass(**kwargs)
        return abc_cls

But I get this error:

Fatal Python error: init_import_site: Failed to import the site module
Python runtime state: initialized
Traceback (most recent call last):
  File "/home/ethan/source/python/cpython/Lib/site.py", line 73, in <module>
    import os
  File "/home/ethan/source/python/cpython/Lib/os.py", line 29, in <module>
    from _collections_abc import _check_methods
  File "/home/ethan/source/python/cpython/Lib/_collections_abc.py", line 122, in <module>
    class Coroutine(Awaitable):
  File "/home/ethan/source/python/cpython/Lib/abc.py", line 103, in __new__
    abc_cls.__bases__ = abc_cls.__bases__[1:]
TypeError: __bases__ assignment: 'Awaitable' object layout differs from '_NoInitSubclass'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35815>
_______________________________________

From report at bugs.python.org  Thu Dec 24 14:13:42 2020
From: report at bugs.python.org (Karl Nelson)
Date: Thu, 24 Dec 2020 19:13:42 +0000
Subject: [issue42731] Enhancement request for proxying PyString
Message-ID: <1608837222.47.0.436477012182.issue42731@roundup.psfhosted.org>


New submission from Karl Nelson <nelson85 at llnl.gov>:

When developing with JPype, the largest hole currently is that Java returns a string type which cannot be represented as a str.  Java strings are string like and immutable and can be pulled to Python when needed, but it is best if they remain in Java until Python requests it as pulling all string values through the API and pushing them back can result in serious overhead.  Thus they need to be represented as a Proxy to a string, which can be accessed as a string at anytime.

Throughout the Python API str is treated as a concrete type (though it is somewhat polymorphic due to different storage for code points sizes.)  There is also handling for an "unready" string which needs additional treatment before it can be accessed.  Unfortunately this does not appear to be suitable for creating a proxy object which can be pulled from another source to create a string on demand.   Having a "__str__()" method is insufficient as that merely makes an object able to become a string rather than considered to be a string by the rest of the API.

Would it be possible to generalize the concept of an unready string so that when Ready is called it fetches the actually string contents, creates a piece of memory to store the string contents (outside of the object itself), and sets the access flags for so that the code points can be interpreted?   Is this already possible in the API?  Are there any other plans to make the str type able to operate as a proxy?

----------
components: Extension Modules
messages: 383701
nosy: Thrameos
priority: normal
severity: normal
status: open
title: Enhancement request for proxying PyString
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42731>
_______________________________________

From report at bugs.python.org  Thu Dec 24 14:22:58 2020
From: report at bugs.python.org (Abdulrahman Alabdulkareem)
Date: Thu, 24 Dec 2020 19:22:58 +0000
Subject: [issue42730] TypeError/hang inside of Time.Sleep() when
 _thread.interrupt_main()
In-Reply-To: <1608830949.51.0.513581784179.issue42730@roundup.psfhosted.org>
Message-ID: <1608837778.14.0.932406079925.issue42730@roundup.psfhosted.org>


Change by Abdulrahman Alabdulkareem <Abdulrahman_3000 at hotmail.com>:


----------
title: TypeError in Time.Sleep when invoked from shell script background -> TypeError/hang inside of Time.Sleep() when _thread.interrupt_main()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42730>
_______________________________________

From report at bugs.python.org  Thu Dec 24 14:36:20 2020
From: report at bugs.python.org (Ken Jin)
Date: Thu, 24 Dec 2020 19:36:20 +0000
Subject: [issue42732] Buildbot s390x Fedora LTO + PGO 3.x fails intermittently
Message-ID: <1608838580.26.0.691630726472.issue42732@roundup.psfhosted.org>


New submission from Ken Jin <kenjin4096 at gmail.com>:

Dear core developers, I noticed that for many recent commits, the s390x Fedora LTO + PGO 3.x buildbot often fails. Here's an error log::


gcc -pthread   -fno-semantic-interposition -flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none -g  -Xlinker -export-dynamic -o python Programs/python.o libpython3.10.a -lcrypt -lpthread -ldl  -lutil -lm   -lm 
gcc -pthread   -fno-semantic-interposition -flto -fuse-linker-plugin -ffat-lto-objects -flto-partition=none -g  -Xlinker -export-dynamic -o Programs/_testembed Programs/_testembed.o libpython3.10.a -lcrypt -lpthread -ldl  -lutil -lm   -lm 
/usr/bin/ld: python.lto.o: in function `run_mod':
/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Python/pythonrun.c:1230: undefined reference to `PyAST_CompileObject'
/usr/bin/ld: python.lto.o: in function `builtin_compile':
/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Python/bltinmodule.c:808: undefined reference to `PyAST_CompileObject'
/usr/bin/ld: python.lto.o: in function `Py_CompileStringObject':
/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Python/pythonrun.c:1307: undefined reference to `PyAST_CompileObject'
/usr/bin/ld: python.lto.o: in function `symtable_lookup':
/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Python/symtable.c:1004: undefined reference to `_Py_Mangle'
/usr/bin/ld: python.lto.o: in function `symtable_record_directive':
/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Python/symtable.c:1161: undefined reference to `_Py_Mangle'
/usr/bin/ld: python.lto.o: in function `type_new':
/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Objects/typeobject.c:2544: undefined reference to `_Py_Mangle'
/usr/bin/ld: python.lto.o: in function `symtable_add_def_helper':
/home/dje/cpython-buildarea/3.x.edelsohn-fedora-z.lto-pgo/build/Python/symtable.c:1018: undefined reference to `_Py_Mangle'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:592: python] Error 1
make[1]: *** Waiting for unfinished jobs....

[.............. I truncated the rest]

I have a hunch the error is caused by a lack of the '-fprofile-generate' flag for the first two gcc commands. The only issue is that it's sometimes there, and sometimes not, and I'm not familiar enough with the buildbot code to find out why. Sorry.

Eg. this commit https://github.com/python/cpython/commit/cc3467a57b61b0e7ef254b36790a1c44b13f2228 has s390x Fedora LTO + PGO 3.x succeeding, the 2 gcc lines also have the '-fprofile-generate' flag.

This commit https://github.com/python/cpython/commit/c6c43b28746b0642cc3c49dd8138b896bed3028f has s390x Fedora LTO + PGO 3.x failing, the 2 gcc lines have a blank space in place of the '-fprofile-generate' flag.

I could also be completely wrong and off track, so please feel free to correct me :), thanks.

----------
components: Demos and Tools
messages: 383702
nosy: kj, pablogsal, vstinner, zach.ware
priority: normal
severity: normal
status: open
title: Buildbot s390x Fedora LTO + PGO 3.x fails intermittently
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42732>
_______________________________________

From report at bugs.python.org  Thu Dec 24 14:53:07 2020
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 24 Dec 2020 19:53:07 +0000
Subject: [issue32501] Documentation for dir([object])
In-Reply-To: <1515228843.27.0.467229070634.issue32501@psf.upfronthosting.co.za>
Message-ID: <1608839587.77.0.860266080054.issue32501@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32501>
_______________________________________

From report at bugs.python.org  Thu Dec 24 15:00:05 2020
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 24 Dec 2020 20:00:05 +0000
Subject: [issue32768] object.__new__ does not accept arguments if __bases__ is
 changed
In-Reply-To: <1517781912.98.0.467229070634.issue32768@psf.upfronthosting.co.za>
Message-ID: <1608840005.37.0.93628562777.issue32768@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

A use-case for writable bases:

__init_subclass__ is called in type.__new__, which means that for Enum __init_subclass__ is called before the members have been added.  To work around this I am currently (3.10) adding in a _NoInitSubclass to the bases before type.__new__ is called, and then removing it.

A better solution to that problem would be a way to tell type.__new__ /not/ to call __init_subclass__, but I don't have that option at this point.

----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32768>
_______________________________________

From report at bugs.python.org  Thu Dec 24 15:01:29 2020
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 24 Dec 2020 20:01:29 +0000
Subject: [issue38397] __init_subclass__ causes TypeError when used with more
 standard library metaclasses (such as EnumMeta)
In-Reply-To: <1570464400.89.0.0085195281122.issue38397@roundup.psfhosted.org>
Message-ID: <1608840089.94.0.0533213341953.issue38397@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

I just added **kwds to EnumMeta -- can this be closed?

----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38397>
_______________________________________

From report at bugs.python.org  Thu Dec 24 15:03:03 2020
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 24 Dec 2020 20:03:03 +0000
Subject: [issue42727] [Enum] EnumMeta.__prepare__ needs to accept **kwds
In-Reply-To: <1608781282.89.0.997821175942.issue42727@roundup.psfhosted.org>
Message-ID: <1608840183.34.0.608683446815.issue42727@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset f7dca9b9c864c1b7807014ea21a30cac76727e8b by Ethan Furman in branch '3.9':
[3.9] bpo-42727: [Enum] EnumMeta.__prepare__ now accepts **kwds (GH-23917). (GH-23926)
https://github.com/python/cpython/commit/f7dca9b9c864c1b7807014ea21a30cac76727e8b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42727>
_______________________________________

From report at bugs.python.org  Thu Dec 24 15:21:46 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 24 Dec 2020 20:21:46 +0000
Subject: [issue42732] Buildbot s390x Fedora LTO + PGO 3.x fails intermittently
In-Reply-To: <1608838580.26.0.691630726472.issue42732@roundup.psfhosted.org>
Message-ID: <1608841306.3.0.144803483351.issue42732@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

Isn't this the same as the problem described in https://bugs.python.org/issue42164 ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42732>
_______________________________________

From report at bugs.python.org  Thu Dec 24 17:06:00 2020
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 24 Dec 2020 22:06:00 +0000
Subject: [issue41644] builtin type kwargs
In-Reply-To: <1598459858.48.0.222216937484.issue41644@roundup.psfhosted.org>
Message-ID: <1608847560.79.0.117747960014.issue41644@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41644>
_______________________________________

From report at bugs.python.org  Thu Dec 24 17:19:56 2020
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 24 Dec 2020 22:19:56 +0000
Subject: [issue42674] __init_subclass__ only called for first subclass when
 class has multiple inheritance
Message-ID: <1608848396.56.0.740431948048.issue42674@roundup.psfhosted.org>


New submission from Ethan Furman <ethan at stoneleaf.us>:

The two subclasses in the test script are not calling super().  When they do, both __init_subclasses__ are called.

----------
nosy: +ethan.furman
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42674>
_______________________________________

From report at bugs.python.org  Thu Dec 24 17:47:00 2020
From: report at bugs.python.org (Ethan Furman)
Date: Thu, 24 Dec 2020 22:47:00 +0000
Subject: [issue42727] [Enum] EnumMeta.__prepare__ needs to accept **kwds
In-Reply-To: <1608781282.89.0.997821175942.issue42727@roundup.psfhosted.org>
Message-ID: <1608850020.79.0.28203316634.issue42727@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
pull_requests: +22778
pull_request: https://github.com/python/cpython/pull/23927

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42727>
_______________________________________

From report at bugs.python.org  Thu Dec 24 18:53:41 2020
From: report at bugs.python.org (Mark Diekhans)
Date: Thu, 24 Dec 2020 23:53:41 +0000
Subject: [issue38435] Start the deprecation cycle for subprocess preexec_fn
In-Reply-To: <1570731497.4.0.313201495913.issue38435@roundup.psfhosted.org>
Message-ID: <1608854021.87.0.275409457612.issue38435@roundup.psfhosted.org>


Mark Diekhans <markd at kermodei.com> added the comment:

calling setpgid() is a common post-fork task that would need to be an explicit parameter to Popen when preexec_fn goes away

----------
nosy: +diekhans

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38435>
_______________________________________

From report at bugs.python.org  Thu Dec 24 21:10:34 2020
From: report at bugs.python.org (Eric Snow)
Date: Fri, 25 Dec 2020 02:10:34 +0000
Subject: [issue36876] [subinterpreters] Global C variables are a problem
In-Reply-To: <1557514902.13.0.853517754348.issue36876@roundup.psfhosted.org>
Message-ID: <1608862234.8.0.528558531944.issue36876@roundup.psfhosted.org>


Change by Eric Snow <ericsnowcurrently at gmail.com>:


----------
pull_requests: +22779
pull_request: https://github.com/python/cpython/pull/23929

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36876>
_______________________________________

From report at bugs.python.org  Thu Dec 24 21:23:14 2020
From: report at bugs.python.org (Ken Jin)
Date: Fri, 25 Dec 2020 02:23:14 +0000
Subject: [issue42732] Buildbot s390x Fedora LTO + PGO 3.x fails intermittently
In-Reply-To: <1608838580.26.0.691630726472.issue42732@roundup.psfhosted.org>
Message-ID: <1608862994.25.0.645874373649.issue42732@roundup.psfhosted.org>


Ken Jin <kenjin4096 at gmail.com> added the comment:

Oops, you're right! Sorry, I'll close this issue. Anyways I realized I had the wrong hunch - I was looking at a different part of the logs.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42732>
_______________________________________

From report at bugs.python.org  Thu Dec 24 22:14:56 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 25 Dec 2020 03:14:56 +0000
Subject: [issue38435] Start the deprecation cycle for subprocess preexec_fn
In-Reply-To: <1570731497.4.0.313201495913.issue38435@roundup.psfhosted.org>
Message-ID: <1608866096.3.0.56832611538.issue38435@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
keywords: +patch
pull_requests: +22780
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/23930

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38435>
_______________________________________

From report at bugs.python.org  Thu Dec 24 22:23:11 2020
From: report at bugs.python.org (=?utf-8?b?5pa95paH5bOw?=)
Date: Fri, 25 Dec 2020 03:23:11 +0000
Subject: [issue42733] [issue] io's r+ mode truncate(0)
Message-ID: <1608866591.42.0.709266826628.issue42733@roundup.psfhosted.org>


New submission from ??? <ke265379ke at gmail.com>:

happen at io's reading & updating(r+) mode
after read,
file object's postion stay in last if you remove whole content ( truncate(0) ),
postion wil not back to 0 still stay in the last
then you start writing from last position(not 0)
that's why problem happen

test case can check here https://github.com/841020/open_source

----------
components: IO
files: Screenshot from 2020-12-25 10-46-42.png
hgrepos: 396
messages: 383710
nosy: ke265379ke
priority: normal
severity: normal
status: open
title: [issue] io's r+ mode truncate(0)
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49697/Screenshot from 2020-12-25 10-46-42.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42733>
_______________________________________

From report at bugs.python.org  Thu Dec 24 22:31:17 2020
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 25 Dec 2020 03:31:17 +0000
Subject: [issue42727] [Enum] EnumMeta.__prepare__ needs to accept **kwds
In-Reply-To: <1608781282.89.0.997821175942.issue42727@roundup.psfhosted.org>
Message-ID: <1608867077.42.0.279535162755.issue42727@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:


New changeset 786d97a66cac48e7a933010367b8993a5b3ab85b by Ethan Furman in branch 'master':
bpo-42727: [Enum] use super() and include **kwds (GH-23927)
https://github.com/python/cpython/commit/786d97a66cac48e7a933010367b8993a5b3ab85b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42727>
_______________________________________

From report at bugs.python.org  Thu Dec 24 22:31:52 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Dec 2020 03:31:52 +0000
Subject: [issue42727] [Enum] EnumMeta.__prepare__ needs to accept **kwds
In-Reply-To: <1608781282.89.0.997821175942.issue42727@roundup.psfhosted.org>
Message-ID: <1608867112.27.0.495270622219.issue42727@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 1.0 -> 2.0
pull_requests: +22781
pull_request: https://github.com/python/cpython/pull/23931

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42727>
_______________________________________

From report at bugs.python.org  Thu Dec 24 23:23:17 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 25 Dec 2020 04:23:17 +0000
Subject: [issue42727] [Enum] EnumMeta.__prepare__ needs to accept **kwds
In-Reply-To: <1608781282.89.0.997821175942.issue42727@roundup.psfhosted.org>
Message-ID: <1608870197.96.0.349794864936.issue42727@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +gregory.p.smith
nosy_count: 2.0 -> 3.0
pull_requests: +22782
pull_request: https://github.com/python/cpython/pull/23932

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42727>
_______________________________________

From report at bugs.python.org  Thu Dec 24 23:31:26 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 25 Dec 2020 04:31:26 +0000
Subject: [issue42727] [Enum] EnumMeta.__prepare__ needs to accept **kwds
In-Reply-To: <1608781282.89.0.997821175942.issue42727@roundup.psfhosted.org>
Message-ID: <1608870686.35.0.448622979878.issue42727@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset 8badadec53cbf9dc049c5b54198c5689481e3f3f by Gregory P. Smith in branch 'master':
bpo-42727: Fix the NEWS entry .rst (GH-23932)
https://github.com/python/cpython/commit/8badadec53cbf9dc049c5b54198c5689481e3f3f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42727>
_______________________________________

From report at bugs.python.org  Thu Dec 24 23:31:33 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Dec 2020 04:31:33 +0000
Subject: [issue42727] [Enum] EnumMeta.__prepare__ needs to accept **kwds
In-Reply-To: <1608781282.89.0.997821175942.issue42727@roundup.psfhosted.org>
Message-ID: <1608870693.89.0.184339728599.issue42727@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22783
pull_request: https://github.com/python/cpython/pull/23933

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42727>
_______________________________________

From report at bugs.python.org  Thu Dec 24 23:52:04 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 25 Dec 2020 04:52:04 +0000
Subject: [issue38435] Start the deprecation cycle for subprocess preexec_fn
In-Reply-To: <1570731497.4.0.313201495913.issue38435@roundup.psfhosted.org>
Message-ID: <1608871924.2.0.236789606341.issue38435@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
versions: +Python 3.10 -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38435>
_______________________________________

From report at bugs.python.org  Thu Dec 24 23:53:34 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Dec 2020 04:53:34 +0000
Subject: [issue42727] [Enum] EnumMeta.__prepare__ needs to accept **kwds
In-Reply-To: <1608781282.89.0.997821175942.issue42727@roundup.psfhosted.org>
Message-ID: <1608872014.5.0.110416577011.issue42727@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 5a6b5d8c392ca7028e7c034710a89492cd704778 by Miss Islington (bot) in branch '3.9':
bpo-42727: Fix the NEWS entry .rst (GH-23932)
https://github.com/python/cpython/commit/5a6b5d8c392ca7028e7c034710a89492cd704778


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42727>
_______________________________________

From report at bugs.python.org  Thu Dec 24 23:57:26 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 25 Dec 2020 04:57:26 +0000
Subject: [issue42388] subprocess.check_output(['echo', 'test'], text=True,
 input=None) fails
In-Reply-To: <1605621389.6.0.523205188314.issue42388@roundup.psfhosted.org>
Message-ID: <1608872246.11.0.335853083583.issue42388@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:


New changeset 64abf373444944a240274a9b6d66d1cb01ecfcdd by Gregory P. Smith in branch 'master':
bpo-42388: Fix subprocess.check_output input=None when text=True (GH-23467)
https://github.com/python/cpython/commit/64abf373444944a240274a9b6d66d1cb01ecfcdd


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42388>
_______________________________________

From report at bugs.python.org  Thu Dec 24 23:57:36 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Dec 2020 04:57:36 +0000
Subject: [issue42388] subprocess.check_output(['echo', 'test'], text=True,
 input=None) fails
In-Reply-To: <1605621389.6.0.523205188314.issue42388@roundup.psfhosted.org>
Message-ID: <1608872256.47.0.764202842836.issue42388@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +22784
pull_request: https://github.com/python/cpython/pull/23934

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42388>
_______________________________________

From report at bugs.python.org  Thu Dec 24 23:57:47 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Dec 2020 04:57:47 +0000
Subject: [issue42388] subprocess.check_output(['echo', 'test'], text=True,
 input=None) fails
In-Reply-To: <1605621389.6.0.523205188314.issue42388@roundup.psfhosted.org>
Message-ID: <1608872267.23.0.551192219748.issue42388@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22785
pull_request: https://github.com/python/cpython/pull/23935

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42388>
_______________________________________

From report at bugs.python.org  Fri Dec 25 00:01:07 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 25 Dec 2020 05:01:07 +0000
Subject: [issue42388] subprocess.check_output(['echo', 'test'], text=True,
 input=None) fails
In-Reply-To: <1605621389.6.0.523205188314.issue42388@roundup.psfhosted.org>
Message-ID: <1608872467.36.0.284492879857.issue42388@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

Meta issue behind this one: The input= behavior on check_output is yet another unfortunate wart in the subprocess collection of APIs.

PR to the main branch is in, 3.9 and 3.8 will automerge after CI runs.

----------
resolution:  -> fixed
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42388>
_______________________________________

From report at bugs.python.org  Fri Dec 25 00:01:43 2020
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 25 Dec 2020 05:01:43 +0000
Subject: [issue42730] TypeError/hang inside of Time.Sleep() when
 _thread.interrupt_main()
In-Reply-To: <1608830949.51.0.513581784179.issue42730@roundup.psfhosted.org>
Message-ID: <1608872503.53.0.472680557122.issue42730@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

When a process executes in the background from a non-interactive bash script, the initial handler for SIGINT is SIG_IGN (ignore). Prior to 3.7, _thread.interrupt_main() tries to trip SIGINT even when the C handler is set to SIG_IGN. But Python uses an integer constant for SIG_IGN (named IgnoreHandler in Modules/signalmodule.c), and trying to call it is a TypeError. This was fixed in 3.7+ to resolve bpo-23395. You've flagged this as an issue with 3.7, but the Stack Overflow question is for 3.6. If you're actually using 3.6 instead of 3.7, this issue should be closed as a duplicate.

To manually enable the normal KeyboardInterrupt exception, call signal.signal(signal.SIGINT, signal.default_int_handler).

----------
nosy: +eryksun
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42730>
_______________________________________

From report at bugs.python.org  Fri Dec 25 00:18:17 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Dec 2020 05:18:17 +0000
Subject: [issue42388] subprocess.check_output(['echo', 'test'], text=True,
 input=None) fails
In-Reply-To: <1605621389.6.0.523205188314.issue42388@roundup.psfhosted.org>
Message-ID: <1608873497.89.0.954031915857.issue42388@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset d5aadb28545fd15cd3517b604a8c7a520abd09c6 by Miss Islington (bot) in branch '3.8':
bpo-42388: Fix subprocess.check_output input=None when text=True (GH-23467)
https://github.com/python/cpython/commit/d5aadb28545fd15cd3517b604a8c7a520abd09c6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42388>
_______________________________________

From report at bugs.python.org  Fri Dec 25 00:18:40 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Dec 2020 05:18:40 +0000
Subject: [issue42388] subprocess.check_output(['echo', 'test'], text=True,
 input=None) fails
In-Reply-To: <1605621389.6.0.523205188314.issue42388@roundup.psfhosted.org>
Message-ID: <1608873520.66.0.320137251467.issue42388@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 7acfe4125725e86c982300cf10c0ab791a0783f4 by Miss Islington (bot) in branch '3.9':
bpo-42388: Fix subprocess.check_output input=None when text=True (GH-23467)
https://github.com/python/cpython/commit/7acfe4125725e86c982300cf10c0ab791a0783f4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42388>
_______________________________________

From report at bugs.python.org  Fri Dec 25 00:27:12 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 25 Dec 2020 05:27:12 +0000
Subject: [issue38435] Start the deprecation cycle for subprocess preexec_fn
In-Reply-To: <1570731497.4.0.313201495913.issue38435@roundup.psfhosted.org>
Message-ID: <1608874032.77.0.17964917375.issue38435@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

PR up to add setpgid support.  From what I've come across, some setpgid() users can use setsid() already available via start_new_session= instead.  But rather than getting into the differences between those, making both available makes sense to allow for anyone's case where setsid() isn't desired.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38435>
_______________________________________

From report at bugs.python.org  Fri Dec 25 00:45:29 2020
From: report at bugs.python.org (Xinmeng Xia)
Date: Fri, 25 Dec 2020 05:45:29 +0000
Subject: [issue42734] "bogus_code_obj.py" should be removed from
 "cPython/Lib/test/crashers"
Message-ID: <1608875129.15.0.565092953865.issue42734@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

In "Python/Lib/test/crashers/README", it said "This directory only contains tests for outstanding bugs that cause the
interpreter to segfault..... Once the crash is fixed, the test case should be moved into an appropriate test." 

The file "bogus_code_obj.py" has been fixed on Python 3.8, 3.9, 3.10. No segmentation fault will be caused any more. I think this file should be removed from "Python/Lib/test/crashers".

----------
components: Library (Lib)
messages: 383721
nosy: xxm
priority: normal
severity: normal
status: open
title: "bogus_code_obj.py" should be removed from "cPython/Lib/test/crashers"
type: enhancement
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42734>
_______________________________________

From report at bugs.python.org  Fri Dec 25 00:48:49 2020
From: report at bugs.python.org (Xinmeng Xia)
Date: Fri, 25 Dec 2020 05:48:49 +0000
Subject: [issue42735] "trace_at_recursion_limit.py" should be removed from
 "Python/Lib/test/crashers"
Message-ID: <1608875329.89.0.262110269237.issue42735@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

In "Python/Lib/test/crashers/", only tests for outstanding bugs that cause the interpreter to segfault should be included.

The file "trace_at_recursion_limit.py" has been fixed on Python 3.7, 3.8, 3.9, 3.10. No segmentation fault will be caused any more. I think this file should be removed from "Python/Lib/test/crashers".

----------
components: Library (Lib)
messages: 383722
nosy: xxm
priority: normal
severity: normal
status: open
title: "trace_at_recursion_limit.py" should be removed from "Python/Lib/test/crashers"
type: enhancement
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42735>
_______________________________________

From report at bugs.python.org  Fri Dec 25 00:55:16 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 25 Dec 2020 05:55:16 +0000
Subject: [issue42736] Add support for making Linux prctl(...) calls to
 subprocess
Message-ID: <1608875716.63.0.116569716148.issue42736@roundup.psfhosted.org>


New submission from Gregory P. Smith <greg at krypto.org>:

Another use of `subprocess preexec_fn=` that I've come across has been to call Linux's `prctl` in the child process before the `exec`.

`_libc.prctl(_PR_SET_PDEATHSIG, value)` for example.

Adding a linux_prctl_calls= parameter listing information about which prctl call(s) to make in the child before exec would satisfy this needed.

No need to go overboard here, this is a _very_ low level syscall.  users need to know what they're doing and will likely abstract use away from actual users via a wrapper library.  i.e: Lets not attempt to reinvent the https://pythonhosted.org/python-prctl/ interface.

Proposal:

linux_prctl_calls: Sequence[tuple]

Where every tuple indicates one prctl call.  the tuple [0] contains a bool indicating if an error returned by that prctl call should be ignored or not.  the tuple[1:6] contain the five int arguments to be passed to prctl.  If the tuple is shorter than 2 elements, the remaining values are assumed 0.

At most, a namedtuple type could be created for this purpose to allow the user to use the https://man7.org/linux/man-pages/man2/prctl.2.html argument names rather than just blindly listing a tuple.

```
namedtuple('LinuxPrctlDescription',
            field_names='check_error, option, arg2, arg3, arg4, arg5',
            defaults=(0,0,0,0))
```

This existing helps https://bugs.python.org/issue38435 deprecate preexec_fn.

----------
components: Extension Modules, Library (Lib)
messages: 383723
nosy: gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: Add support for making Linux prctl(...) calls to subprocess
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42736>
_______________________________________

From report at bugs.python.org  Fri Dec 25 00:55:34 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 25 Dec 2020 05:55:34 +0000
Subject: [issue38435] Start the deprecation cycle for subprocess preexec_fn
In-Reply-To: <1570731497.4.0.313201495913.issue38435@roundup.psfhosted.org>
Message-ID: <1608875734.7.0.680361098012.issue38435@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

https://bugs.python.org/issue42736 filed to track adding Linux prctl() support.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38435>
_______________________________________

From report at bugs.python.org  Fri Dec 25 00:59:19 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 25 Dec 2020 05:59:19 +0000
Subject: [issue38435] Start the deprecation cycle for subprocess preexec_fn
In-Reply-To: <1570731497.4.0.313201495913.issue38435@roundup.psfhosted.org>
Message-ID: <1608875959.58.0.039576390762.issue38435@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

Another preexec_fn use to consider:

 resource.setrlimit(resource.RLIMIT_CORE, (XXX, XXX))

Using an intermediate shell script wrapper that changes the rlimit and exec's the actual process is also an alternative.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38435>
_______________________________________

From report at bugs.python.org  Fri Dec 25 01:00:26 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 25 Dec 2020 06:00:26 +0000
Subject: [issue38435] Start the deprecation cycle for subprocess preexec_fn
In-Reply-To: <1570731497.4.0.313201495913.issue38435@roundup.psfhosted.org>
Message-ID: <1608876026.04.0.380673978773.issue38435@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

I'm also seeing a lot of os.setpgrp() calls, though those are more likely able to use start_new_session to do setsid() as a dropin replacement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38435>
_______________________________________

From report at bugs.python.org  Fri Dec 25 01:05:25 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 25 Dec 2020 06:05:25 +0000
Subject: [issue38435] Start the deprecation cycle for subprocess preexec_fn
In-Reply-To: <1570731497.4.0.313201495913.issue38435@roundup.psfhosted.org>
Message-ID: <1608876325.39.0.238845430554.issue38435@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

signal.signal use case:

Calls to signal.signal(x, y) to sometimes to set a non SIG_DFL behavior on a signal.  SIGINT -> SIG_IGN for example.

I see a lot of legacy looking code calling signal.signal in prexec_fn that appears to set SIG_DFL for the signals that Python otherwise modifies.  Which restore_signals=True should already be doing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38435>
_______________________________________

From report at bugs.python.org  Fri Dec 25 01:28:06 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 25 Dec 2020 06:28:06 +0000
Subject: [issue38435] Start the deprecation cycle for subprocess preexec_fn
In-Reply-To: <1570731497.4.0.313201495913.issue38435@roundup.psfhosted.org>
Message-ID: <1608877686.76.0.593209869303.issue38435@roundup.psfhosted.org>


Change by Gregory P. Smith <greg at krypto.org>:


----------
pull_requests: +22786
pull_request: https://github.com/python/cpython/pull/23936

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38435>
_______________________________________

From report at bugs.python.org  Fri Dec 25 01:31:32 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 25 Dec 2020 06:31:32 +0000
Subject: [issue38435] Start the deprecation cycle for subprocess preexec_fn
In-Reply-To: <1570731497.4.0.313201495913.issue38435@roundup.psfhosted.org>
Message-ID: <1608877892.82.0.0549232972072.issue38435@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

Doing the code inspection of existing preexec_fn= users within our codebase at work is revealing.  But those seem to be the bulk of uses.

I expect this deprecation to take a while.  Ex: if we mark it as PendingDeprecationWarning in 3.10, I'd still wait until _at least_ 3.13 to remove it.

Code using it often has a long legacy and may be written to run on a wide variety of Python versions.  It's painful to do so when features you need in order to stop using it are still only in modern versions.

----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38435>
_______________________________________

From report at bugs.python.org  Fri Dec 25 04:32:50 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 25 Dec 2020 09:32:50 +0000
Subject: [issue42737] PEP 563: drop annotations for complex assign targets
Message-ID: <1608888770.02.0.483696766952.issue42737@roundup.psfhosted.org>


New submission from Batuhan Taskaya <isidentical at gmail.com>:

PEP 526 classifies everything but simple, unparenthesized names (a.b, (a), a[b]) as complex targets. The way the we handle annotations for them right now is, doing literally nothing but evaluating every part of it (just pushing the name to the stack, and popping, without even doing the attribute access);

$ cat t.py
foo[bar]: int
$ python -m dis t.py
  1           0 SETUP_ANNOTATIONS
              2 LOAD_NAME                0 (foo)
              4 POP_TOP
              6 LOAD_NAME                1 (bar)
              8 POP_TOP
             10 LOAD_NAME                2 (int)
             12 POP_TOP
             14 LOAD_CONST               0 (None)
             16 RETURN_VALUE


$ cat t.py
a.b: int
$ python -m dis t.py
  1           0 SETUP_ANNOTATIONS
              2 LOAD_NAME                0 (a)
              4 POP_TOP
              6 LOAD_NAME                1 (int)
              8 POP_TOP
             10 LOAD_CONST               0 (None)
             12 RETURN_VALUE

I noticed this while creating a patch for issue 42725, since I had to create an extra check for non-simple annassign targets (because compiler tries to find their scope, `int` in this case is not compiled to string). 

Since they have no real side effect but just accessing a name, I'd propose we drop this from 3.10 so that both I can simply the patch for issue 42725, and also we have consistency with what we do when the target is simple (instead of storing this time, we'll just drop the bytecode).

$ cat t.py
a.b: int = 5
$ python -m dis t.py
  1           0 SETUP_ANNOTATIONS
              2 LOAD_CONST               0 (5)
              4 LOAD_NAME                0 (a)
              6 STORE_ATTR               1 (b)
              8 LOAD_NAME                2 (int)
             10 POP_TOP
             12 LOAD_CONST               1 (None)
             14 RETURN_VALUE

8/10 will be gone in this case.

If agreed upon, I can propose a patch.

----------
components: Interpreter Core
messages: 383729
nosy: BTaskaya, gvanrossum, lys.nikolaou, pablogsal, serhiy.storchaka
priority: normal
severity: normal
status: open
title: PEP 563: drop annotations for complex assign targets
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42737>
_______________________________________

From report at bugs.python.org  Fri Dec 25 04:33:24 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 25 Dec 2020 09:33:24 +0000
Subject: [issue42725] PEP 563: Should the behavior change for yield/yield
 from's
In-Reply-To: <1608730131.08.0.595189962302.issue42725@roundup.psfhosted.org>
Message-ID: <1608888804.79.0.785245354711.issue42725@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

I have a patch ready to go, but I'd prefer to block this issue until issue 42737 is resolved/decided.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42725>
_______________________________________

From report at bugs.python.org  Fri Dec 25 04:42:32 2020
From: report at bugs.python.org (AR Kareem)
Date: Fri, 25 Dec 2020 09:42:32 +0000
Subject: [issue42730] TypeError/hang inside of Time.Sleep() when
 _thread.interrupt_main()
In-Reply-To: <1608830949.51.0.513581784179.issue42730@roundup.psfhosted.org>
Message-ID: <1608889352.04.0.221647109948.issue42730@roundup.psfhosted.org>


AR Kareem <Abdulrahman_3000 at hotmail.com> added the comment:

My apologies, I meant to flag it as 3.6 instead of 3.7.

I see what's happening now, and thanks for providing the correct way to raise a KeyboardInterrupt.

Correctly flagged as 3.6 and closed.

Thanks.

----------
resolution:  -> duplicate
versions: +Python 3.6 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42730>
_______________________________________

From report at bugs.python.org  Fri Dec 25 05:32:51 2020
From: report at bugs.python.org (Julien Palard)
Date: Fri, 25 Dec 2020 10:32:51 +0000
Subject: [issue36675] Doctest directives and comments missing from code samples
In-Reply-To: <1555757030.56.0.8094269644.issue36675@roundup.psfhosted.org>
Message-ID: <1608892371.2.0.910162400971.issue36675@roundup.psfhosted.org>


Julien Palard <julien+python at palard.fr> added the comment:

Happy Christmas, everybody involved in this issue! I'm happy to announce this issue is resolved since a few days \o/

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36675>
_______________________________________

From report at bugs.python.org  Fri Dec 25 06:01:47 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Dec 2020 11:01:47 +0000
Subject: [issue29076] Mac installer shell updater script silently fails if
 default shell is fish
In-Reply-To: <1482778000.76.0.584407589583.issue29076@psf.upfronthosting.co.za>
Message-ID: <1608894107.21.0.334695202399.issue29076@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +22787
pull_request: https://github.com/python/cpython/pull/23937

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29076>
_______________________________________

From report at bugs.python.org  Fri Dec 25 06:01:58 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Dec 2020 11:01:58 +0000
Subject: [issue29076] Mac installer shell updater script silently fails if
 default shell is fish
In-Reply-To: <1482778000.76.0.584407589583.issue29076@psf.upfronthosting.co.za>
Message-ID: <1608894118.78.0.659436442371.issue29076@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22788
pull_request: https://github.com/python/cpython/pull/23938

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29076>
_______________________________________

From report at bugs.python.org  Fri Dec 25 06:02:01 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Dec 2020 11:02:01 +0000
Subject: [issue29076] Mac installer shell updater script silently fails if
 default shell is fish
In-Reply-To: <1482778000.76.0.584407589583.issue29076@psf.upfronthosting.co.za>
Message-ID: <1608894121.23.0.445275282731.issue29076@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 7f162e867c674f57c308a87fffcdcca3540c8933 by Erlend Egeberg Aasland in branch 'master':
bpo-29076: Add fish support to macOS installer (GH-23302)
https://github.com/python/cpython/commit/7f162e867c674f57c308a87fffcdcca3540c8933


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29076>
_______________________________________

From report at bugs.python.org  Fri Dec 25 06:03:58 2020
From: report at bugs.python.org (AR Kareem)
Date: Fri, 25 Dec 2020 11:03:58 +0000
Subject: [issue42730] TypeError/hang inside of Time.Sleep() when
 _thread.interrupt_main()
In-Reply-To: <1608830949.51.0.513581784179.issue42730@roundup.psfhosted.org>
Message-ID: <1608894238.53.0.777179576277.issue42730@roundup.psfhosted.org>


AR Kareem <Abdulrahman_3000 at hotmail.com> added the comment:

Shouldn't the behaviour for _thread.interrupt_main() be always to interrupt the main thread. 

I would expect that if a child thread uses _thread.interrupt_main() that the main thread be interrupted regardless of how the python script was invoked.

Wouldn't it be more reasonable to make _thread.interrupt_main() always raise a SIGINT? I'm not sure if this is technically considered a bug or not, but it seems that it's not functioning as intended even in Python 3.7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42730>
_______________________________________

From report at bugs.python.org  Fri Dec 25 06:10:52 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Dec 2020 11:10:52 +0000
Subject: [issue42734] "bogus_code_obj.py" should be removed from
 "cPython/Lib/test/crashers"
In-Reply-To: <1608875129.15.0.565092953865.issue42734@roundup.psfhosted.org>
Message-ID: <1608894652.95.0.635919559511.issue42734@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

No, it was not fixed. The code object creation was broken, because the code constructor signature was changed.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42734>
_______________________________________

From report at bugs.python.org  Fri Dec 25 06:17:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Dec 2020 11:17:25 +0000
Subject: [issue38435] Start the deprecation cycle for subprocess preexec_fn
In-Reply-To: <1570731497.4.0.313201495913.issue38435@roundup.psfhosted.org>
Message-ID: <1608895045.24.0.185819658747.issue38435@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Using an intermediate shell script wrapper that changes the rlimit and exec's the actual process is also an alternative.

IMO using Python is more portable than relying on a shell.

I dislike relying on a shell since shells are not really portable (behave differently), unless you restrict yourself to a strict POSIX subset of the shell programming language. While '/bin/sh' is available on most Unix, Android uses '/system/bin/sh', and Windows and VxWorks have no shell (Windows provides cmd.exe which uses Batch programming language, and there are other scripting languages like VBS or PowerShell: so you need a complete different implementation for Windows).

For the oslo.concurrency project, I wrote the Python script prlimit.py: a wrapper calling resource.setrlimit() and then execute a new program. It's similar to the Unix prlimit program, but written in Python to be portable (the "prlimit" program is not available on all platforms).

https://github.com/openstack/oslo.concurrency/blob/master/oslo_concurrency/prlimit.py

I suggest to not provide a builtin wrapper to replace preexec_fn, but suggest replacements in the subprocess and What's New in Python 3.11 documentation (explain how to port existing code).

More generally, the whole preeexc_fn feature could be reimplemented a third-party project by spawning a *new* Python process, run the Python code, and *then* execute the final process. The main feature of preexec_fn is to give the ability to run a function of the current process, whereas what I'm discussing would be code written as a string.

--

preexec_fn can be used for non-trivial issues like only sharing some Windows HANDLE, see:
https://www.python.org/dev/peps/pep-0446/#only-inherit-some-handles-on-windows

Note: This specific problem has been solved the proper way in Python by adding support for PROC_THREAD_ATTRIBUTE_HANDLE_LIST in subprocess.STARTUPINFO: lpAttributeList['handle_list'] parameter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38435>
_______________________________________

From report at bugs.python.org  Fri Dec 25 06:21:36 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Dec 2020 11:21:36 +0000
Subject: [issue42734] Outdated CodeType call in "bogus_code_obj.py"
In-Reply-To: <1608875129.15.0.565092953865.issue42734@roundup.psfhosted.org>
Message-ID: <1608895296.69.0.689973365156.issue42734@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
title: "bogus_code_obj.py" should be removed from "cPython/Lib/test/crashers" -> Outdated CodeType call in "bogus_code_obj.py"

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42734>
_______________________________________

From report at bugs.python.org  Fri Dec 25 06:27:11 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Dec 2020 11:27:11 +0000
Subject: [issue42734] Outdated CodeType call in "bogus_code_obj.py"
In-Reply-To: <1608875129.15.0.565092953865.issue42734@roundup.psfhosted.org>
Message-ID: <1608895631.17.0.219175396101.issue42734@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +22789
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23939

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42734>
_______________________________________

From report at bugs.python.org  Fri Dec 25 06:41:14 2020
From: report at bugs.python.org (Xinmeng Xia)
Date: Fri, 25 Dec 2020 11:41:14 +0000
Subject: [issue42735] "trace_at_recursion_limit.py" should be removed from
 "Python/Lib/test/crashers"
In-Reply-To: <1608875329.89.0.262110269237.issue42735@roundup.psfhosted.org>
Message-ID: <1608896474.11.0.161699696711.issue42735@roundup.psfhosted.org>


Change by Xinmeng Xia <xiaxm at smail.nju.edu.cn>:


----------
type: enhancement -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42735>
_______________________________________

From report at bugs.python.org  Fri Dec 25 06:45:21 2020
From: report at bugs.python.org (Xinmeng Xia)
Date: Fri, 25 Dec 2020 11:45:21 +0000
Subject: [issue42734] Outdated CodeType call in "bogus_code_obj.py"
In-Reply-To: <1608875129.15.0.565092953865.issue42734@roundup.psfhosted.org>
Message-ID: <1608896721.15.0.906743954478.issue42734@roundup.psfhosted.org>


Xinmeng Xia <xiaxm at smail.nju.edu.cn> added the comment:

Yes?you are right. I thought it was fixed,but it wasn't. Thanks.

----------
type: enhancement -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42734>
_______________________________________

From report at bugs.python.org  Fri Dec 25 06:47:31 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Dec 2020 11:47:31 +0000
Subject: [issue42731] Enhancement request for proxying PyString
In-Reply-To: <1608837222.47.0.436477012182.issue42731@roundup.psfhosted.org>
Message-ID: <1608896851.37.0.235306853896.issue42731@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

There is no longer PyString in Python, only PyUnicode.

There are plans to get rid of PyUnicode_READY(). After removing support of "legacy" Unicode objects (which will happen in few years), PyUnicode_READY() will be no longer needed, so all calls of it could be removed. Currently there is a last chance to redesign it for other purposes. I suggest to discuss this on one of mailing lists (Python-ideas or even Python-Dev) with wider auditory, as it can have large impact on the future of C API.

Although I am not sure that PyUnicode_READY() is called in all needed cases. It just happen that the code is not tested intensively with "legacy" Unicode objects because in normal case you get already ready objects. Actually, functions like _PyUnicode_EqualToASCIIString do not call it intentionally and read the Py_UNICODE content of non-ready Unicode objects directly.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42731>
_______________________________________

From report at bugs.python.org  Fri Dec 25 06:48:40 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Dec 2020 11:48:40 +0000
Subject: [issue42685] Improve placing of simple query windows.
In-Reply-To: <1608391787.71.0.662938082611.issue42685@roundup.psfhosted.org>
Message-ID: <1608896920.27.0.601477958462.issue42685@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/issue42685>
_______________________________________

From report at bugs.python.org  Fri Dec 25 06:53:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Dec 2020 11:53:03 +0000
Subject: [issue42738] subprocess: don't close all file descriptors by default
 (close_fds=False)
Message-ID: <1608897183.26.0.576206535349.issue42738@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

To make subprocess faster, I propose to no longer close all file descriptors by default in subprocess: change Popen close_fds parameter default to False (close_fds=False).

Using close_fds=False, subprocess can use posix_spawn() which is safer and faster than fork+exec. For example, on Linux, the glibc implements it as a function using vfork which is faster than fork if the parent allocated a lot of memory. On macOS, posix_spawn() is even a syscall.

The main drawback is that close_fds=False reopens a security vulnerability if a file descriptor is not marked as non-inheritable. The PEP 446 "Make newly created file descriptors non-inheritable" was implemented in Python 3.4: Python should only create non-inheritable FDs, if it's not the case, Python should be fixed. Sadly, 3rd party Python modules may not implement the PEP 446. In this case, close_fds=True should be used explicitly, or these modules should be fixed. os.set_inheritable() can be used to make FDs as non-inheritable.

close_fds=True has a cost on subprocess performance. When the maximum number of file descriptors is larger than 10,000 and Python has no way to list open file descriptors, calling close(fd) once per file descriptor can take several milliseconds. When I wrote the PEP 446 (in 2013), on a FreeBSD buildbot with MAXFD=655,000, closing all FDs took 300 ms (see bpo-11284 "slow close file descriptors").

FreeBSD has been fixed recently by using closefrom() function which makes _posixsubprocess and os.closerange() faster.

In 2020, my Red Hat colleagues still report the issue in Linux containers using... Python 2.7, since Python 2.7 subprocess also close all file descriptors in a loop (there was no code to list open file descriptors). The problem still exists in Python 3 if subprocess cannot open /proc/self/fd/ directory, when /proc pseudo filesystem is not mounted (or if the access is blocked, ex: by a sandbox). The problem is that some containers are created a very high limit for the maximum number of FDs: os.sysconf("SC_OPEN_MAX") returns 1,048,576. Calling close() more than 1 million of times is slow...

See also related issue bpo-38435 "Start the deprecation cycle for subprocess preexec_fn".

--

Notes about close_fds=True.

Python 3.9 can now use closefrom() function on FreeBSD: bpo-38061.

Linux 5.10 has a new closerange() syscall: https://lwn.net/Articles/789023/

Linux 5.11 (not released yet) will add a new CLOSE_RANGE_CLOEXEC flag to close_range(): https://lwn.net/Articles/837816/

--

History of the close_fds parameter default value.

In Python 2.7, subprocess didn't close all file descriptors by default: close_fds=False by default.

Dec 4, 2010: In Python 3.2 (bpo-7213, bpo-2320), subprocess.Popen started to emit a deprecating warning when close_fds was not specified explicitly (commit d23047b62c6f885def9020bd9b304110f9b9c52d):

+        if close_fds is None:
+            # Notification for http://bugs.python.org/issue7213 & issue2320
+            warnings.warn(
+                    'The close_fds parameter was not specified.  Its default'
+                    ' will change from False to True in a future Python'
+                    ' version.  Most users should set it to True.  Please'
+                    ' update your code explicitly set close_fds.',
+                    DeprecationWarning)

Dec 13 2010, bpo-7213: close_fds default value was changed to True on non-Windows platforms, and False on Windows (commit f5604853889bfbbf84b48311c63c0e775dff38cc). The implementation was adjusted in bpo-6559 (commit 8edd99d0852c45f70b6abc851e6b326d4250cd33) to use a new _PLATFORM_DEFAULT_CLOSE_FDS singleton object.

See issues:

* bpo-2320: Race condition in subprocess using stdin
* bpo-6559: add pass_fds paramter to subprocess.Popen()
* bpo-7213: subprocess leaks open file descriptors between Popen instances causing hangs

--

On Windows, there is also the question of handles (HANDLE type). Python 3.7 added the support for the PROC_THREAD_ATTRIBUTE_HANDLE_LIST in subprocess.STARTUPINFO: lpAttributeList['handle_list'] parameter. Hopefully, Windows has a way better default than Unix: all handles are created as non-inheritable by default, so these is no need to explicitly close them.

----------
components: Library (Lib)
messages: 383739
nosy: gregory.p.smith, vstinner
priority: normal
severity: normal
status: open
title: subprocess: don't close all file descriptors by default (close_fds=False)
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42738>
_______________________________________

From report at bugs.python.org  Fri Dec 25 06:53:22 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Dec 2020 11:53:22 +0000
Subject: [issue38435] Start the deprecation cycle for subprocess preexec_fn
In-Reply-To: <1570731497.4.0.313201495913.issue38435@roundup.psfhosted.org>
Message-ID: <1608897202.61.0.778608209516.issue38435@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I just created bpo-42738: "subprocess: don't close all file descriptors by default (close_fds=False)".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38435>
_______________________________________

From report at bugs.python.org  Fri Dec 25 06:55:58 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Dec 2020 11:55:58 +0000
Subject: [issue42739] Crash when try to disassemble bogus code object
Message-ID: <1608897358.97.0.834158885511.issue42739@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

>>> def f(): pass
... 
>>> co = f.__code__.replace(co_linetable=b'')
>>> import dis
>>> dis.dis(co)
python: Objects/codeobject.c:1185: PyLineTable_NextAddressRange: Assertion `!at_end(range)' failed.
Aborted (core dumped)

It is expected that executing bogus code object can crash (or cause any other effect). But it is surprising that just inspecting it causes a crash.

----------
components: Interpreter Core
messages: 383741
nosy: Mark.Shannon, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Crash when try to disassemble bogus code object
type: crash
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42739>
_______________________________________

From report at bugs.python.org  Fri Dec 25 08:05:19 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 25 Dec 2020 13:05:19 +0000
Subject: [issue42733] [issue] io's r+ mode truncate(0)
In-Reply-To: <1608866591.42.0.709266826628.issue42733@roundup.psfhosted.org>
Message-ID: <1608901518.99.0.0678739799513.issue42733@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

You say:

>  after process python3 test_case.py
>  json file's content like this
>  
>  @@@@@@@@@@{"how_dare_you": "how_dare_you"}


I cannot replicate that result.


I created a "data.json" with the following content:


```
>>> with open(FILE_PATH, 'w') as f:
...     f.write('{"how_dare_you": "how_dare_you"}\n')
... 
33
>>> with open(FILE_PATH, 'r') as f:
...     print(f.read())
... 
{"how_dare_you": "how_dare_you"}

```


Then I ran your `test` function and the only result was to delete the newline at the end of the file:


```
>>> test()
beginning tell 0
tell after read 33
tell after delete content 33
content 0 
tell after write 65
content 0 
>>> 
>>> with open(FILE_PATH, 'r') as f:
...     print(f.read())
... 
{"how_dare_you": "how_dare_you"}
>>> 
```

So I cannot replicate your reported bug. There is no sign of any garbage characters inserted at the start of the file as you state.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42733>
_______________________________________

From report at bugs.python.org  Fri Dec 25 08:31:51 2020
From: report at bugs.python.org (=?utf-8?b?5pa95paH5bOw?=)
Date: Fri, 25 Dec 2020 13:31:51 +0000
Subject: [issue42733] [issue] io's r+ mode truncate(0)
In-Reply-To: <1608866591.42.0.709266826628.issue42733@roundup.psfhosted.org>
Message-ID: <1608903111.41.0.800279345559.issue42733@roundup.psfhosted.org>


??? <ke265379ke at gmail.com> added the comment:

hi Steven

thanks for check my post

first test have a problem,you didn?t use r+ mode
step is 
1. f.read
2. f.truncate(0)
3. f.write(something)

my test msg tell you

?
tell after delete content 33
content 0 
tell after write 65
?

so you know after truncate f.tell =33
but no content in file
and after you write something into file
msg tell you f.tell =65
but ? {"how_dare_you": "how_dare_you"}? is only 33 length 
so you know must have someing in file

please use editor open the file
you will find it

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42733>
_______________________________________

From report at bugs.python.org  Fri Dec 25 10:01:05 2020
From: report at bugs.python.org (Ken Jin)
Date: Fri, 25 Dec 2020 15:01:05 +0000
Subject: [issue40494] collections.abc.Callable and type variables
In-Reply-To: <1588579632.5.0.091811612876.issue40494@roundup.psfhosted.org>
Message-ID: <1608908465.1.0.765489007868.issue40494@roundup.psfhosted.org>


Ken Jin <kenjin4096 at gmail.com> added the comment:

Now that issue42195 has been resolved by subclassing types.GenericAlias, can this be closed?

On 3.9 and 3.10:

>>> import typing, collections.abc
>>> T = typing.TypeVar('T')
>>> C2 = collections.abc.Callable[[T], T]
>>> C2[int]
collections.abc.Callable[[int], int]

It seems to be fixed :).

----------
nosy: +kj

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40494>
_______________________________________

From report at bugs.python.org  Fri Dec 25 10:03:46 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Dec 2020 15:03:46 +0000
Subject: [issue42734] Outdated CodeType call in "bogus_code_obj.py"
In-Reply-To: <1608875129.15.0.565092953865.issue42734@roundup.psfhosted.org>
Message-ID: <1608908626.32.0.978996084726.issue42734@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 954a7427ba9c2d02faed32c02090caeca873aeca by Serhiy Storchaka in branch 'master':
bpo-42734: Fix crasher bogus_code_obj.py (GH-23939)
https://github.com/python/cpython/commit/954a7427ba9c2d02faed32c02090caeca873aeca


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42734>
_______________________________________

From report at bugs.python.org  Fri Dec 25 10:03:55 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Dec 2020 15:03:55 +0000
Subject: [issue42734] Outdated CodeType call in "bogus_code_obj.py"
In-Reply-To: <1608875129.15.0.565092953865.issue42734@roundup.psfhosted.org>
Message-ID: <1608908635.9.0.620892041305.issue42734@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +22790
pull_request: https://github.com/python/cpython/pull/23940

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42734>
_______________________________________

From report at bugs.python.org  Fri Dec 25 10:04:09 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Dec 2020 15:04:09 +0000
Subject: [issue42734] Outdated CodeType call in "bogus_code_obj.py"
In-Reply-To: <1608875129.15.0.565092953865.issue42734@roundup.psfhosted.org>
Message-ID: <1608908649.48.0.503744922884.issue42734@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22791
pull_request: https://github.com/python/cpython/pull/23941

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42734>
_______________________________________

From report at bugs.python.org  Fri Dec 25 10:04:29 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Dec 2020 15:04:29 +0000
Subject: [issue15303] Minor revision to the <BaseWidget._setup> method in
 Tkinter
In-Reply-To: <1341822350.55.0.995662615633.issue15303@psf.upfronthosting.co.za>
Message-ID: <1608908669.06.0.789465190259.issue15303@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset bb70b2afe39ad4334a9f3449cddd28149bd628b6 by Serhiy Storchaka in branch 'master':
bpo-15303: Support widgets with boolean value False in Tkinter (GH-23904)
https://github.com/python/cpython/commit/bb70b2afe39ad4334a9f3449cddd28149bd628b6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15303>
_______________________________________

From report at bugs.python.org  Fri Dec 25 10:19:22 2020
From: report at bugs.python.org (Ken Jin)
Date: Fri, 25 Dec 2020 15:19:22 +0000
Subject: [issue42740] typing.py get_args and get_origin should support PEP 604
 and 612
Message-ID: <1608909562.21.0.0257515668126.issue42740@roundup.psfhosted.org>


New submission from Ken Jin <kenjin4096 at gmail.com>:

Currently get_args doesn't work for PEP 604 Union:

>>> get_args(int | str)

or new Callables with PEP 612:

>>> P = ParamSpec('P)
>>> get_args(Callable[P, int])
([~P], <class 'int'>)

get_origin doesn't work with PEP 604 Unions:

>>> get_origin(int | str)


PS: the fix has to be backported partly to 3.9. Because get_args doesn't handle collections.abc.Callable either.

----------
components: Library (Lib)
messages: 383747
nosy: gvanrossum, kj, levkivskyi
priority: normal
severity: normal
status: open
title: typing.py get_args and get_origin should support PEP 604 and 612
type: behavior
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42740>
_______________________________________

From report at bugs.python.org  Fri Dec 25 10:21:02 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Dec 2020 15:21:02 +0000
Subject: [issue42734] Outdated CodeType call in "bogus_code_obj.py"
In-Reply-To: <1608875129.15.0.565092953865.issue42734@roundup.psfhosted.org>
Message-ID: <1608909662.67.0.125017013879.issue42734@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 0178a6b67ca3e782443f311e953509ca3eb4aacf by Miss Islington (bot) in branch '3.8':
bpo-42734: Fix crasher bogus_code_obj.py (GH-23939)
https://github.com/python/cpython/commit/0178a6b67ca3e782443f311e953509ca3eb4aacf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42734>
_______________________________________

From report at bugs.python.org  Fri Dec 25 10:23:20 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Dec 2020 15:23:20 +0000
Subject: [issue42734] Outdated CodeType call in "bogus_code_obj.py"
In-Reply-To: <1608875129.15.0.565092953865.issue42734@roundup.psfhosted.org>
Message-ID: <1608909800.79.0.213032929922.issue42734@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 51f502914656a1f8e8ffdf6e1b06f670d8fea8ed by Miss Islington (bot) in branch '3.9':
bpo-42734: Fix crasher bogus_code_obj.py (GH-23939)
https://github.com/python/cpython/commit/51f502914656a1f8e8ffdf6e1b06f670d8fea8ed


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42734>
_______________________________________

From report at bugs.python.org  Fri Dec 25 10:23:32 2020
From: report at bugs.python.org (Desmond Cheong)
Date: Fri, 25 Dec 2020 15:23:32 +0000
Subject: [issue42727] [Enum] EnumMeta.__prepare__ needs to accept **kwds
In-Reply-To: <1608781282.89.0.997821175942.issue42727@roundup.psfhosted.org>
Message-ID: <1608909812.3.0.839921118089.issue42727@roundup.psfhosted.org>


Change by Desmond Cheong <desmondcheongzx at gmail.com>:


----------
nosy: +desmondcheongzx
nosy_count: 3.0 -> 4.0
pull_requests: +22792
pull_request: https://github.com/python/cpython/pull/23885

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42727>
_______________________________________

From report at bugs.python.org  Fri Dec 25 10:43:25 2020
From: report at bugs.python.org (Ken Jin)
Date: Fri, 25 Dec 2020 15:43:25 +0000
Subject: [issue42740] typing.py get_args and get_origin should support PEP 604
 and 612
In-Reply-To: <1608909562.21.0.0257515668126.issue42740@roundup.psfhosted.org>
Message-ID: <1608911005.68.0.30545421268.issue42740@roundup.psfhosted.org>


Change by Ken Jin <kenjin4096 at gmail.com>:


----------
keywords: +patch
pull_requests: +22793
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23942

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42740>
_______________________________________

From report at bugs.python.org  Fri Dec 25 11:04:14 2020
From: report at bugs.python.org (Ken Jin)
Date: Fri, 25 Dec 2020 16:04:14 +0000
Subject: [issue42741] Sync 3.9's whatsnew document in 3.10 with 3.9 branch
Message-ID: <1608912254.65.0.400957747647.issue42741@roundup.psfhosted.org>


New submission from Ken Jin <kenjin4096 at gmail.com>:

On the 3.10 branch, the what's new document for 3.9 isn't synced with the one on the 3.9 branch.

Currently it's missing two entries:

macOS 11.0 (Big Sur) and Apple Silicon Mac support
issue41100

(next one's my fault, sorry)
collections.abc.Callable changes
issue42195

----------
assignee: docs at python
components: Documentation
messages: 383750
nosy: docs at python, kj, lukasz.langa, pablogsal
priority: normal
severity: normal
status: open
title: Sync 3.9's whatsnew document in 3.10 with 3.9 branch
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42741>
_______________________________________

From report at bugs.python.org  Fri Dec 25 11:04:39 2020
From: report at bugs.python.org (Ken Jin)
Date: Fri, 25 Dec 2020 16:04:39 +0000
Subject: [issue42741] Sync 3.9's whatsnew document in 3.10 with 3.9 branch
In-Reply-To: <1608912254.65.0.400957747647.issue42741@roundup.psfhosted.org>
Message-ID: <1608912279.49.0.630969383366.issue42741@roundup.psfhosted.org>


Change by Ken Jin <kenjin4096 at gmail.com>:


----------
keywords: +patch
pull_requests: +22794
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23943

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42741>
_______________________________________

From report at bugs.python.org  Fri Dec 25 11:07:37 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 25 Dec 2020 16:07:37 +0000
Subject: [issue42727] [Enum] EnumMeta.__prepare__ needs to accept **kwds
In-Reply-To: <1608781282.89.0.997821175942.issue42727@roundup.psfhosted.org>
Message-ID: <1608912457.9.0.724708357699.issue42727@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset fbffda25b4b5f537e651eaab4ca1ec4cde800709 by Miss Islington (bot) in branch '3.9':
bpo-42727: [Enum] use super() and include **kwds (GH-23927)
https://github.com/python/cpython/commit/fbffda25b4b5f537e651eaab4ca1ec4cde800709


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42727>
_______________________________________

From report at bugs.python.org  Fri Dec 25 11:10:05 2020
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 25 Dec 2020 16:10:05 +0000
Subject: [issue42727] [Enum] EnumMeta.__prepare__ needs to accept **kwds
In-Reply-To: <1608781282.89.0.997821175942.issue42727@roundup.psfhosted.org>
Message-ID: <1608912605.47.0.769437323523.issue42727@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
pull_requests:  -22792

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42727>
_______________________________________

From report at bugs.python.org  Fri Dec 25 11:32:43 2020
From: report at bugs.python.org (Anton Abrosimov)
Date: Fri, 25 Dec 2020 16:32:43 +0000
Subject: [issue42742] Add abc.Mapping to dataclass
Message-ID: <1608913963.27.0.877253757924.issue42742@roundup.psfhosted.org>


New submission from Anton Abrosimov <abrosimov.a.a at gmail.com>:

I want to add `abc.Mapping` extension to `dataclasses.dataclass`.

Motivation:

1. `asdict` makes a deep copy of the `dataclass` object. If I only want to iterate over the `field` attributes, I don't want to do a deep copy.
2. `dict(my_dataclass)` can be used as a `dict` representation of `my_dataclass` class without deep copying.
3. `myfunc(**my_dataclass)` looks better and is faster then `myfunc(**asdict(my_dataclass))`.
4. `len(my_dataclass) == len(asdict(my_dataclass))` is expected behavior.
5. `my_dataclass.my_field is my_dataclass['my_field']` is expected behavior.


Looks like a prototype:

from collections.abc import Mapping
from dataclasses import dataclass, fields, _FIELDS, _FIELD


@dataclass  # `(mapping=True)` creates such a class:
class MyDataclass(Mapping):
    a: int = 1
    b: int = 2

    # In `dataclasses._process_class`:
    # if `mapping` is `True`.
    # Make sure 'get', 'items', 'keys', 'values' is not in `MyDataclass` fields.

    def __iter__(self):
        return (f.name for f in fields(self))

    def __getitem__(self, key):
        fields = getattr(self, _FIELDS)
        f = fields[key]
        if f._field_type is not _FIELD:
            raise KeyError(f"'{key}' is not a field of the dataclass.")
        return getattr(self, f.name)

    def __len__(self):
        return len(fields(self))


my_dataclass = MyDataclass(b=3)
print(my_dataclass['a'])
print(my_dataclass['b'])
print(dict(my_dataclass))
print(dict(**my_dataclass))

Stdout:
1
3
{'a': 1, 'b': 3}
{'a': 1, 'b': 3}


Realisation:

Updating the `dataclasses.py`: `dataclass`, `_process_class`, `_DataclassParams`.
Set `mapping` argument to default `False`.


Can this enhancement be accepted?

----------
components: Library (Lib)
messages: 383752
nosy: abrosimov.a.a
priority: normal
severity: normal
status: open
title: Add abc.Mapping to dataclass
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42742>
_______________________________________

From report at bugs.python.org  Fri Dec 25 12:02:16 2020
From: report at bugs.python.org (Daniel Schreck)
Date: Fri, 25 Dec 2020 17:02:16 +0000
Subject: [issue42743] pdb vanishing breakpoints
Message-ID: <1608915736.39.0.746707238377.issue42743@roundup.psfhosted.org>


New submission from Daniel Schreck <daniel.s.schreck at gmail.com>:

Using pdb, breakpoints disappear when stepping into a function in another module. They're not hit from then on. HOWEVER, if any new breakpoint is entered, all the breakpoints reappear. They vanish every time the debugger steps across the module, and only reappear with a new breakpoint entry. Behavior is reproducible.

----------
messages: 383753
nosy: ds2606
priority: normal
severity: normal
status: open
title: pdb vanishing breakpoints
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42743>
_______________________________________

From report at bugs.python.org  Fri Dec 25 12:04:34 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 25 Dec 2020 17:04:34 +0000
Subject: [issue28964] AST literal_eval exceptions provide no information about
 line number
In-Reply-To: <1481665664.26.0.256194535172.issue28964@psf.upfronthosting.co.za>
Message-ID: <1608915874.11.0.908557386375.issue28964@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:


New changeset 586f3dbe15139cafb2a6ffb82cea146906561844 by Irit Katriel in branch 'master':
bpo-28964: add line number of node (if available) to ast.literal_eval error messages (GH-23677)
https://github.com/python/cpython/commit/586f3dbe15139cafb2a6ffb82cea146906561844


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28964>
_______________________________________

From report at bugs.python.org  Fri Dec 25 12:05:11 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Fri, 25 Dec 2020 17:05:11 +0000
Subject: [issue28964] AST literal_eval exceptions provide no information about
 line number
In-Reply-To: <1481665664.26.0.256194535172.issue28964@psf.upfronthosting.co.za>
Message-ID: <1608915911.99.0.116147103633.issue28964@roundup.psfhosted.org>


Change by Batuhan Taskaya <isidentical at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28964>
_______________________________________

From report at bugs.python.org  Fri Dec 25 12:23:40 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 25 Dec 2020 17:23:40 +0000
Subject: [issue42742] Add abc.Mapping to dataclass
In-Reply-To: <1608913963.27.0.877253757924.issue42742@roundup.psfhosted.org>
Message-ID: <1608917020.24.0.703655344599.issue42742@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

You'd need to return a different class in order to add the collections.abc.Mapping base class. Currently, dataclasses by design always return the same class that's passed in.

I'd suggest adding this as a stand-alone decorator.

----------
assignee:  -> eric.smith
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42742>
_______________________________________

From report at bugs.python.org  Fri Dec 25 13:19:27 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Dec 2020 18:19:27 +0000
Subject: [issue42721] Using of simple dialogs without default root window
In-Reply-To: <1608669340.97.0.219315442285.issue42721@roundup.psfhosted.org>
Message-ID: <1608920367.82.0.21974842635.issue42721@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 675c97eb6c7c14c6a68ebf476c52931c1e5c1220 by Serhiy Storchaka in branch 'master':
bpo-42721: Improve using simple dialogs without root window (GH-23897)
https://github.com/python/cpython/commit/675c97eb6c7c14c6a68ebf476c52931c1e5c1220


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42721>
_______________________________________

From report at bugs.python.org  Fri Dec 25 13:32:07 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 25 Dec 2020 18:32:07 +0000
Subject: [issue42736] Add support for making Linux prctl(...) calls to
 subprocess
In-Reply-To: <1608875716.63.0.116569716148.issue42736@roundup.psfhosted.org>
Message-ID: <1608921127.92.0.470305698267.issue42736@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

I wonder if a dedicated datatype should be created for all os-specific parameters like https://golang.org/pkg/syscall/#SysProcAttr. Popen already has way too many parameters. And prctl is a very general interface; probably 98% of prctls would never need to be called pre-exec.

(Separately, os.prctl should be created to expose prctl in all its multiplexed glory?)

(Also, but PDEATHSIG has an infamous footgun where the the signal is sent on exit of the forking thread, which is not necessarily the exit of the invoking process.)

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42736>
_______________________________________

From report at bugs.python.org  Fri Dec 25 13:57:35 2020
From: report at bugs.python.org (Anton Abrosimov)
Date: Fri, 25 Dec 2020 18:57:35 +0000
Subject: [issue42742] Add abc.Mapping to dataclass
In-Reply-To: <1608913963.27.0.877253757924.issue42742@roundup.psfhosted.org>
Message-ID: <1608922655.76.0.874479574566.issue42742@roundup.psfhosted.org>


Anton Abrosimov <abrosimov.a.a at gmail.com> added the comment:

Thanks for the answer, I agree.
The implementation should be like this?


from collections.abc import Mapping
from dataclasses import dataclass, fields, _FIELDS, _FIELD

class _DataclassMappingMixin(Mapping):
    def __iter__(self):
        return (f.name for f in fields(self))

    def __getitem__(self, key):
        fields = getattr(self, _FIELDS)
        f = fields[key]
        if f._field_type is not _FIELD:
            raise KeyError(f"'{key}' is not a dataclass field.")
        return getattr(self, f.name)

    def __len__(self):
        return len(fields(self))


def dataclass_mapping(cls=None, **kwargs):
    def apply_dataclass(cls):
        dataclass_wrap = dataclass(**kwargs)
        return dataclass_wrap(cls)

    def check_mapping_attrs(cls):
        mapping_attrs = (i for i in dir(_DataclassMappingMixin) if i[0] != '_')
        for key in mapping_attrs:
            if hasattr(cls, key):
                raise AttributeError(f"'{key}' is the Mapping reserved attribute.")

    def apply_mapping(cls):
        return type(cls.__name__ + 'Mapping',
                    (cls, _DataclassMappingMixin),
                    {})

    def wrap(cls):
        check_mapping_attrs(cls)
        cls_dataclass = apply_dataclass(cls)
        return apply_mapping(cls_dataclass)

    # See if we're being called as @dataclass or @dataclass().
    if cls is None:
        # We're called with parens.
        return wrap

    # We're called as @dataclass without parens.
    return wrap(cls)


@dataclass_mapping
class MyDataclass:
    a: int = 1
    b: int = 2


my_dataclass = MyDataclass(b='3')
print(my_dataclass.__class__.__name__)
print(my_dataclass['a'])
print(my_dataclass['b'])
print(dict(my_dataclass))
print(dict(**my_dataclass))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42742>
_______________________________________

From report at bugs.python.org  Fri Dec 25 14:14:42 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Fri, 25 Dec 2020 19:14:42 +0000
Subject: [issue42734] Outdated CodeType call in "bogus_code_obj.py"
In-Reply-To: <1608875129.15.0.565092953865.issue42734@roundup.psfhosted.org>
Message-ID: <1608923682.77.0.373414373916.issue42734@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

To make it slightly more readable and future-proof so such things don't become outdated again in the future, you could use the CodeType.replace() method.

See also https://bugs.python.org/issue42422

----------
nosy: +Dennis Sweeney

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42734>
_______________________________________

From report at bugs.python.org  Fri Dec 25 14:35:20 2020
From: report at bugs.python.org (RhinosF1)
Date: Fri, 25 Dec 2020 19:35:20 +0000
Subject: [issue42744] pkg_resources seems to treat python 3.10 as python 3.1
Message-ID: <1608924920.91.0.314661686668.issue42744@roundup.psfhosted.org>


New submission from RhinosF1 <rhinosf1 at gmail.com>:

As seen in https://github.com/MirahezeBots/MirahezeBots/pull/380/checks?check_run_id=1609121656, pkg_resources is throwing errors about version conflicts as it seems it thinks 3.10 is 3.1 or similar. This was fixed for PyPA/Pip in https://github.com/pypa/pip/issues/6730 so it installs from pip fine.

----------
components: Installation
messages: 383760
nosy: RhinosF1
priority: normal
severity: normal
status: open
title: pkg_resources seems to treat python 3.10 as python 3.1
type: compile error
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42744>
_______________________________________

From report at bugs.python.org  Fri Dec 25 14:43:34 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Dec 2020 19:43:34 +0000
Subject: [issue42721] Using of simple dialogs without default root window
In-Reply-To: <1608669340.97.0.219315442285.issue42721@roundup.psfhosted.org>
Message-ID: <1608925414.18.0.619295872664.issue42721@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/issue42721>
_______________________________________

From report at bugs.python.org  Fri Dec 25 14:46:13 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Dec 2020 19:46:13 +0000
Subject: [issue42734] Outdated CodeType call in "bogus_code_obj.py"
In-Reply-To: <1608875129.15.0.565092953865.issue42734@roundup.psfhosted.org>
Message-ID: <1608925573.25.0.925625060252.issue42734@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

To be honest, I was not sure that replace() exists in 3.8 and I was too lazy to write different code for different versions. Next time when bogus_code_obj.py become outdated again we will use replace().

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42734>
_______________________________________

From report at bugs.python.org  Fri Dec 25 14:48:59 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Dec 2020 19:48:59 +0000
Subject: [issue15303] Minor revision to the <BaseWidget._setup> method in
 Tkinter
In-Reply-To: <1341822350.55.0.995662615633.issue15303@psf.upfronthosting.co.za>
Message-ID: <1608925739.9.0.651896170695.issue15303@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15303>
_______________________________________

From report at bugs.python.org  Fri Dec 25 16:16:24 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 25 Dec 2020 21:16:24 +0000
Subject: [issue42742] Add abc.Mapping to dataclass
In-Reply-To: <1608913963.27.0.877253757924.issue42742@roundup.psfhosted.org>
Message-ID: <1608930984.67.0.834569518074.issue42742@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Something like that. You'd have to write some tests and try it out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42742>
_______________________________________

From report at bugs.python.org  Fri Dec 25 16:18:09 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Dec 2020 21:18:09 +0000
Subject: [issue35728] Tkinter font nametofont requires default root
In-Reply-To: <1547328812.09.0.281453810047.issue35728@roundup.psfhosted.org>
Message-ID: <1608931089.3.0.0647070436126.issue35728@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 36a779e64c580519550aa6478c5aa8c58b8fa7b6 by Desmond Cheong in branch 'master':
bpo-35728: Add root parameter to tkinter.font.nametofont() (GH-23885)
https://github.com/python/cpython/commit/36a779e64c580519550aa6478c5aa8c58b8fa7b6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35728>
_______________________________________

From report at bugs.python.org  Fri Dec 25 16:23:56 2020
From: report at bugs.python.org (Anton Abrosimov)
Date: Fri, 25 Dec 2020 21:23:56 +0000
Subject: [issue42742] Add abc.Mapping to dataclass
In-Reply-To: <1608913963.27.0.877253757924.issue42742@roundup.psfhosted.org>
Message-ID: <1608931436.16.0.784836766064.issue42742@roundup.psfhosted.org>


Anton Abrosimov <abrosimov.a.a at gmail.com> added the comment:

An alternative way:

from collections.abc import Mapping
from dataclasses import dataclass, fields, _FIELDS, _FIELD

class DataclassMappingMixin(Mapping):
    def __iter__(self):
        return (f.name for f in fields(self))

    def __getitem__(self, key):
        field = getattr(self, _FIELDS)[key]
        if field._field_type is not _FIELD:
            raise KeyError(f"'{key}' is not a dataclass field.")
        return getattr(self, field.name)

    def __len__(self):
        return len(fields(self))


@dataclass
class MyDataclass(DataclassMappingMixin):
    a: int = 1
    b: int = 2


my_dataclass = MyDataclass(a='3')
print(my_dataclass.__class__.__mro__)
print(my_dataclass.__class__.__name__)
print(my_dataclass['a'])
print(my_dataclass['b'])
print(dict(my_dataclass))
print(dict(**my_dataclass))
print(fields(my_dataclass))


Result:
(<class '__main__.MyDataclass'>,
 <class '__main__.DataclassMappingMixin'>,
 <class 'collections.abc.Mapping'>,
 <class 'collections.abc.Collection'>,
 <class 'collections.abc.Sized'>,
 <class 'collections.abc.Iterable'>,
 <class 'collections.abc.Container'>,
 <class 'object'>)
MyDataclass
3
2
{'a': '3', 'b': 2}
{'a': '3', 'b': 2}
(Field(name='a',type=<class 'int'>, ...),
 Field(name='b',type=<class 'int'>, ...))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42742>
_______________________________________

From report at bugs.python.org  Fri Dec 25 16:38:04 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Dec 2020 21:38:04 +0000
Subject: [issue39171] Missing default root in tkinter simpledialog.py
In-Reply-To: <1577780147.06.0.429247944585.issue39171@roundup.psfhosted.org>
Message-ID: <1608932283.99.0.273015718806.issue39171@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Issue42721 made possible to use these dialogs without default root window. A temporary hidden root window is created for the time of life of a dialog and it is not set as default root window.

Positioning dialog wit5hout parent was improved in issue42685.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39171>
_______________________________________

From report at bugs.python.org  Fri Dec 25 16:39:47 2020
From: report at bugs.python.org (Anton Abrosimov)
Date: Fri, 25 Dec 2020 21:39:47 +0000
Subject: [issue42742] Add abc.Mapping to dataclass
In-Reply-To: <1608913963.27.0.877253757924.issue42742@roundup.psfhosted.org>
Message-ID: <1608932387.37.0.34166365922.issue42742@roundup.psfhosted.org>


Anton Abrosimov <abrosimov.a.a at gmail.com> added the comment:

I think the second option looks better.
More pythonic.
No need to create new classes
No typing hacks.
Mixin can be easily expanded.

Yes, I will do refactoring, typing, documentation and tests in PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42742>
_______________________________________

From report at bugs.python.org  Fri Dec 25 16:42:57 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 25 Dec 2020 21:42:57 +0000
Subject: [issue42742] Add abc.Mapping to dataclass
In-Reply-To: <1608913963.27.0.877253757924.issue42742@roundup.psfhosted.org>
Message-ID: <1608932577.44.0.97783383148.issue42742@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I don't think this belongs in dataclasses itself, at least not until it's been vetted widely. You might want to put it on PyPI first as a standalone project.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42742>
_______________________________________

From report at bugs.python.org  Fri Dec 25 16:51:09 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Dec 2020 21:51:09 +0000
Subject: [issue39177] In tkinter, simple dialogs, askstrings,
 etc. with flexible coordinates and no viewable parent.
In-Reply-To: <1577863304.66.0.670645943584.issue39177@roundup.psfhosted.org>
Message-ID: <1608933069.25.0.0504635298391.issue39177@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Issue42685 improved positioning of dialog windows. Now they are centered at the parent window or screen if there is no parent. It corresponds to behavior of Tk message boxes.

Issue42721 made dialogs be usable without default root window. Temporary hidden root window can be creat3ed for the time of life of the dialog.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39177>
_______________________________________

From report at bugs.python.org  Fri Dec 25 16:56:35 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Dec 2020 21:56:35 +0000
Subject: [issue38649] tkinter messagebox is sloppy
In-Reply-To: <1572464225.7.0.112082789313.issue38649@roundup.psfhosted.org>
Message-ID: <1608933395.84.0.844540398343.issue38649@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I agree that there is a problem. tkinter.messagebox is poorly documented. Different functions can return True, False, None or the name of the button, and it is not specified which function what returns. Set of acceptable values for type and icon are not documented. And there are no tests, so we cannot be sure that all works as expected on all platforms.

I am working on it.

----------
assignee: docs at python -> serhiy.storchaka
components: +Tests
nosy: +serhiy.storchaka
versions: +Python 3.10 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38649>
_______________________________________

From report at bugs.python.org  Fri Dec 25 17:03:10 2020
From: report at bugs.python.org (Anton Abrosimov)
Date: Fri, 25 Dec 2020 22:03:10 +0000
Subject: [issue42742] Add abc.Mapping to dataclass
In-Reply-To: <1608913963.27.0.877253757924.issue42742@roundup.psfhosted.org>
Message-ID: <1608933790.6.0.129052090796.issue42742@roundup.psfhosted.org>


Anton Abrosimov <abrosimov.a.a at gmail.com> added the comment:

This Mixin only works with dataclass objects. And uses the private functionality of the dataclasses. So dataclasses.py is the right place for this. I think I can do enough tests.

And I think that this is too little for a standalone project.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42742>
_______________________________________

From report at bugs.python.org  Fri Dec 25 17:05:14 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 25 Dec 2020 22:05:14 +0000
Subject: [issue42742] Add abc.Mapping to dataclass
In-Reply-To: <1608913963.27.0.877253757924.issue42742@roundup.psfhosted.org>
Message-ID: <1608933914.99.0.288601050878.issue42742@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I'm just warning you that I probably won't accept it. I haven't heard of any demand for this feature.

You might want to bring it up on python-ideas if you want to generate support for the proposal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42742>
_______________________________________

From report at bugs.python.org  Fri Dec 25 17:10:21 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 25 Dec 2020 22:10:21 +0000
Subject: [issue40494] collections.abc.Callable and type variables
In-Reply-To: <1588579632.5.0.091811612876.issue40494@roundup.psfhosted.org>
Message-ID: <1608934221.77.0.321350511368.issue40494@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Indeed. Thanks!

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40494>
_______________________________________

From report at bugs.python.org  Fri Dec 25 17:18:58 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 25 Dec 2020 22:18:58 +0000
Subject: [issue42737] PEP 563: drop annotations for complex assign targets
In-Reply-To: <1608888770.02.0.483696766952.issue42737@roundup.psfhosted.org>
Message-ID: <1608934738.37.0.94713678481.issue42737@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

So the distinction between simple and complex is to define what goes into `__annotations__`. As long as we don't disturb that I think it's fine not to evaluate anything. (There's also the effect on what's considered a local variable, inside functions.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42737>
_______________________________________

From report at bugs.python.org  Fri Dec 25 17:20:46 2020
From: report at bugs.python.org (Anton Abrosimov)
Date: Fri, 25 Dec 2020 22:20:46 +0000
Subject: [issue42742] Add abc.Mapping to dataclass
In-Reply-To: <1608913963.27.0.877253757924.issue42742@roundup.psfhosted.org>
Message-ID: <1608934846.03.0.869696600021.issue42742@roundup.psfhosted.org>


Anton Abrosimov <abrosimov.a.a at gmail.com> added the comment:

Thanks for the good offer, I will definitely use it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42742>
_______________________________________

From report at bugs.python.org  Fri Dec 25 17:35:49 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Dec 2020 22:35:49 +0000
Subject: [issue42318] [tkinter] surrogate pairs in Tcl/Tk string when pasting
 an emoji in a text widget
In-Reply-To: <1605043338.18.0.398355808071.issue42318@roundup.psfhosted.org>
Message-ID: <1608935749.31.0.959439466838.issue42318@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 4d840e428ab1a2712f219c5e4008658cbe15892e by Miss Islington (bot) in branch '3.8':
[3.8] bpo-42318: Fix support of non-BMP characters in Tkinter on macOS (GH-23281). (GH-23784) (GH-23787)
https://github.com/python/cpython/commit/4d840e428ab1a2712f219c5e4008658cbe15892e


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42318>
_______________________________________

From report at bugs.python.org  Fri Dec 25 17:36:49 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 25 Dec 2020 22:36:49 +0000
Subject: [issue42318] [tkinter] surrogate pairs in Tcl/Tk string when pasting
 an emoji in a text widget
In-Reply-To: <1605043338.18.0.398355808071.issue42318@roundup.psfhosted.org>
Message-ID: <1608935809.39.0.478651070582.issue42318@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/issue42318>
_______________________________________

From report at bugs.python.org  Fri Dec 25 17:38:51 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 25 Dec 2020 22:38:51 +0000
Subject: [issue42222] Modernize integer test/conversion in randrange()
In-Reply-To: <1604165232.15.0.0916383458838.issue42222@roundup.psfhosted.org>
Message-ID: <1608935931.66.0.906835422809.issue42222@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

There is another randrange() oddity.  If stop is None, the step argument is ignored:

    >>> randrange(100, stop=None, step=10)
    4

If we want to fully harmonize with range(), then randrange() should only accept positional arguments and should not allow None for the stop argument.  That would leave the unoptimized implementation equivalent to:

    def randrange(self, /, *args):
        return self.choice(range(*args))

The actual implementation can retain its fast paths and have a nicer looking signature perhaps using __text_signature__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42222>
_______________________________________

From report at bugs.python.org  Fri Dec 25 17:50:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Dec 2020 22:50:34 +0000
Subject: [issue42745] [subinterpreters] Make the type lookup cache
 per-interpreter
Message-ID: <1608936634.73.0.0790209715879.issue42745@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Currently, the type lookup cache is shared by all interpreter which causes multiple issues:

* The version tag is currently protected by the GIL, but it would require a new lock if the GIL is made per interpreter (bpo-40512)

* Clearing the cache in an interpreter clears the cache in all interpreters

* The cache has a fixed size of 4096 entries. The cache misses increase with the number of interpreters, since each interpreter has its own types.

I propose to make the type lookup cache per interpreter.

----------
components: Interpreter Core, Subinterpreters
messages: 383777
nosy: vstinner
priority: normal
severity: normal
status: open
title: [subinterpreters] Make the type lookup cache per-interpreter
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42745>
_______________________________________

From report at bugs.python.org  Fri Dec 25 17:57:36 2020
From: report at bugs.python.org (Eric Snow)
Date: Fri, 25 Dec 2020 22:57:36 +0000
Subject: [issue36876] [subinterpreters] Global C variables are a problem
In-Reply-To: <1557514902.13.0.853517754348.issue36876@roundup.psfhosted.org>
Message-ID: <1608937056.72.0.0916639329845.issue36876@roundup.psfhosted.org>


Eric Snow <ericsnowcurrently at gmail.com> added the comment:


New changeset 5ae9be68d9f1a628fdc920b647257f94afb77887 by Eric Snow in branch 'master':
bpo-36876: [c-analyzer tool] Additional CLI updates for "capi" command. (gh-23929)
https://github.com/python/cpython/commit/5ae9be68d9f1a628fdc920b647257f94afb77887


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36876>
_______________________________________

From report at bugs.python.org  Fri Dec 25 18:08:44 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 25 Dec 2020 23:08:44 +0000
Subject: [issue42741] Sync 3.9's whatsnew document in 3.10 with 3.9 branch
In-Reply-To: <1608912254.65.0.400957747647.issue42741@roundup.psfhosted.org>
Message-ID: <1608937724.22.0.544723875127.issue42741@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/issue42741>
_______________________________________

From report at bugs.python.org  Fri Dec 25 18:22:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Dec 2020 23:22:40 +0000
Subject: [issue42745] [subinterpreters] Make the type attribute lookup cache
 per-interpreter
In-Reply-To: <1608936634.73.0.0790209715879.issue42745@roundup.psfhosted.org>
Message-ID: <1608938560.98.0.890491885812.issue42745@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: [subinterpreters] Make the type lookup cache per-interpreter -> [subinterpreters] Make the type attribute lookup cache per-interpreter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42745>
_______________________________________

From report at bugs.python.org  Fri Dec 25 18:35:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Dec 2020 23:35:58 +0000
Subject: [issue42745] [subinterpreters] Make the type attribute lookup cache
 per-interpreter
In-Reply-To: <1608936634.73.0.0790209715879.issue42745@roundup.psfhosted.org>
Message-ID: <1608939358.19.0.164739894341.issue42745@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +22795
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23947

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42745>
_______________________________________

From report at bugs.python.org  Fri Dec 25 18:36:19 2020
From: report at bugs.python.org (yaksha nyx)
Date: Fri, 25 Dec 2020 23:36:19 +0000
Subject: [issue42746] python3.7.3 - ssl.SSLContext() - "Killed"
Message-ID: <1608939379.31.0.291479274657.issue42746@roundup.psfhosted.org>


New submission from yaksha nyx <hgmmym at gmail.com>:

I got a very strange issue with my Python3.7.3.
I use ssl module with urllin.request , when I visit some https website my script always die .so I got this :

*******************************************************************
Python 3.7.3 (default, Dec 26 2020, 06:35:45)
[GCC 6.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ssl                                                                 >>> ssl.OPENSSL_VERSION
'LibreSSL 3.1.1'
>>> ssl.SSLContext()
Killed
*******************************************************************

Just "Killed" , no more infomation . 
How to check this problem ?

----------
assignee: christian.heimes
components: SSL
messages: 383779
nosy: christian.heimes, hgmmym
priority: normal
severity: normal
status: open
title: python3.7.3 - ssl.SSLContext() - "Killed"
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42746>
_______________________________________

From report at bugs.python.org  Fri Dec 25 18:39:03 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Dec 2020 23:39:03 +0000
Subject: [issue40512] [subinterpreters] Meta issue: per-interpreter GIL
In-Reply-To: <1588683075.13.0.0239787407564.issue40512@roundup.psfhosted.org>
Message-ID: <1608939543.58.0.877697938142.issue40512@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Type method cache is shared.

I created bpo-42745: "[subinterpreters] Make the type attribute lookup cache per-interpreter".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40512>
_______________________________________

From report at bugs.python.org  Fri Dec 25 18:41:56 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Dec 2020 23:41:56 +0000
Subject: [issue39465] [subinterpreters] Design a subinterpreter friendly
 alternative to _Py_IDENTIFIER
In-Reply-To: <1580135310.72.0.978238650594.issue39465@roundup.psfhosted.org>
Message-ID: <1608939716.86.0.598413975911.issue39465@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset ba3d67c2fb04a7842741b1b6da5d67f22c579f33 by Victor Stinner in branch 'master':
bpo-39465: Fix _PyUnicode_FromId() for subinterpreters (GH-20058)
https://github.com/python/cpython/commit/ba3d67c2fb04a7842741b1b6da5d67f22c579f33


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39465>
_______________________________________

From report at bugs.python.org  Fri Dec 25 18:48:07 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Dec 2020 23:48:07 +0000
Subject: [issue42747] Remove Py_TPFLAGS_HAVE_VERSION_TAG flag?
Message-ID: <1608940087.88.0.458230907712.issue42747@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

Since the PyTypeObject structure is excluded from the limited C API and the stable ABI on purpose (PEP 384), I don't see the purpose of the Py_TPFLAGS_HAVE_VERSION_TAG flag.

Moreover, a new flag was added recently:

#if !defined(Py_LIMITED_API) || Py_LIMITED_API+0 >= 0x030A0000
/* Type has am_send entry in tp_as_async slot */
#define Py_TPFLAGS_HAVE_AM_SEND (1UL << 21)
#endif

Should it be also removed?


For example, Py_TPFLAGS_HAVE_FINALIZE was deprecated in bpo-32388 by:

commit ada319bb6d0ebcc68d3e0ef2b4279ea061877ac8
Author: Antoine Pitrou <antoine at python.org>
Date:   Wed May 29 22:12:38 2019 +0200

    bpo-32388: Remove cross-version binary compatibility requirement in tp_flags (GH-4944)
    
    It is now allowed to add new fields at the end of the PyTypeObject struct without having to allocate a dedicated compatibility flag i
n tp_flags.
    
    This will reduce the risk of running out of bits in the 32-bit tp_flags value.


By the way, is it worth it to remove Py_TPFLAGS_HAVE_FINALIZE? Or is it going to break too many extension modules?

----------
components: C API
messages: 383782
nosy: petr.viktorin, pitrou, vstinner
priority: normal
severity: normal
status: open
title: Remove Py_TPFLAGS_HAVE_VERSION_TAG flag?
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42747>
_______________________________________

From report at bugs.python.org  Fri Dec 25 18:49:32 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Dec 2020 23:49:32 +0000
Subject: [issue39465] [subinterpreters] Design a subinterpreter friendly
 alternative to _Py_IDENTIFIER
In-Reply-To: <1580135310.72.0.978238650594.issue39465@roundup.psfhosted.org>
Message-ID: <1608940172.66.0.562694143208.issue39465@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39465>
_______________________________________

From report at bugs.python.org  Fri Dec 25 18:49:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 25 Dec 2020 23:49:25 +0000
Subject: [issue39465] [subinterpreters] Design a subinterpreter friendly
 alternative to _Py_IDENTIFIER
In-Reply-To: <1580135310.72.0.978238650594.issue39465@roundup.psfhosted.org>
Message-ID: <1608940165.1.0.53757975558.issue39465@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Ok, it should now be fixed. I close the issue.

See PR 20085 "Per-interpreter interned strings" of bpo-40521 for the follow-up.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39465>
_______________________________________

From report at bugs.python.org  Fri Dec 25 19:38:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Dec 2020 00:38:18 +0000
Subject: [issue42694] Failed test_new_curses_panel in test_curses
In-Reply-To: <1608498600.94.0.0759010269747.issue42694@roundup.psfhosted.org>
Message-ID: <1608943098.21.0.540244321049.issue42694@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
keywords: +patch
pull_requests: +22796
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23948

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42694>
_______________________________________

From report at bugs.python.org  Fri Dec 25 19:40:21 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Dec 2020 00:40:21 +0000
Subject: [issue42694] Failed test_new_curses_panel in test_curses
In-Reply-To: <1608498600.94.0.0759010269747.issue42694@roundup.psfhosted.org>
Message-ID: <1608943221.98.0.899155759594.issue42694@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I can reproduce the issue with the command:

./python -m test -u all test_curses

I wrote PR 23948 to fix the regression.

Note: "./python -m test test_curses" doesn't fail since the test is skipped.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42694>
_______________________________________

From report at bugs.python.org  Fri Dec 25 19:42:13 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Dec 2020 00:42:13 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1608943333.76.0.766488148897.issue1635741@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> These changes introduced a regression in test_curses (see issue42694). And I afraid then introduced regressions in other modules for which there were not purposed tests.

In my experience, when a type is modified to prevent creating an instance using type(), there is a test for that. The issue with bpo-42694 is that test_curses is skipped by default, and it might be skipped on buildbots which don't have curses.

(I wrote a fix for bpo-42694, but let's discuss it there.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Fri Dec 25 19:42:59 2020
From: report at bugs.python.org (mohamed koubaa)
Date: Sat, 26 Dec 2020 00:42:59 +0000
Subject: [issue42694] Failed test_new_curses_panel in test_curses
In-Reply-To: <1608498600.94.0.0759010269747.issue42694@roundup.psfhosted.org>
Message-ID: <1608943379.03.0.653365766662.issue42694@roundup.psfhosted.org>


Change by mohamed koubaa <koubaa.m at gmail.com>:


----------
nosy: +koubaa
nosy_count: 2.0 -> 3.0
pull_requests: +22797
pull_request: https://github.com/python/cpython/pull/21986

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42694>
_______________________________________

From report at bugs.python.org  Fri Dec 25 19:45:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Dec 2020 00:45:46 +0000
Subject: [issue42745] [subinterpreters] Make the type attribute lookup cache
 per-interpreter
In-Reply-To: <1608936634.73.0.0790209715879.issue42745@roundup.psfhosted.org>
Message-ID: <1608943546.55.0.976044035792.issue42745@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 41010184880151d6ae02a226dbacc796e5c90d11 by Victor Stinner in branch 'master':
bpo-42745: Make the type cache per-interpreter (GH-23947)
https://github.com/python/cpython/commit/41010184880151d6ae02a226dbacc796e5c90d11


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42745>
_______________________________________

From report at bugs.python.org  Fri Dec 25 19:46:02 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Dec 2020 00:46:02 +0000
Subject: [issue42745] [subinterpreters] Make the type attribute lookup cache
 per-interpreter
In-Reply-To: <1608936634.73.0.0790209715879.issue42745@roundup.psfhosted.org>
Message-ID: <1608943562.85.0.330590606653.issue42745@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42745>
_______________________________________

From report at bugs.python.org  Fri Dec 25 19:56:19 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Dec 2020 00:56:19 +0000
Subject: [issue42687] tokenize module does not recognize Barry as FLUFL
In-Reply-To: <1608392787.93.0.861284496438.issue42687@roundup.psfhosted.org>
Message-ID: <1608944179.17.0.62699230757.issue42687@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I strongly disagree.  '<>' is not a legal operator any more.  It is a parse-time syntax error.  Whatever historical artifact is left in the CPython tokenizer, recognizing '<>' is not exposed to Python code.

>>> p = ast.parse('a <> b')
Traceback (most recent call last):
...
    a <> b
    ^
SyntaxError: invalid syntax  

When '<>' was legal, we may presume that tokenizer recognized it, so that not recognizing it was an intentional change.  Reverting this would be a dis-service to users.  

I think that the PR and this issue should be closed.  If the historical artifact bothers you, propose removing it instead on introducing a bug into tokenizer.

----------
nosy: +terry.reedy
type:  -> enhancement
versions:  -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42687>
_______________________________________

From report at bugs.python.org  Fri Dec 25 20:18:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Dec 2020 01:18:04 +0000
Subject: [issue42694] Failed test_new_curses_panel in test_curses
In-Reply-To: <1608498600.94.0.0759010269747.issue42694@roundup.psfhosted.org>
Message-ID: <1608945484.76.0.147753048367.issue42694@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 993e88cf08994f7c1e0f9f62fda4ed32634ee2ad by Victor Stinner in branch 'master':
bpo-42694: Prevent creating _curses_panel.panel (GH-23948)
https://github.com/python/cpython/commit/993e88cf08994f7c1e0f9f62fda4ed32634ee2ad


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42694>
_______________________________________

From report at bugs.python.org  Fri Dec 25 20:18:28 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Dec 2020 01:18:28 +0000
Subject: [issue42694] Failed test_new_curses_panel in test_curses
In-Reply-To: <1608498600.94.0.0759010269747.issue42694@roundup.psfhosted.org>
Message-ID: <1608945508.31.0.730354106338.issue42694@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42694>
_______________________________________

From report at bugs.python.org  Fri Dec 25 20:33:34 2020
From: report at bugs.python.org (Ned Deily)
Date: Sat, 26 Dec 2020 01:33:34 +0000
Subject: [issue42257] platform.libc_ver() doesn't consider in case of
 executable is empty string
In-Reply-To: <1604469715.55.0.889552705694.issue42257@roundup.psfhosted.org>
Message-ID: <1608946414.13.0.0303742428218.issue42257@roundup.psfhosted.org>


Change by Ned Deily <nad at python.org>:


----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42257>
_______________________________________

From report at bugs.python.org  Fri Dec 25 20:40:38 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Dec 2020 01:40:38 +0000
Subject: [issue42716] Segmentation fault in running ast.parse() with large
 expression size.
In-Reply-To: <1608632493.48.0.125975965886.issue42716@roundup.psfhosted.org>
Message-ID: <1608946838.96.0.825231518895.issue42716@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Segmentation fault in running ast.literal_eval() with large expression size.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42716>
_______________________________________

From report at bugs.python.org  Fri Dec 25 20:41:01 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Dec 2020 01:41:01 +0000
Subject: [issue42715] Segmentation fault in running exec() with large
 expression size.
In-Reply-To: <1608632437.39.0.152674435504.issue42715@roundup.psfhosted.org>
Message-ID: <1608946861.53.0.721862821059.issue42715@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Segmentation fault in running ast.literal_eval() with large expression size.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42715>
_______________________________________

From report at bugs.python.org  Fri Dec 25 20:41:26 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Dec 2020 01:41:26 +0000
Subject: [issue42714] Segmentation fault in running compile() with large
 expression size.
In-Reply-To: <1608632387.72.0.614247098104.issue42714@roundup.psfhosted.org>
Message-ID: <1608946886.49.0.888557942821.issue42714@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Segmentation fault in running ast.literal_eval() with large expression size.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42714>
_______________________________________

From report at bugs.python.org  Fri Dec 25 20:41:57 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Dec 2020 01:41:57 +0000
Subject: [issue42713] Segmentation fault in running eval() with large
 expression size.
In-Reply-To: <1608632323.64.0.924637507568.issue42713@roundup.psfhosted.org>
Message-ID: <1608946917.26.0.0395427398338.issue42713@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Segmentation fault in running ast.literal_eval() with large expression size.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42713>
_______________________________________

From report at bugs.python.org  Fri Dec 25 20:58:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Dec 2020 01:58:40 +0000
Subject: [issue40521] [subinterpreters] Make free lists and unicode caches
 per-interpreter
In-Reply-To: <1588693682.5.0.219755904926.issue40521@roundup.psfhosted.org>
Message-ID: <1608947920.8.0.678406584287.issue40521@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset ea251806b8dffff11b30d2182af1e589caf88acf by Victor Stinner in branch 'master':
bpo-40521: Per-interpreter interned strings (GH-20085)
https://github.com/python/cpython/commit/ea251806b8dffff11b30d2182af1e589caf88acf


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40521>
_______________________________________

From report at bugs.python.org  Fri Dec 25 21:00:18 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Dec 2020 02:00:18 +0000
Subject: [issue40521] [subinterpreters] Make free lists and unicode caches
 per-interpreter
In-Reply-To: <1588693682.5.0.219755904926.issue40521@roundup.psfhosted.org>
Message-ID: <1608948018.78.0.158277540262.issue40521@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> bpo-40521: Per-interpreter interned strings (GH-20085)

That one wasn't easy, but it's now done! I close the issue.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10 -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40521>
_______________________________________

From report at bugs.python.org  Fri Dec 25 21:19:55 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Dec 2020 02:19:55 +0000
Subject: [issue42733] io's r+ mode truncate(0)
In-Reply-To: <1608866591.42.0.709266826628.issue42733@roundup.psfhosted.org>
Message-ID: <1608949195.36.0.0121566431562.issue42733@roundup.psfhosted.org>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

"Enhancements" (non-bugfix feature changes) can only be applied to future versions.  However, you are asking for the reversion of an intentional feature change made in a 'bugfix' release# for (I believe) 3.1.  Before the change, as I remember, truncating to 0 *did* move the file pointer back to 0.  As I remember, Guide von Rossum requested the change and Antoine Pitrou made it.  

https://docs.python.org/3/library/io.html#io.IOBase.seek
new says "The current stream position isn?t changed."

If you also want to change the stream position, do it with seek(), perhaps before the truncate.

# This change in a bugfix release, a violation the rule stated above, broke the code of multiple people.  (We thereafter strengthened the  policy.)  To fix my code, I had to add a seek(0).  I put it before truncate(0), so I know that this works.

----------
nosy: +terry.reedy
resolution:  -> rejected
stage:  -> resolved
status: open -> closed
title: [issue] io's r+ mode truncate(0) -> io's r+ mode truncate(0)
versions: +Python 3.10 -Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42733>
_______________________________________

From report at bugs.python.org  Fri Dec 25 21:20:18 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 26 Dec 2020 02:20:18 +0000
Subject: [issue42733] [issue] io's r+ mode truncate(0)
In-Reply-To: <1608903111.41.0.800279345559.issue42733@roundup.psfhosted.org>
Message-ID: <20201226022004.GU28254@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

On Fri, Dec 25, 2020 at 01:31:51PM +0000, ??? wrote:

> first test have a problem,you didn?t use r+ mode

I did, I copied your `test()` function exactly, however I did make a 
mistake. I tried again with this:

>>> with open(FILE_PATH, 'r') as f:
...     print(repr(f.read()))
... 
'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00{"how_dare_you": 
"how_dare_you"}'

so you are correct, the file is padded with NUL characters.

Here is a simpler demonstration of the behaviour.

```
FILE_PATH = 'example.data'

# create a file
with open(FILE_PATH, 'w') as f:
    f.write('abc\n')

# Truncate using r+ mode.
with open(FILE_PATH, 'r+') as f:
    assert f.tell() == 0
    assert f.read() == 'abc\n'
    assert f.tell() == 4  # File position is now at end of file.
    f.truncate(0)
    assert f.tell() == 4  # File position has not changed.
    assert f.read() == ''  # Nothing remaining to read.
    f.write('xyz\n')
    f.flush()
    assert f.tell() == 8
    assert f.read() == ''  # Nothing remaining to read.
    # Return the file position to start of file.
    f.seek(0)
    assert f.read() == '\0\0\0\0xyz\n'

```

All the assertions pass.

I think this is standard and correct behaviour. Do you have examples of 
other programming languages that behave differently? PHP seems to do the 
same thing:

https://www.php.net/manual/en/function.ftruncate.php

----------
title: io's r+ mode truncate(0) -> [issue] io's r+ mode truncate(0)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42733>
_______________________________________

From report at bugs.python.org  Fri Dec 25 21:22:13 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 26 Dec 2020 02:22:13 +0000
Subject: [issue42735] "trace_at_recursion_limit.py" should be removed from
 "Python/Lib/test/crashers"
In-Reply-To: <1608875329.89.0.262110269237.issue42735@roundup.psfhosted.org>
Message-ID: <1608949333.36.0.374233531191.issue42735@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +serhiy.storchaka
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42735>
_______________________________________

From report at bugs.python.org  Fri Dec 25 21:55:28 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 26 Dec 2020 02:55:28 +0000
Subject: [issue42733] io's r+ mode truncate(0)
In-Reply-To: <1608949195.36.0.0121566431562.issue42733@roundup.psfhosted.org>
Message-ID: <20201226025515.GV28254@ando.pearwood.info>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

On Sat, Dec 26, 2020 at 02:19:55AM +0000, Terry J. Reedy wrote:

> "Enhancements" (non-bugfix feature changes) can only be applied to 
> future versions.  However, you are asking for the reversion of an 
> intentional feature change made in a 'bugfix' release# for (I believe) 
> 3.1.  Before the change, as I remember, truncating to 0 *did* move the 
> file pointer back to 0.  As I remember, Guide von Rossum requested the 
> change and Antoine Pitrou made it.

Thanks for that insight Terry. I think the current behaviour is correct. 
Sparse files can have holes in them, and non-sparse files have to be 
filled with NUL bytes, so this has to work:

    f.truncate(0)
    f.seek(10)
    f.write('x')
    # File is now ten NUL bytes and a single 'x'

If you swap the order of the truncate and the seek, the behaviour 
shouldn't change: truncate is documented as not moving the file 
position, so changing this will be backwards incompatible and will 
probably break a lot of code that expects the current behaviour.

https://docs.python.org/3/library/io.html#io.IOBase.truncate

I agree with Terry rejecting this feature request. If ??? (Sh?w?n 
F?ng according to Google translate) wishes to disagree, this will have 
to be discussed on the Python-Ideas mailing list first.

----------
title: [issue] io's r+ mode truncate(0) -> io's r+ mode truncate(0)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42733>
_______________________________________

From report at bugs.python.org  Sat Dec 26 01:03:28 2020
From: report at bugs.python.org (Shantanu)
Date: Sat, 26 Dec 2020 06:03:28 +0000
Subject: [issue16396] Importing ctypes.wintypes on Linux gives a ValueError
 instead of an ImportError
In-Reply-To: <1351956172.0.0.64927799046.issue16396@psf.upfronthosting.co.za>
Message-ID: <1608962608.15.0.701795400656.issue16396@roundup.psfhosted.org>


Change by Shantanu <hauntsaninja at gmail.com>:


----------
nosy: +hauntsaninja
nosy_count: 12.0 -> 13.0
pull_requests: +22798
pull_request: https://github.com/python/cpython/pull/23951

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16396>
_______________________________________

From report at bugs.python.org  Sat Dec 26 02:13:41 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 26 Dec 2020 07:13:41 +0000
Subject: [issue42687] tokenize module does not recognize Barry as FLUFL
In-Reply-To: <1608392787.93.0.861284496438.issue42687@roundup.psfhosted.org>
Message-ID: <1608966821.07.0.253528497593.issue42687@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

I concur with Terry.

----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42687>
_______________________________________

From report at bugs.python.org  Sat Dec 26 02:25:53 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 26 Dec 2020 07:25:53 +0000
Subject: [issue42748] test_asdl_parser: load_module() method is deprecated
Message-ID: <1608967553.31.0.855033389199.issue42748@roundup.psfhosted.org>


New submission from Batuhan Taskaya <isidentical at gmail.com>:

Running test_asdl_parser raises a deprecation warning:
0:00:26 load avg: 1.05 [ 23/426] test_asdl_parser
<frozen importlib._bootstrap>:283: DeprecationWarning: the load_module() method is deprecated and slated for removal in Python 3.12; use exec_module() instead

probably related with this line:
https://github.com/python/cpython/blob/ea251806b8dffff11b30d2182af1e589caf88acf/Lib/test/test_asdl_parser.py#L29

----------
messages: 383795
nosy: BTaskaya
priority: normal
severity: normal
status: open
title: test_asdl_parser: load_module() method is deprecated

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42748>
_______________________________________

From report at bugs.python.org  Sat Dec 26 02:39:54 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 26 Dec 2020 07:39:54 +0000
Subject: [issue42737] PEP 563: drop annotations for complex assign targets
In-Reply-To: <1608888770.02.0.483696766952.issue42737@roundup.psfhosted.org>
Message-ID: <1608968394.66.0.878505226657.issue42737@roundup.psfhosted.org>


Change by Batuhan Taskaya <isidentical at gmail.com>:


----------
keywords: +patch
pull_requests: +22799
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23952

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42737>
_______________________________________

From report at bugs.python.org  Sat Dec 26 02:40:18 2020
From: report at bugs.python.org (xitop)
Date: Sat, 26 Dec 2020 07:40:18 +0000
Subject: [issue38085] Interrupting class creation in __init_subclass__ may
 lead to incorrect isinstance() and issubclass() results
In-Reply-To: <1568106581.16.0.558052842785.issue38085@roundup.psfhosted.org>
Message-ID: <1608968418.88.0.768701110635.issue38085@roundup.psfhosted.org>


xitop <reg.bugs at poti.sk> added the comment:

Python 3.9.1 is affected too.

----------
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38085>
_______________________________________

From report at bugs.python.org  Sat Dec 26 04:20:51 2020
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sat, 26 Dec 2020 09:20:51 +0000
Subject: [issue42738] subprocess: don't close all file descriptors by default
 (close_fds=False)
In-Reply-To: <1608897183.26.0.576206535349.issue42738@roundup.psfhosted.org>
Message-ID: <1608974451.12.0.513093964637.issue42738@roundup.psfhosted.org>


Alexey Izbyshev <izbyshev at ispras.ru> added the comment:

> Using close_fds=False, subprocess can use posix_spawn() which is safer and faster than fork+exec. For example, on Linux, the glibc implements it as a function using vfork which is faster than fork if the parent allocated a lot of memory. On macOS, posix_spawn() is even a syscall.

On Linux, unless you care specifically about users with Python 3.10+ on older kernels, implementing support for closerange() syscall in subprocess would provide better net benefit. This is because (a) performance advantage of posix_spawn() is no longer relevant on Linux after bpo-35823 and (b) supporting closerange() would benefit even those users who still need close_fds=True.

----------
nosy: +izbyshev

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42738>
_______________________________________

From report at bugs.python.org  Sat Dec 26 04:24:25 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 Dec 2020 09:24:25 +0000
Subject: [issue42737] PEP 563: drop annotations for complex assign targets
In-Reply-To: <1608888770.02.0.483696766952.issue42737@roundup.psfhosted.org>
Message-ID: <1608974665.39.0.235190254769.issue42737@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Alternatively it could be evaluated in global scope. All names are globals (non-global names do not work in MyPy in any case), yield and await are forbidden outside function. It will still perform run-time check which was an initial intention.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42737>
_______________________________________

From report at bugs.python.org  Sat Dec 26 04:53:42 2020
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sat, 26 Dec 2020 09:53:42 +0000
Subject: [issue38435] Start the deprecation cycle for subprocess preexec_fn
In-Reply-To: <1570731497.4.0.313201495913.issue38435@roundup.psfhosted.org>
Message-ID: <1608976422.97.0.478166659055.issue38435@roundup.psfhosted.org>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
nosy: +izbyshev

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38435>
_______________________________________

From report at bugs.python.org  Sat Dec 26 04:54:00 2020
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sat, 26 Dec 2020 09:54:00 +0000
Subject: [issue42736] Add support for making Linux prctl(...) calls to
 subprocess
In-Reply-To: <1608875716.63.0.116569716148.issue42736@roundup.psfhosted.org>
Message-ID: <1608976440.87.0.322830742423.issue42736@roundup.psfhosted.org>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
nosy: +izbyshev

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42736>
_______________________________________

From report at bugs.python.org  Sat Dec 26 05:25:42 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 Dec 2020 10:25:42 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1608978342.41.0.121020284.issue1635741@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The pitfall of PyType_FromModuleAndSpec() is that it makes types instantiable by default if tp_new is not provided. Created objects can crash when you try to use them because they are not properly initialized.

When there was few uses of PyType_FromModuleAndSpec() I fixed them and added tests, but now there are much more types created with PyType_FromModuleAndSpec(). Please check all other uses of PyType_FromModuleAndSpec(), add workarounds and tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Sat Dec 26 05:27:27 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 26 Dec 2020 10:27:27 +0000
Subject: [issue42737] PEP 563: drop annotations for complex assign targets
In-Reply-To: <1608888770.02.0.483696766952.issue42737@roundup.psfhosted.org>
Message-ID: <1608978447.36.0.753820044724.issue42737@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

> It will still perform run-time check which was an initial intention.

Well, at least from my personal perspective, I'd expect all annotations to behave like strings regardless of their targets.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42737>
_______________________________________

From report at bugs.python.org  Sat Dec 26 05:52:39 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Dec 2020 10:52:39 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1608979959.15.0.92636829336.issue1635741@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I checked for ^.*tp_new.*=.*NULL regex in "git log -p" command output. I checked all commits up to May 8 2016, the commit which added:

+    ((PyTypeObject *)v)->tp_new = NULL;

I met "FlagsType.tp_new = NULL;" multiple times since the code moved multiple times.

Apart of the issue in _curses_panel.panel, I didn't see any other removal by mistake. In this issue, the work started in 2019, so I consider that it's ok. No other tp_new=NULL was removed by mistake.

Again, if tp_new=NULL is used, I suggest to write a function test to ensure that it's not possible to instanciate the type.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Sat Dec 26 06:07:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Dec 2020 11:07:51 +0000
Subject: [issue42745] [subinterpreters] Make the type attribute lookup cache
 per-interpreter
In-Reply-To: <1608936634.73.0.0790209715879.issue42745@roundup.psfhosted.org>
Message-ID: <1608980871.2.0.799026494916.issue42745@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22800
pull_request: https://github.com/python/cpython/pull/23953

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42745>
_______________________________________

From report at bugs.python.org  Sat Dec 26 06:11:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Dec 2020 11:11:58 +0000
Subject: [issue42749] test_tcl failed on 32-bit POWER6 AIX 3.9: big int issue
 with 9223372036854775808
Message-ID: <1608981118.95.0.264551211038.issue42749@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

POWER6 AIX 3.9:
https://buildbot.python.org/all/#/builders/330/builds/221

test.pythoninfo:

platform.architecture: 32bit
platform.platform: AIX-2-00F9C1964C00-powerpc-32bit
tkinter.TCL_VERSION: 8.4
tkinter.TK_VERSION: 8.4
tkinter.info_patchlevel: 8.5.9

======================================================================
FAIL: test_expr_bignum (test.test_tcl.TclTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aixtools/buildarea/3.9.aixtools-aix-power6/build/Lib/test/test_tcl.py", line 441, in test_expr_bignum
    self.assertEqual(result, i)
AssertionError: <bignum object: '9223372036854775808'> != 9223372036854775808

======================================================================
FAIL: test_getint (test.test_tcl.TclTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aixtools/buildarea/3.9.aixtools-aix-power6/build/Lib/test/test_tcl.py", line 148, in test_getint
    self.assertEqual(tcl.getint(' %d ' % i), i)
AssertionError: -9223372036854775808 != 9223372036854775808

======================================================================
FAIL: test_passing_values (test.test_tcl.TclTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aixtools/buildarea/3.9.aixtools-aix-power6/build/Lib/test/test_tcl.py", line 475, in test_passing_values
    self.assertEqual(passValue(i), i if self.wantobjects else str(i))
AssertionError: '9223372036854775808' != 9223372036854775808

----------------------------------------------------------------------

----------
components: Tests, Tkinter
messages: 383802
nosy: gpolo, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: test_tcl failed on 32-bit POWER6 AIX 3.9: big int issue with 9223372036854775808
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42749>
_______________________________________

From report at bugs.python.org  Sat Dec 26 06:36:01 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 26 Dec 2020 11:36:01 +0000
Subject: [issue42748] test_asdl_parser: load_module() method is deprecated
In-Reply-To: <1608967553.31.0.855033389199.issue42748@roundup.psfhosted.org>
Message-ID: <1608982561.96.0.736320750791.issue42748@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
keywords: +patch
nosy: +corona10
nosy_count: 1.0 -> 2.0
pull_requests: +22801
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23954

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42748>
_______________________________________

From report at bugs.python.org  Sat Dec 26 06:47:39 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 Dec 2020 11:47:39 +0000
Subject: [issue42749] test_tcl failed on 32-bit POWER6 AIX 3.9: big int issue
 with 9223372036854775808
In-Reply-To: <1608981118.95.0.264551211038.issue42749@roundup.psfhosted.org>
Message-ID: <1608983259.91.0.228164445617.issue42749@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Interesting that static version is 8.4, but pathlevel is 8.5.9. It means that Tkinter is built with older version of headers and does not support bignum type, but dynamically linked to newer library which can create bignum objects.

There is a problem with tests. They should be skipped if Tkinter is built with old Tcl headers (it is not easy to do reliable). But there is also a problem with configuration which founds too old headers.

----------
nosy: +David.Edelsohn

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42749>
_______________________________________

From report at bugs.python.org  Sat Dec 26 07:12:10 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 Dec 2020 12:12:10 +0000
Subject: [issue42749] test_tcl failed on 32-bit POWER6 AIX 3.9: big int issue
 with 9223372036854775808
In-Reply-To: <1608981118.95.0.264551211038.issue42749@roundup.psfhosted.org>
Message-ID: <1608984730.64.0.115304658678.issue42749@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +22802
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23955

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42749>
_______________________________________

From report at bugs.python.org  Sat Dec 26 08:25:40 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 26 Dec 2020 13:25:40 +0000
Subject: [issue42748] test_asdl_parser: load_module() method is deprecated
In-Reply-To: <1608967553.31.0.855033389199.issue42748@roundup.psfhosted.org>
Message-ID: <1608989140.21.0.0216024843157.issue42748@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:


New changeset 0b281f94b9e5f117d774a1e4e834e797b2b21438 by Dong-hee Na in branch 'master':
bpo-42748: test_asdl_parser now uses exec_module instead of load_module (#23954)
https://github.com/python/cpython/commit/0b281f94b9e5f117d774a1e4e834e797b2b21438


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42748>
_______________________________________

From report at bugs.python.org  Sat Dec 26 08:26:30 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 26 Dec 2020 13:26:30 +0000
Subject: [issue42748] test_asdl_parser: load_module() method is deprecated
In-Reply-To: <1608967553.31.0.855033389199.issue42748@roundup.psfhosted.org>
Message-ID: <1608989190.31.0.779502957017.issue42748@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
components: +Tests
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> enhancement
versions: +Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42748>
_______________________________________

From report at bugs.python.org  Sat Dec 26 08:43:44 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 Dec 2020 13:43:44 +0000
Subject: [issue42735] "trace_at_recursion_limit.py" should be removed from
 "Python/Lib/test/crashers"
In-Reply-To: <1608875329.89.0.262110269237.issue42735@roundup.psfhosted.org>
Message-ID: <1608990224.09.0.973507945013.issue42735@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The initial issue6717 is still open. Are you sure that the bug was fixed rater than that the crasher is outdated?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42735>
_______________________________________

From report at bugs.python.org  Sat Dec 26 08:58:36 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 26 Dec 2020 13:58:36 +0000
Subject: [issue42042] sphinx3 renders diffrently docs.python.org for 3.10
In-Reply-To: <1602763041.43.0.432643801896.issue42042@roundup.psfhosted.org>
Message-ID: <1608991116.77.0.375676311456.issue42042@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:

@pablogsal @rhettinger @mdk @Mariatta

Cool!! everything looks okay!
Now I close this issue.

Thank you to everyone who works on this issue!!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42042>
_______________________________________

From report at bugs.python.org  Sat Dec 26 10:06:16 2020
From: report at bugs.python.org (Ivo Shipkaliev)
Date: Sat, 26 Dec 2020 15:06:16 +0000
Subject: [issue42750] tkinter.Variable equality consistency
Message-ID: <1608995176.07.0.806534213214.issue42750@roundup.psfhosted.org>


New submission from Ivo Shipkaliev <ivo.shipkaliev at gmail.com>:

Greetings!

I just noticed:

>>> import tkinter as tk
>>> root = tk.Tk()

>>> str_0 = tk.StringVar()
>>> str_0.set("same value")

>>> str_1 = tk.StringVar()
>>> str_1.set("same value")

So:

>>> str_0.get() == str_1.get()
True

But:

>>> str_0 == str_1
False

So, maybe a Variable should be compared by value, and not by identity (._name) as currently? (please view attached) Does it make sense?

----------
components: Tkinter
files: equality.diff
keywords: patch
messages: 383807
nosy: epaine, serhiy.storchaka, shippo_
priority: normal
severity: normal
status: open
title: tkinter.Variable equality consistency
type: behavior
versions: Python 3.10
Added file: https://bugs.python.org/file49698/equality.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42750>
_______________________________________

From report at bugs.python.org  Sat Dec 26 10:37:24 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 26 Dec 2020 15:37:24 +0000
Subject: [issue16396] Importing ctypes.wintypes on Linux gives a ValueError
 instead of an ImportError
In-Reply-To: <1351956172.0.0.64927799046.issue16396@psf.upfronthosting.co.za>
Message-ID: <1608997044.35.0.47474266741.issue16396@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 7865f516f313bd31ca48ee1fdae2a80add2293b6 by Shantanu in branch 'master':
bpo-16396: fix BPO number in changelog (GH-23951)
https://github.com/python/cpython/commit/7865f516f313bd31ca48ee1fdae2a80add2293b6


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16396>
_______________________________________

From report at bugs.python.org  Sat Dec 26 10:37:17 2020
From: report at bugs.python.org (miss-islington)
Date: Sat, 26 Dec 2020 15:37:17 +0000
Subject: [issue16396] Importing ctypes.wintypes on Linux gives a ValueError
 instead of an ImportError
In-Reply-To: <1351956172.0.0.64927799046.issue16396@psf.upfronthosting.co.za>
Message-ID: <1608997037.37.0.639099834433.issue16396@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22803
pull_request: https://github.com/python/cpython/pull/23956

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16396>
_______________________________________

From report at bugs.python.org  Sat Dec 26 11:00:09 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sat, 26 Dec 2020 16:00:09 +0000
Subject: [issue42747] Remove Py_TPFLAGS_HAVE_VERSION_TAG flag?
In-Reply-To: <1608940087.88.0.458230907712.issue42747@roundup.psfhosted.org>
Message-ID: <1608998409.72.0.787116532588.issue42747@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:

Let's emit the deprecated message if Py_TPFLAGS_HAVE_VERSION_TAG is set ;)
For example, PyType_Ready looks like a good place

----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42747>
_______________________________________

From report at bugs.python.org  Sat Dec 26 11:55:13 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 Dec 2020 16:55:13 +0000
Subject: [issue42750] tkinter.Variable equality consistency
In-Reply-To: <1608995176.07.0.806534213214.issue42750@roundup.psfhosted.org>
Message-ID: <1609001713.1.0.466519857861.issue42750@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It will break existing code which depends on the current behavior.

I don't see a problem with comparing variables by name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42750>
_______________________________________

From report at bugs.python.org  Sat Dec 26 12:44:59 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 26 Dec 2020 17:44:59 +0000
Subject: [issue42737] PEP 563: drop annotations for complex assign targets
In-Reply-To: <1608888770.02.0.483696766952.issue42737@roundup.psfhosted.org>
Message-ID: <1609004699.57.0.859608065352.issue42737@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Yeah, we're talking about a future here where `from __future__ import annotations` is always on. And that future is now. (3.10)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42737>
_______________________________________

From report at bugs.python.org  Sat Dec 26 12:46:24 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 26 Dec 2020 17:46:24 +0000
Subject: [issue42725] PEP 563: Should the behavior change for yield/yield
 from's
In-Reply-To: <1608730131.08.0.595189962302.issue42725@roundup.psfhosted.org>
Message-ID: <1609004784.75.0.900509327181.issue42725@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

One thing to note here, currently Pablo and I are trying to bring annotation unparsing from the compiler to the parser in issue 41967. If we do so, the annotations won't cause any side effects on the symbol table generation.

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42725>
_______________________________________

From report at bugs.python.org  Sat Dec 26 12:56:38 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 Dec 2020 17:56:38 +0000
Subject: [issue42737] PEP 563: drop annotations for complex assign targets
In-Reply-To: <1608888770.02.0.483696766952.issue42737@roundup.psfhosted.org>
Message-ID: <1609005398.64.0.0424823374839.issue42737@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Do we still need to represent annotation as a subtree in AST? Or make it just a string?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42737>
_______________________________________

From report at bugs.python.org  Sat Dec 26 12:58:15 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 26 Dec 2020 17:58:15 +0000
Subject: [issue42737] PEP 563: drop annotations for complex assign targets
In-Reply-To: <1608888770.02.0.483696766952.issue42737@roundup.psfhosted.org>
Message-ID: <1609005495.93.0.348148673351.issue42737@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

> Do we still need to represent annotation as a subtree in AST? Or make it just a string?

Possibly, we will just represent them as Constant()s. See issue 41967

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42737>
_______________________________________

From report at bugs.python.org  Sat Dec 26 13:01:56 2020
From: report at bugs.python.org (Ivo Shipkaliev)
Date: Sat, 26 Dec 2020 18:01:56 +0000
Subject: [issue42750] tkinter.Variable equality consistency
In-Reply-To: <1608995176.07.0.806534213214.issue42750@roundup.psfhosted.org>
Message-ID: <1609005716.4.0.471939581858.issue42750@roundup.psfhosted.org>


Ivo Shipkaliev <ivo.shipkaliev at gmail.com> added the comment:

If it's gonna break existing code -- fine. I just wanted to point out that if two variables are of the same type and refer to the same value, they should be considered equal, even if they are not the same variable.

In the current implementation, two StrVars can hold the same strings, but are compared unequal, which doesn't seem right.

Considering that we are going through the Tcl interpreter, equality should compare by value, not by identity (regardless of the variable names).

Look at this, please.

>>> int_0 = tk.IntVar()
>>> int_0.set(51)

>>> int_1 = tk.IntVar()
>>> int_1.set(51)


How can:

>>> int_0.get() == int_1.get()
True

and

>>> type(int_0) == type(int_1)
True

..but:

>>> int_0 == int_1
False

This means that the equality operator is only showing the difference in their names, and the statement above loses meaning, as it can never return True.

I think "int_0 is int_1" should be False as it is now. "is" should take into account their names as defined in the Tcl interpreter.

But "int_0 == int_1" should be True. Same as a couple of identical Python lists with different names.

Thank you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42750>
_______________________________________

From report at bugs.python.org  Sat Dec 26 13:08:16 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sat, 26 Dec 2020 18:08:16 +0000
Subject: [issue42745] [subinterpreters] Make the type attribute lookup cache
 per-interpreter
In-Reply-To: <1608936634.73.0.0790209715879.issue42745@roundup.psfhosted.org>
Message-ID: <1609006096.42.0.689011419487.issue42745@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

41010184880151d6ae02a226dbacc796e5c90d11 introduced some reference leaks:

https://buildbot.python.org/all/#/builders/384/builds/136

41010184880151d6ae02a226dbacc796e5c90d11 is the first bad commit
commit 41010184880151d6ae02a226dbacc796e5c90d11
Author: Victor Stinner <vstinner at python.org>
Date:   Sat Dec 26 01:45:43 2020 +0100

    bpo-42745: Make the type cache per-interpreter (GH-23947)

    Make the type attribute lookup cache per-interpreter.

    Add private _PyType_InitCache() function, called by PyInterpreterState_New().

    Continue to share next_version_tag between interpreters, since static
    types are still shared by interpreters.

    Remove MCACHE macro: the cache is no longer disabled if the
    EXPERIMENTAL_ISOLATED_SUBINTERPRETERS macro is defined.

 Include/internal/pycore_interp.h                   |  22 +++
 Include/internal/pycore_object.h                   |   3 +
 Include/internal/pycore_pylifecycle.h              |   2 +-
 .../2020-12-25-23-30-58.bpo-42745.XsFoHS.rst       |   1 +
 Objects/typeobject.c                               | 178 ++++++++++++---------
 Python/pylifecycle.c                               |   2 +-
 Python/pystate.c                                   |   2 +
 7 files changed, 128 insertions(+), 82 deletions(-)
 create mode 100644 Misc/NEWS.d/next/Core and Builtins/2020-12-25-23-30-58.bpo-42745.XsFoHS.rst
bisect run success

I assume PR 23953 fixes those? If that is so, could we land it before more buildbots start to fail?

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42745>
_______________________________________

From report at bugs.python.org  Sat Dec 26 13:21:50 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 Dec 2020 18:21:50 +0000
Subject: [issue42737] PEP 563: drop annotations for complex assign targets
In-Reply-To: <1608888770.02.0.483696766952.issue42737@roundup.psfhosted.org>
Message-ID: <1609006910.64.0.0653829301001.issue42737@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

About the difference in behavior. Currently:

>>> (1/0).numerator: int
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ZeroDivisionError: division by zero
>>> x[0]: int
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'x' is not defined
>>> [][print('Hi!')]: int
Hi!

With PR 23952 it all will be no-op.

Also, there should be changes in the following weird example:

def f():
   (yield).x: int

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42737>
_______________________________________

From report at bugs.python.org  Sat Dec 26 13:31:56 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 26 Dec 2020 18:31:56 +0000
Subject: [issue42750] tkinter.Variable equality consistency
In-Reply-To: <1608995176.07.0.806534213214.issue42750@roundup.psfhosted.org>
Message-ID: <1609007516.71.0.815792287204.issue42750@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

a = tk.IntVar(name='a')
b = tk.IntVar(name='a')
assert a == b  # they refers to the same variable
assert a is not b  # but they are different objects
a.set(42); assert b.get() == a.get() == 42  # yes, it is the same variable
c = tk.IntVar(name='c', value=42)
assert c != a  # they are different variables
assert c.get() == a.get() == 42  # although having equal values
a.set(43); assert c.get() != a.get() == 43  # and setting one does not affect other

I do not see good reasons for making Tk variables comparable by value instead of name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42750>
_______________________________________

From report at bugs.python.org  Sat Dec 26 13:42:51 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Sat, 26 Dec 2020 18:42:51 +0000
Subject: [issue42737] PEP 563: drop annotations for complex assign targets
In-Reply-To: <1608888770.02.0.483696766952.issue42737@roundup.psfhosted.org>
Message-ID: <1609008171.06.0.926840254297.issue42737@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

I think we should still evaluate the targets (even though the sole purpose of this is just having a hint, the yield example seems serious), will update my patch accordingly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42737>
_______________________________________

From report at bugs.python.org  Sat Dec 26 14:04:31 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Dec 2020 19:04:31 +0000
Subject: [issue42745] [subinterpreters] Make the type attribute lookup cache
 per-interpreter
In-Reply-To: <1608936634.73.0.0790209715879.issue42745@roundup.psfhosted.org>
Message-ID: <1609009471.72.0.303983608763.issue42745@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> I assume PR 23953 fixes those?

Yes, it fix the 7 tests which leak:

./python -m test -R 3:3 -j0 test__xxsubinterpreters test_ast test_atexit test_capi test_interpreters test_threading

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42745>
_______________________________________

From report at bugs.python.org  Sat Dec 26 14:07:34 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Dec 2020 19:07:34 +0000
Subject: [issue42747] Remove Py_TPFLAGS_HAVE_VERSION_TAG flag?
In-Reply-To: <1608940087.88.0.458230907712.issue42747@roundup.psfhosted.org>
Message-ID: <1609009654.49.0.178415256762.issue42747@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Maybe we can keep the constants but define them as 0 and deprecate them.

The question is more if these constants solve a real ABI issue or not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42747>
_______________________________________

From report at bugs.python.org  Sat Dec 26 14:26:19 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Dec 2020 19:26:19 +0000
Subject: [issue42745] [subinterpreters] Make the type attribute lookup cache
 per-interpreter
In-Reply-To: <1608936634.73.0.0790209715879.issue42745@roundup.psfhosted.org>
Message-ID: <1609010779.73.0.200251528184.issue42745@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset f4507231e3f0cf8827cec5592571ce371c6813e8 by Victor Stinner in branch 'master':
bpo-42745: finalize_interp_types() calls _PyType_Fini() (GH-23953)
https://github.com/python/cpython/commit/f4507231e3f0cf8827cec5592571ce371c6813e8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42745>
_______________________________________

From report at bugs.python.org  Sat Dec 26 14:29:16 2020
From: report at bugs.python.org (Ivo Shipkaliev)
Date: Sat, 26 Dec 2020 19:29:16 +0000
Subject: [issue42750] tkinter.Variable equality consistency
In-Reply-To: <1608995176.07.0.806534213214.issue42750@roundup.psfhosted.org>
Message-ID: <1609010956.81.0.358008108958.issue42750@roundup.psfhosted.org>


Ivo Shipkaliev <ivo.shipkaliev at gmail.com> added the comment:

There are 2 good reasons for making Tk variables comparable by value:

   1. We honor the equality operator! The equality operator (==) has to compare two objects by value. The current implementation does not fulfil this. Yes, if two Tk variables have the same names in the Tcl interpreter, they are guaranteed to have the same value.

>>> a = tk.IntVar(name='a')
>>> b = tk.IntVar(name='a')
>>> assert a == b  # this is not enough; equality means "by value"
                   # what about when they don't have the same name?

>>> assert a is not b  # this again does not make sense, since
                       # both Python "a" and "b" identifiers lead to
                       # the same "self._tk.globalgetvar(self._name)"
                       # Tcl registered variable: name="a"

>>> a.set(42); assert b.get() == a.get() == 42  # yes!
    # equality in names guarantees equality in value

Yes ... BUT, the negation is not true: if two Tk variables have different names, that does NOT mean that they have different values. This is where we fail the equality operator:

>>> c = tk.IntVar(name='c', value=42)
>>> assert a._name != c._name and a.get() != c.get(), \
...     "Difference in names does not guarantee difference in value"

   2. When we're interested in Tk variable comparison: .get() becomes redundant. Every time two Tk variables are of the same type AND they refer to the same value, we can safely compare them as equal, regardless of how they are named in the Tcl interpreter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42750>
_______________________________________

From report at bugs.python.org  Sat Dec 26 15:02:49 2020
From: report at bugs.python.org (RhinosF1)
Date: Sat, 26 Dec 2020 20:02:49 +0000
Subject: [issue42750] tkinter.Variable equality consistency
In-Reply-To: <1608995176.07.0.806534213214.issue42750@roundup.psfhosted.org>
Message-ID: <1609012969.9.0.403652555946.issue42750@roundup.psfhosted.org>


Change by RhinosF1 <rhinosf1 at gmail.com>:


----------
nosy: +RhinosF1

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42750>
_______________________________________

From report at bugs.python.org  Sat Dec 26 15:16:56 2020
From: report at bugs.python.org (Ivo Shipkaliev)
Date: Sat, 26 Dec 2020 20:16:56 +0000
Subject: [issue42750] tkinter.Variable equality consistency
In-Reply-To: <1608995176.07.0.806534213214.issue42750@roundup.psfhosted.org>
Message-ID: <1609013816.4.0.681129717889.issue42750@roundup.psfhosted.org>


Ivo Shipkaliev <ivo.shipkaliev at gmail.com> added the comment:

2. (continued) .. This is including the case when both variables have the same internal name (the current implementation).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42750>
_______________________________________

From report at bugs.python.org  Sat Dec 26 15:19:51 2020
From: report at bugs.python.org (Ross Rhodes)
Date: Sat, 26 Dec 2020 20:19:51 +0000
Subject: [issue41781] Typos in typing.py
In-Reply-To: <1600084822.87.0.84820912855.issue41781@roundup.psfhosted.org>
Message-ID: <1609013991.85.0.802283327364.issue41781@roundup.psfhosted.org>


Change by Ross Rhodes <ross.rhodes at hotmail.co.uk>:


----------
keywords: +patch
nosy: +trrhodes
nosy_count: 1.0 -> 2.0
pull_requests: +22804
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23957

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41781>
_______________________________________

From report at bugs.python.org  Sat Dec 26 15:21:51 2020
From: report at bugs.python.org (Ross Rhodes)
Date: Sat, 26 Dec 2020 20:21:51 +0000
Subject: [issue41781] Typos in typing.py
In-Reply-To: <1600084822.87.0.84820912855.issue41781@roundup.psfhosted.org>
Message-ID: <1609014111.84.0.436117604561.issue41781@roundup.psfhosted.org>


Ross Rhodes <ross.rhodes at hotmail.co.uk> added the comment:

Hello Patrick,

Thanks for opening this issue. I'm creating a PR to resolve the typo in "_allow_reckless_class_cheks", but I'm unable to find "instnance". Presumably the latter was resolved in an earlier PR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41781>
_______________________________________

From report at bugs.python.org  Sat Dec 26 15:24:54 2020
From: report at bugs.python.org (Patrick Reader)
Date: Sat, 26 Dec 2020 20:24:54 +0000
Subject: [issue41781] Typos in typing.py
In-Reply-To: <1600084822.87.0.84820912855.issue41781@roundup.psfhosted.org>
Message-ID: <1609014294.56.0.745407491745.issue41781@roundup.psfhosted.org>


Patrick Reader <pxeger at protonmail.com> added the comment:

Maybe I added myself by accident while reading the code. Anyway, thanks and you're welcome

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41781>
_______________________________________

From report at bugs.python.org  Sat Dec 26 15:56:28 2020
From: report at bugs.python.org (=?utf-8?q?Rodolfo_Garc=C3=ADa_Pe=C3=B1as?=)
Date: Sat, 26 Dec 2020 20:56:28 +0000
Subject: [issue42751] Imaplib
Message-ID: <1609016188.21.0.0203916799222.issue42751@roundup.psfhosted.org>


New submission from Rodolfo Garc?a Pe?as <rodolfogarciap at gmail.com>:

Hi,

Is it possible to move the imaplib2 implementation (https://github.com/imaplib2/imaplib2/) as imaplib stdlib?

What steps should I do?

Regards,
kix

----------
components: Library (Lib)
messages: 383828
nosy: rodolfogarciap
priority: normal
severity: normal
status: open
title: Imaplib
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42751>
_______________________________________

From report at bugs.python.org  Sat Dec 26 17:09:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Dec 2020 22:09:06 +0000
Subject: [issue40521] [subinterpreters] Make free lists and unicode caches
 per-interpreter
In-Reply-To: <1588693682.5.0.219755904926.issue40521@roundup.psfhosted.org>
Message-ID: <1609020546.45.0.644583174752.issue40521@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> New changeset ea251806b8dffff11b30d2182af1e589caf88acf by Victor Stinner in branch 'master':
> bpo-40521: Per-interpreter interned strings (GH-20085)

I reopen the issue. This change caused a regression in attached interned_bug.py. Output:
---
$ ./python interned_bug.py 
Exception ignored deletion of interned string failed:
KeyError: 'out of memory'
python: Objects/unicodeobject.c:1946: unicode_dealloc: Assertion `Py_REFCNT(unicode) == 1' failed.
Abandon (core dumped)
---

Running "import xml.parsers.expat" in a subinterpreter causes two issues when the subinterpreter completes:

* pyexpat.errors and pyexpat.model dictionaries are cleared: all values set to None
* unicode_dealloc() logs an error on an interned string in the subinterpreter, because the string doesn't exist in the subinterpreter interned dictionary.

The interned string is created in the main interpreter and so stored in the main interpreter interned dictionary.

The string is stored in 2 dictionaries of pyexpat.errors dictionaries:

>>> pyexpat.errors.messages[1]
'out of memory'
>>> pyexpat.errors.codes['out of memory']
1

When the subinterpreter clears pyexpat.errors and pyexpat.model dictionaries, the interned string is deleted: unicode_dealloc() is called. But unicode_dealloc() fails to delete the interned string in the subinterpreter interned dictionary.

pyexpat.errors and pyexpat.model modules are cleared because they are stored as different names in sys.modules by Lib/xml/parsers/expat.py:

sys.modules['xml.parsers.expat.model'] = model
sys.modules['xml.parsers.expat.errors'] = errors

----------
resolution: fixed -> 
status: closed -> open
Added file: https://bugs.python.org/file49699/interned_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40521>
_______________________________________

From report at bugs.python.org  Sat Dec 26 17:10:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Dec 2020 22:10:15 +0000
Subject: [issue40512] [subinterpreters] Meta issue: per-interpreter GIL
In-Reply-To: <1588683075.13.0.0239787407564.issue40512@roundup.psfhosted.org>
Message-ID: <1609020615.05.0.30691030285.issue40512@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I played with ./configure --with-experimental-isolated-subinterpreters. I tried to run "pip list" in parallel in multiple interpreters.

I hit multiple issues:

* non-atomic reference count of Python objects shared by multiple interpreters, objects shared via static types for example.

* resolve_slotdups() uses a static variable

* pip requires _xxsubinterpreters.create(isolated=False): the vendored distro package runs the lsb_release command with subprocess.

* Race conditions in PyType_Ready() on static types:

  * Objects/typeobject.c:5494: PyType_Ready: Assertion "(type->tp_flags & (1UL << 13)) == 0" failed
  * Race condition in add_subclass()

* parser_init() doesn't support subinterpreters

* unicode_dealloc() fails to delete an interned string in the Unicode interned dictionary => https://bugs.python.org/issue40521#msg383829


To run "pip list", I used:

CODE = """
import runpy
import sys
import traceback
sys.argv = ["pip", "list"]
try:
    runpy.run_module("pip", run_name="__main__", alter_sys=True)
except SystemExit:
    pass
except Exception as exc:
    traceback.print_exc()
    print("BUG", exc)
    raise
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40512>
_______________________________________

From report at bugs.python.org  Sat Dec 26 17:23:54 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 26 Dec 2020 22:23:54 +0000
Subject: [issue40512] [subinterpreters] Meta issue: per-interpreter GIL
In-Reply-To: <1588683075.13.0.0239787407564.issue40512@roundup.psfhosted.org>
Message-ID: <1609021434.43.0.444745423169.issue40512@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> * resolve_slotdups() uses a static variable

Attached resolve_slotdups.patch works around the issue by removing the cache.

----------
keywords: +patch
Added file: https://bugs.python.org/file49700/resolve_slotdups.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40512>
_______________________________________

From report at bugs.python.org  Sat Dec 26 18:03:41 2020
From: report at bugs.python.org (Alex Orange)
Date: Sat, 26 Dec 2020 23:03:41 +0000
Subject: [issue42752] multiprocessing Queue leaks a file descriptor associated
 with the pipe writer (#33081 still a problem)
Message-ID: <1609023821.09.0.189504509221.issue42752@roundup.psfhosted.org>


New submission from Alex Orange <crazycasta at gmail.com>:

Didn't feel like necroing #33081, but this is basically that problem. The trouble is the cleanup that appeared to fix #33081 only kicks in once something has been put in the queue. So if for instance a Process function puts something in the queue and the parent gets it, then calls q.close() the writer on the parent side doesn't get culled until the object does. This is particularly a problem for PyPy and isn't exactly great for any weird corner cases if anyone holds onto Queue objects after they're closed for any reason (horders!).

Attached file test_queue.py is an example of how to trigger this problem. Run it without a command line argument "python test_queue.py" and it won't crash (though it will take a very long time to complete). Run with an argument "python test_queue.py fail" and it will fail once you run out of file descriptors (one leaked per queue).

My suggestion on how to handle this is to set self._close to something that will close self._writer. Then, when _start_thread is called, instead of directly passing the self._writer.close object, pass a small function that will switch out self._close to the Finalize method used later on and return self._writer. Finally, inside _feed, use this method to get the _writer object and wrap the outer while 1 with a contextlib.closer on this object.

This is a fair bit of stitching things together here and there so let me know if anyone has any suggestions on this before I get started.

----------
components: Library (Lib)
files: test_queue.py
messages: 383832
nosy: Alex.Orange
priority: normal
severity: normal
status: open
title: multiprocessing Queue leaks a file descriptor associated with the pipe writer (#33081 still a problem)
type: resource usage
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49701/test_queue.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42752>
_______________________________________

From report at bugs.python.org  Sat Dec 26 20:05:55 2020
From: report at bugs.python.org (Erik Soma)
Date: Sun, 27 Dec 2020 01:05:55 +0000
Subject: [issue42687] tokenize module does not recognize Barry as FLUFL
In-Reply-To: <1608392787.93.0.861284496438.issue42687@roundup.psfhosted.org>
Message-ID: <1609031155.72.0.304869654346.issue42687@roundup.psfhosted.org>


Change by Erik Soma <stillusingirc at gmail.com>:


----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42687>
_______________________________________

From report at bugs.python.org  Sat Dec 26 20:31:06 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 27 Dec 2020 01:31:06 +0000
Subject: [issue42751] Imaplib
In-Reply-To: <1609016188.21.0.0203916799222.issue42751@roundup.psfhosted.org>
Message-ID: <1609032666.26.0.228227790921.issue42751@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Are you the owner of imaplib2?

If so, you need to ensure that there are no licencing or copyright issues preventing imaplib2 being transferred into the stdlib. That may (or may not) require you to get agreement from any contributors to the library. That will depend on the licencing agreement your contributors have with you.

If you are not the owner, then you need to get the owner's agreement first, before you do anything else. We're not going to just *take* the library, or fork it.

That means that the imaplib2 library will have to adhere to Python's release schedule, our code of conduct, our policies on backwards compatibility, etc.

If the owner(s) agree that they are interested, then you can propose the idea on the Python-Ideas mailing list for discussion:

https://mail.python.org/mailman3/lists/python-ideas.python.org/

If there is interest in your proposal, then you can ask for a core developer to sponsor a PEP. Once you have a sponsor, you can write a PEP, and the steering council will rule whether or not to accept it.

----------
nosy: +steven.daprano
resolution:  -> postponed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42751>
_______________________________________

From report at bugs.python.org  Sat Dec 26 20:42:41 2020
From: report at bugs.python.org (Qi Yao)
Date: Sun, 27 Dec 2020 01:42:41 +0000
Subject: [issue40148] Add PurePath.with_stem()
In-Reply-To: <1585788024.89.0.165310869252.issue40148@roundup.psfhosted.org>
Message-ID: <1609033361.89.0.0195206094486.issue40148@roundup.psfhosted.org>


Qi Yao <tinyaoqi at gmail.com> added the comment:

In Pathlib, we have functions "with_name()""with_stem()""with_suffix()" to modify the file name in the path.

In issue21798:"Allow adding Path or str to Path", it actually also want to modify the file name, that is "appand string to file name".

if with_stem() more cumbersome as:
path.with_name(path.stem + '_v2' + path.suffix)

why not have a function with_xxxx() more cumbersome as:
path.with_name(path.name + "_name.dat")

----------
nosy: +tinyaoqi

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40148>
_______________________________________

From report at bugs.python.org  Sat Dec 26 22:32:41 2020
From: report at bugs.python.org (Andrei Kulakov)
Date: Sun, 27 Dec 2020 03:32:41 +0000
Subject: [issue42417] Empty body {} in POST requests leads to 405 Method not
 allowed error
In-Reply-To: <1605864023.48.0.825673701965.issue42417@roundup.psfhosted.org>
Message-ID: <1609039961.9.0.209960876326.issue42417@roundup.psfhosted.org>


Andrei Kulakov <andrei.avk at gmail.com> added the comment:

I've tried it with flask_client_long_headers.py , but I get the same output as I've gotten before with flask_client.py .

Can you try it on a few different systems?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42417>
_______________________________________

From report at bugs.python.org  Sat Dec 26 23:19:27 2020
From: report at bugs.python.org (Gerrik Labra)
Date: Sun, 27 Dec 2020 04:19:27 +0000
Subject: [issue42753] "./configure" linux chrome beta
Message-ID: <1609042767.15.0.899316514178.issue42753@roundup.psfhosted.org>


New submission from Gerrik Labra <gerriklabra at gmail.com>:

Ok. So I tried to run the setup in README.txt for the latest linux beta emulator on the google pixel chromebook.

Here is what I got back, and the commands, "make, make test, sudo make test" didn't work.

ennuilysis at penguin:~/Python/Python-3.8.7$ ./configure
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for python3.8... no
checking for python3... python3
checking for --enable-universalsdk... no
checking for --with-universal-archs... no
checking MACHDEP... "linux"
checking for gcc... no
checking for cc... no
checking for cl.exe... no
configure: error: in `/home/ennuilysis/Python/Python-3.8.7':
configure: error: no acceptable C compiler found in $PATH
See `config.log' for more details

----------
components: Installation
messages: 383836
nosy: gerriklabra
priority: normal
severity: normal
status: open
title: "./configure" linux chrome beta
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42753>
_______________________________________

From report at bugs.python.org  Sun Dec 27 02:56:34 2020
From: report at bugs.python.org (Patrick Reader)
Date: Sun, 27 Dec 2020 07:56:34 +0000
Subject: [issue42754] Unpacking of literals inside other literals should be
 optimised away by the compiler
Message-ID: <1609055794.85.0.312864529219.issue42754@roundup.psfhosted.org>


New submission from Patrick Reader <pxeger at protonmail.com>:

When unpacking a collection or string literal inside another literal, the compiler should optimise the unpacking away and store the resultant collection simply as another constant tuple, so that `[*'123', '4', '5']` is the exact same as `['1', '2', '3', '4', '5']`.

Compare:

```
>>> dis.dis("[*'123', '4', '5']")
  1           0 BUILD_LIST               0
              2 BUILD_LIST               0
              4 LOAD_CONST               0 ('123')
              6 LIST_EXTEND              1
              8 LIST_EXTEND              1
             10 LOAD_CONST               1 ('4')
             12 LIST_APPEND              1
             14 LOAD_CONST               2 ('5')
             16 LIST_APPEND              1
```

vs.

```
>>> dis.dis("['1', '2', '3', '4', '5']")
  1           0 BUILD_LIST               0
              2 LOAD_CONST               0 (('1', '2', '3', '4', '5'))
              4 LIST_EXTEND              1
```

and `timeit` shows the latter to be over 3 times as fast.

For example, when generating a list of characters, it is easier and more readable to do `alphabet = [*"abcde"]` instead of `alphabet = ["a", "b", "c", "d", "e"]`. The programmer can do what is most obvious without worrying about performance, because the compiler can do it itself.

----------
components: Interpreter Core
messages: 383837
nosy: pxeger
priority: normal
severity: normal
status: open
title: Unpacking of literals inside other literals should be optimised away by the compiler

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42754>
_______________________________________

From report at bugs.python.org  Sun Dec 27 02:56:46 2020
From: report at bugs.python.org (Patrick Reader)
Date: Sun, 27 Dec 2020 07:56:46 +0000
Subject: [issue42754] Unpacking of literals inside other literals should be
 optimised away by the compiler
In-Reply-To: <1609055794.85.0.312864529219.issue42754@roundup.psfhosted.org>
Message-ID: <1609055806.75.0.92432308989.issue42754@roundup.psfhosted.org>


Change by Patrick Reader <pxeger at protonmail.com>:


----------
type:  -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42754>
_______________________________________

From report at bugs.python.org  Sun Dec 27 03:11:58 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 27 Dec 2020 08:11:58 +0000
Subject: [issue42755] sqlite3.Connection.backup default value is diffrent
 between implmentation and docs
Message-ID: <1609056718.52.0.719197971794.issue42755@roundup.psfhosted.org>


New submission from Dong-hee Na <donghee.na at python.org>:

Docs says that pages default value is 0 but the implementation is -1

docs: https://docs.python.org/3/library/sqlite3.html#sqlite3.Connection.backup
impl: https://github.com/python/cpython/blob/f4507231e3f0cf8827cec5592571ce371c6813e8/Modules/_sqlite/connection.c#L1565

But the behavior will be the same and if the pages is set to zero, we update this value to -1.
https://github.com/python/cpython/blob/f4507231e3f0cf8827cec5592571ce371c6813e8/Modules/_sqlite/connection.c#L1625

So IMHO, I'd like to suggest updating the docs rather than updating the implementation.

----------
components: Extension Modules
messages: 383838
nosy: berker.peksag, corona10, erlendaasland, serhiy.storchaka
priority: normal
severity: normal
status: open
title: sqlite3.Connection.backup default value is diffrent between implmentation and docs

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42755>
_______________________________________

From report at bugs.python.org  Sun Dec 27 03:13:54 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Dec 2020 08:13:54 +0000
Subject: [issue42749] test_tcl failed on 32-bit POWER6 AIX 3.9: big int issue
 with 9223372036854775808
In-Reply-To: <1608981118.95.0.264551211038.issue42749@roundup.psfhosted.org>
Message-ID: <1609056834.28.0.219992832799.issue42749@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset b02ad2458bc127a7afdeef414fa68c9a7f1f32af by Serhiy Storchaka in branch 'master':
bpo-42749: Fix testing bignum if Tkinter is compiled with Tk 8.4 and dynamic linked with Tk >= 8.5 (GH-23955)
https://github.com/python/cpython/commit/b02ad2458bc127a7afdeef414fa68c9a7f1f32af


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42749>
_______________________________________

From report at bugs.python.org  Sun Dec 27 03:13:52 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 27 Dec 2020 08:13:52 +0000
Subject: [issue42749] test_tcl failed on 32-bit POWER6 AIX 3.9: big int issue
 with 9223372036854775808
In-Reply-To: <1608981118.95.0.264551211038.issue42749@roundup.psfhosted.org>
Message-ID: <1609056832.95.0.489136978961.issue42749@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +22806
pull_request: https://github.com/python/cpython/pull/23961

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42749>
_______________________________________

From report at bugs.python.org  Sun Dec 27 03:13:59 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 27 Dec 2020 08:13:59 +0000
Subject: [issue42749] test_tcl failed on 32-bit POWER6 AIX 3.9: big int issue
 with 9223372036854775808
In-Reply-To: <1608981118.95.0.264551211038.issue42749@roundup.psfhosted.org>
Message-ID: <1609056839.61.0.938326612246.issue42749@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22807
pull_request: https://github.com/python/cpython/pull/23962

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42749>
_______________________________________

From report at bugs.python.org  Sun Dec 27 03:32:39 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 27 Dec 2020 08:32:39 +0000
Subject: [issue42749] test_tcl failed on 32-bit POWER6 AIX 3.9: big int issue
 with 9223372036854775808
In-Reply-To: <1608981118.95.0.264551211038.issue42749@roundup.psfhosted.org>
Message-ID: <1609057959.38.0.264345745402.issue42749@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset dda12ad63e927e93d71462ad77cc84da55bada9b by Miss Islington (bot) in branch '3.9':
bpo-42749: Fix testing bignum if Tkinter is compiled with Tk 8.4 and dynamic linked with Tk >= 8.5 (GH-23955)
https://github.com/python/cpython/commit/dda12ad63e927e93d71462ad77cc84da55bada9b


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42749>
_______________________________________

From report at bugs.python.org  Sun Dec 27 03:32:39 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Sun, 27 Dec 2020 08:32:39 +0000
Subject: [issue40956] Use Argument Clinic in sqlite3
In-Reply-To: <1591956335.72.0.553737405887.issue40956@roundup.psfhosted.org>
Message-ID: <1609057959.49.0.120449270412.issue40956@roundup.psfhosted.org>


Dong-hee Na <donghee.na at python.org> added the comment:


New changeset 3ccef1ca474592e191a00e131dfbaf777db271e9 by Erlend Egeberg Aasland in branch 'master':
bpo-40956: Convert _sqlite3.Connection to Argument Clinic, part 2 (GH-23838)
https://github.com/python/cpython/commit/3ccef1ca474592e191a00e131dfbaf777db271e9


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40956>
_______________________________________

From report at bugs.python.org  Sun Dec 27 03:56:49 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Dec 2020 08:56:49 +0000
Subject: [issue42749] test_tcl failed on 32-bit POWER6 AIX 3.9: big int issue
 with 9223372036854775808
In-Reply-To: <1608981118.95.0.264551211038.issue42749@roundup.psfhosted.org>
Message-ID: <1609059409.45.0.710981909822.issue42749@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 9d7c5ab6a4ae9d69b39bd16c3195bf6405ddc2d1 by Miss Islington (bot) in branch '3.8':
bpo-42749: Fix testing bignum if Tkinter is compiled with Tk 8.4 and dynamic linked with Tk >= 8.5 (GH-23955) (GH-23962)
https://github.com/python/cpython/commit/9d7c5ab6a4ae9d69b39bd16c3195bf6405ddc2d1


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42749>
_______________________________________

From report at bugs.python.org  Sun Dec 27 03:58:34 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Dec 2020 08:58:34 +0000
Subject: [issue42749] test_tcl failed on 32-bit POWER6 AIX 3.9: big int issue
 with 9223372036854775808
In-Reply-To: <1608981118.95.0.264551211038.issue42749@roundup.psfhosted.org>
Message-ID: <1609059514.77.0.16987312145.issue42749@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The test should be fixed now, but there is a configuration issue.

----------
nosy: +Michael.Felt
versions: +Python 3.10, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42749>
_______________________________________

From report at bugs.python.org  Sun Dec 27 04:41:54 2020
From: report at bugs.python.org (Ken Jin)
Date: Sun, 27 Dec 2020 09:41:54 +0000
Subject: [issue42740] typing.py get_args and get_origin should support PEP 604
 and 612
In-Reply-To: <1608909562.21.0.0257515668126.issue42740@roundup.psfhosted.org>
Message-ID: <1609062114.32.0.641996142963.issue42740@roundup.psfhosted.org>


Change by Ken Jin <kenjin4096 at gmail.com>:


----------
pull_requests: +22808
pull_request: https://github.com/python/cpython/pull/23963

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42740>
_______________________________________

From report at bugs.python.org  Sun Dec 27 05:05:33 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Sun, 27 Dec 2020 10:05:33 +0000
Subject: [issue40956] Use Argument Clinic in sqlite3
In-Reply-To: <1591956335.72.0.553737405887.issue40956@roundup.psfhosted.org>
Message-ID: <1609063533.75.0.678680873093.issue40956@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
pull_requests: +22809
pull_request: https://github.com/python/cpython/pull/23964

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40956>
_______________________________________

From report at bugs.python.org  Sun Dec 27 05:18:04 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Sun, 27 Dec 2020 10:18:04 +0000
Subject: [issue42755] sqlite3.Connection.backup default value is diffrent
 between implmentation and docs
In-Reply-To: <1609056718.52.0.719197971794.issue42755@roundup.psfhosted.org>
Message-ID: <1609064284.28.0.87215264903.issue42755@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
keywords: +patch
pull_requests: +22810
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23965

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42755>
_______________________________________

From report at bugs.python.org  Sun Dec 27 05:19:26 2020
From: report at bugs.python.org (Ivo Shipkaliev)
Date: Sun, 27 Dec 2020 10:19:26 +0000
Subject: [issue42750] tkinter.Variable equality inconsistency
In-Reply-To: <1608995176.07.0.806534213214.issue42750@roundup.psfhosted.org>
Message-ID: <1609064366.02.0.463443999582.issue42750@roundup.psfhosted.org>


Change by Ivo Shipkaliev <ivo.shipkaliev at gmail.com>:


----------
title: tkinter.Variable equality consistency -> tkinter.Variable equality inconsistency

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42750>
_______________________________________

From report at bugs.python.org  Sun Dec 27 06:05:59 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 27 Dec 2020 11:05:59 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1609067159.69.0.0300122737846.issue1635741@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset bf64d9064ab641b1ef9a0c4bda097ebf1204faf4 by Erlend Egeberg Aasland in branch 'master':
bpo-1635741: sqlite3 uses Py_NewRef/Py_XNewRef (GH-23170)
https://github.com/python/cpython/commit/bf64d9064ab641b1ef9a0c4bda097ebf1204faf4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Sun Dec 27 06:08:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 27 Dec 2020 11:08:51 +0000
Subject: [issue42749] test_tcl failed on 32-bit POWER6 AIX 3.9: big int issue
 with 9223372036854775808
In-Reply-To: <1608981118.95.0.264551211038.issue42749@roundup.psfhosted.org>
Message-ID: <1609067331.35.0.596640410612.issue42749@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> New changeset dda12ad63e927e93d71462ad77cc84da55bada9b by Miss Islington (bot) in branch '3.9':
> bpo-42749: Fix testing bignum if Tkinter is compiled with Tk 8.4 and dynamic linked with Tk >= 8.5 (GH-23955)

test_tcl still fails on POWER6 AIX 3.9:
https://buildbot.python.org/all/#/builders/330/builds/226

======================================================================
FAIL: test_expr_bignum (test.test_tcl.TclTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/aixtools/buildarea/3.9.aixtools-aix-power6/build/Lib/test/test_tcl.py", line 451, in test_expr_bignum
    self.assertRaises(TclError, tcl.call, 'expr', str(2**1000))
AssertionError: TclError not raised by call

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42749>
_______________________________________

From report at bugs.python.org  Sun Dec 27 06:17:55 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 27 Dec 2020 11:17:55 +0000
Subject: [issue42724] Change library name when building.
In-Reply-To: <1608728195.78.0.130143828179.issue42724@roundup.psfhosted.org>
Message-ID: <1609067875.46.0.957412438731.issue42724@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/issue42724>
_______________________________________

From report at bugs.python.org  Sun Dec 27 06:35:21 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 27 Dec 2020 11:35:21 +0000
Subject: [issue42753] "./configure" linux chrome beta
In-Reply-To: <1609042767.15.0.899316514178.issue42753@roundup.psfhosted.org>
Message-ID: <1609068921.24.0.627091019617.issue42753@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Do you have a C compiler installed? It's mentioned here https://devguide.python.org/setup/#unixhttps://devguide.python.org/setup/#unix

I found a number of guides for building Python on Chromebooks via searching. I don't have any experience, so I'm not going to recommend one, but some of them look very detailed.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42753>
_______________________________________

From report at bugs.python.org  Sun Dec 27 06:35:35 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 27 Dec 2020 11:35:35 +0000
Subject: [issue42753] "./configure" linux chrome beta
In-Reply-To: <1609042767.15.0.899316514178.issue42753@roundup.psfhosted.org>
Message-ID: <1609068935.01.0.822756291613.issue42753@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
components: +Build -Installation

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42753>
_______________________________________

From report at bugs.python.org  Sun Dec 27 06:43:54 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 27 Dec 2020 11:43:54 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1609069434.91.0.547822430679.issue1635741@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Progress: 77% (102/132) of extension modules use the new C API.

I used different grep commands to count *all* extension modules, not only the Modules/ directory:

$ grep -E '\<PyModule_Create\>' $(find -name "*.c"|grep -v Doc/|grep -v moduleobject.c)|wc -l
30
$ grep -E '\<PyModuleDef_Init\>' $(find -name "*.c"|grep -v Doc/|grep -v moduleobject.c)|wc -l
102

--

Modules/ directory: 79% (94/119) of extension modules use the new API.

$ grep -E '\<PyModule_Create\>' $(find Modules -name "*.c")|wc -l
25
$ grep -E '\<PyModuleDef_Init\>' $(find Modules -name "*.c")|wc -l
94

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Sun Dec 27 06:45:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 27 Dec 2020 11:45:46 +0000
Subject: [issue40077] Convert static types to heap types: use PyType_FromSpec()
In-Reply-To: <1585238684.65.0.246012172449.issue40077@roundup.psfhosted.org>
Message-ID: <1609069546.33.0.472071276168.issue40077@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Progress: 43% (89/206) of types are declared as heap types on a total of 206 types.

$ grep -E 'static PyTypeObject .* =' $(find -name "*.c"|grep -v Doc/)|wc -l
117
$ grep -E 'PyType_Spec .* =' $(find -name "*.c")|wc -l
89

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40077>
_______________________________________

From report at bugs.python.org  Sun Dec 27 07:35:52 2020
From: report at bugs.python.org (E. Paine)
Date: Sun, 27 Dec 2020 12:35:52 +0000
Subject: [issue42750] tkinter.Variable equality inconsistency
In-Reply-To: <1608995176.07.0.806534213214.issue42750@roundup.psfhosted.org>
Message-ID: <1609072552.27.0.90238808.issue42750@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

See also issue41851. I personally think that being able to compare whether two tkinter variables point to the same Tk variable is very useful so needs to stay in some form. However, I don't see any situation where comparing to see if two tkinter variables are the same Python object would be helpful.

Comparing to a list (for example), `assert a is b` would mean altering one would affect the other (while this is true of tkinter variables, to cover all cases you would instead check whether they are 'equal'). Therefore, while writing `a.get() == b.get()` isn't too bad, the point of this change would be consistency more than anything else (as-per the title).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42750>
_______________________________________

From report at bugs.python.org  Sun Dec 27 08:11:53 2020
From: report at bugs.python.org (=?utf-8?q?W=C3=BCstengecko?=)
Date: Sun, 27 Dec 2020 13:11:53 +0000
Subject: [issue42756] smtplib.LMTP.connect() raises TypeError if `timeout` is
 not specified
Message-ID: <1609074713.39.0.771360640486.issue42756@roundup.psfhosted.org>


New submission from W?stengecko <lemmi59612 at gmail.com>:

Since Python 3.9, calling `smtplib.LMTP.connect()` without explicitly specifying any `timeout=` raises a `TypeError`. Specifying `None` or any integer value works correctly.

```
>>> import smtplib
>>> smtplib.LMTP("/tmp/lmtp.sock")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.9/smtplib.py", line 1071, in __init__
    super().__init__(host, port, local_hostname=local_hostname,
  File "/usr/lib/python3.9/smtplib.py", line 253, in __init__
    (code, msg) = self.connect(host, port)
  File "/usr/lib/python3.9/smtplib.py", line 1085, in connect
    self.sock.settimeout(self.timeout)
TypeError: an integer is required (got type object)
>>> l = smtplib.LMTP()
>>> l.connect("/tmp/lmtp.sock")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.9/smtplib.py", line 1085, in connect
    self.sock.settimeout(self.timeout)
TypeError: an integer is required (got type object)
```

Upon investigation with `pdb`, the default object for the `timeout` parameter (`socket._GLOBAL_DEFAULT_TIMEOUT`) is passed through to the `self.sock.settimeout` call, instead of being handled as "no timeout specified". The relevant changes were introduced as fix for bpo-39329.

----------
components: Library (Lib)
messages: 383850
nosy: wuestengecko
priority: normal
severity: normal
status: open
title: smtplib.LMTP.connect() raises TypeError if `timeout` is not specified
type: crash
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42756>
_______________________________________

From report at bugs.python.org  Sun Dec 27 08:32:22 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Dec 2020 13:32:22 +0000
Subject: [issue42749] test_tcl failed on 32-bit POWER6 AIX 3.9: big int issue
 with 9223372036854775808
In-Reply-To: <1608981118.95.0.264551211038.issue42749@roundup.psfhosted.org>
Message-ID: <1609075942.32.0.901496454307.issue42749@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +22811
pull_request: https://github.com/python/cpython/pull/23966

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42749>
_______________________________________

From report at bugs.python.org  Sun Dec 27 08:56:47 2020
From: report at bugs.python.org (Barney Stratford)
Date: Sun, 27 Dec 2020 13:56:47 +0000
Subject: [issue42513] Socket.recv hangs
In-Reply-To: <1606737349.78.0.516615398151.issue42513@roundup.psfhosted.org>
Message-ID: <1609077407.66.0.552002321392.issue42513@roundup.psfhosted.org>


Barney Stratford <barney_stratford at fastmail.fm> added the comment:

Still waiting for the instrumented code to hang. It sometimes runs for a month or two before freezing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42513>
_______________________________________

From report at bugs.python.org  Sun Dec 27 11:17:32 2020
From: report at bugs.python.org (Yurii Karabas)
Date: Sun, 27 Dec 2020 16:17:32 +0000
Subject: [issue27794] setattr a read-only property;
 the AttributeError should show the attribute that failed
In-Reply-To: <1471528639.63.0.0729109170448.issue27794@psf.upfronthosting.co.za>
Message-ID: <1609085852.45.0.48639506674.issue27794@roundup.psfhosted.org>


Change by Yurii Karabas <1998uriyyo at gmail.com>:


----------
keywords: +patch
nosy: +uriyyo
nosy_count: 8.0 -> 9.0
pull_requests: +22812
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/23967

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27794>
_______________________________________

From report at bugs.python.org  Sun Dec 27 11:20:16 2020
From: report at bugs.python.org (Yurii Karabas)
Date: Sun, 27 Dec 2020 16:20:16 +0000
Subject: [issue27794] setattr a read-only property;
 the AttributeError should show the attribute that failed
In-Reply-To: <1471528639.63.0.0729109170448.issue27794@psf.upfronthosting.co.za>
Message-ID: <1609086016.25.0.598978636392.issue27794@roundup.psfhosted.org>


Yurii Karabas <1998uriyyo at gmail.com> added the comment:

I have implemented this feature using an idea provided by Xiang Zhang.
Basically, property has new optional attribute `name` which will be added to msg of `AttributeError` in a case when `name` is set.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27794>
_______________________________________

From report at bugs.python.org  Sun Dec 27 11:21:35 2020
From: report at bugs.python.org (Ivo Shipkaliev)
Date: Sun, 27 Dec 2020 16:21:35 +0000
Subject: [issue42750] tkinter.Variable equality inconsistency
In-Reply-To: <1608995176.07.0.806534213214.issue42750@roundup.psfhosted.org>
Message-ID: <1609086095.18.0.307598304178.issue42750@roundup.psfhosted.org>


Ivo Shipkaliev <ivo.shipkaliev at gmail.com> added the comment:

"I personally think that being able to compare whether two tkinter variables point to the same Tk variable is very useful so needs to stay in some form." -- I concur.

"However, I don't see any situation where comparing to see if two tkinter variables are the same Python object would be helpful." -- agreed.

"Therefore, while writing 'a.get() == b.get()' isn't too bad, .." -- it isn't. But "a == b" -> False IS, provided that "a.get() == b.get()" is True.

Serhiy, how about:

> class Variable:
>     ...
>     def is_(self, other):  # or maybe "same_as"
>         return self.__class__.__name__ == other.__class__.__name__ \
>             and self._name == other._name
>
>     def __eq__(self, other):
>         return self.__class__.__name__ == other.__class__.__name__ \
>             and self.get() == other.get()

Regards

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42750>
_______________________________________

From report at bugs.python.org  Sun Dec 27 12:27:50 2020
From: report at bugs.python.org (Steve Merritt)
Date: Sun, 27 Dec 2020 17:27:50 +0000
Subject: [issue28964] AST literal_eval exceptions provide no information about
 line number
In-Reply-To: <1608915912.01.0.014383328443.issue28964@roundup.psfhosted.org>
Message-ID: <CAG8dkNy3GggD6mj5ygH8pURUt0PBcCc8p0AFDB8CB0r5a07zKQ@mail.gmail.com>


Steve Merritt <stevemerritt at google.com> added the comment:

Thank you!

On Fri, Dec 25, 2020 at 11:05 AM Batuhan Taskaya <report at bugs.python.org>
wrote:

>
> Change by Batuhan Taskaya <isidentical at gmail.com>:
>
>
> ----------
> resolution:  -> fixed
> stage: patch review -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue28964>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue28964>
_______________________________________

From report at bugs.python.org  Sun Dec 27 12:45:58 2020
From: report at bugs.python.org (hai shi)
Date: Sun, 27 Dec 2020 17:45:58 +0000
Subject: [issue42747] Remove Py_TPFLAGS_HAVE_VERSION_TAG flag?
In-Reply-To: <1608940087.88.0.458230907712.issue42747@roundup.psfhosted.org>
Message-ID: <1609091158.55.0.991504086555.issue42747@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

>I don't see the purpose of the Py_TPFLAGS_HAVE_VERSION_TAG flag.

IMO, There have no more exact description of `Py_TPFLAGS_HAVE_VERSION_TAG`in docs, so I perfer to remove it.

> By the way, is it worth it to remove Py_TPFLAGS_HAVE_FINALIZE? Or is it going to break too many extension modules?

I am not found who use Py_TPFLAGS_HAVE_AM_SEND or Py_TPFLAGS_HAVE_FINALIZE in github.I perfer to keep it as soon as posssible if there have users using them.
MAYBE we should do some surveys firstly?

----------
nosy: +shihai1991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42747>
_______________________________________

From report at bugs.python.org  Sun Dec 27 13:01:57 2020
From: report at bugs.python.org (Johann Bernhardt)
Date: Sun, 27 Dec 2020 18:01:57 +0000
Subject: [issue42757] Class has two prototypes
Message-ID: <1609092117.63.0.33154013313.issue42757@roundup.psfhosted.org>


New submission from Johann Bernhardt <johann.bernhardt at tum.de>:

Greetings,

tl;dr Depending on how a class is imported it will have a differenct class name and therefore prototype. I ran into this issue when i used a class variable to implement an event bus.

To reproduce you need a module and a submodule. The example creates two child classes that and collects their references for further use in a class/static variable in the parent. Depending on the import description this might be broken. Here, the code:

module
  |--main.py
  |--child.py
  |--submodule
       |-parent.py
       |-__init.py__

parent.py:
    class Parent:

        listeners = []

        def __init__(self):
            Parent.listeners.append(self)
            print("Parent: " + str(len(Parent.listeners)))

child.py
    from submodule.parent import Parent

    class Child(Parent):

        def __init__(self):
            super(Child, self).__init__()
            print("Child: " + str(Parent.listeners))

main.py
    from module.child import Child
    from module.submodule.parent import Parent

    class ChildLocal(Parent):

        def __init__(self):
            super(ChildLocal, self).__init__()
            print("ChildLocal: " + str(Parent.listeners))


if __name__ == '__main__':
    child= Child()
    local = ChildLocal()

Result:
    Parent: 1
    Child: [<module.submodule.Child object at 0x0000020F51EE2DC8>]
    Parent: 1
    ChildLocal: [<__main__.ChildLocal object at 0x0000020F51EE2E48>]
Here, the parent object is imported in two different ways and two separate parental classes are created. Hence, each parent class collects only one child

If Parent is importet in child.py as 'from module.submodule.parent import Parent" (difference is the module.) the result looks as follows:
    Parent: 1
    Child: [<module.submodule.Child object at 0x00000182B0982DC8>]
    Parent: 2
    ChildLocal: [<module.submodule.Child object at 0x00000182B0982DC8>, <__main__.ChildLocal object at 0x00000182B0982E48>]
Here, both children are registered in the same parent class as intenden

In conclusion, there is a nasty (to debug) difference between a relative import path and a project root path. I am quite certain this behaviour is as intenden, but on the little chance it isn't i wanted to bring this to attentions, since it is a nightmare to find. Is it intended?

Cheers,
Sin

----------
messages: 383856
nosy: SinTh0r4s
priority: normal
severity: normal
status: open
title: Class has two prototypes
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42757>
_______________________________________

From report at bugs.python.org  Sun Dec 27 13:54:36 2020
From: report at bugs.python.org (Anton Hvornum)
Date: Sun, 27 Dec 2020 18:54:36 +0000
Subject: [issue42758] pathlib.Path to support the "in" operator (x in y)
Message-ID: <1609095276.8.0.751847777656.issue42758@roundup.psfhosted.org>


New submission from Anton Hvornum <anton.feeds+github at gmail.com>:

I would like to propose that the `pathlib.Path()` gets a `in` operator, much like that ipaddress has IP in Subnet, it would be nice if we could be able to do:

```
import pathlib
pathlib.Path('/home/Torxed/machine.qcow2')
pathlib.Path('/home/Torxed/machine.qcow2') in pathlib.Path('/home/Torxed')
```

Currently that would generate:
```
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: argument of type 'PosixPath' is not iterable
```

This would avoid "complicated" implementations such as:
 * https://stackoverflow.com/questions/21411904/python-how-to-check-if-path-is-a-subpath
 * https://stackoverflow.com/questions/3812849/how-to-check-whether-a-directory-is-a-sub-directory-of-another-directory

Which tend to be half-complete truths and would result in potential security issues. pathlib.Path() could help prevent some of those.

----------
components: Library (Lib)
messages: 383857
nosy: Torxed
priority: normal
severity: normal
status: open
title: pathlib.Path to support the "in" operator (x in y)
type: enhancement
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42758>
_______________________________________

From report at bugs.python.org  Sun Dec 27 15:04:17 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 27 Dec 2020 20:04:17 +0000
Subject: [issue41450] OSError is not documented in ssl library,
 but still can be thrown
In-Reply-To: <1596206187.31.0.0863049661733.issue41450@roundup.psfhosted.org>
Message-ID: <1609099457.62.0.901449960777.issue41450@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:

This is resolved by Issue 31122 and code now raises SSLEOFError instead of OSError.

The reason for OSError in the first place was PySSL_SetError function had the following call s->errorhandler();

https://github.com/python/cpython/blob/3.7/Modules/_ssl.c#L782

Where the errorhandler of socketmodule.c was called, and error message that raised was OSError (https://github.com/python/cpython/blob/master/Modules/socketmodule.c#L607)

---

In issue31122, Dima.Tisnek contributed a patch to remove the s-errorhandler() and replace it with  SSLEOFError https://github.com/python/cpython/commit/495bd035662fda29639f9d52bb6baebea31d72fa 

Since the patch was ported to 3.8 and 3.9, OSError is no longer raised by the ssl module for the do_handshake call or wherever PySSL_SetError is utilized.

Closing this bug report as resolved.

----------
assignee: docs at python -> orsenthil
nosy: +Dima.Tisnek, orsenthil
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41450>
_______________________________________

From report at bugs.python.org  Sun Dec 27 15:04:36 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 27 Dec 2020 20:04:36 +0000
Subject: [issue42093] Add opcode cache for LOAD_ATTR
In-Reply-To: <1603163916.18.0.528007796853.issue42093@roundup.psfhosted.org>
Message-ID: <1609099476.29.0.380556108677.issue42093@roundup.psfhosted.org>


Guido van Rossum <gvanrossum at gmail.com> added the comment:

Wow, this is amazing. I just found that this is now faster than slots. Should we mention that in What's New?

(Of course there's an optimization possible for slots as well, but it would require complicating the cache struct. Maybe in 3.11. :-)

----------
nosy: +Guido.van.Rossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42093>
_______________________________________

From report at bugs.python.org  Sun Dec 27 15:04:38 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 27 Dec 2020 20:04:38 +0000
Subject: [issue41450] OSError is not documented in ssl library,
 but still can be thrown
In-Reply-To: <1596206187.31.0.0863049661733.issue41450@roundup.psfhosted.org>
Message-ID: <1609099478.2.0.983194846177.issue41450@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
components: +Library (Lib) -Documentation
versions: +Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41450>
_______________________________________

From report at bugs.python.org  Sun Dec 27 15:16:59 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Dec 2020 20:16:59 +0000
Subject: [issue42759] Take into acount a Tcl interpreter when compare
 variables and fonts
Message-ID: <1609100219.29.0.633808020235.issue42759@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Currently instances of tkinter.Variable and tkinter.font.Font are considered equal when they have the same name even if they belong to different Tcl interpreters. But Tcl interpreters are isolated, and variables and fonts in different interpreters refer to different things.

There is note in the docstring of tkinter.Variable.__eq__ about taking into account master. The following PR fixes this omission.

----------
components: Library (Lib), Tkinter
messages: 383860
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Take into acount a Tcl interpreter when compare variables and fonts
type: behavior
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42759>
_______________________________________

From report at bugs.python.org  Sun Dec 27 15:21:47 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Dec 2020 20:21:47 +0000
Subject: [issue42759] Take into acount a Tcl interpreter when compare
 variables and fonts
In-Reply-To: <1609100219.29.0.633808020235.issue42759@roundup.psfhosted.org>
Message-ID: <1609100507.59.0.276729350104.issue42759@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +22813
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23968

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42759>
_______________________________________

From report at bugs.python.org  Sun Dec 27 15:41:09 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 27 Dec 2020 20:41:09 +0000
Subject: [issue42738] subprocess: don't close all file descriptors by default
 (close_fds=False)
In-Reply-To: <1608897183.26.0.576206535349.issue42738@roundup.psfhosted.org>
Message-ID: <1609101669.05.0.0810636344929.issue42738@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

Note that vfork() support has been merged for 3.10 via bpo-35823, so posix_spawn() is less of a performance carrot than it used to be on Linux.  vfork() exists macOS, that code could likely be enabled there after some investigation+testing.

Regardless, changing this default sounds difficult due to the variety of things depending on the existing behavior - potentially for security issues as you've noted - when running in a process with other file descriptors potentially not managed by Python (ie: extension modules) that don't explicitly use CLOEXEC.

The subprocess APIs are effectively evolving to become lower level over time as we continually find warts in them that need addressing but find defaults that cannot change due to existing uses.  A higher level "best practices for launching child processes module" with APIs reflecting explicit intents (performance vs security vs simplicity) rather than requiring users to understand subprocess platform specific details may be a good idea at this point (on PyPI I assume).

We changed posix close_fds default to True in 3.2 when Jeffrey and I wrote _posixsubprocess to better match the behavior most users actually want - undoing that doesn't feel right.

----------
type:  -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42738>
_______________________________________

From report at bugs.python.org  Sun Dec 27 15:41:27 2020
From: report at bugs.python.org (Paolo Lammens)
Date: Sun, 27 Dec 2020 20:41:27 +0000
Subject: [issue42760] inspect.iscoroutine returns False for asynchronous
 generator functions
Message-ID: <1609101687.37.0.151159530312.issue42760@roundup.psfhosted.org>


New submission from Paolo Lammens <lammenspaolo at gmail.com>:

The `inspect.iscoroutinefunction` and `inspect.iscoroutine` functions return `False` for the `asend`, `athrow` and `aclose` methods of asynchronous generators (PEP 525). These are coroutine functions (i.e. one does e.g. `await gen.asend(value)`) so I would have expected these to return `True`.

Example:

```python
async def generator():
    return
    yield
```

```python
>>> import inspect
>>> g = generator()
>>> inspect.iscoroutinefunction(g.asend)
False

>>> inspect.iscoroutine(g.asend(None))
False
```

----------
components: Library (Lib), asyncio
messages: 383862
nosy: asvetlov, plammens, yselivanov
priority: normal
severity: normal
status: open
title: inspect.iscoroutine returns False for asynchronous generator functions
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42760>
_______________________________________

From report at bugs.python.org  Sun Dec 27 15:42:26 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 27 Dec 2020 20:42:26 +0000
Subject: [issue38435] Start the deprecation cycle for subprocess preexec_fn
In-Reply-To: <1570731497.4.0.313201495913.issue38435@roundup.psfhosted.org>
Message-ID: <1609101746.67.0.606999735331.issue38435@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

> "using Python is more portable than relying on a shell."

Not in environments I use. :)  There isn't an installed python interpreter that can be executed when deploying Python as an embedded interpreter such as anyone using pyoxidizer or similar.  Plus "using python" means adding a Python startup time delay to anything that triggered such an action.  That added latency isn't acceptable in some situations.

When I suggest a workaround for something as involving an intermediate shell script, read that to mean "the user needs an intermediate program to do this complicated work for them - how is up to them - we aren't going to provide it from the stdlib".  A shell script is merely one easy pretty-fast solution - in environments where that is possible.

TL;DR - there's no one size fits all solution here.  But third party libraries could indeed implement any/all of these options including abstracting how and what gets used when if someone wanted to do that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38435>
_______________________________________

From report at bugs.python.org  Sun Dec 27 15:48:47 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 27 Dec 2020 20:48:47 +0000
Subject: [issue42750] tkinter.Variable equality inconsistency
In-Reply-To: <1608995176.07.0.806534213214.issue42750@roundup.psfhosted.org>
Message-ID: <1609102127.02.0.990870760975.issue42750@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

You confuse variable and its value. tkinter.Variable is not a data container like list. It is a reference to external resource, Tcl variable, which contains value. If different Variable instances refer to different Tcl variables, they are different, even if values of these variables at some moment were equal. If they refer to the same Tcl variable, they can be considered equal. Details are different for different Tkinter classes: Font instances with the same name are equal, Variable instances with the same name are equal only if they have the same class (so that StringVar and IntVar are always different), Image and Widget instances with the same name are different. But in any case references to different resources are different.

Use analogy of Path instead of list. The Path object refers to external resource (file). Path objects with the same path are equal. Path objects with different paths are different, even if files have the same content.

I didn't close the ????? right away because I was trying to explain his mistake to Ivo. There is no inconsistency, there is just a misunderstanding. Anyway, I'm closing it now.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42750>
_______________________________________

From report at bugs.python.org  Sun Dec 27 15:52:51 2020
From: report at bugs.python.org (Gerrik Labra)
Date: Sun, 27 Dec 2020 20:52:51 +0000
Subject: [issue42753] "./configure" linux chrome beta
In-Reply-To: <1609042767.15.0.899316514178.issue42753@roundup.psfhosted.org>
Message-ID: <1609102371.61.0.447293528537.issue42753@roundup.psfhosted.org>


Gerrik Labra <gerriklabra at gmail.com> added the comment:

I do not have a C compiler. I do know from the chromebook support that my version of Linux is Debian. So I have that to work with.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42753>
_______________________________________

From report at bugs.python.org  Sun Dec 27 15:53:43 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 27 Dec 2020 20:53:43 +0000
Subject: [issue42736] Add support for making Linux prctl(...) calls to
 subprocess
In-Reply-To: <1608875716.63.0.116569716148.issue42736@roundup.psfhosted.org>
Message-ID: <1609102423.81.0.85376893258.issue42736@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

Thanks for the golang SysProcAttr reference.  The internals of _posixsubprocess have already becoming unwieldy with the abundance of args.  Such a struct/object would also fit in well there and avoid excessive C stack use.  (as izbyshev noted during the vfork work)

Most prctl uses I noticed were PDEATHSIG but I'd need to explicitly audit those.  Users don't seem to care about it's documented main thread caveat (which matches what I've seen; most programs don't use non-daemon threads and exit the main thread).

I want what we do for this to be futureproof for the syscall so that we don't wind up merely picking one feature such as PDEATHSIG to pass a flags through to and needing to add logic to support others later on, delaying the ability to use new system features.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42736>
_______________________________________

From report at bugs.python.org  Sun Dec 27 16:20:22 2020
From: report at bugs.python.org (Ross Rhodes)
Date: Sun, 27 Dec 2020 21:20:22 +0000
Subject: [issue42756] smtplib.LMTP.connect() raises TypeError if `timeout` is
 not specified
In-Reply-To: <1609074713.39.0.771360640486.issue42756@roundup.psfhosted.org>
Message-ID: <1609104022.27.0.47251614016.issue42756@roundup.psfhosted.org>


Change by Ross Rhodes <ross.rhodes at hotmail.co.uk>:


----------
keywords: +patch
nosy: +trrhodes
nosy_count: 1.0 -> 2.0
pull_requests: +22814
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23969

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42756>
_______________________________________

From report at bugs.python.org  Sun Dec 27 16:24:46 2020
From: report at bugs.python.org (Ross Rhodes)
Date: Sun, 27 Dec 2020 21:24:46 +0000
Subject: [issue42756] smtplib.LMTP.connect() raises TypeError if `timeout` is
 not specified
In-Reply-To: <1609074713.39.0.771360640486.issue42756@roundup.psfhosted.org>
Message-ID: <1609104286.22.0.00604641259686.issue42756@roundup.psfhosted.org>


Ross Rhodes <ross.rhodes at hotmail.co.uk> added the comment:

Hello W?stengecko,

Thanks for raising this issue. I've opened a PR which I believe will resolve the problem, but it's difficult to verify this against the mock socket setup. Feel free to leave feedback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42756>
_______________________________________

From report at bugs.python.org  Sun Dec 27 16:41:34 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 27 Dec 2020 21:41:34 +0000
Subject: [issue27794] setattr a read-only property;
 the AttributeError should show the attribute that failed
In-Reply-To: <1471528639.63.0.0729109170448.issue27794@psf.upfronthosting.co.za>
Message-ID: <1609105294.14.0.00796216499402.issue27794@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Yurii, this looks nice.  I question whether *name* should be a part of the constructor because it immediately gets overridden by __set_name__ method.

>>> class A:
...    def x(self):
...        return 44
...    x = property(x, name='y')
...
>>> vars(A)['x'].name
'x'

----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27794>
_______________________________________

From report at bugs.python.org  Sun Dec 27 16:43:25 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 27 Dec 2020 21:43:25 +0000
Subject: [issue42736] Add support for making Linux prctl(...) calls to
 subprocess
In-Reply-To: <1608875716.63.0.116569716148.issue42736@roundup.psfhosted.org>
Message-ID: <1609105405.1.0.0419193676489.issue42736@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I agree that it would be nice to pack these parameters, similar to the Windows STARTUPINFO. The subprocess.Popen constructor has more and more parameter for functions executed between fork and exec:

    def __init__(self, args, bufsize=-1, executable=None,
                 stdin=None, stdout=None, stderr=None,
                 preexec_fn=None, close_fds=True,
                 shell=False, cwd=None, env=None, universal_newlines=None,
                 startupinfo=None, creationflags=0,
                 restore_signals=True, start_new_session=False,
                 pass_fds=(), *, user=None, group=None, extra_groups=None,
                 encoding=None, errors=None, text=None, umask=-1, pipesize=-1):

Parameters:

* close_fds: close()
* pass_fds: _Py_set_inheritable_async_safe()
* restore_signals: _Py_RestoreSignals()
* start_new_session: setsid()
* user: setreuid()
* group: setregid()
* extra_groups: setgroups()
* cwd: chdir()
* umask: umask()
* XXX special case: preexec_fn.

Idea of API:
-------------
preexec = subprocess.Preexec()
preexec.setsid()
preexec.chdir(path)

popen = subprocess.Popen(cmd, preexec=preexec)
popen.wait()
-------------

It would make error reporting more helpful. For example, if the path type is not bytes or str, preexec.chdir(path) call would raise an error, rather than getting an error in the complex Popen constructor.

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42736>
_______________________________________

From report at bugs.python.org  Sun Dec 27 16:58:58 2020
From: report at bugs.python.org (Yurii Karabas)
Date: Sun, 27 Dec 2020 21:58:58 +0000
Subject: [issue27794] setattr a read-only property;
 the AttributeError should show the attribute that failed
In-Reply-To: <1471528639.63.0.0729109170448.issue27794@psf.upfronthosting.co.za>
Message-ID: <1609106338.85.0.217184198974.issue27794@roundup.psfhosted.org>


Yurii Karabas <1998uriyyo at gmail.com> added the comment:

Raymond, it's a good question.

I have added `name` to `property` constructor to support cases when a property is added to a class after it was declared.

For instance:

```
class Foo:
    pass


Foo.foo = property(name='foo')

f = Foo()
f.foo = 10
```

So, in my opinion, it's expected behavior that `name` is overwritten by `__set_name__` method.

What do you think about that? Should we change this behevior?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27794>
_______________________________________

From report at bugs.python.org  Sun Dec 27 17:35:33 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 27 Dec 2020 22:35:33 +0000
Subject: [issue42755] sqlite3.Connection.backup default value is diffrent
 between implmentation and docs
In-Reply-To: <1609056718.52.0.719197971794.issue42755@roundup.psfhosted.org>
Message-ID: <1609108533.08.0.834200107472.issue42755@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset abba83b4b91f78dc556dc0b7700ecb46cba22c01 by Erlend Egeberg Aasland in branch 'master':
bpo-42755: Fix sqlite3.Connection.backup docs (GH-23965)
https://github.com/python/cpython/commit/abba83b4b91f78dc556dc0b7700ecb46cba22c01


----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42755>
_______________________________________

From report at bugs.python.org  Sun Dec 27 17:35:49 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 27 Dec 2020 22:35:49 +0000
Subject: [issue42755] sqlite3.Connection.backup default value is diffrent
 between implmentation and docs
In-Reply-To: <1609056718.52.0.719197971794.issue42755@roundup.psfhosted.org>
Message-ID: <1609108549.7.0.763523726986.issue42755@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +22815
pull_request: https://github.com/python/cpython/pull/23970

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42755>
_______________________________________

From report at bugs.python.org  Sun Dec 27 17:35:57 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 27 Dec 2020 22:35:57 +0000
Subject: [issue42755] sqlite3.Connection.backup default value is diffrent
 between implmentation and docs
In-Reply-To: <1609056718.52.0.719197971794.issue42755@roundup.psfhosted.org>
Message-ID: <1609108557.96.0.56644360414.issue42755@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22816
pull_request: https://github.com/python/cpython/pull/23971

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42755>
_______________________________________

From report at bugs.python.org  Sun Dec 27 17:36:19 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Sun, 27 Dec 2020 22:36:19 +0000
Subject: [issue42755] sqlite3.Connection.backup default value is diffrent
 between implmentation and docs
In-Reply-To: <1609056718.52.0.719197971794.issue42755@roundup.psfhosted.org>
Message-ID: <1609108579.56.0.0323676307689.issue42755@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
nosy:  -miss-islington
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42755>
_______________________________________

From report at bugs.python.org  Sun Dec 27 17:45:48 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 27 Dec 2020 22:45:48 +0000
Subject: [issue42736] Add support for making Linux prctl(...) calls to
 subprocess
In-Reply-To: <1609102423.81.0.85376893258.issue42736@roundup.psfhosted.org>
Message-ID: <2942bfa6-6970-4b03-80be-3dc01a4de47d@www.fastmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

On Sun, Dec 27, 2020, at 14:53, Gregory P. Smith wrote:
> Most prctl uses I noticed were PDEATHSIG but I'd need to explicitly 
> audit those.  Users don't seem to care about it's documented main 
> thread caveat (which matches what I've seen; most programs don't use 
> non-daemon threads and exit the main thread).

It works great until someone refactors their process-launching code to be asynchronous. Anyway, I don't mean to bog this discussion down in the advisability and utility of PDEATHSIG. Clearly, it needs to be supported to remove even less advisable functionality.

> 
> I want what we do for this to be futureproof for the syscall so that we 
> don't wind up merely picking one feature such as PDEATHSIG to pass a 
> flags through to and needing to add logic to support others later on, 
> delaying the ability to use new system features.

The proposal right now feels like overgeneralization leading to an icky interface. It seems in spirit no different form providing a similar interface to syscall(3). At some point the interface will become so general it defeats the initial purpose of introduction, to disallow arbitrary code execution before execve. There will always be new syscalls, multiplexed into prctl/ioctl or not, that people want to make before execution. The universal workaround of a wrapper program can satisfy those on the vanguard.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42736>
_______________________________________

From report at bugs.python.org  Sun Dec 27 17:52:55 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 27 Dec 2020 22:52:55 +0000
Subject: [issue27794] setattr a read-only property;
 the AttributeError should show the attribute that failed
In-Reply-To: <1471528639.63.0.0729109170448.issue27794@psf.upfronthosting.co.za>
Message-ID: <1609109575.5.0.065687500826.issue27794@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> In my opinion, it's expected behavior that `name` is 
> overwritten by `__set_name__` method.

It is almost certain that there will be others won't share that expectation.  The StackOverflow questions and bug reports are inevitable.

Most examples of __set_name__() use a private attribute.  I recommend that you go that route and stick to the spirit of the original bug report.  The OP asked for better error messages when possible.  They didn't ask for an API expansion.

> I have added `name` to `property` constructor to support cases
> when a property is added to a class after it was declared.

That rarely occurs in practice.  I wouldn't worry about it.  Also AFAICT the only time the new error message matters is in the context of a setattr() where the attribute isn't already shown in the traceback.  So the case in question is really a rarity inside another rarity.  Let's declare YAGNI unless an actual end-user problem arises in real-world code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27794>
_______________________________________

From report at bugs.python.org  Sun Dec 27 17:56:44 2020
From: report at bugs.python.org (miss-islington)
Date: Sun, 27 Dec 2020 22:56:44 +0000
Subject: [issue42755] sqlite3.Connection.backup default value is diffrent
 between implmentation and docs
In-Reply-To: <1609056718.52.0.719197971794.issue42755@roundup.psfhosted.org>
Message-ID: <1609109804.83.0.568089302256.issue42755@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 9f6a37cc072dab9f9a13d491d3592d23d9809d2b by Miss Islington (bot) in branch '3.9':
bpo-42755: Fix sqlite3.Connection.backup docs (GH-23965)
https://github.com/python/cpython/commit/9f6a37cc072dab9f9a13d491d3592d23d9809d2b


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42755>
_______________________________________

From report at bugs.python.org  Sun Dec 27 17:56:52 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Sun, 27 Dec 2020 22:56:52 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1609109812.11.0.686960700633.issue1635741@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
pull_requests: +22817
pull_request: https://github.com/python/cpython/pull/23972

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Sun Dec 27 18:21:46 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 27 Dec 2020 23:21:46 +0000
Subject: [issue40512] [subinterpreters] Meta issue: per-interpreter GIL
In-Reply-To: <1588683075.13.0.0239787407564.issue40512@roundup.psfhosted.org>
Message-ID: <1609111306.74.0.408046602273.issue40512@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

FYI I wrote an article about this issue: "Isolate Python Subinterpreters"
https://vstinner.github.io/isolate-subinterpreters.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40512>
_______________________________________

From report at bugs.python.org  Sun Dec 27 18:23:38 2020
From: report at bugs.python.org (Yurii Karabas)
Date: Sun, 27 Dec 2020 23:23:38 +0000
Subject: [issue27794] setattr a read-only property;
 the AttributeError should show the attribute that failed
In-Reply-To: <1471528639.63.0.0729109170448.issue27794@psf.upfronthosting.co.za>
Message-ID: <1609111418.65.0.0897264489818.issue27794@roundup.psfhosted.org>


Yurii Karabas <1998uriyyo at gmail.com> added the comment:

You a totally right, looks like I tried to add a feature that no one asked for:)

I have updated PR and removed `name` parameter from `property` constuctor. Thanks for your advice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27794>
_______________________________________

From report at bugs.python.org  Sun Dec 27 18:28:36 2020
From: report at bugs.python.org (AustEcon)
Date: Sun, 27 Dec 2020 23:28:36 +0000
Subject: [issue42761] Why does python's Popen fail to pass environment
 variables on Mac OS X?
Message-ID: <1609111716.94.0.537110439722.issue42761@roundup.psfhosted.org>


New submission from AustEcon <austecon0922 at gmail.com>:

I have described the issue in a stackoverflow question here:

https://stackoverflow.com/questions/65466303/why-does-pythons-popen-fail-to-pass-environment-variables-on-mac-os-x


In summary, I want to pass environment variables to a child process on Mac OS (Big Sur) with Popen but it is not working (works on Win32 and linux platforms).

Any assistance much appreciated,
AustEcon

----------
components: Library (Lib)
messages: 383877
nosy: AustEcon
priority: normal
severity: normal
status: open
title: Why does python's Popen fail to pass environment variables on Mac OS X?
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42761>
_______________________________________

From report at bugs.python.org  Sun Dec 27 18:33:46 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 27 Dec 2020 23:33:46 +0000
Subject: [issue42761] Why does python's Popen fail to pass environment
 variables on Mac OS X?
In-Reply-To: <1609111716.94.0.537110439722.issue42761@roundup.psfhosted.org>
Message-ID: <1609112026.49.0.498765752579.issue42761@roundup.psfhosted.org>


Change by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42761>
_______________________________________

From report at bugs.python.org  Sun Dec 27 18:43:32 2020
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 27 Dec 2020 23:43:32 +0000
Subject: [issue40288] [subinterpreters] atexit module should not be loaded
 more than once per interpreter
In-Reply-To: <1586917009.7.0.806642420762.issue40288@roundup.psfhosted.org>
Message-ID: <1609112612.79.0.375084561704.issue40288@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Fixed by bpo-42639.

----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Make atexit state per interpreter

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40288>
_______________________________________

From report at bugs.python.org  Sun Dec 27 18:51:33 2020
From: report at bugs.python.org (Jakub Stasiak)
Date: Sun, 27 Dec 2020 23:51:33 +0000
Subject: [issue42513] Socket.recv hangs
In-Reply-To: <1606737349.78.0.516615398151.issue42513@roundup.psfhosted.org>
Message-ID: <1609113093.82.0.549702547299.issue42513@roundup.psfhosted.org>


Change by Jakub Stasiak <jakub+python.org at stasiak.at>:


----------
nosy: +jstasiak

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42513>
_______________________________________

From report at bugs.python.org  Sun Dec 27 19:52:11 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 28 Dec 2020 00:52:11 +0000
Subject: [issue42758] pathlib.Path to support the "in" operator (x in y)
In-Reply-To: <1609095276.8.0.751847777656.issue42758@roundup.psfhosted.org>
Message-ID: <1609116731.03.0.820817994708.issue42758@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Can you describe what this would do? How is it different from path.is_relative_to(other_path)?

>>> import pathlib
>>> pathlib.Path('/home/Torxed/machine.qcow2').is_relative_to(pathlib.Path('/home/Torxed'))
True

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42758>
_______________________________________

From report at bugs.python.org  Sun Dec 27 19:59:25 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 28 Dec 2020 00:59:25 +0000
Subject: [issue42758] pathlib.Path to support the "in" operator (x in y)
In-Reply-To: <1609095276.8.0.751847777656.issue42758@roundup.psfhosted.org>
Message-ID: <1609117165.55.0.613183062356.issue42758@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
versions:  -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42758>
_______________________________________

From report at bugs.python.org  Sun Dec 27 21:09:42 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Dec 2020 02:09:42 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1609121382.03.0.31464400248.issue1635741@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 897387d2c8a956e74770c6bdd0447dfec61e8e27 by Erlend Egeberg Aasland in branch 'master':
bpo-1635741: sqlite3: Fix ref leak introduced by commit bf64d90 (GH-23972)
https://github.com/python/cpython/commit/897387d2c8a956e74770c6bdd0447dfec61e8e27


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Sun Dec 27 21:53:51 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 28 Dec 2020 02:53:51 +0000
Subject: [issue23328] urllib.request fails for proxy credentials that contain
 a '/' character
In-Reply-To: <1422342235.17.0.905041944591.issue23328@psf.upfronthosting.co.za>
Message-ID: <1609124031.93.0.692199688602.issue23328@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
keywords: +patch
pull_requests: +22818
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/23973

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23328>
_______________________________________

From report at bugs.python.org  Sun Dec 27 21:54:56 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 28 Dec 2020 02:54:56 +0000
Subject: [issue23328] urllib.request fails for proxy credentials that contain
 a '/' character
In-Reply-To: <1422342235.17.0.905041944591.issue23328@psf.upfronthosting.co.za>
Message-ID: <1609124096.29.0.322783246433.issue23328@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:

https://github.com/python/cpython/pull/23973 will resolve this issue.  The issue was localized to _parse_proxy method in urllib2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23328>
_______________________________________

From report at bugs.python.org  Sun Dec 27 23:38:15 2020
From: report at bugs.python.org (Xinmeng Xia)
Date: Mon, 28 Dec 2020 04:38:15 +0000
Subject: [issue42762] infinite loop resulted by "yield"
Message-ID: <1609130295.32.0.912620547313.issue42762@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

Let's see the following program:

============================
def foo():
    try:
        yield
    except:
        yield from foo()

for m in foo():
    print(i)
===========================

Expected output:
On line"print(i)",  NameError: name 'i' is not defined


However, the program will fall into infinite loops when running it on Python 3.7-3.10 with the error messages like the following.(no infinite loop on Python 3.5 and Python 3.6)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/xxm/Desktop/nameChanging/report/test1.py", line 160, in <module>
    print(i)
RuntimeError: generator ignored GeneratorExit
Exception ignored in: <generator object foo at 0x7fb30ff639e0>
Traceback (most recent call last):
  File "/home/xxm/Desktop/nameChanging/report/test1.py", line 160, in <module>
    print(i)
RuntimeError: generator ignored GeneratorExit
Exception ignored in: <generator object foo at 0x7fb30ff63a50>
Traceback (most recent call last):
  File "/home/xxm/Desktop/nameChanging/report/test1.py", line 160, in <module>
    print(i)
RuntimeError: generator ignored GeneratorExit
Exception ignored in: <generator object foo at 0x7fb30ff63ac0>
Traceback (most recent call last):
  File "/home/xxm/Desktop/nameChanging/report/test1.py", line 160, in <module>
    print(i)
......
----------------------------------------------------------------------

----------
components: Interpreter Core
messages: 383882
nosy: xxm
priority: normal
severity: normal
status: open
title: infinite loop resulted by "yield"
type: crash
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42762>
_______________________________________

From report at bugs.python.org  Sun Dec 27 23:39:59 2020
From: report at bugs.python.org (Xinmeng Xia)
Date: Mon, 28 Dec 2020 04:39:59 +0000
Subject: [issue42763] Exposing a race in the "_warnings" resulting Python
 parser crash
Message-ID: <1609130399.05.0.938510382701.issue42763@roundup.psfhosted.org>


New submission from Xinmeng Xia <xiaxm at smail.nju.edu.cn>:

This program is initially from "cpython/Lib/test/crashers/warnings_del_crasher.py" in Python 2.7. The original case is fixed for all version of Python and removed from "crashers" directory. However, if we replace the statement  "for i in range(10):" of original program  with the statement "for do_work in range(10):" . The race will happen again, and it will crash Python 3.7 - 3.10.
==================================================
import threading
import warnings

class WarnOnDel(object):
    def __del__(self):
        warnings.warn("oh no something went wrong", UserWarning)

def do_work():
    while True:
        w = WarnOnDel()

-for i in range(10):
+for do_work in range(10):
    t = threading.Thread(target=do_work)
    t.setDaemon(1)
    t.start()
=================================================


Error messages on Python 3.7-3.10:
-------------------------------------------------------------------------------
Exception in thread Thread-2:
Traceback (most recent call last):
  File "/usr/local/python310/lib/python3.10/threading.py", line 960, in _bootstrap_inner
Exception in thread Thread-3:
Traceback (most recent call last):
Exception in thread Thread-4:
  File "/usr/local/python310/lib/python3.10/threading.py", line 960, in _bootstrap_inner
Exception in thread Thread-5:
Traceback (most recent call last):
    self.run()
Traceback (most recent call last):
    self.run()
Exception in thread Thread-6:
Exception in thread Thread-8:
Exception in thread Thread-9:
Exception in thread Thread-10:
Fatal Python error: _enter_buffered_busy: could not acquire lock for <_io.BufferedWriter name='<stderr>'> at interpreter shutdown, possibly due to daemon threads
Python runtime state: finalizing (tstate=0x2679180)

Current thread 0x00007f3481d3a700 (most recent call first):
<no Python frame>
Aborted (core dumped)

----------
components: Interpreter Core
messages: 383883
nosy: xxm
priority: normal
severity: normal
status: open
title: Exposing a race in the "_warnings" resulting Python parser crash
type: crash
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42763>
_______________________________________

From report at bugs.python.org  Sun Dec 27 23:51:23 2020
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 28 Dec 2020 04:51:23 +0000
Subject: [issue42736] Add support for making Linux prctl(...) calls to
 subprocess
In-Reply-To: <1608875716.63.0.116569716148.issue42736@roundup.psfhosted.org>
Message-ID: <1609131083.01.0.253173875003.issue42736@roundup.psfhosted.org>


Gregory P. Smith <greg at krypto.org> added the comment:

Felt and understood.

The plethora of things to do between (v)fork+exec really makes me wish for a "little" eBPF interpreter rather than needing so much specific plumbing.  But that'd have the same problem as preexec_fn: in absence of something that declares an operation safe or not, it'd open the door to unsafe and leave us in no better state than preexec_fn.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42736>
_______________________________________

From report at bugs.python.org  Mon Dec 28 02:45:44 2020
From: report at bugs.python.org (Christof Hanke)
Date: Mon, 28 Dec 2020 07:45:44 +0000
Subject: [issue41354] filecmp.cmp documentation does not match actual code
In-Reply-To: <1595316543.83.0.558279011146.issue41354@roundup.psfhosted.org>
Message-ID: <1609141544.52.0.414896395987.issue41354@roundup.psfhosted.org>


Christof Hanke <christof.hanke at mpcdf.mpg.de> added the comment:

I understand that you are reluctant to change existing code.
But for me as a sysadmin, the current behavior doesn't make sense for two reasons:

* st.st_size is part of _sig.  why would you do a deep compare if  the two files have a different length ?

* comparing thousands of files, a proper shallow-only compare is required, since it takes a long time to compare large files (especially when they are migrated to a tape-backend), so a silent-fallback to a deep-compare is not good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41354>
_______________________________________

From report at bugs.python.org  Mon Dec 28 03:23:34 2020
From: report at bugs.python.org (Anton Hvornum)
Date: Mon, 28 Dec 2020 08:23:34 +0000
Subject: [issue42758] pathlib.Path to support the "in" operator (x in y)
In-Reply-To: <1609095276.8.0.751847777656.issue42758@roundup.psfhosted.org>
Message-ID: <1609143814.59.0.179500090724.issue42758@roundup.psfhosted.org>


Anton Hvornum <anton.feeds+github at gmail.com> added the comment:

Missed that function, but they would behave the same without explicitly use the function call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42758>
_______________________________________

From report at bugs.python.org  Mon Dec 28 04:11:56 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 28 Dec 2020 09:11:56 +0000
Subject: [issue42758] pathlib.Path to support the "in" operator (x in y)
In-Reply-To: <1609095276.8.0.751847777656.issue42758@roundup.psfhosted.org>
Message-ID: <1609146716.58.0.917309854702.issue42758@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

I don't think there's any chance we'd add "in" as an alias for "is_relative_to()", so I'm going to close this.

If you disagree, you could try and get support on python-ideas, and then we can re-open this.

Thanks!

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42758>
_______________________________________

From report at bugs.python.org  Mon Dec 28 04:32:37 2020
From: report at bugs.python.org (=?utf-8?b?5pa95paH5bOw?=)
Date: Mon, 28 Dec 2020 09:32:37 +0000
Subject: [issue42733] io's r+ mode truncate(0)
In-Reply-To: <1608866591.42.0.709266826628.issue42733@roundup.psfhosted.org>
Message-ID: <1609147957.5.0.101516821971.issue42733@roundup.psfhosted.org>


??? <ke265379ke at gmail.com> added the comment:

hi Terry

you are right
i download python version 3.0.1 to check this case

'''
Python 3.0.1 (r301:69556, Dec 28 2020, 14:14:02) 
[GCC 7.5.0] on linux5
Type "help", "copyright", "credits" or "license" for more information.
>>> from test_case import test
[43552 refs]
>>> test()
beginning tell 0
tell after read 32
tell after delete content 0
tell after write 32
[52665 refs]
>>> 

'''

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42733>
_______________________________________

From report at bugs.python.org  Mon Dec 28 05:07:01 2020
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 28 Dec 2020 10:07:01 +0000
Subject: [issue42690] Aiohttp fails when using intel ax200 wireless card
In-Reply-To: <1608452216.56.0.63748155919.issue42690@roundup.psfhosted.org>
Message-ID: <1609150021.14.0.860755876462.issue42690@roundup.psfhosted.org>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

What's the script used, is it the script in the reddit thread? 

The reddit thread mentions a change to the script that might help:

     return [await r.json() for r in responses]

To:
     return await asyncio.gather(*(r.json() for r in responses))

Does that remove the error?

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42690>
_______________________________________

From report at bugs.python.org  Mon Dec 28 05:45:36 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 28 Dec 2020 10:45:36 +0000
Subject: [issue32825] warn user of creation of multiple Tk instances
In-Reply-To: <1518430442.75.0.467229070634.issue32825@psf.upfronthosting.co.za>
Message-ID: <1609152336.83.0.167574540817.issue32825@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/issue32825>
_______________________________________

From report at bugs.python.org  Mon Dec 28 06:21:47 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 28 Dec 2020 11:21:47 +0000
Subject: [issue40077] Convert static types to heap types: use PyType_FromSpec()
In-Reply-To: <1585238684.65.0.246012172449.issue40077@roundup.psfhosted.org>
Message-ID: <1609154507.49.0.469961655969.issue40077@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
pull_requests: +22819
pull_request: https://github.com/python/cpython/pull/23975

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40077>
_______________________________________

From report at bugs.python.org  Mon Dec 28 06:50:41 2020
From: report at bugs.python.org (Ivo Shipkaliev)
Date: Mon, 28 Dec 2020 11:50:41 +0000
Subject: [issue42750] tkinter.Variable equality inconsistency
In-Reply-To: <1608995176.07.0.806534213214.issue42750@roundup.psfhosted.org>
Message-ID: <1609156241.5.0.509562850358.issue42750@roundup.psfhosted.org>


Ivo Shipkaliev <ivo.shipkaliev at gmail.com> added the comment:

Yes, I get it now. I've missed the idea. You can do:

> age = tk.IntVar(value=38, name="mine")
> age_str = tk.StringVar(name="mine")
> is_alive = tk.BooleanVar(name="mine")
> is_alive.get()
True

Maybe not the best example, but still, it was a misunderstanding.

Thank you very much, Serhiy, once again!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42750>
_______________________________________

From report at bugs.python.org  Mon Dec 28 07:38:16 2020
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 28 Dec 2020 12:38:16 +0000
Subject: [issue42257] platform.libc_ver() doesn't consider in case of
 executable is empty string
In-Reply-To: <1604469715.55.0.889552705694.issue42257@roundup.psfhosted.org>
Message-ID: <1609159096.65.0.104481369598.issue42257@roundup.psfhosted.org>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Reviewed. Please check on the PR for comments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42257>
_______________________________________

From report at bugs.python.org  Mon Dec 28 08:16:44 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Dec 2020 13:16:44 +0000
Subject: [issue42257] platform.libc_ver() doesn't consider in case of
 executable is empty string
In-Reply-To: <1604469715.55.0.889552705694.issue42257@roundup.psfhosted.org>
Message-ID: <1609161404.42.0.482699260546.issue42257@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> Currently, `platform.libc_ver()` doesn't consider in case of `executable` variable is an empty string.

I'm curious. In which case sys.executable is an empty string? Do you embed Python in an application. If Python is embedded, would it be possible to share the code used to configure Python initialization?

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42257>
_______________________________________

From report at bugs.python.org  Mon Dec 28 08:48:52 2020
From: report at bugs.python.org (Peixing Xin)
Date: Mon, 28 Dec 2020 13:48:52 +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: <1609163332.62.0.984450427734.issue27640@roundup.psfhosted.org>


Change by Peixing Xin <peixing.xin at windriver.com>:


----------
nosy: +pxinwr
nosy_count: 6.0 -> 7.0
pull_requests: +22820
pull_request: https://github.com/python/cpython/pull/23886

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27640>
_______________________________________

From report at bugs.python.org  Mon Dec 28 09:11:59 2020
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 28 Dec 2020 14:11:59 +0000
Subject: [issue42738] subprocess: don't close all file descriptors by default
 (close_fds=False)
In-Reply-To: <1608897183.26.0.576206535349.issue42738@roundup.psfhosted.org>
Message-ID: <1609164719.71.0.275967226765.issue42738@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> Python 3.7 added the support for the PROC_THREAD_ATTRIBUTE_HANDLE_LIST 
> in subprocess.STARTUPINFO: lpAttributeList['handle_list'] parameter.

The motivating reason to add support for the WinAPI handle list was to allow changing the default to close_fds=True regardless of the need to inherit standard handles. However, even when using the handle list, one still has to make each handle in the list inheritable. Thus concurrent calls to os.system() and os.spawn*() -- which are not implemented via subprocess.Popen(), but should be -- may leak the handles in the list. If the default is changed to close_fds=False, then by default concurrent Popen() calls may also leak temporarily inheritable handles when a handle list isn't used to constrain inheritance.

Background

Windows implicitly duplicates standard I/O handles from a parent process to a child process if they're both console applications and the child inherits the console session. However, subprocess.Popen() requires standard I/O inheritance to work consistently even without an inherited console session. It explicitly inherits standard handles in the STARTUPINFO record, which requires CreateProcessW to be called with bInheritHandles as TRUE. In 3.7+, Popen() also passes the standard-handle values in a PROC_THREAD_ATTRIBUTE_HANDLE_LIST attribute that constrains inheritance, but handles in the list still have to be made inheritable before calling CreateProcessW. Thus they may be leaked by concurrent CreateProcessW calls that inherit handles without a constraining handle list.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42738>
_______________________________________

From report at bugs.python.org  Mon Dec 28 09:21:31 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Dec 2020 14:21:31 +0000
Subject: [issue40522] [subinterpreters] Get the current Python interpreter
 state from Thread Local Storage (autoTSSkey)
In-Reply-To: <1588698734.65.0.223552100195.issue40522@roundup.psfhosted.org>
Message-ID: <1609165291.44.0.792855424994.issue40522@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

There are many ways to get the current interpreter (interp) and the current Python thread state (tstate).

Public C API, opaque function call:

* PyInterpreterState_Get() (new in Python 3.9)
* PyThreadState_Get()

Internal C API, static inline functions:

* _PyInterpreterState_GET()
* _PyThreadState_GET()

There are so many variants that I wrote notes for myself:
https://pythondev.readthedocs.io/pystate.html

This issue is about optimizing _PyInterpreterState_GET() and _PyThreadState_GET() which are supposed to be the most efficient implementations.

Currently, _PyInterpreterState_GET() is implemented as _PyThreadState_GET()->interp, and _PyThreadState_GET() is implemented as:

    _Py_atomic_load_relaxed(_PyRuntime.gilstate.tstate_current)

--

To find the _PyInterpreterState_GET() machine code, I read the PyInterpreterState_Get() assembly code (not optimized, it adds tstate==NULL test) and PyTuple_New() assembly code, since PyTuple_New() now needs to get the current interpreter:

static struct _Py_tuple_state *
get_tuple_state(void)
{
    PyInterpreterState *interp = _PyInterpreterState_GET();
    return &interp->tuple;
}

To find the _PyThreadState_GET() machine code, I read the PyThreadState_Get() assembly code.

I looked at the x86-64 machine code generated by GCC -O3 (no LTO, no PGO, it should not be relevant here), using GCC 10.2.1 on Fedora 33.

_PyThreadState_GET():

   mov    rax,QWORD PTR [rip+0x2292b1]   # 0x743118 <_PyRuntime+568>

_PyInterpreterState_GET():

   mov    rax,QWORD PTR [rip+0x22a7dd]        # 0x743118 <_PyRuntime+568>
   mov    rax,QWORD PTR [rax+0x10]

By default, Python is built with -fPIC: _PyRuntime variable does not have a fixed address.

$ objdump -t ./python|grep '\<_PyRuntime\>'
0000000000742ee0 g     O .bss	00000000000002a0              _PyRuntime

The "[rip+0x2292b1] # 0x743118 <_PyRuntime+568>" indirection is needed by PIC.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40522>
_______________________________________

From report at bugs.python.org  Mon Dec 28 09:25:32 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Dec 2020 14:25:32 +0000
Subject: [issue40522] [subinterpreters] Get the current Python interpreter
 state from Thread Local Storage (autoTSSkey)
In-Reply-To: <1588698734.65.0.223552100195.issue40522@roundup.psfhosted.org>
Message-ID: <1609165532.7.0.395222226871.issue40522@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

>_PyInterpreterState_GET():
>   mov    rax,QWORD PTR [rip+0x22a7dd]        # 0x743118 <_PyRuntime+568>
>   mov    rax,QWORD PTR [rax+0x10]

While working on bpo-39465, I wrote PR 20767 to optimize _PyInterpreterState_GET(): single instruction instead of two:

* Add _PyRuntimeState.interp_current member: atomic variable
* _PyThreadState_Swap() sets _PyRuntimeState.interp_current

But I failed to measure any performance difference.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40522>
_______________________________________

From report at bugs.python.org  Mon Dec 28 09:49:01 2020
From: report at bugs.python.org (Anthony Hodson)
Date: Mon, 28 Dec 2020 14:49:01 +0000
Subject: [issue42764] HTMLParser close() issue
Message-ID: <1609166941.45.0.327676479076.issue42764@roundup.psfhosted.org>


New submission from Anthony Hodson <aeh at xdotd.com>:

HTMLParser close() does not seem to dispose of previous HTML analyses.

I an sending a simple test to demonstrate this, complete with functions 
that are part of a set of testing facilities.  The problem is present for more complex HTML.

----------
components: Library (Lib)
files: htmlparse_bug.py
messages: 383896
nosy: aeh
priority: normal
severity: normal
status: open
title: HTMLParser close() issue
versions: Python 3.9
Added file: https://bugs.python.org/file49702/htmlparse_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42764>
_______________________________________

From report at bugs.python.org  Mon Dec 28 10:26:40 2020
From: report at bugs.python.org (Richard Neumann)
Date: Mon, 28 Dec 2020 15:26:40 +0000
Subject: [issue42765] Introduce new data model method __iter_items__
Message-ID: <1609169200.88.0.326770807054.issue42765@roundup.psfhosted.org>


New submission from Richard Neumann <mail at richard-neumann.de>:

I have use cases in which I use named tuples to represent data sets, e.g:

class BasicStats(NamedTuple):
    """Basic statistics response packet."""

    type: Type
    session_id: BigEndianSignedInt32
    motd: str
    game_type: str
    map: str
    num_players: int
    max_players: int
    host_port: int
    host_ip: IPAddressOrHostname

I want them to behave as intended, i.e. that unpacking them should behave as expected from a tuple:

type, session_id, motd, ? = BasicStats(?)

I also want to be able to serialize them to a JSON-ish dict.
The NamedTuple has an _asdict method, that I could use.

json = BasicStats(?)._asdict()

But for the dict to be passed to JSON, I need customization of the dict representation, e.g. set host_ip to str(self.host_ip), since it might be a non-serializable ipaddress.IPv{4,6}Address. Doing this in an object hook of json.dumps() is a non-starter, since I cannot force the user to remember, which types need to be converted on the several data structures.
Also, using _asdict() seems strange as an exposed API, since it's an underscore method and users hence might not be inclined to use it.

So what I did is to add a method to_json() to convert the named tuple into a JSON-ish dict:

    def to_json(self) -> dict:
        """Returns a JSON-ish dict."""
        return {
            'type': self.type.value,
            'session_id': self.session_id,
            'motd': self.motd,
            'game_type': self.game_type,
            'map': self.map,
            'num_players': self.num_players,
            'max_players': self.max_players,
            'host_port': self.host_port,
            'host_ip': str(self.host_ip)
        }

It would be nicer to have my type just return this appropriate dict when invoking dict(BasicStats(?)). This would require me to override the __iter__() method to yield key / value tuples for the dict.
However, this would break the natural behaviour of tuple unpacking as described above.

Hence, I propose to add a method __iter_items__(self) to the python data model with the following properties:

1) __iter_items__ is expected to return an iterator of 2-tuples representing key / value pairs.
2) the built-in function dict(), when called on an object, will attempt to create the object from __iter_items__ first and fall back to __iter__.

Alternative names could also be __items__ or __iter_dict__.

----------
components: C API
messages: 383897
nosy: conqp
priority: normal
severity: normal
status: open
title: Introduce new data model method __iter_items__
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42765>
_______________________________________

From report at bugs.python.org  Mon Dec 28 10:32:27 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Dec 2020 15:32:27 +0000
Subject: [issue40522] [subinterpreters] Get the current Python interpreter
 state from Thread Local Storage (autoTSSkey)
In-Reply-To: <1588698734.65.0.223552100195.issue40522@roundup.psfhosted.org>
Message-ID: <1609169547.32.0.456191474454.issue40522@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22821
pull_request: https://github.com/python/cpython/pull/23976

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40522>
_______________________________________

From report at bugs.python.org  Mon Dec 28 10:37:30 2020
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Mon, 28 Dec 2020 15:37:30 +0000
Subject: [issue42765] Introduce new data model method __iter_items__
In-Reply-To: <1609169200.88.0.326770807054.issue42765@roundup.psfhosted.org>
Message-ID: <1609169850.33.0.56566784068.issue42765@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/issue42765>
_______________________________________

From report at bugs.python.org  Mon Dec 28 10:42:33 2020
From: report at bugs.python.org (=?utf-8?q?Don=C3=A1t_Nagy?=)
Date: Mon, 28 Dec 2020 15:42:33 +0000
Subject: [issue42766] urllib.request.HTTPPasswordMgr uses commonprefix instead
 of commonpath
Message-ID: <1609170153.96.0.504551551924.issue42766@roundup.psfhosted.org>


New submission from Don?t Nagy <m1nagdon at gmail.com>:

The is_suburi(self, base, test) method of HTTPPasswordMgr in the urllib.request module tries to "Check if test is below base in a URI tree", but it uses the posixpath.commonprefix() function. This is problematic because commonprefix ignores the path structure (for example commonprefix(['/usr/lib', '/usr/local/lib'])=='/usr/l') and therefore the current implementation of is_suburi is essentially equivalent to calling str.startswith after some normalization steps.

If we want to say that example.com/resource101 is *NOT* below example.com/resource1 in a URI tree, then the call to commonprefix should be replaced by a call to posixpath.commonpath(), which does the right thing.

----------
components: Library (Lib)
messages: 383898
nosy: nagdon
priority: normal
severity: normal
status: open
title: urllib.request.HTTPPasswordMgr uses commonprefix instead of commonpath
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42766>
_______________________________________

From report at bugs.python.org  Mon Dec 28 10:53:43 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Dec 2020 15:53:43 +0000
Subject: [issue40522] [subinterpreters] Get the current Python interpreter
 state from Thread Local Storage (autoTSSkey)
In-Reply-To: <1588698734.65.0.223552100195.issue40522@roundup.psfhosted.org>
Message-ID: <1609170823.26.0.981593219144.issue40522@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

PR 23976 stores the currrent interpreter and the current Python thread state into a Thread Local Storage (TLS) using GCC/clang __thread keyword.

On x86-64 using LTO and GCC -O3, _PyThreadState_GET() and _PyInterpreterState_GET() become a single MOV.

Assembly code using LTO and gcc -O3.

_PyThreadState_GET() in _PySys_GetObjectId():

   0x00000000004adabe <+14>: mov rbx,QWORD PTR fs:0xfffffffffffffff8

_PyThreadState_GET() in PyThreadState_Get():

   0x000000000046b660 <+0>: mov  rax,QWORD PTR fs:0xfffffffffffffff8

_PyInterpreterState_GET() in PyTuple_New():

   0x000000000048dfcc <+12>: mov  rax,QWORD PTR fs:0xfffffffffffffff0

_PyInterpreterState_GET() in PyState_FindModule():

   0x000000000044bf20 <+16>: mov  rax,QWORD PTR fs:0xfffffffffffffff0

---

Note: Without LTO, sometimes there is an indirection:

_PyThreadState_GET() in _PySys_GetObjectId(), 2 MOV (PIC indirection):

   mov    rax,QWORD PTR [rip+0x1eb270]        # 0x713fe0
   # rax = 0xfffffffffffffff0 (-16)
   mov    r13,QWORD PTR fs:[rax]

_PyInterpreterState_GET() in PyTuple_New(), 2 MOV (PIC indirection):

  mov    rax,QWORD PTR [rip+0x294d95]        # 0x713ff8
  mov    rax,QWORD PTR fs:[rax]

An optimized Python should always be built with LTO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40522>
_______________________________________

From report at bugs.python.org  Mon Dec 28 10:59:22 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Dec 2020 15:59:22 +0000
Subject: [issue40522] [subinterpreters] Get the current Python interpreter
 state from Thread Local Storage (autoTSSkey)
In-Reply-To: <1588698734.65.0.223552100195.issue40522@roundup.psfhosted.org>
Message-ID: <1609171162.13.0.796501519354.issue40522@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

PR 23976 should make _PyInterpreterState_GET() more efficient, and it prepares the code base for one GIL per interpreter (which is purpose of this issue ;-)).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40522>
_______________________________________

From report at bugs.python.org  Mon Dec 28 11:06:14 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Dec 2020 16:06:14 +0000
Subject: [issue42767] Review usage of atomic variables in signamodule.c
Message-ID: <1609171574.21.0.863053109272.issue42767@roundup.psfhosted.org>


New submission from STINNER Victor <vstinner at python.org>:

In bpo-41713, I ported the _signal module to the multi-phase initialization API. I tried to move the signal state into a structure to cleanup the code, but I was scared by the following atomic variables:
---------------
static volatile struct {
    _Py_atomic_int tripped;
    PyObject *func;
} Handlers[NSIG];

#ifdef MS_WINDOWS
#define INVALID_FD ((SOCKET_T)-1)

static volatile struct {
    SOCKET_T fd;
    int warn_on_full_buffer;
    int use_send;
} wakeup = {.fd = INVALID_FD, .warn_on_full_buffer = 1, .use_send = 0};
#else
#define INVALID_FD (-1)
static volatile struct {
#ifdef __VXWORKS__
    int fd;
#else
    sig_atomic_t fd;
#endif
    int warn_on_full_buffer;
} wakeup = {.fd = INVALID_FD, .warn_on_full_buffer = 1};
#endif

/* Speed up sigcheck() when none tripped */
static _Py_atomic_int is_tripped;
---------------

For me, the most surprising part is Handlers[signum].tripped which is declared as volatile *and* an atomic variable.

I'm not sure if Handlers[signum].func must be volatile neither.

Also, wakeup.fd is declared as sig_atomic_t on Unix. Could we use an atomic variable instead, or is it important to use "sig_atomic_t"?

--

I recently added pycore_atomic_funcs.h which provides functions to access variables atomically. It uses atomic functions if available, or falls back on "volatile" otherwise. Maybe this approach would be interesting here, maybe for Handlers[signum].func?

----------
components: Interpreter Core
messages: 383901
nosy: vstinner
priority: normal
severity: normal
status: open
title: Review usage of atomic variables in signamodule.c
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42767>
_______________________________________

From report at bugs.python.org  Mon Dec 28 11:23:25 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 28 Dec 2020 16:23:25 +0000
Subject: [issue42767] Review usage of atomic variables in signamodule.c
In-Reply-To: <1609171574.21.0.863053109272.issue42767@roundup.psfhosted.org>
Message-ID: <1609172605.58.0.218947112285.issue42767@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42767>
_______________________________________

From report at bugs.python.org  Mon Dec 28 11:23:51 2020
From: report at bugs.python.org (Richard Neumann)
Date: Mon, 28 Dec 2020 16:23:51 +0000
Subject: [issue42768] super().__new__() of list expands arguments
Message-ID: <1609172631.57.0.956527842974.issue42768@roundup.psfhosted.org>


New submission from Richard Neumann <mail at richard-neumann.de>:

When sublassing the built-in list, the invocation of super().__new__ will unexpectedly expand the passed arguments:

class MyTuple(tuple):

    def __new__(cls, *items):
        print(cls, items)
        return super().__new__(cls, items)


class MyList(list):

    def __new__(cls, *items):
        print(cls, items)
        return super().__new__(cls, items)


def main():

    my_tuple = MyTuple(1, 2, 3, 'foo', 'bar')
    print('My tuple:', my_tuple)
    my_list = MyList(1, 2, 3, 'foo', 'bar')
    print('My list:', my_list)


if __name__ == '__main__':
    main()


Actual result:

<class '__main__.MyTuple'> (1, 2, 3, 'foo', 'bar')
My tuple: (1, 2, 3, 'foo', 'bar')
<class '__main__.MyList'> (1, 2, 3, 'foo', 'bar')
Traceback (most recent call last):
  File "/home/neumann/listbug.py", line 24, in <module>
    main()
  File "/home/neumann/listbug.py", line 19, in main
    my_list = MyList(1, 2, 3, 'foo', 'bar')
TypeError: list expected at most 1 argument, got 5


Expected:

<class '__main__.MyTuple'> (1, 2, 3, 'foo', 'bar')
My tuple: (1, 2, 3, 'foo', 'bar')
<class '__main__.MyList'> (1, 2, 3, 'foo', 'bar')
My list: [1, 2, 3, 'foo', 'bar']

----------
components: ctypes
messages: 383902
nosy: conqp
priority: normal
severity: normal
status: open
title: super().__new__() of list expands arguments
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42768>
_______________________________________

From report at bugs.python.org  Mon Dec 28 11:37:04 2020
From: report at bugs.python.org (Damien Levac)
Date: Mon, 28 Dec 2020 16:37:04 +0000
Subject: [issue42769] concurrent.futures.ProcessPoolExecutor is unable to
 forward exceptions with state.
Message-ID: <1609173424.79.0.660348890279.issue42769@roundup.psfhosted.org>


New submission from Damien Levac <damien.levac at gmail.com>:

When running tasks on a `ProcessPoolExecutor`, exceptions raised by the dispatched function should be pickled and accessible to the parent process through the `Future.exception` method.

On Python 3.9.1 (Linux ryzen3950x 5.4.0-58-generic #64-Ubuntu SMP Wed Dec 9 08:16:25 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux) the behavior works with exceptions which are stateless but not if they hold state.

I suspect it is related to the multiprocessing/pickle bug mentioned in the release notes to 3.9.1 but I didn't dig much deeper.

Let me know if I can assist in any way or if any pertinent information is missing: it is my first time reporting a bug here :)

Thank you for your hard work!

----------
components: Library (Lib)
files: repro.py
messages: 383903
nosy: damien.levac
priority: normal
severity: normal
status: open
title: concurrent.futures.ProcessPoolExecutor is unable to forward exceptions with state.
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file49703/repro.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42769>
_______________________________________

From report at bugs.python.org  Mon Dec 28 11:41:52 2020
From: report at bugs.python.org (Marc Culler)
Date: Mon, 28 Dec 2020 16:41:52 +0000
Subject: [issue42068] For macOS,
 package the included Tcl and Tk frameworks in a rational way.
In-Reply-To: <1603027259.23.0.956934315272.issue42068@roundup.psfhosted.org>
Message-ID: <1609173712.49.0.0909883355047.issue42068@roundup.psfhosted.org>


Marc Culler <marc.culler at gmail.com> added the comment:

Hi Ned, I have a comment about the code signing issues that would arise if the Tcl and Tk frameworks were embedded as actual subframeworks inside the Python.framework, and a user later replaced those with newer versions. The answer is that no new issues arise.  The current Python.framework fails codesign verification as soon as a single new package is installed with pip (even upgrading pip itself).  The codesign command detects the new files and exits with non-zero status if called with --verify.  In verbose mode it will list all of the files that were added.

This does not prevent python from working.  So it should just be acknowledged that python's codesigning is used purely to make installation simpler and that no attempt is currently being made to ensure that an installed python framework continues to pass codesign verification.  As a consequence, my proposal in this ticket would raise no new codesigning issues, but it would allow users to much more easily upgrade the Tcl and Tk embedded in /Library/Frameworks/Python.framework versions.  It would also simplify the recipe for building Tcl and Tk in the buildscript.

While the python framework may be viewed as a black box, in fact it is not a black box at all.  It can be changed at will either by python itself or by a user.  Making its structure clearer and cleaner could only be an improvement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42068>
_______________________________________

From report at bugs.python.org  Mon Dec 28 11:46:33 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 28 Dec 2020 16:46:33 +0000
Subject: [issue42768] super().__new__() of list expands arguments
In-Reply-To: <1609172631.57.0.956527842974.issue42768@roundup.psfhosted.org>
Message-ID: <1609173993.66.0.749977151726.issue42768@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Your problem is with list.__init__ method. It expects at most one argument.

tuple does not have specialized __init__ method, it inherits it from object. All work is done in tuple.__new__. list does not have specialized __new__ method, it inherits it from object. All work is done in list.__init__.

If your override __new__ with incompatible signature, make also __init__ supporting it.

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42768>
_______________________________________

From report at bugs.python.org  Mon Dec 28 11:52:07 2020
From: report at bugs.python.org (hai shi)
Date: Mon, 28 Dec 2020 16:52:07 +0000
Subject: [issue42767] Review usage of atomic variables in signamodule.c
In-Reply-To: <1609171574.21.0.863053109272.issue42767@roundup.psfhosted.org>
Message-ID: <1609174327.33.0.13439899874.issue42767@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
nosy: +shihai1991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42767>
_______________________________________

From report at bugs.python.org  Mon Dec 28 12:07:08 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Mon, 28 Dec 2020 17:07:08 +0000
Subject: [issue40810] sqlite3 test CheckTraceCallbackContent fails for sqlite
 v3.7.3 through 3.7.14.1
In-Reply-To: <1590688058.38.0.22519081316.issue40810@roundup.psfhosted.org>
Message-ID: <1609175228.29.0.272840332761.issue40810@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40810>
_______________________________________

From report at bugs.python.org  Mon Dec 28 12:19:24 2020
From: report at bugs.python.org (hai shi)
Date: Mon, 28 Dec 2020 17:19:24 +0000
Subject: [issue30963] xxlimited.c XxoObject_Check should be
 XxoObject_CheckExact
In-Reply-To: <1500412678.84.0.816991478409.issue30963@psf.upfronthosting.co.za>
Message-ID: <1609175964.89.0.294236172281.issue30963@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

> #define XxoObject_CheckExact(v) (Py_TYPE(v) == &Xxo_Type)
`#define Xxo_CheckExact(obj) Py_IS_TYPE(obj, &Xxo_Type)` would be better to hide details now.

> #define XxoObject_Check(v) PyObject_TypeCheck(v, &Xxo_Type)
+1

I think the annotation will worth to be updaetd.
https://github.com/python/cpython/blob/master/Modules/xxlimited.c#L76

----------
keywords: +easy
nosy: +petr.viktorin, shihai1991, vstinner
versions: +Python 3.10 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30963>
_______________________________________

From report at bugs.python.org  Mon Dec 28 12:27:55 2020
From: report at bugs.python.org (Richard Neumann)
Date: Mon, 28 Dec 2020 17:27:55 +0000
Subject: [issue42768] super().__new__() of list expands arguments
In-Reply-To: <1609172631.57.0.956527842974.issue42768@roundup.psfhosted.org>
Message-ID: <1609176475.4.0.0196014536326.issue42768@roundup.psfhosted.org>


Richard Neumann <mail at richard-neumann.de> added the comment:

I could have sworn, that this worked before, but it was obviously me being tired at the end of the work day.
Thanks for pointing this out and sorry for the noise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42768>
_______________________________________

From report at bugs.python.org  Mon Dec 28 12:35:57 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Mon, 28 Dec 2020 17:35:57 +0000
Subject: [issue42754] Unpacking of literals inside other literals should be
 optimised away by the compiler
In-Reply-To: <1609055794.85.0.312864529219.issue42754@roundup.psfhosted.org>
Message-ID: <1609176957.86.0.559373684055.issue42754@roundup.psfhosted.org>


Change by Batuhan Taskaya <isidentical at gmail.com>:


----------
nosy: +BTaskaya

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42754>
_______________________________________

From report at bugs.python.org  Mon Dec 28 12:47:35 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 28 Dec 2020 17:47:35 +0000
Subject: [issue40077] Convert static types to heap types: use PyType_FromSpec()
In-Reply-To: <1585238684.65.0.246012172449.issue40077@roundup.psfhosted.org>
Message-ID: <1609177655.81.0.844971918204.issue40077@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset bf108bb21e1d75e30bd17141cc531dd08a5e5d0c by Erlend Egeberg Aasland in branch 'master':
bpo-40077: Fix typo in simplequeue_get_state_by_type() (GH-23975)
https://github.com/python/cpython/commit/bf108bb21e1d75e30bd17141cc531dd08a5e5d0c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40077>
_______________________________________

From report at bugs.python.org  Mon Dec 28 13:01:33 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 28 Dec 2020 18:01:33 +0000
Subject: [issue42765] Introduce new data model method __iter_items__
In-Reply-To: <1609169200.88.0.326770807054.issue42765@roundup.psfhosted.org>
Message-ID: <1609178493.62.0.584389247439.issue42765@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

This core of this idea is plausible.  It is a common problem for people to want to teach a class how to convert itself to and from JSON.

Altering the API for dicts is a major step, so you would need to take this to python-ideas to start getting buy-in.   A much smaller API change would be to just teach the JSON module to recognize a __json__ method.

Presumably if a robust serialization solution is created, people will need a way to deserialize back into a named tuple, data class, or custom class.  Offhand, the only way I can think of to do this would be to add a field that could be recognized by json.load().  Some care would be needed to not create a pickle-like risk of arbitrary code execution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42765>
_______________________________________

From report at bugs.python.org  Mon Dec 28 13:02:53 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 28 Dec 2020 18:02:53 +0000
Subject: [issue42765] Introduce new data model method __iter_items__
In-Reply-To: <1609169200.88.0.326770807054.issue42765@roundup.psfhosted.org>
Message-ID: <1609178573.36.0.986709566657.issue42765@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +bob.ippolito

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42765>
_______________________________________

From report at bugs.python.org  Mon Dec 28 13:13:16 2020
From: report at bugs.python.org (bazwal)
Date: Mon, 28 Dec 2020 18:13:16 +0000
Subject: [issue42770] Typo in email.headerregistry docs
Message-ID: <1609179196.61.0.989200266115.issue42770@roundup.psfhosted.org>


New submission from bazwal <bazwal at gmail.com>:

The section for class email.headerregistry.ContentDispositionHeader has a typo in an attribute name: "content-disposition" should be corrected to "content_disposition".

----------
assignee: docs at python
components: Documentation
messages: 383910
nosy: bazwal, docs at python
priority: normal
severity: normal
status: open
title: Typo in email.headerregistry docs
type: enhancement
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42770>
_______________________________________

From report at bugs.python.org  Mon Dec 28 13:33:29 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Mon, 28 Dec 2020 18:33:29 +0000
Subject: [issue42754] Unpacking of literals inside other literals should be
 optimised away by the compiler
In-Reply-To: <1609055794.85.0.312864529219.issue42754@roundup.psfhosted.org>
Message-ID: <1609180409.87.0.192257688303.issue42754@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

We could possibly fold this at the AST optimizer, though I am not sure whether this worths anything as an optimization since it is a real obscure pattern. I've only found 2 occurrences (both from a test set on a relatively ~big dataset of source code.

----------
nosy: +Mark.Shannon, pablogsal, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42754>
_______________________________________

From report at bugs.python.org  Mon Dec 28 13:33:57 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Mon, 28 Dec 2020 18:33:57 +0000
Subject: [issue42754] Unpacking of literals inside other literals should be
 optimised away by the compiler
In-Reply-To: <1609055794.85.0.312864529219.issue42754@roundup.psfhosted.org>
Message-ID: <1609180437.16.0.739929040043.issue42754@roundup.psfhosted.org>


Change by Batuhan Taskaya <isidentical at gmail.com>:


----------
Removed message: https://bugs.python.org/msg383911

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42754>
_______________________________________

From report at bugs.python.org  Mon Dec 28 13:34:35 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Mon, 28 Dec 2020 18:34:35 +0000
Subject: [issue42754] Unpacking of literals inside other literals should be
 optimised away by the compiler
In-Reply-To: <1609055794.85.0.312864529219.issue42754@roundup.psfhosted.org>
Message-ID: <1609180475.55.0.337526463202.issue42754@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

We could possibly fold this at the AST optimizer, though I am not sure whether this worths anything as an optimization since it is a real obscure pattern. I've only found 2 occurrences (both from the test suite of black) on a relatively ~big dataset of python source code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42754>
_______________________________________

From report at bugs.python.org  Mon Dec 28 13:48:41 2020
From: report at bugs.python.org (Steve Stagg)
Date: Mon, 28 Dec 2020 18:48:41 +0000
Subject: [issue42717] The python interpreter crashed with
 "_enter_buffered_busy"
In-Reply-To: <1608632703.27.0.708410911987.issue42717@roundup.psfhosted.org>
Message-ID: <1609181321.08.0.9525521884.issue42717@roundup.psfhosted.org>


Steve Stagg <stestagg at gmail.com> added the comment:

I think the problem here is that the issue can only really be detected late on during interpreter shutdown.

This makes recovery very hard to do.  Plus the thread termination has left shared state in an unmanaged condition, so it's super dangerous to re-enter python again

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42717>
_______________________________________

From report at bugs.python.org  Mon Dec 28 13:50:40 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 28 Dec 2020 18:50:40 +0000
Subject: [issue42753] "./configure" linux chrome beta
In-Reply-To: <1609042767.15.0.899316514178.issue42753@roundup.psfhosted.org>
Message-ID: <1609181440.75.0.413687934108.issue42753@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

This appears to not be a bug with Python, so I'm going to close this. If you're having additional build problems, I suggest you ask for help on the python-list mailing list, or maybe on Stack Overflow.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42753>
_______________________________________

From report at bugs.python.org  Mon Dec 28 13:51:37 2020
From: report at bugs.python.org (Steve Stagg)
Date: Mon, 28 Dec 2020 18:51:37 +0000
Subject: [issue42763] Exposing a race in the "_warnings" resulting Python
 parser crash
In-Reply-To: <1609130399.05.0.938510382701.issue42763@roundup.psfhosted.org>
Message-ID: <1609181497.27.0.489860865782.issue42763@roundup.psfhosted.org>


Steve Stagg <stestagg at gmail.com> added the comment:

Looks like a duplicate of issue42717.  

Causing a daemonic thread to terminate while doing IO will trigger the above abort

----------
nosy: +stestagg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42763>
_______________________________________

From report at bugs.python.org  Mon Dec 28 14:10:53 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 28 Dec 2020 19:10:53 +0000
Subject: [issue42222] Modernize integer test/conversion in randrange()
In-Reply-To: <1604165232.15.0.0916383458838.issue42222@roundup.psfhosted.org>
Message-ID: <1609182653.25.0.630134528676.issue42222@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset a9621bb301dba44494e81edc00e3a3b62c96af26 by Raymond Hettinger in branch 'master':
bpo-42222: Modernize integer test/conversion in randrange() (#23064)
https://github.com/python/cpython/commit/a9621bb301dba44494e81edc00e3a3b62c96af26


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42222>
_______________________________________

From report at bugs.python.org  Mon Dec 28 14:11:34 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 28 Dec 2020 19:11:34 +0000
Subject: [issue42222] Modernize integer test/conversion in randrange()
In-Reply-To: <1604165232.15.0.0916383458838.issue42222@roundup.psfhosted.org>
Message-ID: <1609182694.47.0.515060883528.issue42222@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/issue42222>
_______________________________________

From report at bugs.python.org  Mon Dec 28 14:12:23 2020
From: report at bugs.python.org (Mike Miller)
Date: Mon, 28 Dec 2020 19:12:23 +0000
Subject: [issue42771] Implement interactive hotkey,
 Ctrl+L to clear the console in Windows.
Message-ID: <1609182743.02.0.584212046771.issue42771@roundup.psfhosted.org>


New submission from Mike Miller <python.org at mgmiller.net>:

The Ctrl+L as clear-screen hotkey is supported just about everywhere, Unix and Windows, with the exceptions of cmd.exe and python.exe interactive mode.

As the legacy cmd.exe can be easily replaced, that leaves python.exe.  Likely needs to be configured via readline or its analog used under Windows.

Documenting it would be good too.  Am happy to help, write, or test.

----------
components: Windows
messages: 383917
nosy: mixmastamyk, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Implement interactive hotkey, Ctrl+L to clear the console in Windows.
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42771>
_______________________________________

From report at bugs.python.org  Mon Dec 28 14:13:55 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 28 Dec 2020 19:13:55 +0000
Subject: [issue37319] Deprecate using random.randrange() with non-integers
In-Reply-To: <1560801155.55.0.20318571261.issue37319@roundup.psfhosted.org>
Message-ID: <1609182835.07.0.156330787008.issue37319@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

I merged in PR 23064. If you want to make further modifications or improvements that would be welcome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37319>
_______________________________________

From report at bugs.python.org  Mon Dec 28 14:23:37 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 28 Dec 2020 19:23:37 +0000
Subject: [issue42772] randrange() mishandles step when stop is None
Message-ID: <1609183417.92.0.845527263557.issue42772@roundup.psfhosted.org>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

When stop is None, the step argument is ignored:

>>> randrange(1000, None, 100)
651
>>> randrange(1000, step=100)
673

----------
components: Library (Lib)
messages: 383919
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: randrange() mishandles step when stop is None
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42772>
_______________________________________

From report at bugs.python.org  Mon Dec 28 14:23:54 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 28 Dec 2020 19:23:54 +0000
Subject: [issue42772] randrange() mishandles step when stop is None
In-Reply-To: <1609183417.92.0.845527263557.issue42772@roundup.psfhosted.org>
Message-ID: <1609183434.22.0.417661031622.issue42772@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/issue42772>
_______________________________________

From report at bugs.python.org  Mon Dec 28 14:28:41 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 28 Dec 2020 19:28:41 +0000
Subject: [issue42772] randrange() mishandles step when stop is None
In-Reply-To: <1609183417.92.0.845527263557.issue42772@roundup.psfhosted.org>
Message-ID: <1609183721.33.0.655688695482.issue42772@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: rhettinger -> 
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42772>
_______________________________________

From report at bugs.python.org  Mon Dec 28 14:30:32 2020
From: report at bugs.python.org (Mike Miller)
Date: Mon, 28 Dec 2020 19:30:32 +0000
Subject: [issue42771] Implement interactive hotkey,
 Ctrl+L to clear the console in Windows.
In-Reply-To: <1609182743.02.0.584212046771.issue42771@roundup.psfhosted.org>
Message-ID: <1609183832.65.0.489234008041.issue42771@roundup.psfhosted.org>


Mike Miller <python.org at mgmiller.net> added the comment:

I found an implementation of this for Windows in case it is needed.  Not sure if it is the best way to do it, as the Console API is rather clumsy.  However this one works to my knowledge:

https://github.com/tartley/colorama/blob/master/colorama/winterm.py#L111

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42771>
_______________________________________

From report at bugs.python.org  Mon Dec 28 14:33:00 2020
From: report at bugs.python.org (Steve Stagg)
Date: Mon, 28 Dec 2020 19:33:00 +0000
Subject: [issue42762] infinite loop resulted by "yield"
In-Reply-To: <1609130295.32.0.912620547313.issue42762@roundup.psfhosted.org>
Message-ID: <1609183980.66.0.656340237846.issue42762@roundup.psfhosted.org>


Steve Stagg <stestagg at gmail.com> added the comment:

Behaviour was changed in this commit:
---
commit ae3087c6382011c47db82fea4d05f8bbf514265d
Author: Mark Shannon <mark at hotpy.org>
Date:   Sun Oct 22 22:41:51 2017 +0100

    Move exc state to generator. Fixes bpo-25612 (#1773)

    Move exception state information from frame objects to coroutine (generator/thread) object where it belongs.

---

I'm honestly not sure that the older behaviour was 'better' than current.  But I don't know the defined behaviours well enough to be certain

----------
nosy: +stestagg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42762>
_______________________________________

From report at bugs.python.org  Mon Dec 28 14:57:18 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 28 Dec 2020 19:57:18 +0000
Subject: [issue42772] randrange() mishandles step when stop is None
In-Reply-To: <1609183417.92.0.845527263557.issue42772@roundup.psfhosted.org>
Message-ID: <1609185438.19.0.976260305721.issue42772@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

One fix is to move up the code for converting step to istep and then modify the early out test to:  

        if stop is None and istep == 1:
            if istart > 0:
                return self._randbelow(istart)

That would have the downside of slowing down the common case.

Another possibility is changing the default step to a sentinel object and just testing for that:

        if stop is None and step is sentinel:
            if istart > 0:
                return self._randbelow(istart)

That would be user visible in the function signature but it would run fast.

We could bite the bullet and fully harmonize the randrange() signature with range().  That would entail switching to *args and no longer accepting keyword arguments:

     def randrange(self, /, *args):
         "Choose random item from range(stop) or range(start, stop[, step])."
         return self.choice(range(*args))

This would most closely match user expectations but is potentially a breaking change for existing code that uses keyword arguments.  Such code probably exists but is probably not common.

For speed, the actual implementation could still have fast paths for common cases.

For help() and tooltips, we could add a __text_signature__ to cover-up the *args.  However, signature objects currently aren't capable of describing range().  The best we could do is:

    randrange.__text_signature__ = '($self, start, stop, step, /)'

That would give help() that looks like this:

    >>> help(randrange)
    Help on method randrange in module Random:

    randrange(start, stop, step, /) method of __main__.R instance
        Choose random item from range(stop) or range(start, stop[, step]).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42772>
_______________________________________

From report at bugs.python.org  Mon Dec 28 14:57:33 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 28 Dec 2020 19:57:33 +0000
Subject: [issue42772] randrange() mishandles step when stop is None
In-Reply-To: <1609183417.92.0.845527263557.issue42772@roundup.psfhosted.org>
Message-ID: <1609185453.21.0.791950873122.issue42772@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42772>
_______________________________________

From report at bugs.python.org  Mon Dec 28 14:57:57 2020
From: report at bugs.python.org (Ammar Askar)
Date: Mon, 28 Dec 2020 19:57:57 +0000
Subject: [issue42767] Review usage of atomic variables in signamodule.c
In-Reply-To: <1609171574.21.0.863053109272.issue42767@roundup.psfhosted.org>
Message-ID: <1609185477.55.0.527731732658.issue42767@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

> For me, the most surprising part is Handlers[signum].tripped which is declared as volatile *and* an atomic variable.

I think it's just following this part of the C spec (Some background in bpo-12060):

> or refers to any object with static storage duration other than by assigning a value to a static storage duration variable of type volatile sig_atomic_t. Furthermore, if such a call fails, the value of errno is unspecified.

https://pubs.opengroup.org/onlinepubs/007904875/functions/sigaction.html / https://wiki.sei.cmu.edu/confluence/display/c/SIG31-C.+Do+not+access+shared+objects+in+signal+handlers

> I'm not sure if Handlers[signum].func must be volatile neither.

I think your assessment here is right considering it's never used in the signal handler itself.

> Also, wakeup.fd is declared as sig_atomic_t on Unix. Could we use an atomic variable instead, or is it important to use "sig_atomic_t"?

Again looking at the https://wiki.sei.cmu.edu/confluence/display/c/SIG31-C.+Do+not+access+shared+objects+in+signal+handlers recommendation it seems like using an atomic variable is fine but only if it's lock-free.

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42767>
_______________________________________

From report at bugs.python.org  Mon Dec 28 15:06:27 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 28 Dec 2020 20:06:27 +0000
Subject: [issue42740] typing.py get_args and get_origin should support PEP 604
 and 612
In-Reply-To: <1608909562.21.0.0257515668126.issue42740@roundup.psfhosted.org>
Message-ID: <1609185987.83.0.0442230861193.issue42740@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4140f10a16f06c32fd49f9e21fb2a53abe7357f0 by Ken Jin in branch 'master':
bpo-42740: Fix get_args for PEP 585 collections.abc.Callable (GH-23963)
https://github.com/python/cpython/commit/4140f10a16f06c32fd49f9e21fb2a53abe7357f0


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42740>
_______________________________________

From report at bugs.python.org  Mon Dec 28 15:06:41 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 28 Dec 2020 20:06:41 +0000
Subject: [issue42740] typing.py get_args and get_origin should support PEP 604
 and 612
In-Reply-To: <1608909562.21.0.0257515668126.issue42740@roundup.psfhosted.org>
Message-ID: <1609186001.24.0.823200547535.issue42740@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22822
pull_request: https://github.com/python/cpython/pull/23977

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42740>
_______________________________________

From report at bugs.python.org  Mon Dec 28 15:16:01 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 28 Dec 2020 20:16:01 +0000
Subject: [issue42048] Document Argument Clinic's defining_class converter
In-Reply-To: <1602792744.97.0.495560068875.issue42048@roundup.psfhosted.org>
Message-ID: <1609186561.75.0.566526618793.issue42048@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
keywords: +patch
pull_requests: +22823
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23978

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42048>
_______________________________________

From report at bugs.python.org  Mon Dec 28 15:26:47 2020
From: report at bugs.python.org (miss-islington)
Date: Mon, 28 Dec 2020 20:26:47 +0000
Subject: [issue42740] typing.py get_args and get_origin should support PEP 604
 and 612
In-Reply-To: <1608909562.21.0.0257515668126.issue42740@roundup.psfhosted.org>
Message-ID: <1609187207.72.0.862358453085.issue42740@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 03e571f1d5f3e7a11f33bb9f47dd4acedf17b166 by Miss Islington (bot) in branch '3.9':
bpo-42740: Fix get_args for PEP 585 collections.abc.Callable (GH-23963)
https://github.com/python/cpython/commit/03e571f1d5f3e7a11f33bb9f47dd4acedf17b166


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42740>
_______________________________________

From report at bugs.python.org  Mon Dec 28 15:29:48 2020
From: report at bugs.python.org (Ammar Askar)
Date: Mon, 28 Dec 2020 20:29:48 +0000
Subject: [issue42770] Typo in email.headerregistry docs
In-Reply-To: <1609179196.61.0.989200266115.issue42770@roundup.psfhosted.org>
Message-ID: <1609187388.11.0.460704688662.issue42770@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Confirmed, the attribute under https://docs.python.org/3.10/library/email.headerregistry.html#email.headerregistry.ContentDispositionHeader is incorrect.

bazwal, would you like to propose a patch to fix this? The code is here: https://github.com/python/cpython/blob/master/Doc/library/email.headerregistry.rst

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42770>
_______________________________________

From report at bugs.python.org  Mon Dec 28 15:30:47 2020
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 28 Dec 2020 20:30:47 +0000
Subject: [issue42771] Implement interactive hotkey,
 Ctrl+L to clear the console in Windows.
In-Reply-To: <1609182743.02.0.584212046771.issue42771@roundup.psfhosted.org>
Message-ID: <1609187447.74.0.105667128602.issue42771@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> As the legacy cmd.exe can be easily replaced, that leaves python.exe. 

python.exe is a console application, which attaches to a console session. Since Windows 7, each console session is hosted by an instance of conhost.exe.

The CMD shell (cmd.exe) is a console application, the same as python.exe. It doesn't matter whether Python allocates a new console or inherits it from another process such as cmd.exe.

> Likely needs to be configured via readline or its analog used under 
> Windows.

pyreadline implements readline for the Windows console API via ctypes. It supports Ctrl+L to clear the screen, including the scrollback. PSReadLine in PowerShell implements Ctrl+L without clearing the scrollback. That's a better example to follow if someone wants to take up the ambitious project of supporting readline for Windows in the standard library.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42771>
_______________________________________

From report at bugs.python.org  Mon Dec 28 15:33:13 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 28 Dec 2020 20:33:13 +0000
Subject: [issue42772] randrange() mishandles step when stop is None
In-Reply-To: <1609183417.92.0.845527263557.issue42772@roundup.psfhosted.org>
Message-ID: <1609187593.54.0.949057771206.issue42772@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Note, we can't actually use "self.choice(range(*args))" because the underlying len() call can Overflow.  If it does, the components need to be computed manually.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42772>
_______________________________________

From report at bugs.python.org  Mon Dec 28 15:46:13 2020
From: report at bugs.python.org (Ammar Askar)
Date: Mon, 28 Dec 2020 20:46:13 +0000
Subject: [issue42739] Crash when try to disassemble bogus code object
In-Reply-To: <1608897358.97.0.834158885511.issue42739@roundup.psfhosted.org>
Message-ID: <1609188373.82.0.342050558814.issue42739@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

This seems to be part 2 of the problems Mark mentioned in issue42562. Namely in this case the `co_lnotab` accessor uses PyLineTable_NextAddressRange which has that assertion.

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42739>
_______________________________________

From report at bugs.python.org  Mon Dec 28 16:06:51 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 28 Dec 2020 21:06:51 +0000
Subject: [issue42772] randrange() mishandles step when stop is None
In-Reply-To: <1609183417.92.0.845527263557.issue42772@roundup.psfhosted.org>
Message-ID: <1609189611.52.0.500868166925.issue42772@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Another solution is to use an identity test for the step argument

    _one = 1

    class Random:
        def randrange(start, stop=None, step=_one):
            ...
            if stop is None and step is _one:
                if istart > 0:
                    return self._randbelow(istart)

This has the advantage of keeping the API unchanged while still keeping the fast path fast.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42772>
_______________________________________

From report at bugs.python.org  Mon Dec 28 16:28:33 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 28 Dec 2020 21:28:33 +0000
Subject: [issue42772] randrange() mishandles step when stop is None
In-Reply-To: <1609183417.92.0.845527263557.issue42772@roundup.psfhosted.org>
Message-ID: <1609190913.17.0.232646952431.issue42772@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

> Another solution is to use an identity test for the step argument

Should I restore that optimization in issue37319?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42772>
_______________________________________

From report at bugs.python.org  Mon Dec 28 16:30:54 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 28 Dec 2020 21:30:54 +0000
Subject: [issue42754] Unpacking of literals inside other literals should be
 optimised away by the compiler
In-Reply-To: <1609055794.85.0.312864529219.issue42754@roundup.psfhosted.org>
Message-ID: <1609191054.68.0.895184561594.issue42754@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +22824
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23979

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42754>
_______________________________________

From report at bugs.python.org  Mon Dec 28 16:36:34 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 28 Dec 2020 21:36:34 +0000
Subject: [issue42754] Unpacking of literals inside other literals should be
 optimised away by the compiler
In-Reply-To: <1609055794.85.0.312864529219.issue42754@roundup.psfhosted.org>
Message-ID: <1609191394.21.0.809522329636.issue42754@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

I have added a draft PR on how the idea would look like so we can discuss with a specific proposal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42754>
_______________________________________

From report at bugs.python.org  Mon Dec 28 16:49:50 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 28 Dec 2020 21:49:50 +0000
Subject: [issue42765] Introduce new data model method __iter_items__
In-Reply-To: <1609169200.88.0.326770807054.issue42765@roundup.psfhosted.org>
Message-ID: <1609192190.91.0.458178975221.issue42765@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

Hi Richard,


> Also, using _asdict() seems strange as an exposed API, since it's an underscore method and users hence might not be inclined to use it.

I don't consider this a strong argument. Named tuple in general has to use a naming convention for public methods that cannot clash with field names, hence the single underscore, but your concrete named tuple class can offer any methods you like since you know which field names are used and which are not. Just add a public method "asdict" or any name you prefer, and delegate to the single underscore method.



> It would be nicer to have my type just return this appropriate dict when invoking dict(BasicStats(?)).

As we speak there is a discussion on Python-Ideas about this.

https://mail.python.org/archives/list/python-ideas at python.org/thread/2HMRGJ672NDZJZ5PVLMNVW6KP7OHMQDI/#UYDIPMY2HXGL4OLEEFXBTZ2T4CK6TSVU

Your input would be appreciated.


> This would require me to override the __iter__() method to yield key / value tuples for the dict.

The dict constructor does not require that. See discussion on the thread above.

If you search the Python-Ideas archives, I am sure you will find past proposals for a `__json__` protocol. If I recall correctly, there was some concern about opening the flood-gates for dunder protocols (will this be followed with demands for __yaml__, __xml__, __cson__, __toml__, etc?) but perhaps the time is right to revisit this idea.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42765>
_______________________________________

From report at bugs.python.org  Mon Dec 28 16:50:00 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 28 Dec 2020 21:50:00 +0000
Subject: [issue42754] Unpacking of literals inside other literals should be
 optimised away by the compiler
In-Reply-To: <1609055794.85.0.312864529219.issue42754@roundup.psfhosted.org>
Message-ID: <1609192200.74.0.0717993357543.issue42754@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I do not think there are serious raesons for adding this optimization. The Python compiler was intentionally made simple for maintainability. Constant folding supports only base arithmetic and bits operations because they are often used in constant expressions (like 2**32-1 or 1<<18) and indexing because of b'A'[0]. Neither comparisons, nor boolean operators with constants are optimized, because such expression are uncommon, and the maintaining cost overdraws benefit.

This is a similar case. I am -1 for this optimization.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42754>
_______________________________________

From report at bugs.python.org  Mon Dec 28 17:31:27 2020
From: report at bugs.python.org (Ammar Askar)
Date: Mon, 28 Dec 2020 22:31:27 +0000
Subject: [issue42773] build.yml workflow not testing on pushes
Message-ID: <1609194687.05.0.86275810312.issue42773@roundup.psfhosted.org>


New submission from Ammar Askar <ammar at ammaraskar.com>:

It looks like on pushes to Github, we currently aren't running tests. (Though this isn't too big of a concern since they get run on pull requests).

Here's an example of a recent run https://github.com/python/cpython/runs/1609911031

```
fatal: ambiguous argument 'origin/..': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
```

----------
components: Build
messages: 383935
nosy: FFY00, Mariatta, ammar2, vstinner
priority: normal
severity: normal
status: open
title: build.yml workflow not testing on pushes
type: behavior
versions: Python 3.10, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42773>
_______________________________________

From report at bugs.python.org  Mon Dec 28 17:36:09 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 28 Dec 2020 22:36:09 +0000
Subject: [issue42243] Don't access the module dictionary directly
In-Reply-To: <1604305225.53.0.387494771093.issue42243@roundup.psfhosted.org>
Message-ID: <1609194969.19.0.64258256759.issue42243@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
resolution:  -> wont fix

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42243>
_______________________________________

From report at bugs.python.org  Mon Dec 28 17:36:54 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 28 Dec 2020 22:36:54 +0000
Subject: [issue42243] Don't access the module dictionary directly
In-Reply-To: <1604305225.53.0.387494771093.issue42243@roundup.psfhosted.org>
Message-ID: <1609195014.66.0.133523876574.issue42243@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42243>
_______________________________________

From report at bugs.python.org  Mon Dec 28 17:49:20 2020
From: report at bugs.python.org (Cebtenzzre)
Date: Mon, 28 Dec 2020 22:49:20 +0000
Subject: [issue41567] multiprocessing.Pool from concurrent threads failure on
 3.9.0rc1
In-Reply-To: <1597664250.53.0.724586569237.issue41567@roundup.psfhosted.org>
Message-ID: <1609195760.64.0.72157993162.issue41567@roundup.psfhosted.org>


Change by Cebtenzzre <cebtenzzre at gmail.com>:


----------
nosy: +cebtenzzre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41567>
_______________________________________

From report at bugs.python.org  Mon Dec 28 17:49:32 2020
From: report at bugs.python.org (Cebtenzzre)
Date: Mon, 28 Dec 2020 22:49:32 +0000
Subject: [issue35943] PyImport_GetModule() can return partially-initialized
 module
In-Reply-To: <1549646017.22.0.395154635441.issue35943@roundup.psfhosted.org>
Message-ID: <1609195772.3.0.745900534499.issue35943@roundup.psfhosted.org>


Change by Cebtenzzre <cebtenzzre at gmail.com>:


----------
nosy: +cebtenzzre

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35943>
_______________________________________

From report at bugs.python.org  Mon Dec 28 17:59:06 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Mon, 28 Dec 2020 22:59:06 +0000
Subject: [issue42393] Raise overflow errors iso. deprecation warnings in
 socket.htons and socket.ntohs (was deprecated in 3.7)
In-Reply-To: <1605646569.63.0.541454109275.issue42393@roundup.psfhosted.org>
Message-ID: <1609196346.56.0.725600321311.issue42393@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
pull_requests: +22825
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23980

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42393>
_______________________________________

From report at bugs.python.org  Mon Dec 28 18:19:28 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 28 Dec 2020 23:19:28 +0000
Subject: [issue42754] Unpacking of literals inside other literals should be
 optimised away by the compiler
In-Reply-To: <1609055794.85.0.312864529219.issue42754@roundup.psfhosted.org>
Message-ID: <1609197568.71.0.574846279567.issue42754@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> This is a similar case. I am -1 for this optimization.

Yeah, I concur. One of the major drawbacks of this is that the normal case where this happens involves a Load():

z = "something"
x = ["a", *z, "b"]

I see almost no reason to nest the literals in this case, especially in a context sensitive scope. I am closing the draft PR and the issue.

Thanks Patrick for the proposal, though!

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42754>
_______________________________________

From report at bugs.python.org  Mon Dec 28 18:38:16 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Dec 2020 23:38:16 +0000
Subject: [issue42773] build.yml workflow not testing on pushes
In-Reply-To: <1609194687.05.0.86275810312.issue42773@roundup.psfhosted.org>
Message-ID: <1609198696.54.0.572576101864.issue42773@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> build.yml workflow not testing on pushes

What does it mean: "on pushes"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42773>
_______________________________________

From report at bugs.python.org  Mon Dec 28 18:46:16 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 28 Dec 2020 23:46:16 +0000
Subject: [issue42770] Typo in email.headerregistry docs
In-Reply-To: <1609179196.61.0.989200266115.issue42770@roundup.psfhosted.org>
Message-ID: <1609199176.82.0.104306602384.issue42770@roundup.psfhosted.org>


Change by Zackery Spytz <zspytz at gmail.com>:


----------
keywords: +patch
nosy: +ZackerySpytz
nosy_count: 3.0 -> 4.0
pull_requests: +22826
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23982

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42770>
_______________________________________

From report at bugs.python.org  Mon Dec 28 18:51:40 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 28 Dec 2020 23:51:40 +0000
Subject: [issue42772] randrange() mishandles step when stop is None
In-Reply-To: <1609183417.92.0.845527263557.issue42772@roundup.psfhosted.org>
Message-ID: <1609199500.0.0.590349255372.issue42772@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

> Should I restore that optimization in issue37319?

Yes, but to fix the bug it needs to occur earlier in the code (currently line 314):

    if stop is None and step is _ONE: <-- Line 314
                   ^^^^^^^^^^^^^^^^^  <-- Add this   

And again later:
         if istep == 1 and width > 0:   <-- Line 348
                     ^-- change to _ONE

As a standalone optimization, it wasn't worth it, but as a way to fix the bug without a regression, it is reasonable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42772>
_______________________________________

From report at bugs.python.org  Mon Dec 28 18:56:01 2020
From: report at bugs.python.org (Zackery Spytz)
Date: Mon, 28 Dec 2020 23:56:01 +0000
Subject: [issue42770] Typo in email.headerregistry docs
In-Reply-To: <1609179196.61.0.989200266115.issue42770@roundup.psfhosted.org>
Message-ID: <1609199761.63.0.663203369644.issue42770@roundup.psfhosted.org>


Zackery Spytz <zspytz at gmail.com> added the comment:

I've created a fix for this error.

----------
versions: +Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42770>
_______________________________________

From report at bugs.python.org  Mon Dec 28 18:59:58 2020
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 28 Dec 2020 23:59:58 +0000
Subject: [issue40522] [subinterpreters] Get the current Python interpreter
 state from Thread Local Storage (autoTSSkey)
In-Reply-To: <1588698734.65.0.223552100195.issue40522@roundup.psfhosted.org>
Message-ID: <1609199998.25.0.531007934396.issue40522@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Mark Shannon experiment using __thread:

* https://mail.python.org/archives/list/python-dev at python.org/thread/RPSTDB6AEMIACJFZKCKIRFTVLAJQLAS2/

* https://github.com/python/cpython/compare/master...markshannon:threadstate_in_tls

He added " extern __thread struct _ts *_Py_tls_tstate;" to Include/cpython/pystate.h.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40522>
_______________________________________

From report at bugs.python.org  Mon Dec 28 19:31:43 2020
From: report at bugs.python.org (Ammar Askar)
Date: Tue, 29 Dec 2020 00:31:43 +0000
Subject: [issue42773] build.yml workflow not testing on pushes
In-Reply-To: <1609194687.05.0.86275810312.issue42773@roundup.psfhosted.org>
Message-ID: <1609201903.62.0.268128832319.issue42773@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Any commit that gets to pushed to the master, 3.9, 3.8 and 3.7 branches.

e.g all the commits here https://github.com/python/cpython/commits/master, they end up failing the "Check for source changes" step and skipping even when there's non-documentation changes.

----------
versions: +Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42773>
_______________________________________

From report at bugs.python.org  Mon Dec 28 19:42:59 2020
From: report at bugs.python.org (Trevor Marvin)
Date: Tue, 29 Dec 2020 00:42:59 +0000
Subject: [issue42774] 'ipaddress' module,
 bad result for 'is_private' on "192.0.0.0"
Message-ID: <1609202579.47.0.156999705644.issue42774@roundup.psfhosted.org>


New submission from Trevor Marvin <python.org at syntechnix.net>:

Tested on Python 3.6.9 with "ipaddress" module, module version 1.0.

ipaddress.ip_address('192.0.0.0').is_private

Incorrectly returns as 'True'.  Per RFC 1918 / BCP 5, section 3, the private IPv4 space sarting with '192' is only '192.168.0.0/16'.

----------
components: Library (Lib)
messages: 383942
nosy: trevormarvin
priority: normal
severity: normal
status: open
title: 'ipaddress' module, bad result for 'is_private' on "192.0.0.0"
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42774>
_______________________________________

From report at bugs.python.org  Mon Dec 28 19:55:17 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 29 Dec 2020 00:55:17 +0000
Subject: [issue42774] 'ipaddress' module,
 bad result for 'is_private' on "192.0.0.0"
In-Reply-To: <1609202579.47.0.156999705644.issue42774@roundup.psfhosted.org>
Message-ID: <1609203317.21.0.45241676385.issue42774@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

The ipaddress documentation references https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml, which says that 192.0.0.0/29 is reserved and not globally reachable. I think in that sense, it's a private address.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42774>
_______________________________________

From report at bugs.python.org  Mon Dec 28 19:56:45 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 29 Dec 2020 00:56:45 +0000
Subject: [issue42765] Introduce new data model method __iter_items__
In-Reply-To: <1609169200.88.0.326770807054.issue42765@roundup.psfhosted.org>
Message-ID: <1609203405.38.0.723608882253.issue42765@roundup.psfhosted.org>


Change by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42765>
_______________________________________

From report at bugs.python.org  Mon Dec 28 20:27:55 2020
From: report at bugs.python.org (Gerrik Labra)
Date: Tue, 29 Dec 2020 01:27:55 +0000
Subject: [issue42753] "./configure" linux chrome beta
In-Reply-To: <1609181440.75.0.413687934108.issue42753@roundup.psfhosted.org>
Message-ID: <CAAUs7_tJhVuY6CAEBZnmzd79MKF1auevC=rqusyWfRBTcVVdfQ@mail.gmail.com>


Gerrik Labra <gerriklabra at gmail.com> added the comment:

Understood. Thank you.

On Mon, Dec 28, 2020 at 10:50 AM Eric V. Smith <report at bugs.python.org>
wrote:

>
> Eric V. Smith <eric at trueblade.com> added the comment:
>
> This appears to not be a bug with Python, so I'm going to close this. If
> you're having additional build problems, I suggest you ask for help on the
> python-list mailing list, or maybe on Stack Overflow.
>
> ----------
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
> type:  -> behavior
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue42753>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42753>
_______________________________________

From report at bugs.python.org  Mon Dec 28 20:51:46 2020
From: report at bugs.python.org (Trevor Marvin)
Date: Tue, 29 Dec 2020 01:51:46 +0000
Subject: [issue42774] 'ipaddress' module,
 bad result for 'is_private' on "192.0.0.0"
In-Reply-To: <1609202579.47.0.156999705644.issue42774@roundup.psfhosted.org>
Message-ID: <1609206706.66.0.841181626798.issue42774@roundup.psfhosted.org>


Change by Trevor Marvin <python.org at syntechnix.net>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42774>
_______________________________________

From report at bugs.python.org  Mon Dec 28 21:26:33 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 29 Dec 2020 02:26:33 +0000
Subject: [issue42740] typing.py get_args and get_origin should support PEP 604
 and 612
In-Reply-To: <1608909562.21.0.0257515668126.issue42740@roundup.psfhosted.org>
Message-ID: <1609208793.42.0.975633664701.issue42740@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:


New changeset efb1f0918fad2ba3346a986b0e958dc5753a7bbe by Ken Jin in branch 'master':
bpo-42740: Support PEP 604, 612 for typing.py get_args and get_origin (GH-23942)
https://github.com/python/cpython/commit/efb1f0918fad2ba3346a986b0e958dc5753a7bbe


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42740>
_______________________________________

From report at bugs.python.org  Mon Dec 28 21:29:46 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 29 Dec 2020 02:29:46 +0000
Subject: [issue42740] typing.py get_args and get_origin should support PEP 604
 and 612
In-Reply-To: <1608909562.21.0.0257515668126.issue42740@roundup.psfhosted.org>
Message-ID: <1609208986.6.0.455070825427.issue42740@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/issue42740>
_______________________________________

From report at bugs.python.org  Mon Dec 28 22:06:49 2020
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 29 Dec 2020 03:06:49 +0000
Subject: [issue42775] __init_subclass__ should be called in __init__
Message-ID: <1609211209.61.0.873859112725.issue42775@roundup.psfhosted.org>


New submission from Ethan Furman <ethan at stoneleaf.us>:

PEP 487 introduced __init_subclass__ and __set_name__, and both of those were wins for the common cases of metaclass usage.

Unfortunately, the implementation of PEP 487 with regards to __init_subclass__ has made the writing of correct metaclasses significantly harder, if not impossible.

The cause is that when a metaclass calls type.__new__ to actually create the class, type.__new__ calls the __init_subclass__ methods of the new class' parents, passing it the newly created, but incomplete, class.  In code:

```
class Meta(type):
    #
    def __new__(mcls, name, bases, namespace, **kwds):
        # create new class, which will call __init_subclass__ and __set_name__
        new_class = type.__new__(mcls, name, bases, namespace, **kwds)
        # finish setting up class
        new_class.some_attr = 9
```

As you can deduce, when the parent __init_subclass__ is called with the new class, `some_attr` has not been added yet -- the new class is incomplete.

For Enum, this means that __init_subclass__ doesn't have access to the new Enum's members (they haven't beet added yet).

For ABC, this means that __init_subclass__ doesn't have access to __abstract_methods__ (it hasn't been created yet).

Because Enum is pure Python code I was able to work around it:
- remove new __init_subclass__ (if it exists)
- insert dummy class with a no-op __init_subclass__
- call type.__new__
- save any actual __init_subclass__
- add back any new __init_subclass__
- rewrite the new class' __bases__, removing the no-op dummy class
- finish creating the class
- call the parent __init_subclass__ with the now complete Enum class

I have not been able to work around the problem for ABC.

The solution would seem to be to move the calls to __init_subclass__ and __set_names__ to type.__init__.

----------
assignee: ethan.furman
components: Interpreter Core
messages: 383946
nosy: ethan.furman, serhiy.storchaka
priority: high
severity: normal
stage: needs patch
status: open
title: __init_subclass__ should be called in __init__
type: behavior
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42775>
_______________________________________

From report at bugs.python.org  Mon Dec 28 22:08:11 2020
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 29 Dec 2020 03:08:11 +0000
Subject: [issue35815] Able to instantiate a subclass with abstract methods
 from __init_subclass__ of the ABC
In-Reply-To: <1548316625.2.0.852101004839.issue35815@roundup.psfhosted.org>
Message-ID: <1609211291.89.0.725774931611.issue35815@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

If the patch in issue42775 is committed, this problem will be solved.

----------
assignee:  -> ethan.furman
superseder:  -> __init_subclass__ should be called in __init__

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35815>
_______________________________________

From report at bugs.python.org  Mon Dec 28 22:15:45 2020
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 29 Dec 2020 03:15:45 +0000
Subject: [issue42775] __init_subclass__ should be called in __init__
In-Reply-To: <1609211209.61.0.873859112725.issue42775@roundup.psfhosted.org>
Message-ID: <1609211745.49.0.753820963645.issue42775@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

My understanding of using keywords in class headers

  class MyClass(SomeBaseClass, setting='maybe'):
    ...

is that the keywords would get passed into the super classes `__init_subclass__`  (`SomeBaseClass` and `setting`).

However, in the cases of 

- test_descr.py
- test_py_compile.py
- typing.py

that wasn't happening -- until the initial patch of moving the calls from `type.__new__` to `type.__init__`.

An `__init__` has been added in those three locations to discard the keyword arguments being passed in.

----------
nosy: +rhettinger, stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42775>
_______________________________________

From report at bugs.python.org  Mon Dec 28 22:19:59 2020
From: report at bugs.python.org (andy ye)
Date: Tue, 29 Dec 2020 03:19:59 +0000
Subject: [issue42776] The string find method shows the problem
Message-ID: <1609211999.49.0.259573414464.issue42776@roundup.psfhosted.org>


New submission from andy ye <andy.ye.jx at gmail.com>:

data = 'abcddd'
# True
data.find('a', 0)

# False
data.find('a', start=0)


# document
class str(obj):

    def find(self, sub, start=None, end=None): # real signature unknown; restored from __doc__
        """
        S.find(sub[, start[, end]]) -> int
        
        Return the lowest index in S where substring sub is found,
        such that sub is contained within S[start:end].  Optional
        arguments start and end are interpreted as in slice notation.
        
        Return -1 on failure.
        """
        return 0

----------
assignee: docs at python
components: Documentation
files: ??2020-12-29 ??10.57.53.png
messages: 383949
nosy: andyye, docs at python
priority: normal
severity: normal
status: open
title: The string find method shows the problem
versions: Python 3.6
Added file: https://bugs.python.org/file49704/??2020-12-29 ??10.57.53.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42776>
_______________________________________

From report at bugs.python.org  Mon Dec 28 22:31:14 2020
From: report at bugs.python.org (Xinmeng Xia)
Date: Tue, 29 Dec 2020 03:31:14 +0000
Subject: [issue42762] infinite loop resulted by "yield"
In-Reply-To: <1609130295.32.0.912620547313.issue42762@roundup.psfhosted.org>
Message-ID: <1609212674.81.0.534400170494.issue42762@roundup.psfhosted.org>


Xinmeng Xia <xiaxm at smail.nju.edu.cn> added the comment:

Thanks for your kind explanation! My description is a little confusing. Sorry about that. The problem here is that the program should stop when the exception is caught whatever the exception is. (I think bpo-25612 (#1773) fixed exception selection problems and right exception can be caught) The fact is this program will fall into an infinite loop. Error messages are printed in a dead loop. The program doesn't stop. This is not normal. There will be no loops in Python 3.5 and 3.6 (Attached output in Python 3.5 and 3.6). 

 

Output on Python 3.5,3.6 (all errors are printed without any loop )
-----------------------------------------------------
Exception ignored in: <generator object foo at 0x7f4cde5b8b48>
RuntimeError: generator ignored GeneratorExit
Traceback (most recent call last):
  File "/home/xxm/Desktop/nameChanging/report/test1.py", line 248, in <module>
    print(i)
NameError: name 'i' is not defined
Exception ignored in: <generator object foo at 0x7f4cde5b8bf8>
RuntimeError: generator ignored GeneratorExit
Exception ignored in: <generator object foo at 0x7f4cde5b8ca8>
RuntimeError: generator ignored GeneratorExit
--------------------------------------------------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42762>
_______________________________________

From report at bugs.python.org  Mon Dec 28 22:35:59 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 29 Dec 2020 03:35:59 +0000
Subject: [issue42776] The string find method shows the problem
In-Reply-To: <1609211999.49.0.259573414464.issue42776@roundup.psfhosted.org>
Message-ID: <1609212959.0.0.828573022969.issue42776@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

# True
data.find('a', 0)

That will return 0, not True.


# False
data.find('a', start=0)


And that will raise TypeError, not return False.


What exactly are you reporting here? I have read your bug report, and looked at the screen shot, and I have no idea what problem you think you have found or what you want to change about the documentation.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42776>
_______________________________________

From report at bugs.python.org  Mon Dec 28 22:46:12 2020
From: report at bugs.python.org (Xinmeng Xia)
Date: Tue, 29 Dec 2020 03:46:12 +0000
Subject: [issue42763] Exposing a race in the "_warnings" resulting Python
 parser crash
In-Reply-To: <1609130399.05.0.938510382701.issue42763@roundup.psfhosted.org>
Message-ID: <1609213572.39.0.717255589809.issue42763@roundup.psfhosted.org>


Xinmeng Xia <xiaxm at smail.nju.edu.cn> added the comment:

Thank you, but I don't think this is a duplicate of issue42717. This crash is probably caused by the parameter "target" of Thread. "Target" accept the "callable object". Defaults to None. In this program, it's assigned to a "Int object". I think a pre-checking of parameter for such error should be added. 



Minimal test case should be:
===============================
import threading
for i in range(10):
    t = threading.Thread(target=1, daemon=True).start()  
================================= 



In fact, I try this one. No loop, It sometime crashes the parser.(not always, twice in ten times)
==================================
import threading
t = threading.Thread(target=1, daemon=True).start()
==================================

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42763>
_______________________________________

From report at bugs.python.org  Mon Dec 28 22:57:10 2020
From: report at bugs.python.org (Xinmeng Xia)
Date: Tue, 29 Dec 2020 03:57:10 +0000
Subject: [issue42717] The python interpreter crashed with
 "_enter_buffered_busy"
In-Reply-To: <1608632703.27.0.708410911987.issue42717@roundup.psfhosted.org>
Message-ID: <1609214230.79.0.776305957555.issue42717@roundup.psfhosted.org>


Xinmeng Xia <xiaxm at smail.nju.edu.cn> added the comment:

Could we try to limit the number of thread or state or something? I mean if we set parameter of "range", for example, to 1000 or less here, the crash will no longer happen. I think the parser can not handle too heavy loop so that it crashes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42717>
_______________________________________

From report at bugs.python.org  Mon Dec 28 23:12:49 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 29 Dec 2020 04:12:49 +0000
Subject: [issue42770] Typo in email.headerregistry docs
In-Reply-To: <1609179196.61.0.989200266115.issue42770@roundup.psfhosted.org>
Message-ID: <1609215169.46.0.944083238479.issue42770@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset c56988b88fecf6dc70f039704fda6051a0754db1 by Zackery Spytz in branch 'master':
bpo-42770: Fix a typo in the email.headerregistry docs (GH-23982)
https://github.com/python/cpython/commit/c56988b88fecf6dc70f039704fda6051a0754db1


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42770>
_______________________________________

From report at bugs.python.org  Mon Dec 28 23:14:18 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 29 Dec 2020 04:14:18 +0000
Subject: [issue42770] Typo in email.headerregistry docs
In-Reply-To: <1609179196.61.0.989200266115.issue42770@roundup.psfhosted.org>
Message-ID: <1609215258.58.0.384354938871.issue42770@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22828
pull_request: https://github.com/python/cpython/pull/23985

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42770>
_______________________________________

From report at bugs.python.org  Mon Dec 28 23:14:11 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 29 Dec 2020 04:14:11 +0000
Subject: [issue42770] Typo in email.headerregistry docs
In-Reply-To: <1609179196.61.0.989200266115.issue42770@roundup.psfhosted.org>
Message-ID: <1609215251.18.0.293286293097.issue42770@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22827
pull_request: https://github.com/python/cpython/pull/23984

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42770>
_______________________________________

From report at bugs.python.org  Mon Dec 28 23:17:59 2020
From: report at bugs.python.org (David)
Date: Tue, 29 Dec 2020 04:17:59 +0000
Subject: [issue42777] WindowsPath does not implement is_mount but ntpath
 implements and offers a ismount method
Message-ID: <1609215479.73.0.163162738943.issue42777@roundup.psfhosted.org>


New submission from David <db+pythonbugs at d1b.org>:

pathlib.WindowsPath[0] does not implement is_mount but ntpath implements and offers a ismount[1] method. Perhaps WindowsPath is_mount can make use of ntpath.ismount ?



[0] https://github.com/python/cpython/blob/master/Lib/pathlib.py#L1578
[1] https://github.com/python/cpython/blob/master/Lib/ntpath.py#L248

----------
messages: 383955
nosy: db
priority: normal
severity: normal
status: open
title: WindowsPath does not implement is_mount but ntpath implements and offers a ismount method

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42777>
_______________________________________

From report at bugs.python.org  Mon Dec 28 23:21:51 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 29 Dec 2020 04:21:51 +0000
Subject: [issue42770] Typo in email.headerregistry docs
In-Reply-To: <1609179196.61.0.989200266115.issue42770@roundup.psfhosted.org>
Message-ID: <1609215711.83.0.925762767922.issue42770@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset e11639880a73f30b4009efa8d14c350932e35332 by Miss Islington (bot) in branch '3.8':
bpo-42770: Fix a typo in the email.headerregistry docs (GH-23982)
https://github.com/python/cpython/commit/e11639880a73f30b4009efa8d14c350932e35332


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42770>
_______________________________________

From report at bugs.python.org  Mon Dec 28 23:37:37 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 29 Dec 2020 04:37:37 +0000
Subject: [issue42770] Typo in email.headerregistry docs
In-Reply-To: <1609179196.61.0.989200266115.issue42770@roundup.psfhosted.org>
Message-ID: <1609216657.46.0.608360175782.issue42770@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 0b43778b3cd222761beb850178492b6bd0ea2370 by Miss Islington (bot) in branch '3.9':
bpo-42770: Fix a typo in the email.headerregistry docs (GH-23982)
https://github.com/python/cpython/commit/0b43778b3cd222761beb850178492b6bd0ea2370


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42770>
_______________________________________

From report at bugs.python.org  Mon Dec 28 23:39:25 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 29 Dec 2020 04:39:25 +0000
Subject: [issue1398781] Example in section 5.3 "Pure Embedding" doesn't work.
Message-ID: <1609216765.37.0.650451414175.issue1398781@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
keywords:  -easy
versions: +Python 3.10 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1398781>
_______________________________________

From report at bugs.python.org  Mon Dec 28 23:39:53 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 29 Dec 2020 04:39:53 +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: <1609216793.27.0.0890338884753.issue8822@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
versions: +Python 3.10 -Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8822>
_______________________________________

From report at bugs.python.org  Mon Dec 28 23:41:38 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 29 Dec 2020 04:41:38 +0000
Subject: [issue8481] doc: ctypes no need to explicitly allocate writable
 memory with Structure
In-Reply-To: <1271834227.47.0.0148350492358.issue8481@psf.upfronthosting.co.za>
Message-ID: <1609216898.07.0.393099455307.issue8481@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:

This is a not a bug, it asks for parameter types to explained. API documentation reference should provide the guidance.

----------
nosy: +orsenthil
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed
versions: +Python 3.10 -Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8481>
_______________________________________

From report at bugs.python.org  Mon Dec 28 23:42:00 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 29 Dec 2020 04:42:00 +0000
Subject: [issue8595] Explain the default timeout in http-client-related
 libraries
In-Reply-To: <1272768884.43.0.28527344604.issue8595@psf.upfronthosting.co.za>
Message-ID: <1609216920.98.0.96023341721.issue8595@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
assignee: docs at python -> orsenthil
versions: +Python 3.10 -Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue8595>
_______________________________________

From report at bugs.python.org  Mon Dec 28 23:46:22 2020
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 29 Dec 2020 04:46:22 +0000
Subject: [issue42770] Typo in email.headerregistry docs
In-Reply-To: <1609179196.61.0.989200266115.issue42770@roundup.psfhosted.org>
Message-ID: <1609217182.27.0.938890958172.issue42770@roundup.psfhosted.org>


Zachary Ware <zachary.ware at gmail.com> added the comment:

Thanks for the report, bazwal; for the patch, Zackery; and for the ping Ammar :)

----------
nosy: +zach.ware
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type: enhancement -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42770>
_______________________________________

From report at bugs.python.org  Tue Dec 29 00:26:34 2020
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 29 Dec 2020 05:26:34 +0000
Subject: [issue42775] __init_subclass__ should be called in __init__
In-Reply-To: <1609211209.61.0.873859112725.issue42775@roundup.psfhosted.org>
Message-ID: <1609219594.0.0.478511235166.issue42775@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42775>
_______________________________________

From report at bugs.python.org  Tue Dec 29 00:28:41 2020
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 29 Dec 2020 05:28:41 +0000
Subject: [issue42775] __init_subclass__ should be called in __init__
In-Reply-To: <1609211209.61.0.873859112725.issue42775@roundup.psfhosted.org>
Message-ID: <1609219721.38.0.685936328198.issue42775@roundup.psfhosted.org>


Change by Ethan Furman <ethan at stoneleaf.us>:


----------
keywords: +patch
pull_requests: +22829
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/23986

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42775>
_______________________________________

From report at bugs.python.org  Tue Dec 29 00:34:10 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 29 Dec 2020 05:34:10 +0000
Subject: [issue42775] __init_subclass__ should be called in __init__
In-Reply-To: <1609211209.61.0.873859112725.issue42775@roundup.psfhosted.org>
Message-ID: <1609220050.8.0.162542663598.issue42775@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Whoa, you start a discussion on python-dev and another on bpo? That sounds a bit hasty.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42775>
_______________________________________

From report at bugs.python.org  Tue Dec 29 01:09:04 2020
From: report at bugs.python.org (ye andy)
Date: Tue, 29 Dec 2020 06:09:04 +0000
Subject: [issue42776] The string find method shows the problem
In-Reply-To: <1609212959.0.0.828573022969.issue42776@roundup.psfhosted.org>
Message-ID: <CANJBW=84pXGU-6iP8+M+-P9S8sBmHBi31C8Lcwe4nV_HC=hvpQ@mail.gmail.com>


ye andy <andy.ye.jx at gmail.com> added the comment:

When I say True here, I'm not talking about querying, I'm talking about
syntax, as far as I know, document is supposed to support keyword
arguments, but it doesn't

Steven D'Aprano <report at bugs.python.org> ?2020?12?29??? ??11:36???

>
> Steven D'Aprano <steve+python at pearwood.info> added the comment:
>
> # True
> data.find('a', 0)
>
> That will return 0, not True.
>
>
> # False
> data.find('a', start=0)
>
>
> And that will raise TypeError, not return False.
>
>
> What exactly are you reporting here? I have read your bug report, and
> looked at the screen shot, and I have no idea what problem you think you
> have found or what you want to change about the documentation.
>
> ----------
> nosy: +steven.daprano
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue42776>
> _______________________________________
>

----------
nosy: +andy.ye.jx

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42776>
_______________________________________

From report at bugs.python.org  Tue Dec 29 01:24:20 2020
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 29 Dec 2020 06:24:20 +0000
Subject: [issue42775] __init_subclass__ should be called in __init__
In-Reply-To: <1609211209.61.0.873859112725.issue42775@roundup.psfhosted.org>
Message-ID: <1609223060.37.0.963900428573.issue42775@roundup.psfhosted.org>


Ethan Furman <ethan at stoneleaf.us> added the comment:

Guido, I just wanted to get it all in place while it was fresh in my mind.  Actual code tends to make a discussion easier.  I'll make sure and transcribe any relevant discussion from python-dev to here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42775>
_______________________________________

From report at bugs.python.org  Tue Dec 29 01:34:25 2020
From: report at bugs.python.org (FredInChina)
Date: Tue, 29 Dec 2020 06:34:25 +0000
Subject: [issue7057] tkinter doc: more 3.x updates
In-Reply-To: <1254697168.63.0.205098696566.issue7057@psf.upfronthosting.co.za>
Message-ID: <1609223665.88.0.377610382858.issue7057@roundup.psfhosted.org>


FredInChina <trustgold at gmail.com> added the comment:

Are there good reasons not to close this issue?
It is marked as "easy", but it seems that the problems in reference have either been fixed, or died of old age.

----------
nosy: +ReblochonMasque

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue7057>
_______________________________________

From report at bugs.python.org  Tue Dec 29 02:23:57 2020
From: report at bugs.python.org (FredInChina)
Date: Tue, 29 Dec 2020 07:23:57 +0000
Subject: [issue42560] Improve Tkinter Documentation
In-Reply-To: <1607020537.02.0.420924180434.issue42560@roundup.psfhosted.org>
Message-ID: <1609226637.24.0.0131676220439.issue42560@roundup.psfhosted.org>


FredInChina <trustgold at gmail.com> added the comment:

I agree with @MasonGinter, the documentation is somewhat lacking. Relying on third parties is fragile - we were fortunate that the University of New Mexico Tech docs maintained by Pr. John W. Shipman were [salvaged](https://anzeljg.github.io/rin2/book2/2405/docs/tkinter/index.html) after his premature death; yet, some important example files were lost.

We now see [effbot.org](effbot.org) "taking a leave"... What other warnings do we need?


> "we don't know what Tk version to write them for".  
I don't understand why @epaine; shouldn't the docs be made available for the currently maintained version of python?

----------
nosy: +ReblochonMasque

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42560>
_______________________________________

From report at bugs.python.org  Tue Dec 29 02:51:01 2020
From: report at bugs.python.org (Tom Hale)
Date: Tue, 29 Dec 2020 07:51:01 +0000
Subject: [issue42778] Add follow_symlinks=True to {os.path,Path}.samefile
Message-ID: <1609228261.66.0.888283704166.issue42778@roundup.psfhosted.org>


New submission from Tom Hale <tom at hale.ee>:

The os.path and Path implementations of samefile() do not allow comparisons of symbolic links:

% mkdir empty && chdir empty
% ln -s non-existant broken
% ln broken lnbroken
% ls -i # Show inode numbers
19325632 broken@  19325632 lnbroken@
% Yup, they are the same file... but...
% python -c 'import os; print(os.path.samefile("lnbroken", "broken", follow_symlinks=False))'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: samefile() got an unexpected keyword argument 'follow_symlinks'
% python -c 'import os; print(os.path.samefile("lnbroken", "broken"))'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3.8/genericpath.py", line 100, in samefile
    s1 = os.stat(f1)
FileNotFoundError: [Errno 2] No such file or directory: 'lnbroken'
%

Both samefile()s use os.stat under the hood, but neither allow setting  os.stat()'s `follow_symlinks` parameter.

https://docs.python.org/3/library/os.html#os.stat

https://docs.python.org/3/library/os.path.html#os.path.samefile

https://docs.python.org/3/library/pathlib.html#pathlib.Path.samefile

----------
components: Library (Lib)
messages: 383965
nosy: Tom Hale
priority: normal
severity: normal
status: open
title: Add follow_symlinks=True to {os.path,Path}.samefile
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42778>
_______________________________________

From report at bugs.python.org  Tue Dec 29 02:55:27 2020
From: report at bugs.python.org (Tom Hale)
Date: Tue, 29 Dec 2020 07:55:27 +0000
Subject: [issue42778] Add follow_symlinks=True parameter to both
 os.path.samefile() and Path.samefile()
In-Reply-To: <1609228261.66.0.888283704166.issue42778@roundup.psfhosted.org>
Message-ID: <1609228527.29.0.377389804284.issue42778@roundup.psfhosted.org>


Tom Hale <tom at hale.ee> added the comment:

In summary:

The underlying os.stat() takes a follow_symlinks=True parameter but it can't be set to False when trying to samefile() two symbolic links.

----------
title: Add follow_symlinks=True to {os.path,Path}.samefile -> Add follow_symlinks=True parameter to both os.path.samefile() and Path.samefile()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42778>
_______________________________________

From report at bugs.python.org  Tue Dec 29 03:12:44 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 29 Dec 2020 08:12:44 +0000
Subject: [issue40522] [subinterpreters] Get the current Python interpreter
 state from Thread Local Storage (autoTSSkey)
In-Reply-To: <1588698734.65.0.223552100195.issue40522@roundup.psfhosted.org>
Message-ID: <1609229564.99.0.993630674788.issue40522@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> An optimized Python should always be built with LTO.

In MacOS is quite challenging to activate LTO, so normally optimized builds are only done with PGO. Also in Windows I am not sure is possible to use LTO. Same for many other platforms

----------
nosy: +pablogsal

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40522>
_______________________________________

From report at bugs.python.org  Tue Dec 29 03:13:34 2020
From: report at bugs.python.org (Tom Hale)
Date: Tue, 29 Dec 2020 08:13:34 +0000
Subject: [issue36656] Add race-free os.link and os.symlink wrapper / helper
In-Reply-To: <1555577087.92.0.769196427693.issue36656@roundup.psfhosted.org>
Message-ID: <1609229614.6.0.545380677891.issue36656@roundup.psfhosted.org>


Tom Hale <tom at hale.ee> added the comment:

Related issue found in testing:

bpo-42778 Add follow_symlinks=True parameter to both os.path.samefile() and Path.samefile()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36656>
_______________________________________

From report at bugs.python.org  Tue Dec 29 04:49:50 2020
From: report at bugs.python.org (minipython)
Date: Tue, 29 Dec 2020 09:49:50 +0000
Subject: [issue42779] Pow compute can only available in python3.7
Message-ID: <1609235390.01.0.221368482362.issue42779@roundup.psfhosted.org>


New submission from minipython <599192367 at qq.com>:

The code can only computed based on python 3.7.Python 3.9 and python 3.6 cannot compute the code.It is very strange problem.

----------
components: C API
files: chinarest.py
messages: 383969
nosy: minipython
priority: normal
severity: normal
status: open
title: Pow compute can only available in python3.7
type: resource usage
versions: Python 3.7
Added file: https://bugs.python.org/file49705/chinarest.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42779>
_______________________________________

From report at bugs.python.org  Tue Dec 29 04:53:18 2020
From: report at bugs.python.org (Nicholas Sim)
Date: Tue, 29 Dec 2020 09:53:18 +0000
Subject: [issue35134] Add a new Include/cpython/ subdirectory for the "CPython
 API" with implementation details
In-Reply-To: <1541076409.33.0.788709270274.issue35134@psf.upfronthosting.co.za>
Message-ID: <1609235598.6.0.670404878525.issue35134@roundup.psfhosted.org>


Change by Nicholas Sim <nsim at posteo.net>:


----------
nosy: +nw0
nosy_count: 6.0 -> 7.0
pull_requests: +22830
pull_request: https://github.com/python/cpython/pull/23988

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35134>
_______________________________________

From report at bugs.python.org  Tue Dec 29 04:58:47 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Dec 2020 09:58:47 +0000
Subject: [issue35134] Add a new Include/cpython/ subdirectory for the "CPython
 API" with implementation details
In-Reply-To: <1541076409.33.0.788709270274.issue35134@psf.upfronthosting.co.za>
Message-ID: <1609235927.63.0.913941282132.issue35134@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Victor, could you please add README files in directories cpython and internals? It is not clear what headers are considered more private.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue35134>
_______________________________________

From report at bugs.python.org  Tue Dec 29 05:12:04 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 29 Dec 2020 10:12:04 +0000
Subject: [issue42747] Remove Py_TPFLAGS_HAVE_VERSION_TAG flag?
In-Reply-To: <1608940087.88.0.458230907712.issue42747@roundup.psfhosted.org>
Message-ID: <1609236724.31.0.413510312939.issue42747@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

IMO, these flags are useless. Both the stable ABI and the version-specific builds of extension modules use the memory layout of the current interpreter and fill unset slots with NULL.

Py_TPFLAGS_HAVE_AM_SEND is new in 3.10, so it can  be removed (or replaced by a check for Py_TYPE(iter)->tp_as_async != NULL && Py_TYPE(iter)->tp_as_async->am_send != NULL).

Py_TPFLAGS_HAVE_VERSION_TAG and Py_TPFLAGS_HAVE_FINALIZE are there since 2.6 and 3.8 respectively, and mentioned in documentation. Extensions that use the stable ABI can *check for them*. We cannot do a survey of all existing extension modules. The flags can't be removed without breaking stable ABI.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42747>
_______________________________________

From report at bugs.python.org  Tue Dec 29 05:20:22 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 29 Dec 2020 10:20:22 +0000
Subject: [issue42625] Segmentation fault of PyState_AddModule()
In-Reply-To: <1607785781.22.0.676457210715.issue42625@roundup.psfhosted.org>
Message-ID: <1609237222.07.0.00519636594476.issue42625@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

Thanks, Victor, for explaining!


You'll also see NULL checks in existing code where they aren't strictly necessary, but removing them would be too much trouble.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42625>
_______________________________________

From report at bugs.python.org  Tue Dec 29 05:34:44 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 29 Dec 2020 10:34:44 +0000
Subject: [issue41618] [C API] How many slots of static types should be exposed
 in PyType_GetSlot()
In-Reply-To: <1598172498.12.0.869607269568.issue41618@roundup.psfhosted.org>
Message-ID: <1609238084.61.0.360036940439.issue41618@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

Documentation for developers *of* CPython should generally go in the dev guide, a comment in the code, or in issues like this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41618>
_______________________________________

From report at bugs.python.org  Tue Dec 29 05:36:22 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Dec 2020 10:36:22 +0000
Subject: [issue42747] Remove Py_TPFLAGS_HAVE_VERSION_TAG flag?
In-Reply-To: <1608940087.88.0.458230907712.issue42747@roundup.psfhosted.org>
Message-ID: <1609238182.26.0.715210685469.issue42747@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

I don't think that it was right thing to break binary compatibility. It virtually buried the stable ABI.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42747>
_______________________________________

From report at bugs.python.org  Tue Dec 29 05:56:25 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Dec 2020 10:56:25 +0000
Subject: [issue42749] test_tcl failed on 32-bit POWER6 AIX 3.9: big int issue
 with 9223372036854775808
In-Reply-To: <1608981118.95.0.264551211038.issue42749@roundup.psfhosted.org>
Message-ID: <1609239385.95.0.327795074316.issue42749@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 156b7f7052102ee1633a18e9a136ad8c38f66db0 by Serhiy Storchaka in branch 'master':
bpo-42749: Use dynamic version to test for unsupported bignum in Tk (GH-23966)
https://github.com/python/cpython/commit/156b7f7052102ee1633a18e9a136ad8c38f66db0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42749>
_______________________________________

From report at bugs.python.org  Tue Dec 29 05:56:28 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 29 Dec 2020 10:56:28 +0000
Subject: [issue42749] test_tcl failed on 32-bit POWER6 AIX 3.9: big int issue
 with 9223372036854775808
In-Reply-To: <1608981118.95.0.264551211038.issue42749@roundup.psfhosted.org>
Message-ID: <1609239388.7.0.183712879885.issue42749@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22832
pull_request: https://github.com/python/cpython/pull/23990

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42749>
_______________________________________

From report at bugs.python.org  Tue Dec 29 05:56:16 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 29 Dec 2020 10:56:16 +0000
Subject: [issue42749] test_tcl failed on 32-bit POWER6 AIX 3.9: big int issue
 with 9223372036854775808
In-Reply-To: <1608981118.95.0.264551211038.issue42749@roundup.psfhosted.org>
Message-ID: <1609239376.87.0.0812068103851.issue42749@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22831
pull_request: https://github.com/python/cpython/pull/23989

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42749>
_______________________________________

From report at bugs.python.org  Tue Dec 29 05:56:58 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Dec 2020 10:56:58 +0000
Subject: [issue42759] Take into acount a Tcl interpreter when compare
 variables and fonts
In-Reply-To: <1609100219.29.0.633808020235.issue42759@roundup.psfhosted.org>
Message-ID: <1609239418.73.0.691943992179.issue42759@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 1df56bc0597a051c13d53514e120e9b6764185f8 by Serhiy Storchaka in branch 'master':
bpo-42759: Fix equality comparison of Variable and Font in Tkinter (GH-23968)
https://github.com/python/cpython/commit/1df56bc0597a051c13d53514e120e9b6764185f8


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42759>
_______________________________________

From report at bugs.python.org  Tue Dec 29 05:57:10 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 29 Dec 2020 10:57:10 +0000
Subject: [issue42759] Take into acount a Tcl interpreter when compare
 variables and fonts
In-Reply-To: <1609100219.29.0.633808020235.issue42759@roundup.psfhosted.org>
Message-ID: <1609239430.25.0.105577961724.issue42759@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 1.0 -> 2.0
pull_requests: +22833
pull_request: https://github.com/python/cpython/pull/23991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42759>
_______________________________________

From report at bugs.python.org  Tue Dec 29 06:16:54 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 29 Dec 2020 11:16:54 +0000
Subject: [issue42749] test_tcl failed on 32-bit POWER6 AIX 3.9: big int issue
 with 9223372036854775808
In-Reply-To: <1608981118.95.0.264551211038.issue42749@roundup.psfhosted.org>
Message-ID: <1609240614.93.0.807733838321.issue42749@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 323cbb5531eb72527d0e3b02f28c1cdc5b7fce92 by Miss Islington (bot) in branch '3.8':
bpo-42749: Use dynamic version to test for unsupported bignum in Tk (GH-23966)
https://github.com/python/cpython/commit/323cbb5531eb72527d0e3b02f28c1cdc5b7fce92


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42749>
_______________________________________

From report at bugs.python.org  Tue Dec 29 06:17:47 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 29 Dec 2020 11:17:47 +0000
Subject: [issue42749] test_tcl failed on 32-bit POWER6 AIX 3.9: big int issue
 with 9223372036854775808
In-Reply-To: <1608981118.95.0.264551211038.issue42749@roundup.psfhosted.org>
Message-ID: <1609240667.87.0.131538877946.issue42749@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 7bdb3e08251894b49e7893db1dc4868e2656b342 by Miss Islington (bot) in branch '3.9':
bpo-42749: Use dynamic version to test for unsupported bignum in Tk (GH-23966)
https://github.com/python/cpython/commit/7bdb3e08251894b49e7893db1dc4868e2656b342


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42749>
_______________________________________

From report at bugs.python.org  Tue Dec 29 06:18:30 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 29 Dec 2020 11:18:30 +0000
Subject: [issue42759] Take into acount a Tcl interpreter when compare
 variables and fonts
In-Reply-To: <1609100219.29.0.633808020235.issue42759@roundup.psfhosted.org>
Message-ID: <1609240710.26.0.310981558682.issue42759@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 578caafabe1de652a8f31dbeb8cc660e1ed725eb by Miss Islington (bot) in branch '3.9':
bpo-42759: Fix equality comparison of Variable and Font in Tkinter (GH-23968)
https://github.com/python/cpython/commit/578caafabe1de652a8f31dbeb8cc660e1ed725eb


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42759>
_______________________________________

From report at bugs.python.org  Tue Dec 29 06:43:26 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 29 Dec 2020 11:43:26 +0000
Subject: [issue42779] Pow compute can only available in python3.7
In-Reply-To: <1609235390.01.0.221368482362.issue42779@roundup.psfhosted.org>
Message-ID: <1609242206.28.0.649087365541.issue42779@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

What error are you getting?

Can you demonstrate the error without gmpy2, as that is a third-party library and nothing to do with us.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42779>
_______________________________________

From report at bugs.python.org  Tue Dec 29 06:45:33 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Tue, 29 Dec 2020 11:45:33 +0000
Subject: [issue42776] The string find method shows the problem
In-Reply-To: <1609211999.49.0.259573414464.issue42776@roundup.psfhosted.org>
Message-ID: <1609242333.33.0.9307167106.issue42776@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

'abcddd'.find('a', start=0) would appear to be allowed from the help text, but it isn't legal. This is because .find() does not allow keyword arguments.

It looks like find could be documented as
find(self, sub, start=None, end=None, /)

Although it doesn't look like any of the str methods use self in the documentation.

I'm reasonably sure None is correct as the default for start and end, but I suspect it's not universally true of str methods that None works as the default. So it wouldn't surprise me if not all of the str methods  can be expressed in python code.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42776>
_______________________________________

From report at bugs.python.org  Tue Dec 29 06:49:37 2020
From: report at bugs.python.org (minipython)
Date: Tue, 29 Dec 2020 11:49:37 +0000
Subject: [issue42779] Pow compute can only available in python3.7
In-Reply-To: <1609235390.01.0.221368482362.issue42779@roundup.psfhosted.org>
Message-ID: <1609242577.44.0.801129973522.issue42779@roundup.psfhosted.org>


minipython <599192367 at qq.com> added the comment:

The issue is that if i use function pow(c,e),it can be computed in python37 in 3 minutes.But it cannot be computed in python36 or python39.Without gmpy2 library,i find the bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42779>
_______________________________________

From report at bugs.python.org  Tue Dec 29 06:52:15 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Dec 2020 11:52:15 +0000
Subject: [issue16396] Importing ctypes.wintypes on Linux gives a ValueError
 instead of an ImportError
In-Reply-To: <1351956172.0.0.64927799046.issue16396@psf.upfronthosting.co.za>
Message-ID: <1609242735.44.0.177404434668.issue16396@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 71d73900ebd4a93a64dae9d2fbef4337fa975e66 by Miss Islington (bot) in branch '3.9':
bpo-16396: fix BPO number in changelog (GH-23951) (GH-23956)
https://github.com/python/cpython/commit/71d73900ebd4a93a64dae9d2fbef4337fa975e66


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue16396>
_______________________________________

From report at bugs.python.org  Tue Dec 29 06:55:31 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Dec 2020 11:55:31 +0000
Subject: [issue41781] Typos in typing.py
In-Reply-To: <1600084822.87.0.84820912855.issue41781@roundup.psfhosted.org>
Message-ID: <1609242931.63.0.544923213147.issue41781@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset c1af128f5a5893839536453dcc8b2ed7b95b3c3a by Ross in branch 'master':
bpo-41781: Fix typo in internal function name in typing (GH-23957)
https://github.com/python/cpython/commit/c1af128f5a5893839536453dcc8b2ed7b95b3c3a


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41781>
_______________________________________

From report at bugs.python.org  Tue Dec 29 07:07:09 2020
From: report at bugs.python.org (hai shi)
Date: Tue, 29 Dec 2020 12:07:09 +0000
Subject: [issue41781] Typos in typing.py
In-Reply-To: <1600084822.87.0.84820912855.issue41781@roundup.psfhosted.org>
Message-ID: <1609243629.14.0.472618155202.issue41781@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

Thanks Patrick for your PR.
Thanks Serhiy for your merge.

----------
nosy: +shihai1991
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41781>
_______________________________________

From report at bugs.python.org  Tue Dec 29 07:16:12 2020
From: report at bugs.python.org (Luca Barba)
Date: Tue, 29 Dec 2020 12:16:12 +0000
Subject: [issue40633] json.dumps() should encode float number NaN to null
In-Reply-To: <1589550124.35.0.830023884715.issue40633@roundup.psfhosted.org>
Message-ID: <1609244172.16.0.649486782406.issue40633@roundup.psfhosted.org>


Luca Barba <alucab at alucab.org> added the comment:

I agree with arjanstaring

This implementation is not standard compliant and breaks interoperability with every ECMA compliant Javascript deserializer.

Technically is awful of course but interoperability and standardization come before than technical cleanliness IMHO

Regarding standardization:

If you consider https://tools.ietf.org/html/rfc7159

there is no way to represent the literal "nan" with the grammar supplied in section 6 hence the Infinity and Nan values are forbidden so as "nan"

For interoperability 

If you consider http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf

It is clearly stated in section 24.5.2 Note 4 that JSON.stringify produces null for Infinity and NaN

"Finite numbers are stringified as if by calling ToString(number). NaN and Infinity regardless of sign are represented as the String null"

It is clearly stated in section 24.5.1 that JSON.parse uses eval-like parsing as a reference for decoding. nan is not an allowed keyword at all. For interoperability NaN could be used but out from the JSON standard.

So what happens is that this will break all the ECMA compliant parsers (aka browsers) in the world. Which is what is happening to my project by the way

Pandas serialization methos (to_json) already adjusts this issue, but I really think the standard should too

----------
nosy: +alucab

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40633>
_______________________________________

From report at bugs.python.org  Tue Dec 29 07:21:01 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 29 Dec 2020 12:21:01 +0000
Subject: [issue42779] Pow compute can only available in python3.7
In-Reply-To: <1609235390.01.0.221368482362.issue42779@roundup.psfhosted.org>
Message-ID: <1609244461.07.0.98582309148.issue42779@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I cannot replicate that. On my computer, I can compute pow(c, e) in approximately two minutes using Python 3.9:


>>> from time import time
>>> t = time(); a = pow(c, e); time()-t
122.07566785812378
>>> math.log10(a)
50473921.44753242


Can you give more information please?

- exact version number used
- OS
- how much memory?
- if you leave pow(c, e) running for 10 minutes, does it complete?
- can you compute pow(c, 10000)? how long does that take?
- how about pow(c, 1000)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42779>
_______________________________________

From report at bugs.python.org  Tue Dec 29 07:21:50 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 29 Dec 2020 12:21:50 +0000
Subject: [issue23328] urllib.request fails for proxy credentials that contain
 a '/' character
In-Reply-To: <1422342235.17.0.905041944591.issue23328@psf.upfronthosting.co.za>
Message-ID: <1609244510.49.0.186110319311.issue23328@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +22834
pull_request: https://github.com/python/cpython/pull/23992

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23328>
_______________________________________

From report at bugs.python.org  Tue Dec 29 07:22:01 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 29 Dec 2020 12:22:01 +0000
Subject: [issue23328] urllib.request fails for proxy credentials that contain
 a '/' character
In-Reply-To: <1422342235.17.0.905041944591.issue23328@psf.upfronthosting.co.za>
Message-ID: <1609244521.51.0.544499457352.issue23328@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22835
pull_request: https://github.com/python/cpython/pull/23993

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23328>
_______________________________________

From report at bugs.python.org  Tue Dec 29 07:22:31 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Dec 2020 12:22:31 +0000
Subject: [issue38435] Start the deprecation cycle for subprocess preexec_fn
In-Reply-To: <1570731497.4.0.313201495913.issue38435@roundup.psfhosted.org>
Message-ID: <1609244551.15.0.534411188227.issue38435@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Would not be more consistent with other parameters to name the new parameter "pgid" or "process_group"?

And why not use None as default, like for user and group?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38435>
_______________________________________

From report at bugs.python.org  Tue Dec 29 07:22:45 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 29 Dec 2020 12:22:45 +0000
Subject: [issue42779] pow() of huge input does not complete
In-Reply-To: <1609235390.01.0.221368482362.issue42779@roundup.psfhosted.org>
Message-ID: <1609244565.09.0.69843971232.issue42779@roundup.psfhosted.org>


Change by Steven D'Aprano <steve+python at pearwood.info>:


----------
components: +Interpreter Core -C API
title: Pow compute can only available in python3.7 -> pow() of huge input does not complete
versions: +Python 3.6, Python 3.9 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42779>
_______________________________________

From report at bugs.python.org  Tue Dec 29 07:22:56 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 29 Dec 2020 12:22:56 +0000
Subject: [issue23328] urllib.request fails for proxy credentials that contain
 a '/' character
In-Reply-To: <1422342235.17.0.905041944591.issue23328@psf.upfronthosting.co.za>
Message-ID: <1609244576.01.0.763652367216.issue23328@roundup.psfhosted.org>


Change by Senthil Kumaran <senthil at uthcode.com>:


----------
versions: +Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23328>
_______________________________________

From report at bugs.python.org  Tue Dec 29 07:24:46 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Dec 2020 12:24:46 +0000
Subject: [issue42728] Typo in documentation: importlib.metadata
In-Reply-To: <1608794693.94.0.363783921808.issue42728@roundup.psfhosted.org>
Message-ID: <1609244686.44.0.0299635682632.issue42728@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +brett.cannon, eric.snow, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42728>
_______________________________________

From report at bugs.python.org  Tue Dec 29 07:33:23 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Dec 2020 12:33:23 +0000
Subject: [issue42700] xml.parsers.expat.errors description of codes/messages
 is flipped
In-Reply-To: <1608516708.54.0.399014748226.issue42700@roundup.psfhosted.org>
Message-ID: <1609245203.97.0.775835058033.issue42700@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 84402eb11086f97d31164aaa23e7238da3464f41 by Michael Wayne Goodman in branch 'master':
bpo-42700: Swap descriptions in pyexpat.errors (GH-23876)
https://github.com/python/cpython/commit/84402eb11086f97d31164aaa23e7238da3464f41


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42700>
_______________________________________

From report at bugs.python.org  Tue Dec 29 07:33:28 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 29 Dec 2020 12:33:28 +0000
Subject: [issue42700] xml.parsers.expat.errors description of codes/messages
 is flipped
In-Reply-To: <1608516708.54.0.399014748226.issue42700@roundup.psfhosted.org>
Message-ID: <1609245208.66.0.316528914672.issue42700@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +22836
pull_request: https://github.com/python/cpython/pull/23994

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42700>
_______________________________________

From report at bugs.python.org  Tue Dec 29 07:33:38 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 29 Dec 2020 12:33:38 +0000
Subject: [issue42700] xml.parsers.expat.errors description of codes/messages
 is flipped
In-Reply-To: <1608516708.54.0.399014748226.issue42700@roundup.psfhosted.org>
Message-ID: <1609245218.85.0.512549124228.issue42700@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22837
pull_request: https://github.com/python/cpython/pull/23995

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42700>
_______________________________________

From report at bugs.python.org  Tue Dec 29 07:35:13 2020
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Tue, 29 Dec 2020 12:35:13 +0000
Subject: [issue41224] Document is_annotate() in symtable and update doc strings
In-Reply-To: <1594082969.57.0.57546378767.issue41224@roundup.psfhosted.org>
Message-ID: <1609245313.66.0.118617492311.issue41224@roundup.psfhosted.org>


Change by Andr?s Delfino <adelfino at gmail.com>:


----------
nosy: +adelfino
nosy_count: 2.0 -> 3.0
pull_requests: +22838
pull_request: https://github.com/python/cpython/pull/23861

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41224>
_______________________________________

From report at bugs.python.org  Tue Dec 29 07:36:29 2020
From: report at bugs.python.org (Ross Rhodes)
Date: Tue, 29 Dec 2020 12:36:29 +0000
Subject: [issue42778] Add follow_symlinks=True parameter to both
 os.path.samefile() and Path.samefile()
In-Reply-To: <1609228261.66.0.888283704166.issue42778@roundup.psfhosted.org>
Message-ID: <1609245389.01.0.477282806162.issue42778@roundup.psfhosted.org>


Change by Ross Rhodes <ross.rhodes at hotmail.co.uk>:


----------
keywords: +patch
nosy: +trrhodes
nosy_count: 1.0 -> 2.0
pull_requests: +22839
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/23996

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42778>
_______________________________________

From report at bugs.python.org  Tue Dec 29 07:37:46 2020
From: report at bugs.python.org (Ross Rhodes)
Date: Tue, 29 Dec 2020 12:37:46 +0000
Subject: [issue42778] Add follow_symlinks=True parameter to both
 os.path.samefile() and Path.samefile()
In-Reply-To: <1609228261.66.0.888283704166.issue42778@roundup.psfhosted.org>
Message-ID: <1609245466.73.0.279473921903.issue42778@roundup.psfhosted.org>


Ross Rhodes <ross.rhodes at hotmail.co.uk> added the comment:

Hi Tom,

Thanks for raising this issue. I've opened a PR to permit us to set `follow_symlinks` in both os.path and pathlib. Feel free to leave feedback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42778>
_______________________________________

From report at bugs.python.org  Tue Dec 29 07:42:03 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Dec 2020 12:42:03 +0000
Subject: [issue42673] Optimize round_size for rehashing
In-Reply-To: <1608284127.41.0.53520654621.issue42673@roundup.psfhosted.org>
Message-ID: <1609245723.08.0.220427801204.issue42673@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Since no benchmarking data was provided, I suggest to close this issue. We do not accept optimization changes without evidences of performance boost.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42673>
_______________________________________

From report at bugs.python.org  Tue Dec 29 07:42:18 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 29 Dec 2020 12:42:18 +0000
Subject: [issue42700] xml.parsers.expat.errors description of codes/messages
 is flipped
In-Reply-To: <1608516708.54.0.399014748226.issue42700@roundup.psfhosted.org>
Message-ID: <1609245738.85.0.916357568181.issue42700@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 70ced2dd27ee59abee9af6926e9ce7d93f06f885 by Miss Islington (bot) in branch '3.8':
bpo-42700: Swap descriptions in pyexpat.errors (GH-23876)
https://github.com/python/cpython/commit/70ced2dd27ee59abee9af6926e9ce7d93f06f885


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42700>
_______________________________________

From report at bugs.python.org  Tue Dec 29 07:45:14 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 29 Dec 2020 12:45:14 +0000
Subject: [issue40137] TODO list when PEP 573 "Module State Access from C
 Extension Methods" will be implemented
In-Reply-To: <1585753703.83.0.0762180613721.issue40137@roundup.psfhosted.org>
Message-ID: <1609245914.49.0.315610447462.issue40137@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset dd39123970892733c317f235808638ae5c0ccf04 by Hai Shi in branch 'master':
bpo-40137: Convert _functools module to use PyType_FromModuleAndSpec. (GH-23405)
https://github.com/python/cpython/commit/dd39123970892733c317f235808638ae5c0ccf04


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40137>
_______________________________________

From report at bugs.python.org  Tue Dec 29 07:55:39 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 29 Dec 2020 12:55:39 +0000
Subject: [issue42700] xml.parsers.expat.errors description of codes/messages
 is flipped
In-Reply-To: <1608516708.54.0.399014748226.issue42700@roundup.psfhosted.org>
Message-ID: <1609246539.98.0.17641460626.issue42700@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset cc7f745e80bc177dfc746b057e1c7656b78382e5 by Miss Islington (bot) in branch '3.9':
bpo-42700: Swap descriptions in pyexpat.errors (GH-23876)
https://github.com/python/cpython/commit/cc7f745e80bc177dfc746b057e1c7656b78382e5


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42700>
_______________________________________

From report at bugs.python.org  Tue Dec 29 07:58:39 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Dec 2020 12:58:39 +0000
Subject: [issue42655] Fix subprocess extra_groups gid conversion
In-Reply-To: <1608113122.79.0.244683118693.issue42655@roundup.psfhosted.org>
Message-ID: <1609246719.03.0.264852718477.issue42655@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 0159e5efeebd12b3cf365c8569ca000eac7cb03e by Jakub Kul?k in branch 'master':
bpo-42655: Fix subprocess extra_groups gid conversion (GH-23762)
https://github.com/python/cpython/commit/0159e5efeebd12b3cf365c8569ca000eac7cb03e


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42655>
_______________________________________

From report at bugs.python.org  Tue Dec 29 07:59:10 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 29 Dec 2020 12:59:10 +0000
Subject: [issue42655] Fix subprocess extra_groups gid conversion
In-Reply-To: <1608113122.79.0.244683118693.issue42655@roundup.psfhosted.org>
Message-ID: <1609246750.04.0.754544029552.issue42655@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +22840
pull_request: https://github.com/python/cpython/pull/23997

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42655>
_______________________________________

From report at bugs.python.org  Tue Dec 29 08:05:56 2020
From: report at bugs.python.org (Albert Zeyer)
Date: Tue, 29 Dec 2020 13:05:56 +0000
Subject: [issue37159] Use copy_file_range() in shutil.copyfile() (server-side
 copy)
In-Reply-To: <1559712291.98.0.707685827942.issue37159@roundup.psfhosted.org>
Message-ID: <1609247156.59.0.51614595307.issue37159@roundup.psfhosted.org>


Albert Zeyer <albzey at googlemail.com> added the comment:

According to the man page of copy_file_range (https://man7.org/linux/man-pages/man2/copy_file_range.2.html), copy_file_range also should support copy-on-write:

>       copy_file_range() gives filesystems an opportunity to implement
>       "copy acceleration" techniques, such as the use of reflinks
>       (i.e., two or more inodes that share pointers to the same copy-
>       on-write disk blocks) or server-side-copy (in the case of NFS).

Is this wrong?

However, while researching more about FICLONE vs copy_file_range, I found e.g. this: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24399

Which suggests that there are other problems with copy_file_range?

----------
nosy: +Albert.Zeyer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37159>
_______________________________________

From report at bugs.python.org  Tue Dec 29 08:07:15 2020
From: report at bugs.python.org (minipython)
Date: Tue, 29 Dec 2020 13:07:15 +0000
Subject: [issue42779] pow() of huge input does not complete
In-Reply-To: <1609235390.01.0.221368482362.issue42779@roundup.psfhosted.org>
Message-ID: <1609247235.5.0.287421687627.issue42779@roundup.psfhosted.org>


minipython <599192367 at qq.com> added the comment:

Here are my information.
1.python 3.8.6
2.windows 10(build 19042 20h2)
3. 16Gb memory
4. It doesn't complete.It takes about 30 minutes but it gives no output.
5. It takes 6.346898794174194s
6. It takes 0.3690004348754883s.

----------
versions: +Python 3.8 -Python 3.6, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42779>
_______________________________________

From report at bugs.python.org  Tue Dec 29 08:17:51 2020
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 29 Dec 2020 13:17:51 +0000
Subject: [issue23328] urllib.request fails for proxy credentials that contain
 a '/' character
In-Reply-To: <1422342235.17.0.905041944591.issue23328@psf.upfronthosting.co.za>
Message-ID: <1609247871.99.0.016662671899.issue23328@roundup.psfhosted.org>


Senthil Kumaran <senthil at uthcode.com> added the comment:

Merged in 

3.10 - https://github.com/python/cpython/commit/030a713183084594659aefd77b76fe30178e23c8

3.9 - https://github.com/python/cpython/commit/df794406a8803e3d6062af8404d7564833f9af28

3.8 - https://github.com/python/cpython/commit/741f22df24ca61db38b5a7a2a58b5939b7154a01

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue23328>
_______________________________________

From report at bugs.python.org  Tue Dec 29 08:22:17 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 29 Dec 2020 13:22:17 +0000
Subject: [issue42655] Fix subprocess extra_groups gid conversion
In-Reply-To: <1608113122.79.0.244683118693.issue42655@roundup.psfhosted.org>
Message-ID: <1609248137.31.0.467746859241.issue42655@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 3966e2ea412a5f190dc8655d9aa7a15c08c4e280 by Miss Islington (bot) in branch '3.9':
bpo-42655: Fix subprocess extra_groups gid conversion (GH-23762)
https://github.com/python/cpython/commit/3966e2ea412a5f190dc8655d9aa7a15c08c4e280


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42655>
_______________________________________

From report at bugs.python.org  Tue Dec 29 08:22:59 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Dec 2020 13:22:59 +0000
Subject: [issue40956] Use Argument Clinic in sqlite3
In-Reply-To: <1591956335.72.0.553737405887.issue40956@roundup.psfhosted.org>
Message-ID: <1609248179.07.0.389357520091.issue40956@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 84d79cfda947f6bc28a5aa11db8055aa40a6b03a by Erlend Egeberg Aasland in branch 'master':
bpo-40956: Convert _sqlite3.Row to Argument Clinic (GH-23964)
https://github.com/python/cpython/commit/84d79cfda947f6bc28a5aa11db8055aa40a6b03a


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40956>
_______________________________________

From report at bugs.python.org  Tue Dec 29 08:32:18 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Dec 2020 13:32:18 +0000
Subject: [issue41224] Document is_annotate() in symtable and update doc strings
In-Reply-To: <1594082969.57.0.57546378767.issue41224@roundup.psfhosted.org>
Message-ID: <1609248738.97.0.247269245425.issue41224@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 2edfc86f69d8a74f4821974678f664ff94a9dc22 by Andre Delfino in branch 'master':
bpo-41224: Add versionadded for Symbol.is_annotated (GH-23861)
https://github.com/python/cpython/commit/2edfc86f69d8a74f4821974678f664ff94a9dc22


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41224>
_______________________________________

From report at bugs.python.org  Tue Dec 29 08:36:34 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Dec 2020 13:36:34 +0000
Subject: [issue41224] Document is_annotate() in symtable and update doc strings
In-Reply-To: <1594082969.57.0.57546378767.issue41224@roundup.psfhosted.org>
Message-ID: <1609248994.14.0.313935376076.issue41224@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The method was added in 3.6. Please backport documentation changes to 3.9 and 3.8.

----------
stage: resolved -> needs patch
status: closed -> open
versions: +Python 3.8, Python 3.9 -Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41224>
_______________________________________

From report at bugs.python.org  Tue Dec 29 08:39:51 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Dec 2020 13:39:51 +0000
Subject: [issue42700] xml.parsers.expat.errors description of codes/messages
 is flipped
In-Reply-To: <1608516708.54.0.399014748226.issue42700@roundup.psfhosted.org>
Message-ID: <1609249191.14.0.31395307158.issue42700@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for your contribution Michael.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42700>
_______________________________________

From report at bugs.python.org  Tue Dec 29 08:41:01 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Dec 2020 13:41:01 +0000
Subject: [issue42655] Fix subprocess extra_groups gid conversion
In-Reply-To: <1608113122.79.0.244683118693.issue42655@roundup.psfhosted.org>
Message-ID: <1609249261.75.0.708148107236.issue42655@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Thank you for your contribution Jakub.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42655>
_______________________________________

From report at bugs.python.org  Tue Dec 29 09:05:51 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Dec 2020 14:05:51 +0000
Subject: [issue42779] pow() of huge input does not complete
In-Reply-To: <1609235390.01.0.221368482362.issue42779@roundup.psfhosted.org>
Message-ID: <1609250751.4.0.0192581149121.issue42779@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Are you sure that this is a time of calculating pow() and not the time of calculating decimal representation of the result?

On my computer:

>>> t = time(); a = pow(c, 2**14+1); time()-t
11.957276344299316
>>> t = time(); a = pow(c, 2**15+1); time()-t
36.08853316307068
>>> t = time(); a = pow(c, 2**16+1); time()-t
107.43462753295898

The computational complexity is O((log(c)*e)**1.5). And it needs not so much memory: around 20 MB for final result, and few times more for intermediate results, so this is not matter of swapping.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42779>
_______________________________________

From report at bugs.python.org  Tue Dec 29 09:10:10 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Dec 2020 14:10:10 +0000
Subject: [issue42749] test_tcl failed on 32-bit POWER6 AIX 3.9: big int issue
 with 9223372036854775808
In-Reply-To: <1608981118.95.0.264551211038.issue42749@roundup.psfhosted.org>
Message-ID: <1609251010.37.0.504179013846.issue42749@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

test_tcl is passed: https://buildbot.python.org/all/#/builders/330/builds/228 .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42749>
_______________________________________

From report at bugs.python.org  Tue Dec 29 09:28:34 2020
From: report at bugs.python.org (Steve Stagg)
Date: Tue, 29 Dec 2020 14:28:34 +0000
Subject: [issue42717] The python interpreter crashed with
 "_enter_buffered_busy"
In-Reply-To: <1608632703.27.0.708410911987.issue42717@roundup.psfhosted.org>
Message-ID: <1609252114.43.0.819397020382.issue42717@roundup.psfhosted.org>


Steve Stagg <stestagg at gmail.com> added the comment:

It's one of those ugly multithreading issues that's really hard to reason about unfortunately.

In this case, it's not the size of the loop so much as you've discovered a way to make it very likely that the background thread is doing IO (and holding the IO lock) during shutdown.

Here's an example that reproduces the abort for me (again, it's multithreading, so you may have a different experience) with a smaller range value:

---
import sys, threading

def run():
    for i in range(100):
        sys.stderr.write(' =.= ' * 10000)

if __name__ == '__main__':
    threading.Thread(target=run, daemon=True).start()
---

The problem with daemon threads is that they get killed fairly suddenly and without much ability to correct bad state during shutdown, so any fix here would likely be around re-visiting the thread termination code as linked in the issue above.

There may be a fix possible, but it's going to be a complex thread state management fix, not just a limit on loop counts, unfortunately

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42717>
_______________________________________

From report at bugs.python.org  Tue Dec 29 09:30:30 2020
From: report at bugs.python.org (minipython)
Date: Tue, 29 Dec 2020 14:30:30 +0000
Subject: [issue42779] pow() of huge input does not complete
In-Reply-To: <1609235390.01.0.221368482362.issue42779@roundup.psfhosted.org>
Message-ID: <1609252230.05.0.356934180535.issue42779@roundup.psfhosted.org>


minipython <599192367 at qq.com> added the comment:

ohhhhhhhhhhhhh.You are right.If i directly compute the huge result without printing,it only takes 115s.Thank you very much.I'm sorry to forget noting the print function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42779>
_______________________________________

From report at bugs.python.org  Tue Dec 29 09:41:38 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 29 Dec 2020 14:41:38 +0000
Subject: [issue42779] pow() of huge input does not complete
In-Reply-To: <1609235390.01.0.221368482362.issue42779@roundup.psfhosted.org>
Message-ID: <1609252898.86.0.619231599436.issue42779@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

The computational complexity of algorithm used to convert integer to decimals is proportional to the cube of the size of the number. It is known issue. There are better algorithms (perhaps gmpy2 uses them), but they benefit only extremely large numbers, for which exact decimal form is not very useful.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42779>
_______________________________________

From report at bugs.python.org  Tue Dec 29 10:02:36 2020
From: report at bugs.python.org (Steve Stagg)
Date: Tue, 29 Dec 2020 15:02:36 +0000
Subject: [issue42763] Exposing a race in the "_warnings" resulting Python
 parser crash
In-Reply-To: <1609130399.05.0.938510382701.issue42763@roundup.psfhosted.org>
Message-ID: <1609254156.76.0.536248442472.issue42763@roundup.psfhosted.org>


Steve Stagg <stestagg at gmail.com> added the comment:

If we take your minimal example (that /sometimes/ crashes), and look at what python is doing:

import threading
t = threading.Thread(target=1, daemon=True).start()

---

The main thread does the following:

M1. Startup interpreter, parse code
M2. Import & execute threading module
M3. Create thread `T`, set target=1, set daemon=True
M4. Start thread
M5. Finalize local variables & state
M6. Terminate daemon threads
M7. Acquire IO lock to clean up IO
M8. Shutdown interpreter

Whereas the thread `T` does this:

T1. Startup
T2. Try to call target
T3. Realise that target is not callable & raise exception ('int' object is not callable)
T4. Acquire IO lock to print traceback
T5. Print traceback line 1
T6. Print traceback line n
T7. Release IO lock
T8. Shutdown thread


Now steps T1->T8 can happen *at any time* between M4 and M6.  But the moment M6 runs, the thread disappears without warning.

If the T4 step is run, then the daemon thread owns the IO lock, and must release it, but if step T7 doesn't run, then that lock is never released.

So in the case where you get a crash, the order is something like:

M1. M2. M3. M4.  T1. T2. T3. T4. T5. M5. [thread killed] M6. M7. <- Crash, because M7 can't acquire lock

But when there is no crash, the order is probably:

M1. M2. M3. M4.  T1. T2. T3. T4. T5. T6. T7. T8. M5. M6. M7. M8. <- No Crash because IO lock released in T7.

So you can see that this is the same fundamental thing as issue42717  (Where the shutdown during output was caused by spamming output repeatedly), but caused by a different route.

It might be possible to add handlers to the daemonic thread shutdown to clean up IO locks more cleanly?  But it's tricky, it seems like daemonic threads shutdown when they attempt to re-acquire the GIL after the interpreter has shutdown, so we're in pretty complex state management territory here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42763>
_______________________________________

From report at bugs.python.org  Tue Dec 29 10:08:41 2020
From: report at bugs.python.org (=?utf-8?q?W=C3=BCstengecko?=)
Date: Tue, 29 Dec 2020 15:08:41 +0000
Subject: [issue42756] smtplib.LMTP.connect() raises TypeError if `timeout` is
 not specified
In-Reply-To: <1609074713.39.0.771360640486.issue42756@roundup.psfhosted.org>
Message-ID: <1609254521.92.0.164018164557.issue42756@roundup.psfhosted.org>


W?stengecko <lemmi59612 at gmail.com> added the comment:

Hello,
I can confirm that the PR resolves the issue.
Thanks for the quick fix!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42756>
_______________________________________

From report at bugs.python.org  Tue Dec 29 10:48:41 2020
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 29 Dec 2020 15:48:41 +0000
Subject: [issue42658] os.path.normcase() is inconsistent with Windows file
 system
In-Reply-To: <1608122666.52.0.137113409131.issue42658@roundup.psfhosted.org>
Message-ID: <1609256921.73.0.993353075096.issue42658@roundup.psfhosted.org>


Eryk Sun <eryksun at gmail.com> added the comment:

> "lowercase two strings by means of LCMapStringEx() and then wcscmp
> the two" always gives the same result as "compare the two strings 
> with CompareStringOrdinal()"

For checking case-insensitive equality, it shouldn't matter whether names are converted to uppercase or lowercase when using invariant non-linguistic casing. It's based on symmetric mappings between pairs of uppercase and lowercase codes, which avoids problems such as '?' (U+03F4) and '?' (U+0398) both lowercasing as '?' (U+03B8), or '?' uppercasing as 'SS'.

That said, when sorting filenames, you need to use LCMAP_UPPERCASE in order to match the case-insensitive sort order of Windows. For example, '?' (U+0178) is greater than '?' (U+0176), but -- respectively lowercase -- '?' (U+00FF) is less than '?' (U+0177). In particular, if you have an NTFS directory with two files named '?' and '?', the listing will be ['?', '?'] -- in uppercase order. (An NTFS directory is stored on disk as a b-tree sorted by uppercase filenames.)

For the implementation, _winapi.LCMapStringEx and related constants could be added.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42658>
_______________________________________

From report at bugs.python.org  Tue Dec 29 11:06:13 2020
From: report at bugs.python.org (Steve Stagg)
Date: Tue, 29 Dec 2020 16:06:13 +0000
Subject: [issue42762] infinite loop resulted by "yield"
In-Reply-To: <1609130295.32.0.912620547313.issue42762@roundup.psfhosted.org>
Message-ID: <1609257973.35.0.0724631234108.issue42762@roundup.psfhosted.org>


Steve Stagg <stestagg at gmail.com> added the comment:

I'm sorry, I did get a bit confused earlier, I'd mentally switched to context managers.

I agree this is a bug, and a kinda weird one!

I've narrowed it down to this:

If an exception causes flow to exit a for-loop that's powered by a generator, then when the generator object is deleted, GeneratorExit() is incorrectly raised in the generator.

This can be shown with the following example (easier to debug without the infinite loop):

---
def foo():
    try:
        yield
    except:
        print("!!! WE SHOULDN'T BE HERE!!!")

x = foo()
try:
    for _ in x:
       print(i)
except NameError:
    pass 

print("LOOP DONE")
del x   # <--- We shouldn't be here printed on this line.
print("FINAL")
---

As you discovered, if you change print(i) to print(1), then the "shouldn't be here" line is NOT printed, but if you leave it as print(i) then the exception is printed.

You can see that the error doesn't happen until after LOOP DONE, which is because `del x` is finalizing the generator object, and the invalid exception logic happens then.

I'm trying to get more info here, if I don't by the time you come online, I'd recommend creating a *new* issue, with the non-loop example above, and explanation because I think on this issue, I've caused a lot of noise (sorry again!).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42762>
_______________________________________

From report at bugs.python.org  Tue Dec 29 11:43:35 2020
From: report at bugs.python.org (Steve Stagg)
Date: Tue, 29 Dec 2020 16:43:35 +0000
Subject: [issue42762] infinite loop resulted by "yield"
In-Reply-To: <1609130295.32.0.912620547313.issue42762@roundup.psfhosted.org>
Message-ID: <1609260215.52.0.149559397124.issue42762@roundup.psfhosted.org>


Steve Stagg <stestagg at gmail.com> added the comment:

Ok, so I now understand a bit more, and think it's not a bug!  But explaining it involves some fairly deep thinking about generators.

I'll try to explain my reasoning.

Let's take a simple example:

---

def foo():
    try:
        yield
    except:
        print("ERROR")

for x in foo():
    print(1)
---


It's convenient to think of it as python adding an implicit throw StopIteration() at the end of the generator function, I'll also rewrite the code to be roughly equivalent:

---
 1. def foo():
 2.     try:
 3.         yield None
 4.     except:
 5.         print("ERROR")
 6.     #throw StopIteration():
 7. 
 8. foo_gen = foo()
 9. while True:
10.     try:
11.         x = next(foo_gen)
12.    except StopIteration:
13.         break
14.    print(1)
15. del foo_gen
---

Now, if we step through how python runs the code starting at line 8.:

8. Create foo() <- this just creates a generator object
9. Enter while loop (not interesting for now)
10. try:
11. call next() on our generator to get the next value
2. try: <- we're running the generator until we get a yield now
3. yield None <- yield None to parent code
11. x = None <- assign yielded value to x
12. except StopIteration <- no exception raised so this doesn't get triggered
14. print(1) <- Print 1 to the output
9. Reached end of while loop, return to the start
10. try:
11. Re-enter the generator to get the next value, starting from where we left it..
4. except: <- there was no exception raised, so this doesn't get triggered
6. (implicit) throw StopIteration because generator finished
12. `except StopIteration` <- this is triggered because generator threw StopIteration
13. break <- break out of while loop
15. remove foo_gen variable, and clean up generator.

<- Deleting `foo_gen` causes `.close()` to be called on the generator which causes a GeneratorExit exception to be raised in the generator, BUT generator has already finished, so the GeneratorExit does nothing.

--

This is basically how the for-loop in your example works, and you can see that there's no generator exception, BUT if we change the print(1) to print(i) and try again:

8. Create foo() <- this just creates a generator object
9. Enter while loop (not interesting for now)
10. try:
11. call next() on our generator to get the next value
2. try: <- we're running the generator until we get a yield now
3. yield None <- yield None to parent code
11. x = None <- assign yielded value to x
12. except StopIteration <- no exception raised so this doesn't get triggered
*** CHANGED BIT ***
14. print(i) <- i doesn't exist, so throw NameError
14. The exception made us exit the current stack frame, so start cleaning up/deleting local variables

<- Deleting `foo_gen` causes `.close()` to be called on the generator which causes GeneratorExit() to be raised within the generator, but the generator is currently paused on line 3. so raise exception as-if we're currently running line 3:

4. except: <- this broad except catches the GeneratorExit exception because it appears to have happened on line 3.
5. print("ERROR") <- We only get here if the above steps happened.

---

So, if you don't let a generator naturally finish itself, but stop consuming the generator before it's raised its final StopIteration, then when the variable goes out-of-scope, a GeneratorExit will be raised at the point of the last yield that it ran.

If you then catch that GeneratorExit, and enter a new un-consumed loop (as in your `yield from foo()` line), then that line will also create the same situation again in a loop..

I understand that this used to "work" in previous python versions, but actually, having dug into things a lot more, I think the current behaviour is correct, and previous behaviors were not correct.

The "bug" here is in the example code that is catching GeneratorExit and then creating a new generator in the except:, rather than anything in Python

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42762>
_______________________________________

From report at bugs.python.org  Tue Dec 29 11:43:53 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 29 Dec 2020 16:43:53 +0000
Subject: [issue40052] Incorrect pointer alignment in _PyVectorcall_Function()
 of cpython/abstract.h
In-Reply-To: <1585033092.63.0.928625583781.issue40052@roundup.psfhosted.org>
Message-ID: <1609260233.05.0.52930645154.issue40052@roundup.psfhosted.org>


Change by Petr Viktorin <encukou at gmail.com>:


----------
nosy: +petr.viktorin
nosy_count: 4.0 -> 5.0
pull_requests: +22841
pull_request: https://github.com/python/cpython/pull/23999

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40052>
_______________________________________

From report at bugs.python.org  Tue Dec 29 12:05:38 2020
From: report at bugs.python.org (Albert Zeyer)
Date: Tue, 29 Dec 2020 17:05:38 +0000
Subject: [issue37157] shutil: add reflink=False to file copy functions to
 control clone/CoW copies (use copy_file_range)
In-Reply-To: <1559684200.61.0.18008315195.issue37157@roundup.psfhosted.org>
Message-ID: <1609261538.36.0.349074787495.issue37157@roundup.psfhosted.org>


Albert Zeyer <albzey at googlemail.com> added the comment:

Is FICLONE really needed? Doesn't copy_file_range already supports the same?

I posted the same question here: https://stackoverflow.com/questions/65492932/ficlone-vs-ficlonerange-vs-copy-file-range-for-copy-on-write-support

----------
nosy: +Albert.Zeyer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37157>
_______________________________________

From report at bugs.python.org  Tue Dec 29 12:18:38 2020
From: report at bugs.python.org (cptpcrd)
Date: Tue, 29 Dec 2020 17:18:38 +0000
Subject: [issue42780] os.set_inheritable() fails for O_PATH file descriptors
 on Linux
Message-ID: <1609262318.62.0.976413615492.issue42780@roundup.psfhosted.org>


New submission from cptpcrd <cptpcrd.enterprise at gmail.com>:

Note: I filed this bug report after seeing https://github.com/rust-lang/rust/pull/62425 and verifying that it was also reproducible on Python. Credit for discovering the underlying issue should go to Aleksa Sarai, and further discussion can be found there.

# Background

Linux has O_PATH file descriptors. These are file descriptors that refer to a specific path, without allowing any other kind of access to the file. They can't be used to read or write data; instead, they're intended to be used for use cases like the *at() functions. In that respect, they have similar semantics to O_SEARCH on other platforms (except that they also work on other file types, not just directories).

More information on O_PATH file descriptors can be found in open(2) (https://www.man7.org/linux/man-pages/man2/open.2.html), or in the Rust PR linked above.

# The problem

As documented in the Rust PR linked above, *no* ioctl() calls will succeed on O_PATH file descriptors (they always fail with EBADF). Since os.set_inheritable() uses ioctl(FIOCLEX)/ioctl(FIONCLEX), it will fail on O_PATH file descriptors.

This is easy to reproduce:

>>> import os
>>> a = os.open("/", os.O_RDONLY)
>>> b = os.open("/", os.O_PATH)
>>> os.set_inheritable(a, True)
>>> os.set_inheritable(b, True)  # Should succeed!
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 9] Bad file descriptor
>>>

I believe this affects all versions of Python going back to version 3.4 (where os.set_inheritable()/os.get_inheritable() were introduced).

# Possible fixes

I see two potential paths for fixing this:

1. Don't use ioctl(FIOCLEX) at all on Linux.

This is what Rust did. However, based on bpo-22258 I'm guessing there would be opposition to implementing this strategy in Python, on the grounds that the fcntl() route takes an extra syscall (which is fair).

2. On Linux, fall back on fcntl() if ioctl(FIOCLEX) fails with EBADF.

This could be a very simple patch to Python/fileutils.c. I've attached a basic version of said patch (not sure if it matches standard coding conventions).

Downsides: This would add 2 extra syscalls for O_PATH file descriptors, and 1 extra syscall for actual cases of invalid file descriptors (i.e. EBADF). However, I believe these are edge cases that shouldn't come up frequently.

----------
files: set-inheritable-o-path.patch
keywords: patch
messages: 384016
nosy: cptpcrd
priority: normal
severity: normal
status: open
title: os.set_inheritable() fails for O_PATH file descriptors on Linux
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file49706/set-inheritable-o-path.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42780>
_______________________________________

From report at bugs.python.org  Tue Dec 29 12:34:32 2020
From: report at bugs.python.org (Ken Jin)
Date: Tue, 29 Dec 2020 17:34:32 +0000
Subject: [issue41559] Add support for PEP 612 (Parameter Specification
 Variables) to typing.py
In-Reply-To: <1597516564.62.0.520187732663.issue41559@roundup.psfhosted.org>
Message-ID: <1609263272.44.0.369177428717.issue41559@roundup.psfhosted.org>


Change by Ken Jin <kenjin4096 at gmail.com>:


----------
pull_requests: +22842
pull_request: https://github.com/python/cpython/pull/24000

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41559>
_______________________________________

From report at bugs.python.org  Tue Dec 29 12:55:45 2020
From: report at bugs.python.org (Jurjen N.E. Bos)
Date: Tue, 29 Dec 2020 17:55:45 +0000
Subject: [issue42673] Optimize round_size for rehashing
In-Reply-To: <1609245723.08.0.220427801204.issue42673@roundup.psfhosted.org>
Message-ID: <CAAxmQtfujeB4Vjfns-PJ2k7T_WkWNoePiuFyWncDpUGMM6rDRw@mail.gmail.com>


Jurjen N.E. Bos <jneb at users.sourceforge.net> added the comment:

Harsh, but fair.
I'll do a better job next time!

Op di 29 dec. 2020 13:42 schreef Serhiy Storchaka <report at bugs.python.org>:

>
> Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:
>
> Since no benchmarking data was provided, I suggest to close this issue. We
> do not accept optimization changes without evidences of performance boost.
>
> ----------
> status: open -> pending
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <https://bugs.python.org/issue42673>
> _______________________________________
>

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42673>
_______________________________________

From report at bugs.python.org  Tue Dec 29 13:05:10 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 29 Dec 2020 18:05:10 +0000
Subject: [issue42762] infinite loop resulted by "yield"
In-Reply-To: <1609130295.32.0.912620547313.issue42762@roundup.psfhosted.org>
Message-ID: <1609265110.02.0.399651133934.issue42762@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Even weirder, the old behavior returns if "except:" is replaced by "except BaseException as e:".

============================
def foo():
    try:
        yield
    except BaseException as e:
        yield from foo()

for m in foo():
    print(i)

----------
nosy: +Mark.Shannon, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42762>
_______________________________________

From report at bugs.python.org  Tue Dec 29 13:12:58 2020
From: report at bugs.python.org (Luciano Ramalho)
Date: Tue, 29 Dec 2020 18:12:58 +0000
Subject: [issue42781] functools.cached_property docs should explain that it is
 non-overriding
Message-ID: <1609265578.67.0.475985633003.issue42781@roundup.psfhosted.org>


New submission from Luciano Ramalho <luciano at ramalho.org>:

functools.cached_property is a great addition to the standard library, thanks!

However, the docs do not say that @cached_property produces a non-overriding descriptor, in contrast with @property.

If a user replaces a @property with a @cached_property, her code may or may not break depending on the existence of an instance attribute with the same name as the decorated method. This is surprising and may affect correctness, so it deserves even more attention than the possible performance loss already mentioned in the docs, related to the shared-dict optimization.

In the future, perhaps we can add an argument to @cached_property to optionally make it produce overriding descriptors.

----------
assignee: docs at python
components: Documentation
messages: 384019
nosy: docs at python, ramalho
priority: normal
severity: normal
status: open
title: functools.cached_property docs should explain that it is non-overriding
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42781>
_______________________________________

From report at bugs.python.org  Tue Dec 29 13:32:24 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 29 Dec 2020 18:32:24 +0000
Subject: [issue42775] __init_subclass__ should be called in __init__
In-Reply-To: <1609211209.61.0.873859112725.issue42775@roundup.psfhosted.org>
Message-ID: <1609266744.65.0.687897690621.issue42775@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

I see this as a backwards incompatible change and it's not worth doing for what seems to me a very minor benefit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42775>
_______________________________________

From report at bugs.python.org  Tue Dec 29 13:38:15 2020
From: report at bugs.python.org (Winson Luk)
Date: Tue, 29 Dec 2020 18:38:15 +0000
Subject: [issue42782] shutil.move creates a new directory even on failure
Message-ID: <1609267095.96.0.244357223295.issue42782@roundup.psfhosted.org>


Change by Winson Luk <winson at luk.cc>:


----------
components: Library (Lib)
nosy: winsonluk
priority: normal
severity: normal
status: open
title: shutil.move creates a new directory even on failure
type: behavior
versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42782>
_______________________________________

From report at bugs.python.org  Tue Dec 29 13:39:41 2020
From: report at bugs.python.org (Winson Luk)
Date: Tue, 29 Dec 2020 18:39:41 +0000
Subject: [issue42782] shutil.move creates a new directory even on failure
Message-ID: <1609267181.59.0.228763185139.issue42782@roundup.psfhosted.org>


Change by Winson Luk <winson at luk.cc>:


----------
keywords: +patch
pull_requests: +22843
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24001

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42782>
_______________________________________

From report at bugs.python.org  Tue Dec 29 13:42:56 2020
From: report at bugs.python.org (Winson Luk)
Date: Tue, 29 Dec 2020 18:42:56 +0000
Subject: [issue42782] shutil.move creates a new directory even on failure
Message-ID: <1609267376.56.0.274024517588.issue42782@roundup.psfhosted.org>


New submission from Winson Luk <winson at luk.cc>:

shutil.move calls shutil.copytree(), then os.rmtree() (in that order). If the user does not have permission to delete the source directory, copytree succeeds but rmtree fails. The user sees an error (Permission Denied), but the destination directory is still created. The expected behavior should be a Permission Denied without the creation of the destination directory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42782>
_______________________________________

From report at bugs.python.org  Tue Dec 29 13:51:40 2020
From: report at bugs.python.org (E. Paine)
Date: Tue, 29 Dec 2020 18:51:40 +0000
Subject: [issue42560] Improve Tkinter Documentation
In-Reply-To: <1607020537.02.0.420924180434.issue42560@roundup.psfhosted.org>
Message-ID: <1609267900.86.0.877712538717.issue42560@roundup.psfhosted.org>


E. Paine <paineelisha at gmail.com> added the comment:

> shouldn't the docs be made available for the currently maintained version of python?

Problem is the Tk version (which underpins tkinter) varies by distribution. Currently, Windows and MacOS Intel installers are packaged with 8.6.8, while MacOS Universal2 is soon to be packaged with a head later than 8.6.10. The situation gets worse on Linux, where different distros provide very different versions (CentOS 7, for example, runs Tk 8.5.13 which was released back in 2012). As the available options vary by version, we face an issue of what we actually describe in the docs.

As a side note, Shipman's docs are now also hosted at tkdocs.com/shipman, a site maintained by Mark Roseman, which should be more reliable than a github.io page (see issue37149 - he will also handle any copyright claims, etc. that may arise that meant we couldn't host it on docs.python.org).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42560>
_______________________________________

From report at bugs.python.org  Tue Dec 29 13:53:22 2020
From: report at bugs.python.org (Winson Luk)
Date: Tue, 29 Dec 2020 18:53:22 +0000
Subject: [issue42782] shutil.move creates a new directory even on failure
In-Reply-To: <1609267376.56.0.274024517588.issue42782@roundup.psfhosted.org>
Message-ID: <1609268002.56.0.501688503859.issue42782@roundup.psfhosted.org>


Winson Luk <winson at luk.cc> added the comment:

To replicate:

$ mkdir foo
$ sudo chown root foo
$ sudo touch foo/child
$ python3
>>> import shutil
>>> shutil.move('foo', 'bar')
PermissionError
$ ls foo
child
$ ls bar
child

If shutil.move() encountered a permission error and failed, bar should not have been created.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42782>
_______________________________________

From report at bugs.python.org  Tue Dec 29 14:09:02 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 29 Dec 2020 19:09:02 +0000
Subject: [issue42781] functools.cached_property docs should explain that it is
 non-overriding
In-Reply-To: <1609265578.67.0.475985633003.issue42781@roundup.psfhosted.org>
Message-ID: <1609268942.43.0.848071696893.issue42781@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

FYI, the usual term is "data descriptor" instead of "overriding descriptor".

Normally the docs for things like property() and cached_property() don't mention the term descriptor at all.  From the user point of view, that is an implementation detail.  What is important is what it does and how to use it.

In the case of cached_property(), the docs do a pretty good job, "Transform a method of a class into a property whose value is computed once and then cached as a normal attribute for the life of the instance."

>From a user point of view, that is exactly what happens.  The method is called exactly once.  The result is cached in an attribute and it behaves like a normal attribute for the remaining life (effectively, the descriptor is gone.

I would suggest a small amendment, and say "cached as a normal attribute with the same name".   The choice of attribute isn't arbitrary, it is exactly the same as the cached property.

> In the future, perhaps we can add an argument to @cached_property
> to optionally make it produce overriding descriptors.

That doesn't make any sense to me.  It would defeat the entire mechanism for cached_property().

> If a user replaces a @property with a @cached_property, her 
> code may or may not break depending on the existence of an 
> instance attribute with the same name as the decorated method. 

We've never had a report of an issue like this and I don't expect to see over.  In general, if someone is using property(), it is already a bit challenging to store and retrieve attributes that have the same name as the property.

I think it is sufficient to just state that cached_property() uses the attribute with the same name as the property.  That way, it won't be a "surprise" that attribute with the same name gets used :-)

One other possible addition is to note that the attribute is writeable:

class A:
    @cached_property
    def x(self):
        print('!')
        return 42

>>> a = A()
>>> vars(a)           # Initially, there is no instance variable
{}
>>> a.x               # Method is called
!
42
>>> vars(a)           # Data is stored in the instance variable
{'x': 42}
>>> a.x               # Method is not called again
42  
>>> a.x = 10          # Attribue is writeable
>>> vars(a)
{'x': 10}
>>> a.x
10

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42781>
_______________________________________

From report at bugs.python.org  Tue Dec 29 14:40:26 2020
From: report at bugs.python.org (Simon Willison)
Date: Tue, 29 Dec 2020 19:40:26 +0000
Subject: [issue42783] asyncio.sleep(0) idiom is not documented
Message-ID: <1609270826.19.0.331548885122.issue42783@roundup.psfhosted.org>


New submission from Simon Willison <swillison at gmail.com>:

asyncio.sleep(0) is the recommended idiom for co-operatively yielding control of the event loop to another task: https://github.com/python/asyncio/issues/284 and https://til.simonwillison.net/python/yielding-in-asyncio

This isn't currently explained in the documentation.

----------
assignee: docs at python
components: Documentation, asyncio
messages: 384025
nosy: asvetlov, docs at python, simonw, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.sleep(0) idiom is not documented
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42783>
_______________________________________

From report at bugs.python.org  Tue Dec 29 14:44:24 2020
From: report at bugs.python.org (Simon Willison)
Date: Tue, 29 Dec 2020 19:44:24 +0000
Subject: [issue42783] asyncio.sleep(0) idiom is not documented
In-Reply-To: <1609270826.19.0.331548885122.issue42783@roundup.psfhosted.org>
Message-ID: <1609271064.2.0.949076836863.issue42783@roundup.psfhosted.org>


Change by Simon Willison <swillison at gmail.com>:


----------
keywords: +patch
pull_requests: +22845
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24002

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42783>
_______________________________________

From report at bugs.python.org  Tue Dec 29 14:49:18 2020
From: report at bugs.python.org (Anton Abrosimov)
Date: Tue, 29 Dec 2020 19:49:18 +0000
Subject: [issue42742] Add abc.Mapping to dataclass
In-Reply-To: <1608913963.27.0.877253757924.issue42742@roundup.psfhosted.org>
Message-ID: <1609271358.1.0.419123492935.issue42742@roundup.psfhosted.org>


Anton Abrosimov <abrosimov.a.a at gmail.com> added the comment:

Link to python-ideas thread:
https://mail.python.org/archives/list/python-ideas at python.org/thread/XNXCUJVNOOVPAPL6LF627EOCBUUUX2DG/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42742>
_______________________________________

From report at bugs.python.org  Tue Dec 29 15:08:52 2020
From: report at bugs.python.org (Steve Stagg)
Date: Tue, 29 Dec 2020 20:08:52 +0000
Subject: [issue42762] infinite loop resulted by "yield"
In-Reply-To: <1609130295.32.0.912620547313.issue42762@roundup.psfhosted.org>
Message-ID: <1609272532.19.0.527411087176.issue42762@roundup.psfhosted.org>


Steve Stagg <stestagg at gmail.com> added the comment:

That /is/ weird.  I tried a few variations, and it looks like something is being stored on the exception that is stopping the loop behaviour.

"except BaseException:"      <- infinite loop
"except BaseException as e:" <- NO loop
"except BaseException as e:
   del e
   yield from foo()"         <- infinite loop

So is this a reference being retained somewhere?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42762>
_______________________________________

From report at bugs.python.org  Tue Dec 29 15:17:09 2020
From: report at bugs.python.org (Steve Stagg)
Date: Tue, 29 Dec 2020 20:17:09 +0000
Subject: [issue42762] infinite loop resulted by "yield"
In-Reply-To: <1609130295.32.0.912620547313.issue42762@roundup.psfhosted.org>
Message-ID: <1609273029.2.0.635791762506.issue42762@roundup.psfhosted.org>


Steve Stagg <stestagg at gmail.com> added the comment:

(sorry for spam!)

So, this is a retained reference issue.
If I change the script to be this:


---
import gc

DEPTH = 100

def foo():
    global DEPTH
    try:
        yield
    except BaseException as e:
        DEPTH -= 1
        if DEPTH < 1:
            return
        gc.collect()
        yield from foo()


def x():
    for m in foo():
        print(i)

try:
    x()
except:
    pass


ges = [o for o in gc.get_objects() if isinstance(o, GeneratorExit)]
if ges:
    ge, = ges
    print(gc.get_referrers(ge))
---

Then there's a reference to the GeneratorExit being retained (I guess from the exception frames, althought I thought exception frames were cleared up these days?):

[[GeneratorExit()], {'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__': <_frozen_importlib_external.SourceFileLoader object at 0x7fac8899ceb0>, '__spec__': None, '__annotations__': {}, '__builtins__': <module 'builtins' (built-in)>, '__file__': '/home/sstagg/tmp/fuzztest/tx.py', '__cached__': None, 'gc': <module 'gc' (built-in)>, 'DEPTH': 99, 'foo': <function foo at 0x7fac887dc5e0>, 'x': <function x at 0x7fac887dc700>, 'ges': [GeneratorExit()], 'ge': GeneratorExit()}, <frame at 0x7fac8894d400, file '/home/sstagg/tmp/fuzztest/tx.py', line 14, code foo>]
Exception ignored in: <generator object foo at 0x7fac88851740>
RuntimeError: generator ignored GeneratorExit.

Given the infinite loop happens during the finalization of the generator, I think this reference is stopping the loop from going forever.

I tried removing the "as e" from the above script, and no references are retained.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42762>
_______________________________________

From report at bugs.python.org  Tue Dec 29 15:34:08 2020
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 29 Dec 2020 20:34:08 +0000
Subject: [issue42780] os.set_inheritable() fails for O_PATH file descriptors
 on Linux
In-Reply-To: <1609262318.62.0.976413615492.issue42780@roundup.psfhosted.org>
Message-ID: <1609274048.92.0.977107745802.issue42780@roundup.psfhosted.org>


Change by Alexey Izbyshev <izbyshev at ispras.ru>:


----------
components: +Library (Lib)
nosy: +vstinner
versions:  -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42780>
_______________________________________

From report at bugs.python.org  Tue Dec 29 16:30:18 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 29 Dec 2020 21:30:18 +0000
Subject: [issue42780] os.set_inheritable() fails for O_PATH file descriptors
 on Linux
In-Reply-To: <1609262318.62.0.976413615492.issue42780@roundup.psfhosted.org>
Message-ID: <1609277418.19.0.55908149807.issue42780@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

Doing two syscalls does not seem so bad.

Linux may allow FIOCLEX on O_PATH in the future.

----------
nosy: +benjamin.peterson
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42780>
_______________________________________

From report at bugs.python.org  Tue Dec 29 16:59:46 2020
From: report at bugs.python.org (=?utf-8?q?Filipe_La=C3=ADns?=)
Date: Tue, 29 Dec 2020 21:59:46 +0000
Subject: [issue42773] build.yml workflow not testing on pushes
In-Reply-To: <1609194687.05.0.86275810312.issue42773@roundup.psfhosted.org>
Message-ID: <1609279186.72.0.962169433025.issue42773@roundup.psfhosted.org>


Change by Filipe La?ns <lains at riseup.net>:


----------
keywords: +patch
pull_requests: +22846
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24004

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42773>
_______________________________________

From report at bugs.python.org  Tue Dec 29 17:00:51 2020
From: report at bugs.python.org (=?utf-8?q?Filipe_La=C3=ADns?=)
Date: Tue, 29 Dec 2020 22:00:51 +0000
Subject: [issue42773] build.yml workflow not testing on pushes
In-Reply-To: <1609194687.05.0.86275810312.issue42773@roundup.psfhosted.org>
Message-ID: <1609279251.92.0.884564734559.issue42773@roundup.psfhosted.org>


Filipe La?ns <lains at riseup.net> added the comment:

This is due to a typo, I commented on the original PR and opened a PR fixing it. Cheers :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42773>
_______________________________________

From report at bugs.python.org  Tue Dec 29 17:32:47 2020
From: report at bugs.python.org (FredInChina)
Date: Tue, 29 Dec 2020 22:32:47 +0000
Subject: [issue42560] Improve Tkinter Documentation
In-Reply-To: <1607020537.02.0.420924180434.issue42560@roundup.psfhosted.org>
Message-ID: <1609281167.84.0.851075846752.issue42560@roundup.psfhosted.org>


FredInChina <trustgold at gmail.com> added the comment:

Ah, I understand now, thank you for the clear explanation @epaine, appreciated. Thanks also for the link to Pr. Shipman's docs mirror on tkdocs.

It is not my place to argue what to do in such a case, but please allow me to re-emphasize the need for better tkinter documentation. It would, of course be imperfect, but not out of place to offer docs for the latest version of python, and the latest stable version of Tk? Even those that still have to rely on a previous version would surely find it useful.

Thank you for listening.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42560>
_______________________________________

From report at bugs.python.org  Tue Dec 29 17:36:32 2020
From: report at bugs.python.org (Luciano Ramalho)
Date: Tue, 29 Dec 2020 22:36:32 +0000
Subject: [issue42781] functools.cached_property docs should explain that it is
 non-overriding
In-Reply-To: <1609265578.67.0.475985633003.issue42781@roundup.psfhosted.org>
Message-ID: <1609281392.72.0.971821260772.issue42781@roundup.psfhosted.org>


Luciano Ramalho <luciano at ramalho.org> added the comment:

> FYI, the usual term is "data descriptor" instead of "overriding descriptor".

Yes, the Python docs are consistent in always using "data descriptor", but I've adopted "overriding descriptor" from Martelli's Python in a Nutshell--in Fluent Python I also put a note saying that "data descriptor" is used in the docs. I think "overriding descriptor" is more descriptive. In particular, I find "non-data descriptor" quite puzzling. But this issue is not about changing the jargon.

> Normally the docs for things like property() and cached_property()
> don't mention the term descriptor at all.  From the user point of
> view, that is an implementation detail.

I'd agree, if I wasn't personally bitten by the issue I reported. I was refactoring an existing class which had hand-made caches in a couple of methods decorated with @property. When I discovered @cached_property, I tried to simplify my code by using it, and it broke my code in one place, but not in the other. Leonardo Rochael had experience with cached_property and told me about the difference.

I suggest a warning noting the different behavior regarding existing instance attributes. The warning doesn't need to assume the user knows what is a descriptor, but it should in my opinion point to your excellent Descriptor HowTo Guide for more information.

> I would suggest a small amendment, and say "cached as a normal attribute with the same name". The choice of attribute isn't arbitrary, it is exactly the same as the cached property.

That's good too.

>> In the future, perhaps we can add an argument to @cached_property
>> to optionally make it produce overriding descriptors.

> That doesn't make any sense to me.  It would defeat the entire mechanism for cached_property().

My idea would be to add a dummy __set__ method if the overriding option was True (default would be False). The method could raise an exception. But its presence would make @cached_property behave more like @property in the most common use case of @property: as an overriding descriptor emulating a read-only attribute.

>> If a user replaces a @property with a @cached_property, her 
>> code may or may not break depending on the existence of an 
>> instance attribute with the same name as the decorated method. 

> We've never had a report of an issue like this and I don't expect to see over.

You just did ;-). I filed this issue after spending hours trying to figure out what the problem was in my code on my second attempt at using @cached_property. I expected @cached_property would work as a drop-in replacement for @property when emulating a read-only attribute, and it did not.

> One other possible addition is to note that the attribute is writeable:

Yes, the code snippet you suggested is a good way of saying "this produces a non-overriding descriptor". 

However we want to say it, I think it is important to contrast the behavior of @cached_property v. @property regarding the presence of attributes with the same name.

Cheers and a happy 2021 with two doses of vaccine for you and your loved ones, Raymond!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42781>
_______________________________________

From report at bugs.python.org  Tue Dec 29 18:32:19 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 29 Dec 2020 23:32:19 +0000
Subject: [issue40052] Incorrect pointer alignment in _PyVectorcall_Function()
 of cpython/abstract.h
In-Reply-To: <1585033092.63.0.928625583781.issue40052@roundup.psfhosted.org>
Message-ID: <1609284739.59.0.342734345784.issue40052@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 056c08211b402b4dbc1530a9de9d00ad5309909f by Petr Viktorin in branch 'master':
bpo-40052: Fix alignment issue in PyVectorcall_Function() (GH-23999)
https://github.com/python/cpython/commit/056c08211b402b4dbc1530a9de9d00ad5309909f


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40052>
_______________________________________

From report at bugs.python.org  Tue Dec 29 18:32:25 2020
From: report at bugs.python.org (miss-islington)
Date: Tue, 29 Dec 2020 23:32:25 +0000
Subject: [issue40052] Incorrect pointer alignment in _PyVectorcall_Function()
 of cpython/abstract.h
In-Reply-To: <1585033092.63.0.928625583781.issue40052@roundup.psfhosted.org>
Message-ID: <1609284745.2.0.995609316659.issue40052@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22847
pull_request: https://github.com/python/cpython/pull/24005

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40052>
_______________________________________

From report at bugs.python.org  Tue Dec 29 18:54:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Dec 2020 23:54:57 +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: <1609286097.57.0.378195888118.issue27640@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


Added file: https://bugs.python.org/file49707/pr23886_files.diff

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27640>
_______________________________________

From report at bugs.python.org  Tue Dec 29 18:55:14 2020
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 29 Dec 2020 23:55:14 +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: <1609286114.68.0.387697588463.issue27640@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

pr23886_files.diff: see https://github.com/python/cpython/pull/23886#issuecomment-752279731

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27640>
_______________________________________

From report at bugs.python.org  Tue Dec 29 19:53:25 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 30 Dec 2020 00:53:25 +0000
Subject: [issue42781] functools.cached_property docs should explain that it is
 non-overriding
In-Reply-To: <1609265578.67.0.475985633003.issue42781@roundup.psfhosted.org>
Message-ID: <1609289605.47.0.426659476137.issue42781@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy:  -rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42781>
_______________________________________

From report at bugs.python.org  Tue Dec 29 19:54:44 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Dec 2020 00:54:44 +0000
Subject: [issue42780] os.set_inheritable() fails for O_PATH file descriptors
 on Linux
In-Reply-To: <1609262318.62.0.976413615492.issue42780@roundup.psfhosted.org>
Message-ID: <1609289684.75.0.939001888268.issue42780@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> 2. On Linux, fall back on fcntl() if ioctl(FIOCLEX) fails with EBADF.

I like this approach!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42780>
_______________________________________

From report at bugs.python.org  Tue Dec 29 19:56:35 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Dec 2020 00:56:35 +0000
Subject: [issue40137] TODO list when PEP 573 "Module State Access from C
 Extension Methods" will be implemented
In-Reply-To: <1585753703.83.0.0762180613721.issue40137@roundup.psfhosted.org>
Message-ID: <1609289795.49.0.257426423712.issue40137@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

The following commit introduces a reference leak:

commit dd39123970892733c317f235808638ae5c0ccf04
Author: Hai Shi <shihai1992 at gmail.com>
Date:   Tue Dec 29 20:45:07 2020 +0800

    bpo-40137: Convert _functools module to use PyType_FromModuleAndSpec. (GH-23405)

 Lib/test/test_functools.py                         |   3 +-
 .../2020-11-19-23-12-57.bpo-40137.bihl9O.rst       |   1 +
 Modules/_functoolsmodule.c                         | 475 +++++++++++----------
 3 files changed, 255 insertions(+), 224 deletions(-)
 create mode 100644 Misc/NEWS.d/next/Core and Builtins/2020-11-19-23-12-57.bpo-40137.bihl9O.rst


Leaks:

test_interpreters leaked [2038, 2034, 2038] references, sum=6110
test_threading leaked [452, 452, 452] references, sum=1356
test_capi leaked [452, 452, 452] references, sum=1356
test__xxsubinterpreters leaked [6332, 6328, 6332] references, sum=18992
test_ast leaked [226, 226, 226] references, sum=678

https://buildbot.python.org/all/#/builders/129/builds/144

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40137>
_______________________________________

From report at bugs.python.org  Tue Dec 29 20:01:51 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Dec 2020 01:01:51 +0000
Subject: [issue40137] TODO list when PEP 573 "Module State Access from C
 Extension Methods" will be implemented
In-Reply-To: <1585753703.83.0.0762180613721.issue40137@roundup.psfhosted.org>
Message-ID: <1609290111.44.0.820428832417.issue40137@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
pull_requests: +22848
pull_request: https://github.com/python/cpython/pull/24006

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40137>
_______________________________________

From report at bugs.python.org  Tue Dec 29 20:03:37 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Dec 2020 01:03:37 +0000
Subject: [issue40137] TODO list when PEP 573 "Module State Access from C
 Extension Methods" will be implemented
In-Reply-To: <1585753703.83.0.0762180613721.issue40137@roundup.psfhosted.org>
Message-ID: <1609290217.32.0.555173377807.issue40137@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I wrote PR 24006 to fix the leak.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40137>
_______________________________________

From report at bugs.python.org  Tue Dec 29 20:05:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Dec 2020 01:05:10 +0000
Subject: [issue42749] test_tcl failed on 32-bit POWER6 AIX 3.9: big int issue
 with 9223372036854775808
In-Reply-To: <1608981118.95.0.264551211038.issue42749@roundup.psfhosted.org>
Message-ID: <1609290310.62.0.260599543102.issue42749@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

I confirm that test_tcl pass again on POWER6 AIX 3.9. Thanks Serhiy for the fix!

I checked the following build: https://buildbot.python.org/all/#/builders/330/builds/229

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42749>
_______________________________________

From report at bugs.python.org  Tue Dec 29 20:06:37 2020
From: report at bugs.python.org (Paulo Henrique Silva)
Date: Wed, 30 Dec 2020 01:06:37 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1609290397.83.0.526054768096.issue1635741@roundup.psfhosted.org>


Paulo Henrique Silva <ph.silva at gmail.com> added the comment:

Repeated msg355187 testing on master[056c08211b].

---
#include <Python.h>

void func()
{
    Py_Initialize(); Py_Finalize();
    Py_ssize_t cnt = _Py_GetRefTotal();
    printf("sys.gettotalrefcount(): %zd\n", cnt);
}

int main(int argc, char *argv[])
{
    Py_SetProgramName(L"./_testembed");
    for (int i=0; i < 10; i++) {
        func();
    }
}
---

No refs leaking anymore!?

---
sys.gettotalrefcount(): 10241
sys.gettotalrefcount(): 10241
sys.gettotalrefcount(): 10241
sys.gettotalrefcount(): 10241
sys.gettotalrefcount(): 10241
sys.gettotalrefcount(): 10241
sys.gettotalrefcount(): 10241
sys.gettotalrefcount(): 10241
sys.gettotalrefcount(): 10241
sys.gettotalrefcount(): 10241

---

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Tue Dec 29 20:10:10 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Dec 2020 01:10:10 +0000
Subject: [issue42747] Remove Py_TPFLAGS_HAVE_VERSION_TAG flag?
In-Reply-To: <1608940087.88.0.458230907712.issue42747@roundup.psfhosted.org>
Message-ID: <1609290610.57.0.299681996831.issue42747@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Serhiy Storchaka:
> I don't think that it was right thing to break binary compatibility. It virtually buried the stable ABI.

IMO there is a misunderstanding about the stable ABI. PyType_FromSpec() doesn't need Py_TPFLAGS_HAVE_xxx flags: this function allocates a heap type which *has* all these members (set to 0/NULL by default).

And it's not possible to define a static type using the limited C API, since the PyTypeObject structure is excluded from it on purpose.

See bpo-32388 for a similar discussion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42747>
_______________________________________

From report at bugs.python.org  Tue Dec 29 20:22:42 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Dec 2020 01:22:42 +0000
Subject: [issue42747] Remove Py_TPFLAGS_HAVE_VERSION_TAG flag?
In-Reply-To: <1608940087.88.0.458230907712.issue42747@roundup.psfhosted.org>
Message-ID: <1609291362.45.0.874980425144.issue42747@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Ah, I see that there is a misunderstanding. The flag is used for two things:

(*) Create/Declare a type

IMO Py_TPFLAGS_HAVE_VERSION_TAG and Py_TPFLAGS_HAVE_FINALIZE are useless for that.

(*) Check if a type has the flag

An extension built with the stable ABI *can* use PyType_HasFeature(type, Py_TPFLAGS_HAVE_VERSION_TAG).

I'm only aware of PyQt which uses the stable ABI. Is there other projects using it? Do these projects check for Py_TPFLAGS_HAVE_VERSION_TAG or Py_TPFLAGS_HAVE_FINALIZE flag?

If we cannot be used that no extension module built with the stable ABI for these flags, the safe option is to keep them, deprecate them, and always define them. For example, add the flags to Py_TPFLAGS_DEFAULT and/or add them in type_new() or PyType_Ready().

--

Py_TPFLAGS_HAVE_VERSION_TAG is really an internal tag. It should only be used by _PyType_Lookup().

I'm not sure why someone would like to check explicitly for the Py_TPFLAGS_HAVE_FINALIZE flag. I would expect that only Python internals call the tp_finalize slot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42747>
_______________________________________

From report at bugs.python.org  Tue Dec 29 20:24:06 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Dec 2020 01:24:06 +0000
Subject: [issue1635741] Py_Finalize() doesn't clear all Python objects at exit
Message-ID: <1609291446.54.0.612971774154.issue1635741@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> No refs leaking anymore!?

Well, there is another test:

$ ./python -X showrefcount -c pass
[23547 refs, 6589 blocks]

Python still leaks 23547 refs at exit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue1635741>
_______________________________________

From report at bugs.python.org  Tue Dec 29 20:24:54 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Dec 2020 01:24:54 +0000
Subject: [issue40137] TODO list when PEP 573 "Module State Access from C
 Extension Methods" will be implemented
In-Reply-To: <1585753703.83.0.0762180613721.issue40137@roundup.psfhosted.org>
Message-ID: <1609291494.45.0.415727548705.issue40137@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset ba0e49a4648e727d1a16b3ce479499eb39f22311 by Victor Stinner in branch 'master':
bpo-40137: Fix refleak in _functools_exec() (GH-24006)
https://github.com/python/cpython/commit/ba0e49a4648e727d1a16b3ce479499eb39f22311


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40137>
_______________________________________

From report at bugs.python.org  Tue Dec 29 21:12:31 2020
From: report at bugs.python.org (cptpcrd)
Date: Wed, 30 Dec 2020 02:12:31 +0000
Subject: [issue42780] os.set_inheritable() fails for O_PATH file descriptors
 on Linux
In-Reply-To: <1609262318.62.0.976413615492.issue42780@roundup.psfhosted.org>
Message-ID: <1609294351.13.0.804871982208.issue42780@roundup.psfhosted.org>


cptpcrd <cptpcrd.enterprise at gmail.com> added the comment:

> I like this approach!

Should I put together unit tests to go with the patch? Maybe `test_os.FDInheritanceTests.test_set_inheritable_o_path()`?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42780>
_______________________________________

From report at bugs.python.org  Tue Dec 29 21:29:52 2020
From: report at bugs.python.org (Xinmeng Xia)
Date: Wed, 30 Dec 2020 02:29:52 +0000
Subject: [issue42717] The python interpreter crashed with
 "_enter_buffered_busy"
In-Reply-To: <1608632703.27.0.708410911987.issue42717@roundup.psfhosted.org>
Message-ID: <1609295392.52.0.763905203274.issue42717@roundup.psfhosted.org>


Xinmeng Xia <xiaxm at smail.nju.edu.cn> added the comment:

Thank you for your patient reply. I see now. Hoping that some one can figure out a good idea to fix this problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42717>
_______________________________________

From report at bugs.python.org  Tue Dec 29 21:42:06 2020
From: report at bugs.python.org (Xinmeng Xia)
Date: Wed, 30 Dec 2020 02:42:06 +0000
Subject: [issue42763] Exposing a race in the "_warnings" resulting Python
 parser crash
In-Reply-To: <1609130399.05.0.938510382701.issue42763@roundup.psfhosted.org>
Message-ID: <1609296126.3.0.484626946372.issue42763@roundup.psfhosted.org>


Xinmeng Xia <xiaxm at smail.nju.edu.cn> added the comment:

Now I see. By the way, I think this case should be moved back to "cpython/Lib/test/crashers/" since the bug still exists.  It is not fixed completely, the old case is outdated. I suggest we can put the new case into directory "crashers".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42763>
_______________________________________

From report at bugs.python.org  Tue Dec 29 22:57:05 2020
From: report at bugs.python.org (hai shi)
Date: Wed, 30 Dec 2020 03:57:05 +0000
Subject: [issue40137] TODO list when PEP 573 "Module State Access from C
 Extension Methods" will be implemented
In-Reply-To: <1585753703.83.0.0762180613721.issue40137@roundup.psfhosted.org>
Message-ID: <1609300625.36.0.314081616547.issue40137@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

> I wrote PR 24006 to fix the leak.
Oh, thanks for your fix, victor.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40137>
_______________________________________

From report at bugs.python.org  Tue Dec 29 23:30:55 2020
From: report at bugs.python.org (hai shi)
Date: Wed, 30 Dec 2020 04:30:55 +0000
Subject: [issue40137] TODO list when PEP 573 "Module State Access from C
 Extension Methods" will be implemented
In-Reply-To: <1585753703.83.0.0762180613721.issue40137@roundup.psfhosted.org>
Message-ID: <1609302655.98.0.33431037705.issue40137@roundup.psfhosted.org>


hai shi <shihai1991 at 126.com> added the comment:

After PR 23405 and PR 24006 merged, I think this bpo can be closed.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40137>
_______________________________________

From report at bugs.python.org  Wed Dec 30 02:44:25 2020
From: report at bugs.python.org (Big Boss)
Date: Wed, 30 Dec 2020 07:44:25 +0000
Subject: [issue42784] issues with object.h includes
Message-ID: <1609314265.69.0.183951284891.issue42784@roundup.psfhosted.org>


New submission from Big Boss <bigbossbro08 at gmail.com>:

using #include <object.h> in header files is known to cause conflict with other projects using similar <object.h> header file. Best workaround should be renaming to <pyobject.h>. Probably better to do the same thing to other header files as well. Or wrap it around with a folder. Like <utils/object.h>

----------
components: C API
messages: 384050
nosy: bigbossbro08
priority: normal
severity: normal
status: open
title: issues with object.h includes
type: compile error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42784>
_______________________________________

From report at bugs.python.org  Wed Dec 30 03:50:07 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Wed, 30 Dec 2020 08:50:07 +0000
Subject: [issue42747] Remove Py_TPFLAGS_HAVE_VERSION_TAG flag?
In-Reply-To: <1608940087.88.0.458230907712.issue42747@roundup.psfhosted.org>
Message-ID: <1609318207.56.0.7761972806.issue42747@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

> I'm only aware of PyQt which uses the stable ABI. Is there other projects using it? Do these projects check for Py_TPFLAGS_HAVE_VERSION_TAG or Py_TPFLAGS_HAVE_FINALIZE flag?

I think there are. Who knows how many; they're not required to register anywhere.


If the flags do end up being removed, it would be nice to reserve the bits (in a comment), so they aren't reused too soon.

Also, ISTM that PEP 387 applies, and requires warning for two releases. How can that be done for flags?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42747>
_______________________________________

From report at bugs.python.org  Wed Dec 30 04:25:07 2020
From: report at bugs.python.org (Anthony Hodson)
Date: Wed, 30 Dec 2020 09:25:07 +0000
Subject: [issue42764] HTMLParser close() issue
In-Reply-To: <1609166941.45.0.327676479076.issue42764@roundup.psfhosted.org>
Message-ID: <1609320307.27.0.10022067598.issue42764@roundup.psfhosted.org>


Anthony Hodson <aeh at xdotd.com> added the comment:

Resolved by correct initiation of subclass

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42764>
_______________________________________

From report at bugs.python.org  Wed Dec 30 04:51:58 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 30 Dec 2020 09:51:58 +0000
Subject: [issue27794] setattr a read-only property;
 the AttributeError should show the attribute that failed
In-Reply-To: <1471528639.63.0.0729109170448.issue27794@psf.upfronthosting.co.za>
Message-ID: <1609321918.21.0.793773684555.issue27794@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset c56387f80c5aabf8100ceaffe365cc004ce0d7e0 by Yurii Karabas in branch 'master':
bpo-27794: Add `name` attribute to `property` class (GH-23967)
https://github.com/python/cpython/commit/c56387f80c5aabf8100ceaffe365cc004ce0d7e0


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27794>
_______________________________________

From report at bugs.python.org  Wed Dec 30 04:52:51 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 30 Dec 2020 09:52:51 +0000
Subject: [issue27794] setattr a read-only property;
 the AttributeError should show the attribute that failed
In-Reply-To: <1471528639.63.0.0729109170448.issue27794@psf.upfronthosting.co.za>
Message-ID: <1609321971.26.0.730636035955.issue27794@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Thanks for the PR :-)

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27794>
_______________________________________

From report at bugs.python.org  Wed Dec 30 05:49:04 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Wed, 30 Dec 2020 10:49:04 +0000
Subject: [issue40956] Use Argument Clinic in sqlite3
In-Reply-To: <1591956335.72.0.553737405887.issue40956@roundup.psfhosted.org>
Message-ID: <1609325344.05.0.882500943501.issue40956@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
pull_requests: +22849
pull_request: https://github.com/python/cpython/pull/24007

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40956>
_______________________________________

From report at bugs.python.org  Wed Dec 30 06:20:51 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Dec 2020 11:20:51 +0000
Subject: [issue40633] json.dumps() should encode float number NaN to null
In-Reply-To: <1589550124.35.0.830023884715.issue40633@roundup.psfhosted.org>
Message-ID: <1609327251.57.0.0452539096216.issue40633@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

@Luca: you might want to open a new feature request issue; it's not clear to me what exact behaviour change you're proposing for Python.

What was rejected in this issue was the proposal to *automatically* convert NaNs and infinities to nulls by default, but that still leaves open the possibility of adding an option to do such conversion, provided that a sufficiently strong case could be made for adding such an option, and that we can figure out what we want the behaviour should be (should _all_ things that JSON doesn't know how to encode be converted to null, or just infinities and nans?)

If you want standards compliance, then that's already there: you can use the existing flag allow_nan=False when generating JSON. I agree that it would have been better if that were the default, but changing it now is probably a no-go - it would break too much existing code.

I'm still confused by Arjan Staring's comments: they seem to be saying that the JSON specification states that a NaN should be converted to the string "null", but there's nothing in RFC 7159 to support that - as you point out, it explicitly says that NaNs and infinities are disallowed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40633>
_______________________________________

From report at bugs.python.org  Wed Dec 30 06:30:57 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Dec 2020 11:30:57 +0000
Subject: [issue40137] TODO list when PEP 573 "Module State Access from C
 Extension Methods" will be implemented
In-Reply-To: <1585753703.83.0.0762180613721.issue40137@roundup.psfhosted.org>
Message-ID: <1609327857.77.0.915344510998.issue40137@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> _abc: abc_invalidation_counter is shared by all module instances.

For the record, this one has been fixed by:

commit 77c614624b6bf2145bef69830d0f499d8b55ec0c
Author: Dong-hee Na <donghee.na92 at gmail.com>
Date:   Sat May 9 17:31:40 2020 +0900

    bpo-40566: Apply PEP 573 to abc module (GH-20005)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40137>
_______________________________________

From report at bugs.python.org  Wed Dec 30 06:38:22 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Dec 2020 11:38:22 +0000
Subject: [issue40522] [subinterpreters] Get the current Python interpreter
 state from Thread Local Storage (autoTSSkey)
In-Reply-To: <1588698734.65.0.223552100195.issue40522@roundup.psfhosted.org>
Message-ID: <1609328302.87.0.0458429530287.issue40522@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

One GIL per interpreter requires to store the tstate per thread. I don't see any other option. We need to replace the global _PyRuntime atomic variable with a TLS variable. I'm trying to reduce the overhead, but it's heard to beat the performance of an atomic variable.

That's also we I modified many functions to pass explicitly tstate to subfunctions in internal C functions, to avoid any possible overhead of getting tstate.

https://vstinner.github.io/cpython-pass-tstate.html


Pablo:
> In MacOS is quite challenging to activate LTO, so normally optimized builds are only done with PGO.

Oh right, I forgot macOS. I should check how TLS is compiled on macOS. IMO wwo MOV instead of MOV is not a major performance bottleneck.

The best would be to be able to avoid pthread_getspecific() function which is less efficient than a TLS variable. The glibc implementation uses an array for a few variables (first 32 variables?) and then a slower hash table.


Pablo:
> Also in Windows I am not sure is possible to use LTO. Same for many other platforms.

I will check how it's implemented on Windows.

We cannot use TLS on all platforms, since it requires C11 features which are not available on all platforms. Also, the implementation depends on the architecture.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40522>
_______________________________________

From report at bugs.python.org  Wed Dec 30 06:43:15 2020
From: report at bugs.python.org (Christian Tismer)
Date: Wed, 30 Dec 2020 11:43:15 +0000
Subject: [issue30459] PyList_SET_ITEM  could be safer
In-Reply-To: <1495638852.56.0.0790136948712.issue30459@psf.upfronthosting.co.za>
Message-ID: <1609328595.17.0.511304254669.issue30459@roundup.psfhosted.org>


Christian Tismer <tismer at stackless.com> added the comment:

Congrats to that change!

----------
nosy: +Christian.Tismer

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30459>
_______________________________________

From report at bugs.python.org  Wed Dec 30 07:05:30 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Dec 2020 12:05:30 +0000
Subject: [issue40633] json.dumps() should encode float number NaN to null
In-Reply-To: <1589550124.35.0.830023884715.issue40633@roundup.psfhosted.org>
Message-ID: <1609329930.18.0.853601072648.issue40633@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

For the record, some helpful resources:

ECMA-404 (the ECMA standardization of JSON): http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf

RFC 8259 (current RFC for JSON): https://tools.ietf.org/html/rfc7159. (I mistakenly referred to RFC 7159 in a previous comment, but that's obsoleted by RFC 8259; however, none of the language around infinities and nans has changed, and none of the current errata to RFC 8259 have any impact on infinity or nan encoding.)

This Stack Overflow question and its answers contain some interesting discussion and links: https://stackoverflow.com/questions/1423081/json-left-out-infinity-and-nan-json-status-in-ecmascript 

Essentially, there's no good answer here: standard JSON simply can't encode infinities and NaNs. Absent a fix for the standard itself, both Python and ECMAScript end up papering over that fact. Unfortunately from an interoperability point of view, they do so in different ways - Python effectively extends the JSON spec in such a way that it produces invalid JSON by default; ECMAScript converts all of Infinity, -Infinity, NaN and null to the exact same JSON string, producing valid JSON but losing the ability to restore the original values from their JSON representations.

FWIW, Python's solution to this problem is (whether by accident or design I'm not sure) forward-looking in the sense that it's compatible with JSON 5: https://spec.json5.org

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40633>
_______________________________________

From report at bugs.python.org  Wed Dec 30 07:06:37 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Dec 2020 12:06:37 +0000
Subject: [issue40633] json.dumps() should encode float number NaN to null
In-Reply-To: <1589550124.35.0.830023884715.issue40633@roundup.psfhosted.org>
Message-ID: <1609329997.17.0.562219072135.issue40633@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> RFC 8259 (current RFC for JSON): https://tools.ietf.org/html/rfc7159

Argh; copy-and-paste fail. That link should have been https://tools.ietf.org/html/rfc8259, of course.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40633>
_______________________________________

From report at bugs.python.org  Wed Dec 30 07:38:08 2020
From: report at bugs.python.org (Paolo Lammens)
Date: Wed, 30 Dec 2020 12:38:08 +0000
Subject: [issue42785] Support operator module callables in inspect.signature
Message-ID: <1609331888.16.0.35363195517.issue42785@roundup.psfhosted.org>


New submission from Paolo Lammens <lammenspaolo at gmail.com>:

Currently, `inspect.signature` doesn't support all callables from the `operator` module, e.g. `operator.attrgetter`:

```python
>>> import inspect
>>> import operator
>>> inspect.signature(operator.attrgetter("spam"))
ValueError: callable operator.attrgetter('is_host') is not supported by signature
```

Support for this could be added either directly to `inspect.signature` or by adding `__signature__` attributes to `operator`'s classes.

----------
components: Library (Lib)
messages: 384061
nosy: plammens
priority: normal
severity: normal
status: open
title: Support operator module callables in inspect.signature
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42785>
_______________________________________

From report at bugs.python.org  Wed Dec 30 07:39:03 2020
From: report at bugs.python.org (Paolo Lammens)
Date: Wed, 30 Dec 2020 12:39:03 +0000
Subject: [issue42785] Support operator module callables in inspect.signature
In-Reply-To: <1609331888.16.0.35363195517.issue42785@roundup.psfhosted.org>
Message-ID: <1609331943.62.0.972623791382.issue42785@roundup.psfhosted.org>


Paolo Lammens <lammenspaolo at gmail.com> added the comment:

Correction:

```
ValueError: callable operator.attrgetter('spam') is not supported by signature
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42785>
_______________________________________

From report at bugs.python.org  Wed Dec 30 07:39:46 2020
From: report at bugs.python.org (Paolo Lammens)
Date: Wed, 30 Dec 2020 12:39:46 +0000
Subject: [issue42760] inspect.iscoroutine returns False for asynchronous
 generator functions
In-Reply-To: <1609101687.37.0.151159530312.issue42760@roundup.psfhosted.org>
Message-ID: <1609331986.64.0.497479442207.issue42760@roundup.psfhosted.org>


Change by Paolo Lammens <lammenspaolo at gmail.com>:


----------
versions: +Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42760>
_______________________________________

From report at bugs.python.org  Wed Dec 30 07:40:13 2020
From: report at bugs.python.org (Paolo Lammens)
Date: Wed, 30 Dec 2020 12:40:13 +0000
Subject: [issue42760] inspect.iscoroutine returns False for asynchronous
 generator methods
In-Reply-To: <1609101687.37.0.151159530312.issue42760@roundup.psfhosted.org>
Message-ID: <1609332013.52.0.0565690797971.issue42760@roundup.psfhosted.org>


Change by Paolo Lammens <lammenspaolo at gmail.com>:


----------
title: inspect.iscoroutine returns False for asynchronous generator functions -> inspect.iscoroutine returns False for asynchronous generator methods

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42760>
_______________________________________

From report at bugs.python.org  Wed Dec 30 07:50:50 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Dec 2020 12:50:50 +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: <1609332650.93.0.495524347867.issue27640@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:


New changeset 277ce3060becc120f1c877346562bd6880f4be71 by pxinwr in branch 'master':
bpo-27640: Add --disable-test-modules configure option (GH-23886)
https://github.com/python/cpython/commit/277ce3060becc120f1c877346562bd6880f4be71


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27640>
_______________________________________

From report at bugs.python.org  Wed Dec 30 07:56:22 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Dec 2020 12:56:22 +0000
Subject: [issue27640] Add --disable-test-modules configure option to not build
 nor install tests
In-Reply-To: <1469700317.99.0.84265252625.issue27640@psf.upfronthosting.co.za>
Message-ID: <1609332982.47.0.568738221743.issue27640@roundup.psfhosted.org>


Change by STINNER Victor <vstinner at python.org>:


----------
title: add the '--disable-test-suite' option to configure -> Add --disable-test-modules configure option to not build nor install tests

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27640>
_______________________________________

From report at bugs.python.org  Wed Dec 30 07:56:02 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Dec 2020 12:56:02 +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: <1609332962.78.0.806062910202.issue27640@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Thanks all, it's now fixed in the master branch, the future Python 3.10.

Thanks Xavier de Gaye for the initial patch and reported the issue.

Thanks Peixing Xin for the final change which is now even better! 

Thanks also Thomas Petazzoni who maintained the downstream patch in buildroot.

See also discussion on PR 23886 about the technical change and the different tests that we run to ensure that the change doesn't break anything, and that it works as expected.

I'm really not comfortable at all to change the Python build system. It's very complex and fragile, I don't know it very well, so I'm not confident in what I am doing. For these reasons, I'm strongly against backporting the change to stable branches (3.8 and 3.9) and so I close the issue

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27640>
_______________________________________

From report at bugs.python.org  Wed Dec 30 08:08:47 2020
From: report at bugs.python.org (Frederik Rietdijk)
Date: Wed, 30 Dec 2020 13:08:47 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1609333727.85.0.60854765511.issue29708@roundup.psfhosted.org>


Frederik Rietdijk <fridh at fridh.nl> added the comment:

Building Python packages reproducibly has now basically been resolved with the reproducible bytecode as well as changes in tools such as pip.

Unfortunately, the interpreters do not yet seem to be reproducible. After certain changes, a Nixpkgs build of 3.9 shows several tiny bytecode differences. What could have caused these differences? Please see the attached diffoscope report. 

As part of installation all bytecode is force regenerated using compileall. This is using the default checked-hash.

----------
nosy: +Frederik Rietdijk
versions: +Python 3.9 -Python 3.7
Added file: https://bugs.python.org/file49708/python39_2.html

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Wed Dec 30 08:10:04 2020
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 30 Dec 2020 13:10:04 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1609333804.37.0.576132523597.issue29708@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> tiny bytecode differences

bpo-37596 "Reproducible pyc: frozenset is not serialized in a deterministic order" is not fixed yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Wed Dec 30 08:54:49 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Wed, 30 Dec 2020 13:54:49 +0000
Subject: [issue24464] "sqlite3_enable_shared_cache" deprecation warning when
 compiling with macOS system SQLite3
In-Reply-To: <1434627103.24.0.34027869681.issue24464@psf.upfronthosting.co.za>
Message-ID: <1609336489.0.0.877854665137.issue24464@roundup.psfhosted.org>


Change by Erlend Egeberg Aasland <erlend.aasland at innova.no>:


----------
pull_requests: +22850
pull_request: https://github.com/python/cpython/pull/24008

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue24464>
_______________________________________

From report at bugs.python.org  Wed Dec 30 09:54:10 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 30 Dec 2020 14:54:10 +0000
Subject: [issue42773] build.yml workflow not testing on pushes
In-Reply-To: <1609194687.05.0.86275810312.issue42773@roundup.psfhosted.org>
Message-ID: <1609340050.74.0.919842766007.issue42773@roundup.psfhosted.org>


miss-islington <mariatta.wijaya+miss-islington at gmail.com> added the comment:


New changeset 4ac923f2756f835f512339ee181348cc535ab07f by Filipe La?ns in branch 'master':
bpo-42773: fix tests not being run on pushes (GH-24004)
https://github.com/python/cpython/commit/4ac923f2756f835f512339ee181348cc535ab07f


----------
nosy: +miss-islington

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42773>
_______________________________________

From report at bugs.python.org  Wed Dec 30 11:00:56 2020
From: report at bugs.python.org (Svyatoslav)
Date: Wed, 30 Dec 2020 16:00:56 +0000
Subject: [issue42786] Different repr for collections.abc.Callable and
 typing.Callable
Message-ID: <1609344056.94.0.962444681663.issue42786@roundup.psfhosted.org>


New submission from Svyatoslav <prometheus3375 at gmail.com>:

Was making some typing conversions to string and noticed a different behavior of collections.abc.Callable and typing.Callable here in 3.9.1. Issues issue42195 and issue40494 can be related.

>>> import collections, typing
>>> repr(collections.abc.Callable[[int], str])
"collections.abc.Callable[[<class 'int'>], str]"
>>> repr(typing.Callable[[int], str])
'typing.Callable[[int], str]'

The variant from collections is wrong, it is not consistent with other GenericAlias reprs like
>>> repr(tuple[list[float], int, str])
'tuple[list[float], int, str]'

The problem is actually in the list usage to denote callable arguments:
>>> repr(tuple[[float], int, str])
"tuple[[<class 'float'>], int, str]"

Here is the same error. This error disallows to use typing in eval/exec statements:
>>> c = collections.abc.Callable[[int], str]
>>> d = eval(repr(c))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1
    collections.abc.Callable[[<class 'int'>], str]
                              ^
SyntaxError: invalid syntax

Ofc there is no such problem with typing.Callable:
>>> c = typing.Callable[[int], str]
>>> d = eval(repr(c))
>>> 

Interesting, if pass a list into typing.Tuple, an exception is raised:
>>> repr(typing.Tuple[[float], int, str])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "f:\software\python3.9\lib\typing.py", line 262, in inner
    return func(*args, **kwds)
  File "f:\software\python3.9\lib\typing.py", line 896, in __getitem__
    params = tuple(_type_check(p, msg) for p in params)
  File "f:\software\python3.9\lib\typing.py", line 896, in <genexpr>
    params = tuple(_type_check(p, msg) for p in params)
  File "f:\software\python3.9\lib\typing.py", line 151, in _type_check
    raise TypeError(f"{msg} Got {arg!r:.100}.")
TypeError: Tuple[t0, t1, ...]: each t must be a type. Got [<class 'float'>].

I think it is not correct that tuple accepts lists as generics, i. e. for tuple[[float], int, str] an exception as above should be raised. Bu this is the topic for other issue (maybe even already reported).

----------
messages: 384068
nosy: Prometheus3375
priority: normal
severity: normal
status: open
title: Different repr for collections.abc.Callable and typing.Callable
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42786>
_______________________________________

From report at bugs.python.org  Wed Dec 30 11:01:25 2020
From: report at bugs.python.org (Konstantin Ryabitsev)
Date: Wed, 30 Dec 2020 16:01:25 +0000
Subject: [issue42787] email.utils.getaddresses improper parsing of unicode
 realnames
Message-ID: <1609344085.02.0.266691103598.issue42787@roundup.psfhosted.org>


New submission from Konstantin Ryabitsev <konstantin at linuxfoundation.org>:

What it currently does:

>>> import email.utils
>>> email.utils.getaddresses(['Shuming [???] <shumingf at realtek.com>'])
[('', 'Shuming'), ('', ''), ('', '???'), ('', ''), ('', 'shumingf at realtek.com')]

What it should do:

>>> import email.utils
>>> email.utils.getaddresses(['Shuming [???] <shumingf at realtek.com>'])
[('Shuming [???]'), 'shumingf at realtek.com')]

----------
components: email
messages: 384069
nosy: barry, konstantin2, r.david.murray
priority: normal
severity: normal
status: open
title: email.utils.getaddresses improper parsing of unicode realnames
type: enhancement
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42787>
_______________________________________

From report at bugs.python.org  Wed Dec 30 11:39:33 2020
From: report at bugs.python.org (Ken Jin)
Date: Wed, 30 Dec 2020 16:39:33 +0000
Subject: [issue42786] Different repr for collections.abc.Callable and
 typing.Callable
In-Reply-To: <1609344056.94.0.962444681663.issue42786@roundup.psfhosted.org>
Message-ID: <1609346373.35.0.140990840662.issue42786@roundup.psfhosted.org>


Ken Jin <kenjin4096 at gmail.com> added the comment:

This was addressed in issue42195 and issue40494 as you pointed out :). It has been fixed in Python 3.10. Unfortunately the backport didn't make it in time for Python 3.9.1, and will come in Python 3.9.2 instead. Sadly there's not much to do about that.

On 3.10:

>>> import collections
>>> repr(collections.abc.Callable[[int], str])
'collections.abc.Callable[[int], str]'

----------
nosy: +kj

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42786>
_______________________________________

From report at bugs.python.org  Wed Dec 30 11:46:04 2020
From: report at bugs.python.org (Dong-hee Na)
Date: Wed, 30 Dec 2020 16:46:04 +0000
Subject: [issue40522] [subinterpreters] Get the current Python interpreter
 state from Thread Local Storage (autoTSSkey)
In-Reply-To: <1588698734.65.0.223552100195.issue40522@roundup.psfhosted.org>
Message-ID: <1609346764.73.0.551787253985.issue40522@roundup.psfhosted.org>


Change by Dong-hee Na <donghee.na at python.org>:


----------
nosy: +corona10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40522>
_______________________________________

From report at bugs.python.org  Wed Dec 30 11:47:32 2020
From: report at bugs.python.org (Ross Rhodes)
Date: Wed, 30 Dec 2020 16:47:32 +0000
Subject: [issue42787] email.utils.getaddresses improper parsing of unicode
 realnames
In-Reply-To: <1609344085.02.0.266691103598.issue42787@roundup.psfhosted.org>
Message-ID: <1609346852.48.0.425807535798.issue42787@roundup.psfhosted.org>


Ross Rhodes <ross.rhodes at hotmail.co.uk> added the comment:

Hi Konstantin,

Thanks for raising this issue. It appears the field provided in your example does not conform to RFC 2822 followed by this email library. Square brackets are treated as special characters in [section 3.2.1](https://tools.ietf.org/html/rfc2822#section-3.2.1), which is handled in the [_parseaddr](https://github.com/python/cpython/blob/master/Lib/email/_parseaddr.py#L219) file.

The above combined with the fact that any [failed parsing returns an two-tuple of ('', '')](https://github.com/python/cpython/blob/master/Lib/email/utils.py#L212) I believe explains the behavior observed.

----------
nosy: +trrhodes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42787>
_______________________________________

From report at bugs.python.org  Wed Dec 30 11:57:41 2020
From: report at bugs.python.org (hai shi)
Date: Wed, 30 Dec 2020 16:57:41 +0000
Subject: [issue40522] [subinterpreters] Get the current Python interpreter
 state from Thread Local Storage (autoTSSkey)
In-Reply-To: <1588698734.65.0.223552100195.issue40522@roundup.psfhosted.org>
Message-ID: <1609347461.83.0.720852299443.issue40522@roundup.psfhosted.org>


Change by hai shi <shihai1991 at 126.com>:


----------
nosy: +shihai1991

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40522>
_______________________________________

From report at bugs.python.org  Wed Dec 30 12:15:52 2020
From: report at bugs.python.org (Ross Rhodes)
Date: Wed, 30 Dec 2020 17:15:52 +0000
Subject: [issue41914] test_pdb fails
In-Reply-To: <1601671175.99.0.383994267715.issue41914@roundup.psfhosted.org>
Message-ID: <1609348552.84.0.407516045747.issue41914@roundup.psfhosted.org>


Ross Rhodes <ross.rhodes at hotmail.co.uk> added the comment:

Hi Sumagna,

test_pdb appears to be working as expected on my machine. I realise this was posted a few months ago so would you mind trying again and seeing if the issue persists? If so, which OS are you running your tests on?

----------
nosy: +trrhodes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41914>
_______________________________________

From report at bugs.python.org  Wed Dec 30 12:31:26 2020
From: report at bugs.python.org (yao_way)
Date: Wed, 30 Dec 2020 17:31:26 +0000
Subject: =?utf-8?q?=5Bissue42788=5D_Issue_with_Python=E2=80=99s_Floor_Division?=
Message-ID: <1609349486.6.0.659948013801.issue42788@roundup.psfhosted.org>


New submission from yao_way <yao_way at yahoo.com>:

There might be an issue with Python?s floor division:
Experienced Behavior: >>> (1 / 1) // 1 --> 1.0; >>> (0 / 1) // 1 --> 0.0
Expected Behavior: >>> (1 / 1) // 1 --> 1; >>> (0 / 1) // 1 --> 0

----------
components: Interpreter Core
messages: 384073
nosy: yao_way
priority: normal
severity: normal
status: open
title: Issue with Python?s Floor Division
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42788>
_______________________________________

From report at bugs.python.org  Wed Dec 30 12:41:30 2020
From: report at bugs.python.org (=?utf-8?q?Filipe_La=C3=ADns?=)
Date: Wed, 30 Dec 2020 17:41:30 +0000
Subject: [issue42773] build.yml workflow not testing on pushes
In-Reply-To: <1609194687.05.0.86275810312.issue42773@roundup.psfhosted.org>
Message-ID: <1609350090.29.0.400130475838.issue42773@roundup.psfhosted.org>


Filipe La?ns <lains at riseup.net> added the comment:

Ammar, could you confirm the issue is now solved?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42773>
_______________________________________

From report at bugs.python.org  Wed Dec 30 12:42:03 2020
From: report at bugs.python.org (Svyatoslav)
Date: Wed, 30 Dec 2020 17:42:03 +0000
Subject: [issue42786] Different repr for collections.abc.Callable and
 typing.Callable
In-Reply-To: <1609344056.94.0.962444681663.issue42786@roundup.psfhosted.org>
Message-ID: <1609350123.19.0.147396104946.issue42786@roundup.psfhosted.org>


Svyatoslav <prometheus3375 at gmail.com> added the comment:

Ok, thanks for the answer. Did I understand correctly that the issue will be fixed in 3.9.2 as well?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42786>
_______________________________________

From report at bugs.python.org  Wed Dec 30 12:43:51 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 30 Dec 2020 17:43:51 +0000
Subject: =?utf-8?q?=5Bissue42788=5D_Issue_with_Python=E2=80=99s_Floor_Division?=
In-Reply-To: <1609349486.6.0.659948013801.issue42788@roundup.psfhosted.org>
Message-ID: <1609350231.92.0.856931815509.issue42788@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

The current behavior was specified in PEP 238:

   int / int -> float            
   float // int -> float 

See:  https://www.python.org/dev/peps/pep-0238/#semantics-of-floor-division

----------
nosy: +rhettinger
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42788>
_______________________________________

From report at bugs.python.org  Wed Dec 30 12:44:48 2020
From: report at bugs.python.org (Ammar Askar)
Date: Wed, 30 Dec 2020 17:44:48 +0000
Subject: [issue42773] build.yml workflow not testing on pushes
In-Reply-To: <1609194687.05.0.86275810312.issue42773@roundup.psfhosted.org>
Message-ID: <1609350288.43.0.638254372014.issue42773@roundup.psfhosted.org>


Ammar Askar <ammar at ammaraskar.com> added the comment:

Thank you Filipe and Mariatta, the fix looks good to me. I think it needs a backport to the 3.9 branch though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42773>
_______________________________________

From report at bugs.python.org  Wed Dec 30 12:46:13 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 30 Dec 2020 17:46:13 +0000
Subject: =?utf-8?q?=5Bissue42788=5D_Issue_with_Python=E2=80=99s_Floor_Division?=
In-Reply-To: <1609349486.6.0.659948013801.issue42788@roundup.psfhosted.org>
Message-ID: <1609350373.76.0.296766120455.issue42788@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Regular division (/) yields a float, so 1 / 1 is 1.0.

https://docs.python.org/3/reference/expressions.html#binary-arithmetic-operations says that for floor division, the arguments are first converted to a common type, which here would be float.

So, your examples are basically:

>>> 1 / 1
1.0
>>> 1.0 // 1
1.0

>>> 0 / 1
0.0
>>> 0.0 // 1
0.0

This is working as expected, and is not a bug.

----------
nosy: +eric.smith -rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42788>
_______________________________________

From report at bugs.python.org  Wed Dec 30 12:46:52 2020
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 30 Dec 2020 17:46:52 +0000
Subject: =?utf-8?q?=5Bissue42788=5D_Issue_with_Python=E2=80=99s_Floor_Division?=
In-Reply-To: <1609349486.6.0.659948013801.issue42788@roundup.psfhosted.org>
Message-ID: <1609350412.54.0.666867238225.issue42788@roundup.psfhosted.org>


Eric V. Smith <eric at trueblade.com> added the comment:

Oops, my message collided with rhettinger.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42788>
_______________________________________

From report at bugs.python.org  Wed Dec 30 12:55:23 2020
From: report at bugs.python.org (Ken Jin)
Date: Wed, 30 Dec 2020 17:55:23 +0000
Subject: [issue42786] Different repr for collections.abc.Callable and
 typing.Callable
In-Reply-To: <1609344056.94.0.962444681663.issue42786@roundup.psfhosted.org>
Message-ID: <1609350923.7.0.297989262392.issue42786@roundup.psfhosted.org>


Ken Jin <kenjin4096 at gmail.com> added the comment:

You're welcome, and yes you're right! You can read the news item for it here https://docs.python.org/3/whatsnew/3.9.html#notable-changes-in-python-3-9-2. 

The expected release date for Python 3.9.2 is Monday, 2021-02-15 according to PEP 596 https://www.python.org/dev/peps/pep-0596/.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42786>
_______________________________________

From report at bugs.python.org  Wed Dec 30 13:18:46 2020
From: report at bugs.python.org (Pandu E POLUAN)
Date: Wed, 30 Dec 2020 18:18:46 +0000
Subject: [issue27820] Possible bug in smtplib when initial_response_ok=False
In-Reply-To: <1471739698.94.0.271523306415.issue27820@psf.upfronthosting.co.za>
Message-ID: <1609352326.9.0.585563553801.issue27820@roundup.psfhosted.org>


Pandu E POLUAN <pepoluan at gmail.com> added the comment:

I tried creating a PR, but for the life of me I couldn't wrap my head around how testAUTH_LOGIN is being performed (it's in Lib/test/test_smtplib.py)

All I know is, the test doesn't AT ALL test for situations where initial_response_ok=False. ALL tests are done with initial_response_ok=True.

There needs to be a whole set of additions to test_smtplib.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27820>
_______________________________________

From report at bugs.python.org  Wed Dec 30 13:24:57 2020
From: report at bugs.python.org (Svyatoslav)
Date: Wed, 30 Dec 2020 18:24:57 +0000
Subject: [issue42786] Different repr for collections.abc.Callable and
 typing.Callable
In-Reply-To: <1609344056.94.0.962444681663.issue42786@roundup.psfhosted.org>
Message-ID: <1609352697.76.0.986612046915.issue42786@roundup.psfhosted.org>


Svyatoslav <prometheus3375 at gmail.com> added the comment:

Thanks a lot! I am closing this issue.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42786>
_______________________________________

From report at bugs.python.org  Wed Dec 30 14:06:35 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 30 Dec 2020 19:06:35 +0000
Subject: [issue42789] Do not skip test_curses on non-tty
Message-ID: <1609355195.18.0.84938555409.issue42789@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Currently many tests in test_curses are skipped if sys.__stdout__ is not attached to terminal. All tests are ran only when run them manually, and without using pager. This leads to passing bugs, like in issue42694.

The proposed PR makes tests always ran. If __stdout__ is not attached to terminal, it tries to attach it to terminal, using __stderr__ if it is attached to terminal, or opening /dev/tty. If neither __stdout__ nor __stderr__ are attached to terminal, it tries to use temporary file, but some functions do not work in this case and will be untested.

It could be better to use os.openpty(), but too many curses outputs can overflow the buffer (2 KiB) and cause the test and all subsequent tests to fail. Currently all tests are passed if use os.openpty(), but I afraid that adding more tests will overflow the buffer and it will confuse future developers. My attempts to solve this issue was unsuccessful for that time, so I left more complicated and less flexible, but more reliable solution.

----------
components: Tests
messages: 384083
nosy: serhiy.storchaka, twouters
priority: normal
severity: normal
status: open
title: Do not skip test_curses on non-tty
type: enhancement
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42789>
_______________________________________

From report at bugs.python.org  Wed Dec 30 14:11:47 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 30 Dec 2020 19:11:47 +0000
Subject: [issue42789] Do not skip test_curses on non-tty
In-Reply-To: <1609355195.18.0.84938555409.issue42789@roundup.psfhosted.org>
Message-ID: <1609355507.94.0.145770629494.issue42789@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
pull_requests: +22851
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24009

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42789>
_______________________________________

From report at bugs.python.org  Wed Dec 30 14:14:26 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 30 Dec 2020 19:14:26 +0000
Subject: [issue42773] build.yml workflow not testing on pushes
In-Reply-To: <1609194687.05.0.86275810312.issue42773@roundup.psfhosted.org>
Message-ID: <1609355666.59.0.00714412883014.issue42773@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22853
pull_request: https://github.com/python/cpython/pull/24011

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42773>
_______________________________________

From report at bugs.python.org  Wed Dec 30 14:14:16 2020
From: report at bugs.python.org (miss-islington)
Date: Wed, 30 Dec 2020 19:14:16 +0000
Subject: [issue42773] build.yml workflow not testing on pushes
In-Reply-To: <1609194687.05.0.86275810312.issue42773@roundup.psfhosted.org>
Message-ID: <1609355656.63.0.991103587771.issue42773@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22852
pull_request: https://github.com/python/cpython/pull/24010

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42773>
_______________________________________

From report at bugs.python.org  Wed Dec 30 14:26:59 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 30 Dec 2020 19:26:59 +0000
Subject: [issue42790] test.regrtest outputs to stdout instead of stderr
Message-ID: <1609356419.4.0.571157981474.issue42790@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

unittest outputs progress and summary to stderr, but test.regrtest outputs it to stdout. Except that it outputs progress to stderr if option -W is used.

It caused some problems with test_curses, because curses uses stdout, and when re-attach it to other terminal or file we can lose the regrtest output. It makes the code more complicated.

----------
components: Tests
messages: 384084
nosy: serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: test.regrtest outputs to stdout instead of stderr
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42790>
_______________________________________

From report at bugs.python.org  Wed Dec 30 15:22:51 2020
From: report at bugs.python.org (Artyom Kaltovich)
Date: Wed, 30 Dec 2020 20:22:51 +0000
Subject: [issue42791] There is no way to json encode object to str.
Message-ID: <1609359771.92.0.340715050179.issue42791@roundup.psfhosted.org>


New submission from Artyom Kaltovich <kaltovichartyom at gmail.com>:

Hello.

At first I want to say thank you for all your efforts in python development. I really appreciate it. :)

I am trying to convert custom object to json. 

But, I've found a problem. JSONEncoder has ``default`` method for converting custom objects to some primitives and ``encode`` for converting structures.

But what if I want to return completed json string? I can't do it in ``default``, because JSONEncoder will think it is string and encode it accordingly later in ``iterencode`` method.

Then I tried redefine encode, but it is called with the dict(array_name=default(o)) so I should convert the dict as a whole and basically reimplement all conversions (for int, float, and lists of course).

Did I missed something or there is no way to do it?

I suggest to introduce another method, e.g. encode_obj and call it there:

https://github.com/python/cpython/blob/master/Lib/json/encoder.py#L438
```
   o = _default(o)
   yield from _iterencode(o, _current_indent_level)
```
->
```
   o = _encode_obj(_default(o))
   yield from _iterencode(o, _current_indent_level)
```

If you are agree I would be happy to implement it.

Best Regards,
Artsiom.

----------
components: Library (Lib)
messages: 384085
nosy: kaltovichartyom
priority: normal
severity: normal
status: open
title: There is no way to json encode object to str.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42791>
_______________________________________

From report at bugs.python.org  Wed Dec 30 15:29:36 2020
From: report at bugs.python.org (Saiyang Gou)
Date: Wed, 30 Dec 2020 20:29:36 +0000
Subject: [issue40631] PEG Parser: Cannot used starred expression in
 parenthesised expr
In-Reply-To: <1589544267.84.0.231872596395.issue40631@roundup.psfhosted.org>
Message-ID: <1609360176.44.0.755006542272.issue40631@roundup.psfhosted.org>


Saiyang Gou <gousaiyang223 at gmail.com> added the comment:

Well, there is actually a bug:

root at f1b4a742d8fc:/# python3.9
Python 3.9.1 (default, Dec  8 2020, 03:24:52)
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> x = [1, 2]
>>> y = 3
>>> *x, y
(1, 2, 3)
>>> (*x), y
  File "<stdin>", line 1
    (*x), y
     ^
SyntaxError: can't use starred expression here

root at f1b4a742d8fc:/# python3.8
Python 3.8.6 (default, Oct  6 2020, 03:22:36)
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> x = [1, 2]
>>> y = 3
>>> *x, y
(1, 2, 3)
>>> (*x), y
(1, 2, 3)

This is different from the previous message where the starred expression is "alone" (and thus invalid). Since this bug happens in 3.9 but not in 3.8, it might be due to the PEG parser.

Also,
root at f1b4a742d8fc:/# python3.9
Python 3.9.1 (default, Dec  8 2020, 03:24:52)
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> del *x
  File "<stdin>", line 1
    del *x
        ^
SyntaxError: cannot delete starred
>>> del (*x)
  File "<stdin>", line 1
    del (*x)
         ^
SyntaxError: can't use starred expression here

The latter case should also report "SyntaxError: cannot delete starred".

----------
nosy: +gousaiyang

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40631>
_______________________________________

From report at bugs.python.org  Wed Dec 30 15:34:07 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 30 Dec 2020 20:34:07 +0000
Subject: [issue42093] Add opcode cache for LOAD_ATTR
In-Reply-To: <1603163916.18.0.528007796853.issue42093@roundup.psfhosted.org>
Message-ID: <1609360447.59.0.727992115993.issue42093@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

>Wow, this is amazing. I just found that this is now faster than slots. 

Not only that: is even faster than the highly-tuned namedtuple access descriptors that used to be the faster access to an attribute:

3.9 results
-----------
  17.6 ns       read_classvar_from_class
  16.3 ns       read_classvar_from_instance
  23.2 ns       read_instancevar
  19.7 ns       read_instancevar_slots
  17.9 ns       read_namedtuple
  39.2 ns       read_boundmethod

Now this is the faster way to get an attribute:

3.10 results
------------
  17.9 ns       read_classvar_from_class
  16.9 ns       read_classvar_from_instance
  14.1 ns       read_instancevar
  20.0 ns       read_instancevar_slots
  18.0 ns       read_namedtuple
  40.7 ns       read_boundmethod

> Should we mention that in What's New?

Good idea!. I will prepare a PR complementing the current paragraph.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42093>
_______________________________________

From report at bugs.python.org  Wed Dec 30 15:37:24 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 30 Dec 2020 20:37:24 +0000
Subject: [issue40631] PEG Parser: Cannot used starred expression in
 parenthesised expr
In-Reply-To: <1589544267.84.0.231872596395.issue40631@roundup.psfhosted.org>
Message-ID: <1609360644.24.0.955259923512.issue40631@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
resolution: not a bug -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40631>
_______________________________________

From report at bugs.python.org  Wed Dec 30 16:15:10 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 30 Dec 2020 21:15:10 +0000
Subject: [issue40631] PEG Parser: Cannot used starred expression in
 parenthesised expr
In-Reply-To: <1589544267.84.0.231872596395.issue40631@roundup.psfhosted.org>
Message-ID: <1609362910.11.0.851481904533.issue40631@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
keywords: +patch
pull_requests: +22854
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/24014

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40631>
_______________________________________

From report at bugs.python.org  Wed Dec 30 16:23:41 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Wed, 30 Dec 2020 21:23:41 +0000
Subject: [issue40631] PEG Parser: Cannot used starred expression in
 parenthesised expr
In-Reply-To: <1589544267.84.0.231872596395.issue40631@roundup.psfhosted.org>
Message-ID: <1609363421.33.0.344651294181.issue40631@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +22855
pull_request: https://github.com/python/cpython/pull/24015

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40631>
_______________________________________

From report at bugs.python.org  Wed Dec 30 17:08:17 2020
From: report at bugs.python.org (Jah-On)
Date: Wed, 30 Dec 2020 22:08:17 +0000
Subject: [issue42792] [MacOS] Can't open file in a separate (threading.Thread)
 thread
Message-ID: <1609366097.56.0.326063377127.issue42792@roundup.psfhosted.org>


New submission from Jah-On <john.schulz1 at protonmail.com>:

Tested on MacOS Big Sur... Most recent version as of posting.

----------
components: macOS
files: test.py
messages: 384088
nosy: Jah-On, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: [MacOS] Can't open file in a separate (threading.Thread) thread
versions: Python 3.8
Added file: https://bugs.python.org/file49709/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42792>
_______________________________________

From report at bugs.python.org  Wed Dec 30 17:09:13 2020
From: report at bugs.python.org (Jah-On)
Date: Wed, 30 Dec 2020 22:09:13 +0000
Subject: [issue42792] [MacOS] Can't open file in a separate (threading.Thread)
 thread
In-Reply-To: <1609366097.56.0.326063377127.issue42792@roundup.psfhosted.org>
Message-ID: <1609366153.47.0.60369785225.issue42792@roundup.psfhosted.org>


Change by Jah-On <john.schulz1 at protonmail.com>:


Added file: https://bugs.python.org/file49710/lol.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42792>
_______________________________________

From report at bugs.python.org  Wed Dec 30 17:30:20 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 30 Dec 2020 22:30:20 +0000
Subject: [issue40631] PEG Parser: Cannot used starred expression in
 parenthesised expr
In-Reply-To: <1589544267.84.0.231872596395.issue40631@roundup.psfhosted.org>
Message-ID: <1609367420.49.0.0975835073848.issue40631@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

Honestly this seems like a bug in 3.8 to me (if it indeed behaves like this):

>>> (*x), y
(1, 2, 3)

Every time I mistakenly tried (*x) I really meant (*x,), so it's surprising that (*x), y would be interpreted as (*x, y) rather than flagging (*x) as an error.

Please don't "fix" this even if it is a regression.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40631>
_______________________________________

From report at bugs.python.org  Wed Dec 30 18:01:45 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 30 Dec 2020 23:01:45 +0000
Subject: [issue42792] [MacOS] Can't open file in a separate (threading.Thread)
 thread
In-Reply-To: <1609366097.56.0.326063377127.issue42792@roundup.psfhosted.org>
Message-ID: <1609369305.59.0.911358228436.issue42792@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Your test file has the line:

    f = open("lol.txt", "r", "utf-8")

But the third positional argument to the 'open' built-in function is "buffering", which expects an integer. Pass the "utf-8" argument by name instead:

    f = open("lol.txt", "r", encoding="utf-8")

As a side note, you probably also want to join your thread before exiting the script.

Closing here, since it looks as though there's no Python bug.

----------
nosy: +mark.dickinson
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42792>
_______________________________________

From report at bugs.python.org  Wed Dec 30 18:10:30 2020
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Wed, 30 Dec 2020 23:10:30 +0000
Subject: [issue41224] Document is_annotate() in symtable and update doc strings
In-Reply-To: <1594082969.57.0.57546378767.issue41224@roundup.psfhosted.org>
Message-ID: <1609369830.72.0.622471393078.issue41224@roundup.psfhosted.org>


Change by Andr?s Delfino <adelfino at gmail.com>:


----------
pull_requests: +22856
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/24016

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41224>
_______________________________________

From report at bugs.python.org  Wed Dec 30 18:12:48 2020
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Wed, 30 Dec 2020 23:12:48 +0000
Subject: [issue41224] Document is_annotate() in symtable and update doc strings
In-Reply-To: <1594082969.57.0.57546378767.issue41224@roundup.psfhosted.org>
Message-ID: <1609369968.87.0.85188581973.issue41224@roundup.psfhosted.org>


Change by Andr?s Delfino <adelfino at gmail.com>:


----------
pull_requests: +22857
pull_request: https://github.com/python/cpython/pull/24017

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41224>
_______________________________________

From report at bugs.python.org  Wed Dec 30 18:14:40 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Wed, 30 Dec 2020 23:14:40 +0000
Subject: [issue40631] PEG Parser: Cannot used starred expression in
 parenthesised expr
In-Reply-To: <1589544267.84.0.231872596395.issue40631@roundup.psfhosted.org>
Message-ID: <1609370080.29.0.971473847075.issue40631@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

It makes sense to me to be able to do `(*a), b` if I can do `*a, b`, but I don't really have a strong opinion on it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40631>
_______________________________________

From report at bugs.python.org  Wed Dec 30 18:22:48 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 30 Dec 2020 23:22:48 +0000
Subject: [issue40631] PEG Parser: Cannot used starred expression in
 parenthesised expr
In-Reply-To: <1589544267.84.0.231872596395.issue40631@roundup.psfhosted.org>
Message-ID: <1609370568.85.0.510638055458.issue40631@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

Parenthesis can be added around expression. But `*a` is not an expression (as well as `+`, `or`, `1:5`, you cannot surround them with parenthesis).

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40631>
_______________________________________

From report at bugs.python.org  Wed Dec 30 18:39:22 2020
From: report at bugs.python.org (Saiyang Gou)
Date: Wed, 30 Dec 2020 23:39:22 +0000
Subject: [issue40631] PEG Parser: Cannot used starred expression in
 parenthesised expr
In-Reply-To: <1589544267.84.0.231872596395.issue40631@roundup.psfhosted.org>
Message-ID: <1609371562.86.0.862632403017.issue40631@roundup.psfhosted.org>


Saiyang Gou <gousaiyang223 at gmail.com> added the comment:

Also the current behavior allows `(*x), y = 1` assignment. If `(*x)` is to be totally disallowed, `(*x), y = 1` should also be rejected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40631>
_______________________________________

From report at bugs.python.org  Wed Dec 30 18:41:18 2020
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 30 Dec 2020 23:41:18 +0000
Subject: [issue40631] PEG Parser: Cannot used starred expression in
 parenthesised expr
In-Reply-To: <1589544267.84.0.231872596395.issue40631@roundup.psfhosted.org>
Message-ID: <1609371678.21.0.702501119083.issue40631@roundup.psfhosted.org>


Guido van Rossum <guido at python.org> added the comment:

> It makes sense to me to be able to do `(*a), b` if I can do `*a, b`, but I don't really have a strong opinion on it.

I disagree. *a is not an expression, so the normal rules for parenthesizing those don't apply. I've always thought of *a as a feature of the "comma" syntax. Note too that (**a) is not valid and never was. Also note that 2.7 doesn't support f((*a)). In fact 3.4 doesn't either -- but 3.5 does.

I don't know how this slipped into earlier Python 3 versions -- apparently there aren't tests for this, and it's not used in popular 3rd code either, or we would have found out when we first implemented PEP 617.

Most likely it's due to the general problem where the parser would just accept parenthesized stuff in various places where it shouldn't (e.g. also f(a=1) could be spelled as f((a)=1) -- this was fixed in 3.8).

> Also the current behavior allows `(*x), y = 1` assignment. If `(*x)` is to be totally disallowed, `(*x), y = 1` should also be rejected.

I agree.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40631>
_______________________________________

From report at bugs.python.org  Wed Dec 30 18:47:00 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Wed, 30 Dec 2020 23:47:00 +0000
Subject: [issue42686] include built-in Math functions in SQLite to 3.35.0 of
 march 2021
In-Reply-To: <1608391961.58.0.717857253057.issue42686@roundup.psfhosted.org>
Message-ID: <1609372020.92.0.449544155543.issue42686@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Using SQLite 3.35.0 nightly build, building Python using PCbuild/build.bat and PCBuild\pcbuild.sln with VS 2017 (does this reflect how the Windows team build the installers?), I can confirm that math functions are _not_ included by default. I added SQLITE_ENABLE_MATH_FUNCTIONS to PCbuild/sqlite3.vcxproj, but then VS 2017 fails building sqlite:

1>------ Rebuild All started: Project: sqlite3, Configuration: Debug Win32 ------
1>sqlite3.c
1>c:\src\cpython.git\externals\sqlite-3.33.0.0\sqlite3.c(119997): error C2099: initializer is not a constant
1>c:\src\cpython.git\externals\sqlite-3.33.0.0\sqlite3.c(119997): warning C4047: 'initializing': 'FuncDef *' differs in levels of indirection from 'void (__cdecl *)(sqlite3_context *,int,sqlite3_value **)'
1>c:\src\cpython.git\externals\sqlite-3.33.0.0\sqlite3.c(119997): warning C4047: 'initializing': 'void (__cdecl *)(sqlite3_context *,int,sqlite3_value **)' differs in levels of indirection from 'char [5]'
1>c:\src\cpython.git\externals\sqlite-3.33.0.0\sqlite3.c(119998): error C2099: initializer is not a constant
1>c:\src\cpython.git\externals\sqlite-3.33.0.0\sqlite3.c(119998): warning C4047: 'initializing': 'FuncDef *' differs in levels of indirection from 'void (__cdecl *)(sqlite3_context *,int,sqlite3_value **)'
1>c:\src\cpython.git\externals\sqlite-3.33.0.0\sqlite3.c(119998): warning C4047: 'initializing': 'void (__cdecl *)(sqlite3_context *,int,sqlite3_value **)' differs in levels of indirection from 'char [8]'
1>c:\src\cpython.git\externals\sqlite-3.33.0.0\sqlite3.c(119999): error C2099: initializer is not a constant
1>c:\src\cpython.git\externals\sqlite-3.33.0.0\sqlite3.c(119999): warning C4047: 'initializing': 'FuncDef *' differs in levels of indirection from 'void (__cdecl *)(sqlite3_context *,int,sqlite3_value **)'
1>c:\src\cpython.git\externals\sqlite-3.33.0.0\sqlite3.c(119999): warning C4047: 'initializing': 'void (__cdecl *)(sqlite3_context *,int,sqlite3_value **)' differs in levels of indirection from 'char [6]'
1>Done building project "sqlite3.vcxproj" -- FAILED.
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

(Note, I've overwritten the files in the externals\sqlite-3.33.0.0 directory with the nightly build.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42686>
_______________________________________

From report at bugs.python.org  Wed Dec 30 19:27:32 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Thu, 31 Dec 2020 00:27:32 +0000
Subject: [issue40631] PEG Parser: Cannot used starred expression in
 parenthesised expr
In-Reply-To: <1589544267.84.0.231872596395.issue40631@roundup.psfhosted.org>
Message-ID: <1609374452.31.0.0795882837005.issue40631@roundup.psfhosted.org>


Lysandros Nikolaou <lisandrosnik at gmail.com> added the comment:

Yup, this all sounds much more reasonable. Thanks for the explanation, Guido.

> Also the current behavior allows `(*x), y = 1` assignment. If `(*x)` is to be totally disallowed, `(*x), y = 1` should also be rejected.

This is allowed in 3.9.1 and 3.10.0a2, but not allowed in 3.9.0 and 3.10.0a1. I'll work on finding out when this got messed up and fix it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40631>
_______________________________________

From report at bugs.python.org  Wed Dec 30 20:19:12 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 31 Dec 2020 01:19:12 +0000
Subject: [issue42772] randrange() mishandles step when stop is None
In-Reply-To: <1609183417.92.0.845527263557.issue42772@roundup.psfhosted.org>
Message-ID: <1609377552.23.0.682835001994.issue42772@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
pull_requests: +22858
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24018

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42772>
_______________________________________

From report at bugs.python.org  Wed Dec 30 20:28:29 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 31 Dec 2020 01:28:29 +0000
Subject: [issue42772] randrange() mishandles step when stop is None
In-Reply-To: <1609183417.92.0.845527263557.issue42772@roundup.psfhosted.org>
Message-ID: <1609378109.7.0.519311456453.issue42772@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

Upon further reflection, I think these cases should raise a TypeError because the meaning is ambiguous:

    randrange(1000, step=10) # Could only mean start=0 stop=1000 step=10

but that conflicts with:

    randrange(1000, None, 100)  # Has no reasonable interpretation

For comparison, this currently raises a TypeError because None isn't a sensible argument for stop:

    range(1000, None, 100)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42772>
_______________________________________

From report at bugs.python.org  Wed Dec 30 20:28:45 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 31 Dec 2020 01:28:45 +0000
Subject: [issue42772] randrange() mishandles step when stop is None
In-Reply-To: <1609183417.92.0.845527263557.issue42772@roundup.psfhosted.org>
Message-ID: <1609378125.72.0.335253522103.issue42772@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/issue42772>
_______________________________________

From report at bugs.python.org  Wed Dec 30 21:04:42 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 31 Dec 2020 02:04:42 +0000
Subject: [issue40631] PEG Parser: Cannot used starred expression in
 parenthesised expr
In-Reply-To: <1589544267.84.0.231872596395.issue40631@roundup.psfhosted.org>
Message-ID: <1609380282.34.0.593095783628.issue40631@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:

> I'll work on finding out when this got messed up and fix it.

Apparently is 

commit bca701403253379409dece03053dbd739c0bd059 (HEAD)
Author: Lysandros Nikolaou <lisandrosnik at gmail.com>
Date:   Tue Oct 27 00:42:04 2020 +0200

    bpo-42123: Run the parser two times and only enable invalid rules on the second run (GH-22111)


~/github/python/master v3.10.0a2~61 9s
? ./python -c "(*x), y = 1,2"

~/github/python/master v3.10.0a2~61
? git checkout HEAD^
Previous HEAD position was bca7014032 bpo-42123: Run the parser two times and only enable invalid rules on the second run (GH-22111)
HEAD is now at c8c4200b65 bpo-42157: Convert unicodedata.UCD to heap type (GH-22991)

~/github/python/master remotes/welikeparsers/master
? make -j -s
 CC='gcc -pthread' LDSHARED='gcc -pthread -shared    ' OPT='-g -Og -Wall'       _TCLTK_INCLUDES='' _TCLTK_LIBS=''       ./python -E ./setup.py -q build

The following modules found by detect_modules() in setup.py, have been
built by the Makefile instead, as configured by the Setup files:
_abc                  atexit                pwd
time


~/github/python/master remotes/welikeparsers/master
? ./python -c "(*x), y = 1,2"
  File "<string>", line 1
    (*x), y = 1,2
     ^
SyntaxError: can't use starred expression here

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40631>
_______________________________________

From report at bugs.python.org  Wed Dec 30 22:05:31 2020
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 31 Dec 2020 03:05:31 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1609383931.62.0.0746488403476.issue29708@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

See bpo-34093 too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Wed Dec 30 22:10:25 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 31 Dec 2020 03:10:25 +0000
Subject: [issue40631] PEG Parser: Cannot used starred expression in
 parenthesised expr
In-Reply-To: <1589544267.84.0.231872596395.issue40631@roundup.psfhosted.org>
Message-ID: <1609384225.9.0.751094654825.issue40631@roundup.psfhosted.org>


Change by Pablo Galindo Salgado <pablogsal at gmail.com>:


----------
pull_requests: +22859
pull_request: https://github.com/python/cpython/pull/24019

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40631>
_______________________________________

From report at bugs.python.org  Wed Dec 30 23:23:39 2020
From: report at bugs.python.org (Raymond Sit)
Date: Thu, 31 Dec 2020 04:23:39 +0000
Subject: [issue41884] tempfile.py TemporaryDirectory/mkdtemp defaults to mode
 0o700, propose to add mode argument
In-Reply-To: <1601384162.52.0.6703641276.issue41884@roundup.psfhosted.org>
Message-ID: <1609388619.58.0.26590446632.issue41884@roundup.psfhosted.org>


Change by Raymond Sit <raysit555 at gmail.com>:


----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41884>
_______________________________________

From report at bugs.python.org  Thu Dec 31 03:07:35 2020
From: report at bugs.python.org (Frederik Rietdijk)
Date: Thu, 31 Dec 2020 08:07:35 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1609402055.83.0.583953779872.issue29708@roundup.psfhosted.org>


Frederik Rietdijk <fridh at fridh.nl> added the comment:

note the optimized .pyc is deterministic. As far as I know only __debug__ is set to False, or is there something else different?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Thu Dec 31 03:10:49 2020
From: report at bugs.python.org (Narek)
Date: Thu, 31 Dec 2020 08:10:49 +0000
Subject: [issue42793] Bug of round function
Message-ID: <1609402249.13.0.578194517068.issue42793@roundup.psfhosted.org>


New submission from Narek <artikcinarek2006 at gmail.com>:

The my code is folowing

for i in range(1, 5):
    a = i + 0.5
    b = round(a)
    print(a, "rounded as =>", b)

output is

1.5 => 2
2.5 => 2
3.5 => 4
4.5 => 4

the rounding is not correct in output

----------
files: main.py
messages: 384101
nosy: Narek2018
priority: normal
severity: normal
status: open
title: Bug of round function
type: performance
versions: Python 3.9
Added file: https://bugs.python.org/file49711/main.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42793>
_______________________________________

From report at bugs.python.org  Thu Dec 31 03:45:06 2020
From: report at bugs.python.org (Dennis Sweeney)
Date: Thu, 31 Dec 2020 08:45:06 +0000
Subject: [issue42793] Bug of round function
In-Reply-To: <1609402249.13.0.578194517068.issue42793@roundup.psfhosted.org>
Message-ID: <1609404306.6.0.625064463515.issue42793@roundup.psfhosted.org>


Dennis Sweeney <sweeney.dennis650 at gmail.com> added the comment:

This is not a bug. See https://stackoverflow.com/a/10825998/11461120

----------
nosy: +Dennis Sweeney

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42793>
_______________________________________

From report at bugs.python.org  Thu Dec 31 04:00:22 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 31 Dec 2020 09:00:22 +0000
Subject: [issue42793] Bug of round function
In-Reply-To: <1609402249.13.0.578194517068.issue42793@roundup.psfhosted.org>
Message-ID: <1609405222.25.0.718565907355.issue42793@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

It works as documented. https://docs.python.org/3/library/functions.html#round

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42793>
_______________________________________

From report at bugs.python.org  Thu Dec 31 04:06:37 2020
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 31 Dec 2020 09:06:37 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1609405597.29.0.228018138706.issue29708@roundup.psfhosted.org>


Inada Naoki <songofacandy at gmail.com> added the comment:

> note the optimized .pyc is deterministic. As far as I know only __debug__ is set to False, or is there something else different?

There is no difference between normal pyc and optimized pyc.

* frozenset is deterministic if PYTHONHASHSEED is set
* FLAG_REF is unstable. It is based on reference count but it is changed by various environment (environment variables, build path, order of py files, and any other thing using interned strings). bpo-30493 must be fixed.

----------
versions: +Python 3.10 -Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Thu Dec 31 04:06:54 2020
From: report at bugs.python.org (Inada Naoki)
Date: Thu, 31 Dec 2020 09:06:54 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1609405614.67.0.0265236198982.issue29708@roundup.psfhosted.org>


Change by Inada Naoki <songofacandy at gmail.com>:


----------
dependencies: +Reproducible pyc: FLAG_REF is not stable.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Thu Dec 31 04:20:13 2020
From: report at bugs.python.org (Albert Zeyer)
Date: Thu, 31 Dec 2020 09:20:13 +0000
Subject: [issue37157] shutil: add reflink=False to file copy functions to
 control clone/CoW copies (use copy_file_range)
In-Reply-To: <1559684200.61.0.18008315195.issue37157@roundup.psfhosted.org>
Message-ID: <1609406413.2.0.610785307668.issue37157@roundup.psfhosted.org>


Albert Zeyer <albzey at googlemail.com> added the comment:

I did some further research (with all details here: https://stackoverflow.com/a/65518879/133374).

See vfs_copy_file_range in the Linux kernel. This first tries to call remap_file_range if possible.

FICLONE calls ioctl_file_clone. ioctl_file_clone calls vfs_clone_file_range. vfs_clone_file_range calls remap_file_range. I.e. FICLONE == remap_file_range.

So using copy_file_range (if available) should be the most generic solution, which includes copy-on-write support, and server-side copy support.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37157>
_______________________________________

From report at bugs.python.org  Thu Dec 31 04:36:38 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 31 Dec 2020 09:36:38 +0000
Subject: [issue42794] test_nntplib fails on CI
Message-ID: <1609407398.52.0.195663540983.issue42794@roundup.psfhosted.org>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Since yesterday ALL PRs are blocked by failing test_nntplib.

For example https://github.com/python/cpython/runs/1629664606?check_suite_focus=true:

======================================================================
ERROR: test_descriptions (test.test_nntplib.NetworkedNNTP_SSLTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/runner/work/cpython/cpython/Lib/test/test_nntplib.py", line 250, in wrapped
    meth(self)
  File "/home/runner/work/cpython/cpython/Lib/test/test_nntplib.py", line 99, in test_descriptions
    desc = descs[self.GROUP_NAME]
KeyError: 'comp.lang.python'

======================================================================
FAIL: test_description (test.test_nntplib.NetworkedNNTP_SSLTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/runner/work/cpython/cpython/Lib/test/test_nntplib.py", line 250, in wrapped
    meth(self)
  File "/home/runner/work/cpython/cpython/Lib/test/test_nntplib.py", line 85, in test_description
    self.assertIn("Python", desc)
AssertionError: 'Python' not found in ''

----------------------------------------------------------------------

----------
components: Tests
messages: 384106
nosy: serhiy.storchaka
priority: critical
severity: normal
status: open
title: test_nntplib fails on CI
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42794>
_______________________________________

From report at bugs.python.org  Thu Dec 31 04:44:56 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 31 Dec 2020 09:44:56 +0000
Subject: [issue39068] Base 85 encoding initialization race condition
In-Reply-To: <1576518904.56.0.627490233403.issue39068@roundup.psfhosted.org>
Message-ID: <1609407896.91.0.692426480783.issue39068@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 9655434cca5dfbea97bf6d355aec028e840b289c by Brandon Stansbury in branch 'master':
bpo-39068: Fix race condition in base64 (GH-17627)
https://github.com/python/cpython/commit/9655434cca5dfbea97bf6d355aec028e840b289c


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39068>
_______________________________________

From report at bugs.python.org  Thu Dec 31 04:47:28 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 31 Dec 2020 09:47:28 +0000
Subject: [issue39068] Base 85 encoding initialization race condition
In-Reply-To: <1576518904.56.0.627490233403.issue39068@roundup.psfhosted.org>
Message-ID: <1609408048.23.0.0664969239063.issue39068@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
keywords: +patch
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +22860
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24020

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39068>
_______________________________________

From report at bugs.python.org  Thu Dec 31 05:11:26 2020
From: report at bugs.python.org (Alex Garel)
Date: Thu, 31 Dec 2020 10:11:26 +0000
Subject: [issue40512] [subinterpreters] Meta issue: per-interpreter GIL
In-Reply-To: <1588683075.13.0.0239787407564.issue40512@roundup.psfhosted.org>
Message-ID: <1609409486.22.0.286159028707.issue40512@roundup.psfhosted.org>


Change by Alex Garel <alex at garel.org>:


----------
nosy: +alex-garel

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40512>
_______________________________________

From report at bugs.python.org  Thu Dec 31 06:09:27 2020
From: report at bugs.python.org (Pandu E POLUAN)
Date: Thu, 31 Dec 2020 11:09:27 +0000
Subject: [issue27820] Possible bug in smtplib when initial_response_ok=False
In-Reply-To: <1471739698.94.0.271523306415.issue27820@psf.upfronthosting.co.za>
Message-ID: <1609412967.23.0.0403305393659.issue27820@roundup.psfhosted.org>


Pandu E POLUAN <pepoluan at gmail.com> added the comment:

I tried adding the code below to test_smtplib.py:

    def testAUTH_LOGIN_initial_response_notok(self):
        self.serv.add_feature("AUTH LOGIN")
        smtp = smtplib.SMTP(HOST, self.port, local_hostname='localhost',
                            timeout=support.LOOPBACK_TIMEOUT)
        resp = smtp.login(sim_auth[0], sim_auth[1], initial_response_ok=False)
        self.assertEqual(resp, (235, b'Authentication Succeeded'))
        smtp.close()

and I ended up with:

======================================================================
ERROR: testAUTH_LOGIN_initial_response_notok (test.test_smtplib.SMTPSimTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/pepoluan/projects/cpython/Lib/test/test_smtplib.py", line 1065, in testAUTH_LOGIN_initial_response_notok
    resp = smtp.login(sim_auth[0], sim_auth[1], initial_response_ok=False)
  File "/home/pepoluan/projects/cpython/Lib/smtplib.py", line 738, in login
    raise last_exception
  File "/home/pepoluan/projects/cpython/Lib/smtplib.py", line 727, in login
    (code, resp) = self.auth(
  File "/home/pepoluan/projects/cpython/Lib/smtplib.py", line 650, in auth
    raise SMTPAuthenticationError(code, resp)
smtplib.SMTPAuthenticationError: (451, b'Internal confusion')

----------------------------------------------------------------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue27820>
_______________________________________

From report at bugs.python.org  Thu Dec 31 06:37:17 2020
From: report at bugs.python.org (Paolo Lammens)
Date: Thu, 31 Dec 2020 11:37:17 +0000
Subject: [issue42795] Asyncio loop.create_server doesn't bind to any interface
 if host is a sequence with jus the empty string
Message-ID: <1609414637.07.0.323924138606.issue42795@roundup.psfhosted.org>


New submission from Paolo Lammens <lammenspaolo at gmail.com>:

When a sequence containing just the empty string (e.g. `['']`) is passed as the `host` parameter of `loop.create_server`, the server seems not to bind to any network interface. Since, per the [documentation](https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.loop.create_server) for `create_server`, the empty string means "bind to all interfaces", 

> If host is an empty string or None all interfaces are assumed and a list of multiple 
> sockets will be returned (most likely one for IPv4 and another one for IPv6).


and also

> The host parameter can also be a sequence (e.g. list) of hosts to bind to.

I would have expected a list containing the empty string to also work as expected, i.e. "binding to all hosts in the sequence", so binding to "" and thus to every interface.

Example:

Server script:

```python
import asyncio


async def server():
    async def connection_callback(reader, writer: asyncio.StreamWriter):
        print(f"got connection from {writer.get_extra_info('peername')}")
        writer.close()
        await writer.wait_closed()

    s = await asyncio.start_server(connection_callback, host=[''], port=4567)
    async with s:
        print("starting server")
        await s.serve_forever()


asyncio.run(server())
```

Client script:

```python
import asyncio


async def client():
    reader, writer = await asyncio.open_connection("127.0.0.1", 4567)
    print(f"connected to {writer.get_extra_info('peername')}")
    writer.close()
    await writer.wait_closed()


asyncio.run(client())
```

Expected:

- Server:
  ```
  starting server
  got connection from ('127.0.0.1', xxxxx)
  ```

- Client:
  ```
  connected to ('127.0.0.1', xxxxx)
  ```

Actual:

- Server:
  ```
  starting server
  ```

- Client: a ConnectionError is raised (the host machine refused the connection)

----------
components: asyncio
messages: 384109
nosy: asvetlov, plammens, yselivanov
priority: normal
severity: normal
status: open
title: Asyncio loop.create_server doesn't bind to any interface if host is a sequence with jus the empty string
type: behavior
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42795>
_______________________________________

From report at bugs.python.org  Thu Dec 31 06:38:06 2020
From: report at bugs.python.org (Paolo Lammens)
Date: Thu, 31 Dec 2020 11:38:06 +0000
Subject: [issue42795] Asyncio loop.create_server doesn't bind to any interface
 if host is a sequence with just the empty string
In-Reply-To: <1609414637.07.0.323924138606.issue42795@roundup.psfhosted.org>
Message-ID: <1609414686.64.0.196116281496.issue42795@roundup.psfhosted.org>


Change by Paolo Lammens <lammenspaolo at gmail.com>:


----------
title: Asyncio loop.create_server doesn't bind to any interface if host is a sequence with jus the empty string -> Asyncio loop.create_server doesn't bind to any interface if host is a sequence with just the empty string

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42795>
_______________________________________

From report at bugs.python.org  Thu Dec 31 07:11:15 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 31 Dec 2020 12:11:15 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1609416675.09.0.105299908733.issue29708@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

> note the optimized .pyc is deterministic. As far as I know only __debug__ is set to False, or is there something else different?

Hum, maybe there is a misunderstanding on the PEP 552 purpose.

I understood that the main point of the PEP 552 is to compare hash(<source code>), rather than checking the .py and .pyc file modification time.

It doesn't magically make the PYC file content fully reproducible. Correct me if I misunderstood PEP 552 as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Thu Dec 31 07:30:06 2020
From: report at bugs.python.org (Ross Rhodes)
Date: Thu, 31 Dec 2020 12:30:06 +0000
Subject: [issue42794] test_nntplib fails on CI
In-Reply-To: <1609407398.52.0.195663540983.issue42794@roundup.psfhosted.org>
Message-ID: <1609417806.4.0.662368918014.issue42794@roundup.psfhosted.org>


Ross Rhodes <ross.rhodes at hotmail.co.uk> added the comment:

Server is returning '215 Newsgroup descriptions in form "group description"', but an empty list of lines, so it's reaching the 'nothing' case in _getdescriptions: https://github.com/python/cpython/blob/master/Lib/nntplib.py#L660

----------
nosy: +trrhodes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42794>
_______________________________________

From report at bugs.python.org  Thu Dec 31 07:32:33 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 31 Dec 2020 12:32:33 +0000
Subject: [issue26407] csv.writer.writerows masks exceptions from __iter__
In-Reply-To: <1456144733.82.0.26880413097.issue26407@psf.upfronthosting.co.za>
Message-ID: <1609417953.09.0.251452334888.issue26407@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +22861
pull_request: https://github.com/python/cpython/pull/24021

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26407>
_______________________________________

From report at bugs.python.org  Thu Dec 31 07:33:40 2020
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 31 Dec 2020 12:33:40 +0000
Subject: [issue42794] test_nntplib fails on CI
In-Reply-To: <1609407398.52.0.195663540983.issue42794@roundup.psfhosted.org>
Message-ID: <1609418020.99.0.947896835719.issue42794@roundup.psfhosted.org>


STINNER Victor <vstinner at python.org> added the comment:

Right now, it works for me:

$ ./python -m test -u all test_nntplib  -v -m test_descriptions
...
test_descriptions (test.test_nntplib.NNTPv1Tests) ... ok
test_descriptions (test.test_nntplib.NNTPv2Tests) ... ok
test_descriptions (test.test_nntplib.NetworkedNNTPTests) ... ok
skipped "<class 'test.test_nntplib.NetworkedNNTP_SSLTests'> got [SSL: DH_KEY_TOO_SMALL] dh key too small (_ssl.c:1122) connecting to 'nntp.aioe.org'"
...
Tests result: SUCCESS

----------
nosy: +vstinner

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42794>
_______________________________________

From report at bugs.python.org  Thu Dec 31 07:37:08 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 31 Dec 2020 12:37:08 +0000
Subject: [issue39068] Base 85 encoding initialization race condition
In-Reply-To: <1576518904.56.0.627490233403.issue39068@roundup.psfhosted.org>
Message-ID: <1609418228.28.0.054501190817.issue39068@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +22862
pull_request: https://github.com/python/cpython/pull/24022

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue39068>
_______________________________________

From report at bugs.python.org  Thu Dec 31 07:42:32 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 31 Dec 2020 12:42:32 +0000
Subject: [issue36589] Incorrect error handling in curses.update_lines_cols()
In-Reply-To: <1554923035.79.0.592038232821.issue36589@roundup.psfhosted.org>
Message-ID: <1609418552.03.0.950753205269.issue36589@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +22863
pull_request: https://github.com/python/cpython/pull/24023

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue36589>
_______________________________________

From report at bugs.python.org  Thu Dec 31 07:42:57 2020
From: report at bugs.python.org (Irit Katriel)
Date: Thu, 31 Dec 2020 12:42:57 +0000
Subject: [issue15097] Improving wording on the thread-safeness of import
In-Reply-To: <1339943036.28.0.366324520843.issue15097@psf.upfronthosting.co.za>
Message-ID: <1609418577.29.0.00526796137435.issue15097@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

The threading doc no longer mentions import at all. Any objections to closing this issue as out of date?  Or is there anything else to look into here?

----------
nosy: +iritkatriel
resolution:  -> out of date
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue15097>
_______________________________________

From report at bugs.python.org  Thu Dec 31 07:45:33 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 31 Dec 2020 12:45:33 +0000
Subject: [issue41401] Using non-ascii that require UTF-8 breaks AIX testing
In-Reply-To: <1595772423.92.0.81107313537.issue41401@roundup.psfhosted.org>
Message-ID: <1609418733.56.0.958259955007.issue41401@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +22864
pull_request: https://github.com/python/cpython/pull/24024

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41401>
_______________________________________

From report at bugs.python.org  Thu Dec 31 07:50:44 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 31 Dec 2020 12:50:44 +0000
Subject: [issue42425] Possible leak in initialization of errmap for OSError
In-Reply-To: <1605970873.69.0.937757784906.issue42425@roundup.psfhosted.org>
Message-ID: <1609419044.74.0.045422551176.issue42425@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +22865
pull_request: https://github.com/python/cpython/pull/24025

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42425>
_______________________________________

From report at bugs.python.org  Thu Dec 31 07:57:49 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 31 Dec 2020 12:57:49 +0000
Subject: [issue42794] test_nntplib fails on CI
In-Reply-To: <1609407398.52.0.195663540983.issue42794@roundup.psfhosted.org>
Message-ID: <1609419469.61.0.954029798316.issue42794@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:

On my computer tests are passed. They are only failed on CI.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42794>
_______________________________________

From report at bugs.python.org  Thu Dec 31 08:01:22 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 31 Dec 2020 13:01:22 +0000
Subject: [issue42759] Take into acount a Tcl interpreter when compare
 variables and fonts
In-Reply-To: <1609100219.29.0.633808020235.issue42759@roundup.psfhosted.org>
Message-ID: <1609419682.61.0.691316167488.issue42759@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
pull_requests: +22866
pull_request: https://github.com/python/cpython/pull/24026

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42759>
_______________________________________

From report at bugs.python.org  Thu Dec 31 08:10:17 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 31 Dec 2020 13:10:17 +0000
Subject: [issue41224] Document is_annotate() in symtable and update doc strings
In-Reply-To: <1594082969.57.0.57546378767.issue41224@roundup.psfhosted.org>
Message-ID: <1609420217.1.0.741723301444.issue41224@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset 7a7f3e0d6a197c81fff83ad777c74324ceb4198f by Andre Delfino in branch '3.9':
[3.9] bpo-41224: Add versionadded for Symbol.is_annotated (GH-23861). (GH-24017)
https://github.com/python/cpython/commit/7a7f3e0d6a197c81fff83ad777c74324ceb4198f


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41224>
_______________________________________

From report at bugs.python.org  Thu Dec 31 08:10:49 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 31 Dec 2020 13:10:49 +0000
Subject: [issue41224] Document is_annotate() in symtable and update doc strings
In-Reply-To: <1594082969.57.0.57546378767.issue41224@roundup.psfhosted.org>
Message-ID: <1609420249.96.0.114468570159.issue41224@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset bc15cdbc6eb112cb72acf189769ecd539dd45652 by Andre Delfino in branch '3.8':
[3.8] bpo-41224: Add versionadded for Symbol.is_annotated (GH-23861). (GH-24016)
https://github.com/python/cpython/commit/bc15cdbc6eb112cb72acf189769ecd539dd45652


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41224>
_______________________________________

From report at bugs.python.org  Thu Dec 31 08:16:56 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 31 Dec 2020 13:16:56 +0000
Subject: [issue42393] Raise overflow errors iso. deprecation warnings in
 socket.htons and socket.ntohs (was deprecated in 3.7)
In-Reply-To: <1605646569.63.0.541454109275.issue42393@roundup.psfhosted.org>
Message-ID: <1609420616.18.0.0511817055921.issue42393@roundup.psfhosted.org>


Serhiy Storchaka <storchaka+cpython at gmail.com> added the comment:


New changeset f4936ad1c4d0ae1948e428aeddc7d3096252dae4 by Erlend Egeberg Aasland in branch 'master':
bpo-42393: Raise OverflowError iso. DeprecationWarning on overflow in socket.ntohs and socket.htons (GH-23980)
https://github.com/python/cpython/commit/f4936ad1c4d0ae1948e428aeddc7d3096252dae4


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42393>
_______________________________________

From report at bugs.python.org  Thu Dec 31 08:49:15 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 31 Dec 2020 13:49:15 +0000
Subject: [issue42393] Raise overflow errors iso. deprecation warnings in
 socket.htons and socket.ntohs (was deprecated in 3.7)
In-Reply-To: <1605646569.63.0.541454109275.issue42393@roundup.psfhosted.org>
Message-ID: <1609422555.41.0.0216061716304.issue42393@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/issue42393>
_______________________________________

From report at bugs.python.org  Thu Dec 31 08:50:01 2020
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 31 Dec 2020 13:50:01 +0000
Subject: [issue41224] Document is_annotate() in symtable and update doc strings
In-Reply-To: <1594082969.57.0.57546378767.issue41224@roundup.psfhosted.org>
Message-ID: <1609422601.9.0.675704520262.issue41224@roundup.psfhosted.org>


Change by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue41224>
_______________________________________

From report at bugs.python.org  Thu Dec 31 08:51:57 2020
From: report at bugs.python.org (Kurochan)
Date: Thu, 31 Dec 2020 13:51:57 +0000
Subject: [issue42257] platform.libc_ver() doesn't consider in case of
 executable is empty string
In-Reply-To: <1604469715.55.0.889552705694.issue42257@roundup.psfhosted.org>
Message-ID: <1609422717.56.0.245746684815.issue42257@roundup.psfhosted.org>


Kurochan <kuro at kurochan.org> added the comment:

> If Python is embedded

Yes. It's embedded Python.
This issue caused in datadog-agent with embedded Python.
https://github.com/DataDog/datadog-agent/

>  would it be possible to share the code used to configure Python initialization?
I'm not sure where the Python installation code is. Maybe it's around here.
https://github.com/DataDog/datadog-agent/blob/master/docs/dev/agent_omnibus.md

https://github.com/DataDog/datadog-agent/blob/master/omnibus/config/software/python3.rb

datadog-agent's official install script is here.
https://s3.amazonaws.com/dd-agent/scripts/install_script.sh

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42257>
_______________________________________

From report at bugs.python.org  Thu Dec 31 09:00:50 2020
From: report at bugs.python.org (Irit Katriel)
Date: Thu, 31 Dec 2020 14:00:50 +0000
Subject: [issue19206] Support disabling file I/O when doing traceback
 formatting
In-Reply-To: <1381324623.16.0.375897659555.issue19206@psf.upfronthosting.co.za>
Message-ID: <1609423250.14.0.570803464794.issue19206@roundup.psfhosted.org>


Change by Irit Katriel <iritkatriel at yahoo.com>:


----------
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue19206>
_______________________________________

From report at bugs.python.org  Thu Dec 31 09:07:25 2020
From: report at bugs.python.org (Irit Katriel)
Date: Thu, 31 Dec 2020 14:07:25 +0000
Subject: [issue26454] add support string that are not inherited from
 PyStringObject
In-Reply-To: <1456664775.79.0.943467327671.issue26454@psf.upfronthosting.co.za>
Message-ID: <1609423645.18.0.953135106303.issue26454@roundup.psfhosted.org>


Irit Katriel <iritkatriel at yahoo.com> added the comment:

If you are still having an issue with this, please create a new ticket and explain better what the problem is. Ideally, attach code that demonstrates the problem (along with what you expected the code to do and what it actually does, and state which system and python version you are seeing the issue on).

----------
resolution:  -> rejected
stage:  -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26454>
_______________________________________

From report at bugs.python.org  Thu Dec 31 09:10:48 2020
From: report at bugs.python.org (Kurochan)
Date: Thu, 31 Dec 2020 14:10:48 +0000
Subject: [issue42257] platform.libc_ver() doesn't consider in case of
 executable is empty string
In-Reply-To: <1604469715.55.0.889552705694.issue42257@roundup.psfhosted.org>
Message-ID: <1609423848.31.0.0508043795222.issue42257@roundup.psfhosted.org>


Kurochan <kuro at kurochan.org> added the comment:

Also, PR comment processed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42257>
_______________________________________

From report at bugs.python.org  Thu Dec 31 09:16:33 2020
From: report at bugs.python.org (Rahul Jha)
Date: Thu, 31 Dec 2020 14:16:33 +0000
Subject: [issue12915] Add inspect.locate and inspect.resolve
In-Reply-To: <1315326633.9.0.910127000285.issue12915@psf.upfronthosting.co.za>
Message-ID: <1609424193.05.0.0845112804765.issue12915@roundup.psfhosted.org>


Change by Rahul Jha <rahul722j at gmail.com>:


----------
nosy: +RJ722

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue12915>
_______________________________________

From report at bugs.python.org  Thu Dec 31 09:43:33 2020
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 31 Dec 2020 14:43:33 +0000
Subject: [issue42257] platform.libc_ver() doesn't consider in case of
 executable is empty string
In-Reply-To: <1604469715.55.0.889552705694.issue42257@roundup.psfhosted.org>
Message-ID: <1609425813.87.0.612195206413.issue42257@roundup.psfhosted.org>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Thanks for the patch.

Merging is currently prevented by an unrelated test for nntplib failing. See e.g. https://github.com/python/cpython/pull/23140/checks?check_run_id=1630509357. This is being tracked in https://bugs.python.org/issue42794

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42257>
_______________________________________

From report at bugs.python.org  Thu Dec 31 09:45:49 2020
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 31 Dec 2020 14:45:49 +0000
Subject: [issue42794] test_nntplib fails on CI
In-Reply-To: <1609407398.52.0.195663540983.issue42794@roundup.psfhosted.org>
Message-ID: <1609425949.78.0.0550759026739.issue42794@roundup.psfhosted.org>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

FWIW, I'm getting the same errors in PR https://github.com/python/cpython/pull/23140

Checking on the server that's being used, the newsgroup description is empty indeed: https://news.aioe.org/index.php?id=statistics-about-groups&group=comp.lang.python

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42794>
_______________________________________

From report at bugs.python.org  Thu Dec 31 10:10:28 2020
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 31 Dec 2020 15:10:28 +0000
Subject: [issue29708] support reproducible Python builds
In-Reply-To: <1488540966.18.0.904677570473.issue29708@psf.upfronthosting.co.za>
Message-ID: <1609427428.25.0.708078008138.issue29708@roundup.psfhosted.org>


Benjamin Peterson <benjamin at python.org> added the comment:

PEP 552 was a necessary but not sufficient step on the road towards fully deterministic pycs. The PEP says: "(Note there are other problems [1] [2] we do not address here that can make pycs non-deterministic.)" where [1] and [2] are basically the issues Inada-san has linked.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue29708>
_______________________________________

From report at bugs.python.org  Thu Dec 31 10:26:05 2020
From: report at bugs.python.org (Petr Viktorin)
Date: Thu, 31 Dec 2020 15:26:05 +0000
Subject: [issue30963] xxlimited.c XxoObject_Check should be
 XxoObject_CheckExact
In-Reply-To: <1500412678.84.0.816991478409.issue30963@psf.upfronthosting.co.za>
Message-ID: <1609428365.94.0.42268734671.issue30963@roundup.psfhosted.org>


Petr Viktorin <encukou at gmail.com> added the comment:

The Check code is now commented out, and the issue of type checking is mentioned in PEP 630.
(The xxlimited_35 module still contains XxoObject_Check, among other historical code.)

----------
resolution:  -> postponed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue30963>
_______________________________________

From report at bugs.python.org  Thu Dec 31 10:34:15 2020
From: report at bugs.python.org (Lysandros Nikolaou)
Date: Thu, 31 Dec 2020 15:34:15 +0000
Subject: [issue40631] PEG Parser: Cannot used starred expression in
 parenthesised expr
In-Reply-To: <1589544267.84.0.231872596395.issue40631@roundup.psfhosted.org>
Message-ID: <1609428855.07.0.471304273845.issue40631@roundup.psfhosted.org>


Change by Lysandros Nikolaou <lisandrosnik at gmail.com>:


----------
pull_requests: +22867
pull_request: https://github.com/python/cpython/pull/24027

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue40631>
_______________________________________

From report at bugs.python.org  Thu Dec 31 10:44:23 2020
From: report at bugs.python.org (Gabriele Tornetta)
Date: Thu, 31 Dec 2020 15:44:23 +0000
Subject: [issue42796] tempfile doesn't seem to play nicely with os.chdir on
 Windows
Message-ID: <1609429462.99.0.549073524259.issue42796@roundup.psfhosted.org>


New submission from Gabriele Tornetta <phoenix1987 at gmail.com>:

The following script causes havoc on Windows while it works as expected on  Linux

~~~ python
import os
import tempfile


def test_chdir():
    with tempfile.TemporaryDirectory() as tempdir:
        os.chdir(tempdir)
~~~

Running the above on Windows results in RecursionError: maximum recursion depth exceeded while calling a Python object (see attachment for the full stacktrace).

----------
components: Library (Lib)
files: tempfile_st.txt
messages: 384125
nosy: Gabriele Tornetta
priority: normal
severity: normal
status: open
title: tempfile doesn't seem to play nicely with os.chdir on Windows
type: crash
versions: Python 3.9
Added file: https://bugs.python.org/file49712/tempfile_st.txt

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42796>
_______________________________________

From report at bugs.python.org  Thu Dec 31 12:57:08 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 31 Dec 2020 17:57:08 +0000
Subject: [issue42382] No easy way to get the distribution which provided a
 importlib.metadata.EntryPoint
In-Reply-To: <1605596181.46.0.7808505308.issue42382@roundup.psfhosted.org>
Message-ID: <1609437428.51.0.812539201981.issue42382@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:


New changeset dfdca85dfa64e72df385b3a486f85b773fc0f135 by Jason R. Coombs in branch 'master':
bpo-42382: In importlib.metadata, `EntryPoint` objects now expose `dist` (#23758)
https://github.com/python/cpython/commit/dfdca85dfa64e72df385b3a486f85b773fc0f135


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42382>
_______________________________________

From report at bugs.python.org  Thu Dec 31 13:05:13 2020
From: report at bugs.python.org (Batuhan Taskaya)
Date: Thu, 31 Dec 2020 18:05:13 +0000
Subject: [issue42454] Move slice creation to the compiler for constants
In-Reply-To: <1606237897.31.0.957567165008.issue42454@roundup.psfhosted.org>
Message-ID: <1609437913.63.0.250834614327.issue42454@roundup.psfhosted.org>


Batuhan Taskaya <isidentical at gmail.com> added the comment:

I've given this another shot, but even though I was able to create a patch that preserved slices as (type(slice), start, stop, step) tuples in the consts_cache, this final optimization prevented me to finalize it; ?https://github.com/python/cpython/blob/master/Python/compile.c#L5855-L5858

So, unless anyone else came up with a reasonable idea to do this optimization at the compile-time without actually making them hashable, I am re-proposing the idea of making them hashable.

Pro:
  - Up to %30+ speedup on slicing with constants (extremely common)
Cons:
  - Mappings accepts slices, which would rarely lead some esoteric cases (like the examples given)

Comments would be appreciated

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42454>
_______________________________________

From report at bugs.python.org  Thu Dec 31 13:57:21 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 31 Dec 2020 18:57:21 +0000
Subject: [issue38780] SysLogHandler crash atexit
In-Reply-To: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>
Message-ID: <1609441041.77.0.781597054264.issue38780@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I started work on a test in https://github.com/jaraco/cpython/tree/bugfix/bpo-38780-test, but (a) the test was failing to exhibit the expected failures, and (b) I realized that the fix isn't having the intended effect either, because for unix sockets, [self.socket is unconditionally set](https://github.com/python/cpython/blob/dfdca85dfa64e72df385b3a486f85b773fc0f135/Lib/logging/handlers.py#L872), overriding any NullSocket or None value.

The SysLogHandler code will need to be reorganized if self.socket is intended to model two modes (broken and initialized).

I'm not sure when I'll get another chance to take a look at this, but I'll not be able to wrap it up today, so I'm going to unassign it for now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38780>
_______________________________________

From report at bugs.python.org  Thu Dec 31 13:57:31 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 31 Dec 2020 18:57:31 +0000
Subject: [issue38780] SysLogHandler crash atexit
In-Reply-To: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>
Message-ID: <1609441051.09.0.70041427079.issue38780@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
assignee: jaraco -> 

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38780>
_______________________________________

From report at bugs.python.org  Thu Dec 31 13:57:44 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 31 Dec 2020 18:57:44 +0000
Subject: [issue38780] SysLogHandler crash atexit
In-Reply-To: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>
Message-ID: <1609441064.47.0.295116307997.issue38780@roundup.psfhosted.org>


Change by Jason R. Coombs <jaraco at jaraco.com>:


----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38780>
_______________________________________

From report at bugs.python.org  Thu Dec 31 14:08:11 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 31 Dec 2020 19:08:11 +0000
Subject: [issue42189] copy.deepcopy() no longer works on platform.uname_result
 objects
In-Reply-To: <1603936415.14.0.266024580779.issue42189@roundup.psfhosted.org>
Message-ID: <1609441691.31.0.171672825634.issue42189@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:


New changeset a6fd0f414c0cb4cd5cc20eb2df3340b31c6f7743 by Jason R. Coombs in branch 'master':
bpo-42163, bpo-42189, bpo-42659: Support uname_tuple._replace (for all but processor) (#23010)
https://github.com/python/cpython/commit/a6fd0f414c0cb4cd5cc20eb2df3340b31c6f7743


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42189>
_______________________________________

From report at bugs.python.org  Thu Dec 31 14:08:11 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 31 Dec 2020 19:08:11 +0000
Subject: [issue42659] Objects of uname_result Class Cannot be Successfully
 Pickled
In-Reply-To: <1608131578.78.0.823168956156.issue42659@roundup.psfhosted.org>
Message-ID: <1609441691.35.0.751213344368.issue42659@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:


New changeset a6fd0f414c0cb4cd5cc20eb2df3340b31c6f7743 by Jason R. Coombs in branch 'master':
bpo-42163, bpo-42189, bpo-42659: Support uname_tuple._replace (for all but processor) (#23010)
https://github.com/python/cpython/commit/a6fd0f414c0cb4cd5cc20eb2df3340b31c6f7743


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42659>
_______________________________________

From report at bugs.python.org  Thu Dec 31 14:08:11 2020
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 31 Dec 2020 19:08:11 +0000
Subject: [issue42163] _replace() no longer works on platform.uname_result
 objects
In-Reply-To: <1603750912.81.0.950571190169.issue42163@roundup.psfhosted.org>
Message-ID: <1609441691.23.0.0897365705931.issue42163@roundup.psfhosted.org>


Jason R. Coombs <jaraco at jaraco.com> added the comment:


New changeset a6fd0f414c0cb4cd5cc20eb2df3340b31c6f7743 by Jason R. Coombs in branch 'master':
bpo-42163, bpo-42189, bpo-42659: Support uname_tuple._replace (for all but processor) (#23010)
https://github.com/python/cpython/commit/a6fd0f414c0cb4cd5cc20eb2df3340b31c6f7743


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42163>
_______________________________________

From report at bugs.python.org  Thu Dec 31 14:18:13 2020
From: report at bugs.python.org (Costas Basdekis)
Date: Thu, 31 Dec 2020 19:18:13 +0000
Subject: [issue42797] Allow doctest to select tests via -m/--match option
Message-ID: <1609442293.63.0.396324558319.issue42797@roundup.psfhosted.org>


New submission from Costas Basdekis <costas.basdekis at gmail.com>:

Most testing frameworks allow for only a subset of tests to be run, and the reason is usually either to focus on a specific test among many failing ones, or for speed purposes if running the whole suite is too slow.

With doctests, it's usually the case that the are light and fast, but if you make a breaking change you can still have many tests failing, and you want to focus only on one.

This proposition adds an `-m`/`--match` option to the doctest runner, to allow to select 1 or more specific tests to run.

The proposed format for the parameters is :
* <test-name-suffix>:<indexes>
* <test-name-suffix> is a glob-like string where '*' characters can match any substring of a test's name, and an '*' is implicitly added to the start of the pattern: eg 'do_*_method' matches '__main__.do_a_method' and '__main__.MyClass.do_b_method'
* <indexes> is a list of numbers or ranges to match the 0-based index examples within the test:  eg '1' matches the second example, `-3` matches the first 4 examples, '4-` matches all but the first 4 examples, and `-3,5,7-10,20-` matches examples 0, 1, 2, 3, 5, 7, 8, 9, 10, 20, and the rest

----------
components: Tests
messages: 384132
nosy: costas-basdekis
priority: normal
severity: normal
status: open
title: Allow doctest to select tests via -m/--match option
type: enhancement
versions: Python 3.10

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42797>
_______________________________________

From report at bugs.python.org  Thu Dec 31 14:20:11 2020
From: report at bugs.python.org (Paul Watson)
Date: Thu, 31 Dec 2020 19:20:11 +0000
Subject: [issue42798] pip search fails
Message-ID: <1609442411.49.0.32642630503.issue42798@roundup.psfhosted.org>


New submission from Paul Watson <paul.hermeneutic at gmail.com>:

Fresh install of 3.9.1
Created venv
Activated venv

(py3.9) 13:12:59.52  C:\venv\py3.9\Scripts
C:>pip search astronomy
ERROR: Exception:
Traceback (most recent call last):
  File "c:\venv\py3.9\lib\site-packages\pip\_internal\cli\base_command.py", line 228, in _main
    status = self.run(options, args)
  File "c:\venv\py3.9\lib\site-packages\pip\_internal\commands\search.py", line 60, in run
    pypi_hits = self.search(query, options)
  File "c:\venv\py3.9\lib\site-packages\pip\_internal\commands\search.py", line 80, in search
    hits = pypi.search({'name': query, 'summary': query}, 'or')
  File "C:\Users\mike\AppData\Local\Programs\Python\Python39\lib\xmlrpc\client.py", line 1116, in __call__
    return self.__send(self.__name, args)
  File "C:\Users\mike\AppData\Local\Programs\Python\Python39\lib\xmlrpc\client.py", line 1456, in __request
    response = self.__transport.request(
  File "c:\venv\py3.9\lib\site-packages\pip\_internal\network\xmlrpc.py", line 45, in request
    return self.parse_response(response.raw)
  File "C:\Users\mike\AppData\Local\Programs\Python\Python39\lib\xmlrpc\client.py", line 1348, in parse_response
    return u.close()
  File "C:\Users\mike\AppData\Local\Programs\Python\Python39\lib\xmlrpc\client.py", line 662, in close
    raise Fault(**self._stack[0])
xmlrpc.client.Fault: <Fault -32500: "RuntimeError: PyPI's XMLRPC API has been temporarily disabled due to unmanageable load and will be deprecated in the near future. See https://status.python.org/ for more information.">

(py3.9) 13:13:08.09  C:\venv\py3.9\Scripts
C:>python --version
Python 3.9.1

----------
components: Demos and Tools
messages: 384133
nosy: Paul Watson
priority: normal
severity: normal
status: open
title: pip search fails
type: crash
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42798>
_______________________________________

From report at bugs.python.org  Thu Dec 31 14:23:22 2020
From: report at bugs.python.org (Costas Basdekis)
Date: Thu, 31 Dec 2020 19:23:22 +0000
Subject: [issue42797] Allow doctest to select tests via -m/--match option
In-Reply-To: <1609442293.63.0.396324558319.issue42797@roundup.psfhosted.org>
Message-ID: <1609442602.68.0.629580241208.issue42797@roundup.psfhosted.org>


Change by Costas Basdekis <costas.basdekis at gmail.com>:


----------
keywords: +patch
pull_requests: +22868
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24028

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42797>
_______________________________________

From report at bugs.python.org  Thu Dec 31 14:35:39 2020
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 31 Dec 2020 19:35:39 +0000
Subject: [issue42728] Typo in documentation: importlib.metadata
In-Reply-To: <1608794693.94.0.363783921808.issue42728@roundup.psfhosted.org>
Message-ID: <1609443339.77.0.592643205697.issue42728@roundup.psfhosted.org>


Change by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry, jaraco

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42728>
_______________________________________

From report at bugs.python.org  Thu Dec 31 14:36:37 2020
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 31 Dec 2020 19:36:37 +0000
Subject: [issue42454] Move slice creation to the compiler for constants
In-Reply-To: <1606237897.31.0.957567165008.issue42454@roundup.psfhosted.org>
Message-ID: <1609443397.76.0.472176848603.issue42454@roundup.psfhosted.org>


Mark Dickinson <dickinsm at gmail.com> added the comment:

@Batuhan Taskaya: would it be worth starting a discussion on either python-ideas or python-dev? (Or on discuss.python.org.)

My concern is that we're discussing a core language change. It's not a major change, but it's not an insignificant one either, and right now the discussion is buried in an issue whose description and "Type" category suggest that it's purely about performance - those giving this issue a casual glance may not realise that there's a language change involved.

I don't have strong opinions on the change itself either way, but others might have.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42454>
_______________________________________

From report at bugs.python.org  Thu Dec 31 14:39:30 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 31 Dec 2020 19:39:30 +0000
Subject: [issue42728] Typo in documentation: importlib.metadata
In-Reply-To: <1608794693.94.0.363783921808.issue42728@roundup.psfhosted.org>
Message-ID: <1609443570.59.0.889637554148.issue42728@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 6.0 -> 7.0
pull_requests: +22870
pull_request: https://github.com/python/cpython/pull/24029

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42728>
_______________________________________

From report at bugs.python.org  Thu Dec 31 14:40:22 2020
From: report at bugs.python.org (miss-islington)
Date: Thu, 31 Dec 2020 19:40:22 +0000
Subject: [issue42728] Typo in documentation: importlib.metadata
In-Reply-To: <1608794693.94.0.363783921808.issue42728@roundup.psfhosted.org>
Message-ID: <1609443622.51.0.374076883935.issue42728@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22871
pull_request: https://github.com/python/cpython/pull/24030

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42728>
_______________________________________

From report at bugs.python.org  Thu Dec 31 15:19:39 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 31 Dec 2020 20:19:39 +0000
Subject: [issue37193] Memory leak while running TCP/UDPServer with
 socketserver.ThreadingMixIn
In-Reply-To: <1559908419.41.0.390422965351.issue37193@roundup.psfhosted.org>
Message-ID: <1609445979.1.0.999498122628.issue37193@roundup.psfhosted.org>


Pablo Galindo Salgado <pablogsal at gmail.com> added the comment:


New changeset b5711c940f70af89f2b4cf081a3fcd83924f3ae7 by Jason R. Coombs in branch 'master':
bpo-37193: Remove thread objects which finished process its request (GH-23127)
https://github.com/python/cpython/commit/b5711c940f70af89f2b4cf081a3fcd83924f3ae7


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37193>
_______________________________________

From report at bugs.python.org  Thu Dec 31 15:25:41 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Thu, 31 Dec 2020 20:25:41 +0000
Subject: [issue42686] include built-in Math functions in SQLite to 3.35.0 of
 march 2021
In-Reply-To: <1608391961.58.0.717857253057.issue42686@roundup.psfhosted.org>
Message-ID: <1609446341.29.0.825943846582.issue42686@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

FYI, I've opened a thread on the SQLite Forum: https://sqlite.org/forum/forumpost/721645dc36

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42686>
_______________________________________

From report at bugs.python.org  Thu Dec 31 15:26:17 2020
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 31 Dec 2020 20:26:17 +0000
Subject: [issue37193] Memory leak while running TCP/UDPServer with
 socketserver.ThreadingMixIn
In-Reply-To: <1559908419.41.0.390422965351.issue37193@roundup.psfhosted.org>
Message-ID: <1609446377.42.0.796470810347.issue37193@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/issue37193>
_______________________________________

From report at bugs.python.org  Thu Dec 31 15:28:05 2020
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 31 Dec 2020 20:28:05 +0000
Subject: [issue42728] Typo in documentation: importlib.metadata
In-Reply-To: <1608794693.94.0.363783921808.issue42728@roundup.psfhosted.org>
Message-ID: <1609446485.2.0.317821988574.issue42728@roundup.psfhosted.org>


Barry A. Warsaw <barry at python.org> added the comment:

Thanks for the report and fix!

----------
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42728>
_______________________________________

From report at bugs.python.org  Thu Dec 31 15:36:46 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 31 Dec 2020 20:36:46 +0000
Subject: [issue42781] functools.cached_property docs should explain that it is
 non-overriding
In-Reply-To: <1609265578.67.0.475985633003.issue42781@roundup.psfhosted.org>
Message-ID: <1609447006.76.0.23038606131.issue42781@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
keywords: +patch
nosy: +rhettinger
nosy_count: 2.0 -> 3.0
pull_requests: +22872
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/24031

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42781>
_______________________________________

From report at bugs.python.org  Thu Dec 31 15:44:32 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Thu, 31 Dec 2020 20:44:32 +0000
Subject: [issue38780] SysLogHandler crash atexit
In-Reply-To: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>
Message-ID: <1609447472.14.0.86816832343.issue38780@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

I've forked your work, Jason:
https://github.com/erlend-aasland/cpython/tree/bpo-38780-test

I added the test from msg356475, and I'm able to reproduce it by asserting that the `socket` attribute is present (commit f0f8ff8f06afd43947e268824aa4381add05ce8f)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38780>
_______________________________________

From report at bugs.python.org  Thu Dec 31 15:51:23 2020
From: report at bugs.python.org (Erlend Egeberg Aasland)
Date: Thu, 31 Dec 2020 20:51:23 +0000
Subject: [issue38780] SysLogHandler crash atexit
In-Reply-To: <1573579569.01.0.575609345468.issue38780@roundup.psfhosted.org>
Message-ID: <1609447883.86.0.737722766339.issue38780@roundup.psfhosted.org>


Erlend Egeberg Aasland <erlend.aasland at innova.no> added the comment:

Using a NullSocket fixes the test in commit f0f8ff8f06afd43947e268824aa4381add05ce8f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38780>
_______________________________________

From report at bugs.python.org  Thu Dec 31 16:13:36 2020
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 31 Dec 2020 21:13:36 +0000
Subject: [issue26407] csv.writer.writerows masks exceptions from __iter__
In-Reply-To: <1456144733.82.0.26880413097.issue26407@psf.upfronthosting.co.za>
Message-ID: <1609449216.74.0.15439109264.issue26407@roundup.psfhosted.org>


Change by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage: patch review -> commit review
versions:  -Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue26407>
_______________________________________

From report at bugs.python.org  Thu Dec 31 17:14:20 2020
From: report at bugs.python.org (Josh Triplett)
Date: Thu, 31 Dec 2020 22:14:20 +0000
Subject: [issue42799] Please document fnmatch LRU cache size (256) and suggest
 alternatives
Message-ID: <1609452860.68.0.697253388073.issue42799@roundup.psfhosted.org>


New submission from Josh Triplett <josh at joshtriplett.org>:

fnmatch translates shell patterns to regexes, using an LRU cache of 256 elements. The documentation doesn't mention the cache size, just "They cache the compiled regular expressions for speed.". Without this knowledge, it's possible to get pathologically bad performance by exceeding the cache size.

Please consider adding documentation of the cache size to the module documentation for fnmatch, along with a suggestion to use fnmatch.translate directly if you have more patterns than that.

----------
components: Library (Lib)
messages: 384141
nosy: joshtriplett
priority: normal
severity: normal
status: open
title: Please document fnmatch LRU cache size (256) and suggest alternatives
versions: Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42799>
_______________________________________

From report at bugs.python.org  Thu Dec 31 18:39:01 2020
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 31 Dec 2020 23:39:01 +0000
Subject: [issue42797] Allow doctest to select tests via -m/--match option
In-Reply-To: <1609442293.63.0.396324558319.issue42797@roundup.psfhosted.org>
Message-ID: <1609457941.36.0.276598992482.issue42797@roundup.psfhosted.org>


Steven D'Aprano <steve+python at pearwood.info> added the comment:

I think that -m is unacceptable as it will clash with Python's -m option.

I'm not convinced that this added complexity will provide enough benefit to make it worth while. I can see myself spending an order of magnitude more time trying to work out why my test suffixes and indexes are selecting the wrong tests than I would save.

The use of indexes to select individual tests within a single docstring is especially fragile and error-prone since it requires counting by the user. It's also likely to introduce artificial errors since tests can rely on side-effects of previous tests, e.g.

    >>> import math
    >>> math.sqrt(25)
    5.0

Selecting test number 1 alone will fail unless test number 0 is also run. For these reasons, I think that in practice, the finest selection unit we can run is a single docstring. Trying to select individual tests within a unit is likely to be far too fragile and error prone to be practical.

So by my estimation, we have the following selections:

- module docstring alone
- named function or class docstring alone
- named class.method docstring alone
- named class and all its methods

----------
nosy: +steven.daprano, tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42797>
_______________________________________

From report at bugs.python.org  Thu Dec 31 19:16:58 2020
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 01 Jan 2021 00:16:58 +0000
Subject: [issue42800] Traceback objects allow accessing frame objects without
 triggering audit hooks
Message-ID: <1609460218.67.0.01717828776.issue42800@roundup.psfhosted.org>


New submission from Ammar Askar <ammar at ammaraskar.com>:

It is possible to access all the frame objects in the interpret without triggering any audit hooks through the use of exceptions. Namely, through the traceback's tb_frame property. Ordinarily one would trigger the "sys._current_frames" or "sys._getframe" event but this code path bypasses those.

There is already precedent for raising events for certain sensitive properties such as `__code__` in funcobject. (through a "object.__getattr__" event) so perhaps this property should be protected in a similar way.


This issue was recently demonstrated in a security competition:
* https://github.com/hstocks/ctf_writeups/blob/master/2020/hxp/audited/README.md
* https://github.com/fab1ano/hxp-ctf-20/blob/master/audited/README.md

----------
assignee: steve.dower
components: Library (Lib)
keywords: security_issue
messages: 384143
nosy: ammar2, christian.heimes, steve.dower
priority: normal
severity: normal
status: open
title: Traceback objects allow accessing frame objects without triggering audit hooks
type: security
versions: Python 3.10, Python 3.8, Python 3.9

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42800>
_______________________________________

From report at bugs.python.org  Thu Dec 31 19:37:29 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 01 Jan 2021 00:37:29 +0000
Subject: [issue37193] Memory leak while running TCP/UDPServer with
 socketserver.ThreadingMixIn
In-Reply-To: <1559908419.41.0.390422965351.issue37193@roundup.psfhosted.org>
Message-ID: <1609461449.3.0.453381223353.issue37193@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22873
pull_request: https://github.com/python/cpython/pull/24032

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37193>
_______________________________________

From report at bugs.python.org  Thu Dec 31 19:37:39 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 01 Jan 2021 00:37:39 +0000
Subject: [issue37193] Memory leak while running TCP/UDPServer with
 socketserver.ThreadingMixIn
In-Reply-To: <1559908419.41.0.390422965351.issue37193@roundup.psfhosted.org>
Message-ID: <1609461459.72.0.574795965003.issue37193@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
pull_requests: +22874
pull_request: https://github.com/python/cpython/pull/24033

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue37193>
_______________________________________

From report at bugs.python.org  Thu Dec 31 20:00:20 2020
From: report at bugs.python.org (karl)
Date: Fri, 01 Jan 2021 01:00:20 +0000
Subject: [issue25479] Increase unit test coverage for abc.py
In-Reply-To: <1445829241.77.0.00855893760535.issue25479@psf.upfronthosting.co.za>
Message-ID: <1609462820.7.0.503878564456.issue25479@roundup.psfhosted.org>


Change by karl <karl+pythonbugs at la-grange.net>:


----------
keywords: +patch
nosy: +karlcow
nosy_count: 2.0 -> 3.0
pull_requests: +22875
pull_request: https://github.com/python/cpython/pull/24034

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25479>
_______________________________________

From report at bugs.python.org  Thu Dec 31 20:02:14 2020
From: report at bugs.python.org (karl)
Date: Fri, 01 Jan 2021 01:02:14 +0000
Subject: [issue25479] Increase unit test coverage for abc.py
In-Reply-To: <1445829241.77.0.00855893760535.issue25479@psf.upfronthosting.co.za>
Message-ID: <1609462934.22.0.371649383797.issue25479@roundup.psfhosted.org>


karl <karl+pythonbugs at la-grange.net> added the comment:

@iritkatriel Github PR done. 
https://github.com/python/cpython/pull/24034

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue25479>
_______________________________________

From report at bugs.python.org  Thu Dec 31 20:06:07 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 01 Jan 2021 01:06:07 +0000
Subject: [issue42781] functools.cached_property docs should explain that it is
 non-overriding
In-Reply-To: <1609265578.67.0.475985633003.issue42781@roundup.psfhosted.org>
Message-ID: <1609463167.52.0.679839035423.issue42781@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset c8a7b8fa1b5f9a6d3052db792018dc27c5a3a794 by Raymond Hettinger in branch 'master':
bpo-42781: Document the mechanics of cached_property from a user viewpoint (GH-24031)
https://github.com/python/cpython/commit/c8a7b8fa1b5f9a6d3052db792018dc27c5a3a794


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42781>
_______________________________________

From report at bugs.python.org  Thu Dec 31 20:06:41 2020
From: report at bugs.python.org (miss-islington)
Date: Fri, 01 Jan 2021 01:06:41 +0000
Subject: [issue42781] functools.cached_property docs should explain that it is
 non-overriding
In-Reply-To: <1609265578.67.0.475985633003.issue42781@roundup.psfhosted.org>
Message-ID: <1609463201.5.0.721816022991.issue42781@roundup.psfhosted.org>


Change by miss-islington <mariatta.wijaya+miss-islington at gmail.com>:


----------
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +22876
pull_request: https://github.com/python/cpython/pull/24035

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42781>
_______________________________________

From report at bugs.python.org  Thu Dec 31 20:12:21 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 01 Jan 2021 01:12:21 +0000
Subject: [issue42781] functools.cached_property docs should explain that it is
 non-overriding
In-Reply-To: <1609265578.67.0.475985633003.issue42781@roundup.psfhosted.org>
Message-ID: <1609463541.19.0.428516547277.issue42781@roundup.psfhosted.org>


Change by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: docs at python -> rhettinger
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42781>
_______________________________________

From report at bugs.python.org  Thu Dec 31 20:36:21 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 01 Jan 2021 01:36:21 +0000
Subject: [issue42781] functools.cached_property docs should explain that it is
 non-overriding
In-Reply-To: <1609265578.67.0.475985633003.issue42781@roundup.psfhosted.org>
Message-ID: <1609464981.19.0.219567431272.issue42781@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:


New changeset 8333d421c0d7b90de3ff92002af9fd2c5d5f373c by Miss Islington (bot) in branch '3.9':
bpo-42781: Document the mechanics of cached_property from a user viewpoint (GH-24031) (#24035)
https://github.com/python/cpython/commit/8333d421c0d7b90de3ff92002af9fd2c5d5f373c


----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42781>
_______________________________________

From report at bugs.python.org  Thu Dec 31 20:56:16 2020
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 01 Jan 2021 01:56:16 +0000
Subject: [issue42799] Please document fnmatch LRU cache size (256) and suggest
 alternatives
In-Reply-To: <1609452860.68.0.697253388073.issue42799@roundup.psfhosted.org>
Message-ID: <1609466176.99.0.483423539071.issue42799@roundup.psfhosted.org>


Raymond Hettinger <raymond.hettinger at gmail.com> added the comment:

In addition to documenting the cache size, consider a substantial increase to the limit.   Compiled regex patterns tend to be very small.  We can afford to have a lot of them (tens of thousands seems reasonable to me).

Regarding the suggested alternative, ISTM that calling translate() directly doesn't help much.  For a cache miss, the overhead of the lru_cache() is very small relative to the work done by translate().

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42799>
_______________________________________

From report at bugs.python.org  Thu Dec 31 21:14:09 2020
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 01 Jan 2021 02:14:09 +0000
Subject: [issue33944] Deprecate and remove code execution in pth files
In-Reply-To: <1529688140.44.0.56676864532.issue33944@psf.upfronthosting.co.za>
Message-ID: <1609467249.58.0.436336338187.issue33944@roundup.psfhosted.org>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

PEP 648 has been posted with a proposal to migrate sitecustomize.py, usersitecustomize.py and arbitrary code execution in pth files to a directory based `__sitecustomize__` structure: https://www.python.org/dev/peps/pep-0648/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue33944>
_______________________________________

From report at bugs.python.org  Thu Dec 31 21:36:59 2020
From: report at bugs.python.org (Alex Orange)
Date: Fri, 01 Jan 2021 02:36:59 +0000
Subject: [issue42752] multiprocessing Queue leaks a file descriptor associated
 with the pipe writer (#33081 still a problem)
In-Reply-To: <1609023821.09.0.189504509221.issue42752@roundup.psfhosted.org>
Message-ID: <1609468619.92.0.822679872473.issue42752@roundup.psfhosted.org>


Alex Orange <crazycasta at gmail.com> added the comment:

Well, having not heard anything I decided to just make a patch and throw it up. Here it is. This includes a test that will fail with the old version and passes once patched as well as the patch to the queue code itself.

Worth noting, the CleanExchange class is used because simpler things like using a closure to pass the exchange mechanism hold a reference to the Queue one way or another that is difficult/impossible to kill. This is because the intermediate thread mechanisms hold a reference to all the arguments that are passed to the run function. CleanExchange allows an indirect reference to be passed and for the reference to Queue to be None'd out.

----------
keywords: +patch
Added file: https://bugs.python.org/file49713/queue_close_write.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue42752>
_______________________________________